libretech
351e3dfc23
per user-request einen branch der main-content UND rewrite-content trägt — saubere separierung statt symlink/merge-conflict. struktur: - slides/<course>/ → main-content restored, eigene assets (kein new-demo-leak) - slides/<course>-2026/ → rewrite-content, eigene assets (komplett kopiert + new demos) Makefile: COURSES += 223015b-2026 223015c-2026 dhbw-2026 mit eigenen NAME/KAPITEL/DEPLOY/KLAUSUR-konfig. Klausur für b+c=1, dhbw=leer. Deploy-paths /hdm/223015b-2026 etc. make build durchlaufen für alle 6 decks, 0 fehler. dedup: 223015c+dhbw assets identisch in beiden ordnern (kein neu-demos auf b ergänzt). 223015b 86 → 120 files in -2026 (= +34 neue eroeffner/usb-c-drei-achsen/container-vs-codec/etc).
549 lines
20 KiB
Markdown
549 lines
20 KiB
Markdown
---
|
||
marp: true
|
||
theme: gaia
|
||
paginate: true
|
||
backgroundColor: #fff
|
||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
|
||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||
title: Kompression
|
||
---
|
||
|
||
<style>
|
||
:root {
|
||
--color-foreground: #1a1a2e;
|
||
--color-highlight: #1e5f8a;
|
||
--color-dimmed: #4a4a6a;
|
||
}
|
||
section.invert { --color-foreground: #fff; }
|
||
section { font-size: 1.7rem; }
|
||
h1 { color: #1e5f8a; }
|
||
section.invert h1 { color: #fff; }
|
||
h2 { color: #1f2937; }
|
||
pre {
|
||
background: #0f0f23;
|
||
color: #5fb3e4;
|
||
border-radius: 8px;
|
||
border-left: 3px solid #1e5f8a;
|
||
}
|
||
pre code { background: transparent; color: inherit; }
|
||
code {
|
||
background: #0f0f23;
|
||
padding: 0.15em 0.4em;
|
||
border-radius: 4px;
|
||
font-family: ui-monospace, "SF Mono", Menlo, Consolas, monospace;
|
||
}
|
||
section code:not(.hljs) { color: #5fb3e4 !important; }
|
||
section code.hljs { color: #f8f8f8 !important; }
|
||
a { color: var(--color-highlight); }
|
||
section.klausur {
|
||
background: repeating-linear-gradient(
|
||
135deg,
|
||
#e3f2fd,
|
||
#e3f2fd 40px,
|
||
#fff 40px,
|
||
#fff 80px
|
||
) !important;
|
||
}
|
||
@media print {
|
||
section.klausur { background: #e3f2fd !important; }
|
||
}
|
||
section.aufgabe { background: #e3f2fd !important; }
|
||
section.aufgabe footer { display: none; }
|
||
section.erklaerung :not(header),
|
||
section.erklaerung :not(footer) { font-size: 1.1rem; }
|
||
section.erklaerung h1 { font-size: 1.5rem; color: #1e5f8a; margin-bottom: 0.3rem; }
|
||
section.erklaerung ul, section.erklaerung ol { font-size: 1.0rem; line-height: 1.4; }
|
||
section.erklaerung p { font-size: 1.0rem; line-height: 1.4; }
|
||
section.erklaerung table { font-size: 0.9rem; }
|
||
</style>
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Kapitel 2
|
||
## Kompression — Prinzipien und Pipelines
|
||
|
||
<!--
|
||
Eine Stunde, eine Frage: *Wie machen wir Daten kleiner — und was darf dabei verloren gehen?*
|
||
|
||
Vorbereitung für Kapitel 3 (Inhalte: Bild/Audio/Video), wo wir die konkreten Pipelines durchgehen. Hier nur die zwei großen Prinzipien.
|
||
|
||
Anschluss an Kap 1: dort haben wir gesehen, wie groß unkomprimierte Audio-Daten werden (10 MB/Min für CD-Audio). Jetzt: wie kommt man auf 1 MB/Min und es klingt fast gleich?
|
||
|
||
Bogen: lossless (Redundanz raus) ↔ lossy (Irrelevanz raus).
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Daten sind unhandlich
|
||
|
||
<!--
|
||
WhatsApp-Foto vom Wochenende: 200 KB.
|
||
Dasselbe Bild aus der Kamera: 12 MB.
|
||
|
||
Spotify-Track: ~3 MB für 3 Minuten.
|
||
Derselbe Track als Studio-WAV: ~30 MB.
|
||
|
||
ZIP einer Code-Sammlung: 1/3 der Originalgröße.
|
||
|
||
In allen drei Fällen ist die Datei *kleiner*. Aber bei manchen ist Information *weg* — und bei anderen nicht. Was ist der Unterschied?
|
||
-->
|
||
|
||
---
|
||
|
||
# Foto-Größenschock
|
||
|
||
| Variante | Größe | Sichtbarer Unterschied? |
|
||
|----------|------:|------------------------|
|
||
| Original aus der iPhone-Kamera (HEIC) | 3,2 MB | — |
|
||
| Foto via WhatsApp geteilt | 230 KB | kaum |
|
||
| Instagram-Story (komprimiert) | 80 KB | minimal |
|
||
| WhatsApp-Profilbild (klein) | 12 KB | sichtbar |
|
||
|
||
**Faktor: bis zu 270×.** *Wo geht die Information hin?*
|
||
|
||
<!--
|
||
Diese Folie hängt das Konzept der Kompression an einem alltäglichen Beispiel auf.
|
||
|
||
- iPhone-Kamera: bereits H.265-komprimiert (HEIC) — aber als „Original" gehandelt.
|
||
- WhatsApp: komprimiert nochmal, plus Resolution-Reduktion. Faktor ~13x.
|
||
- Instagram-Story: noch aggressiver, optimiert für schnelles Laden.
|
||
- Profilbild: max. ~96×96 Pixel, hoher JPEG-Komp-Faktor.
|
||
|
||
Pointe: alle vier sind „dasselbe Bild" — aber jede Stufe wirft *etwas* weg. Was genau? Und wer entscheidet, was weggeworfen wird? Antwort kommt mit dem Konzept lossy vs lossless.
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
Das gleiche Phänomen in der Audio-Welt:
|
||
- FLAC (lossless): 5,3 MB, jede Frequenz erhalten
|
||
- MP3 (lossy, 128 kbit/s): 480 KB, hohe Frequenzen weggeworfen, Transienten geglättet
|
||
|
||
Wellenform-Vergleich macht es konkret:
|
||
- Links (grün): detaillierte FLAC-Wellenform mit allen Spikes
|
||
- Rechts (rot): MP3-Wellenform glatter, Detail-Information fehlt
|
||
|
||
Pointe für die Studis: auf dem Smartphone-Lautsprecher hört man den Unterschied meist nicht. Im Studio-Monitor mit Kopfhörer schon. MP3 wirft 91 % der Daten weg, die der Mensch im Alltag nicht vermisst.
|
||
|
||
→ Das ist „Lossy". Das Gegenteil ist „Lossless" (FLAC, ZIP).
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Erster Weg: Verlustfrei (Lossless)
|
||
|
||
<!--
|
||
Prinzip: Redundanz raus, Information unverändert.
|
||
|
||
Beispiele:
|
||
- ZIP-Archiv: gleiche Datei nach Entpacken
|
||
- PNG-Bild: identisch zum Original
|
||
- FLAC-Audio: identisch zur ursprünglichen Wellenform
|
||
- TIFF, RAW (Camera-RAW): Foto im Rohformat
|
||
|
||
Trick: Wiederholungen, Muster, häufige Sequenzen werden kürzer geschrieben.
|
||
-->
|
||
|
||
---
|
||
|
||
# Prinzip: Redundanz raus
|
||
|
||
Der Datenstrom enthält oft **Wiederholungen** — gleiche Pixel, gleiche Buchstaben, gleiche Frequenz-Häppchen.
|
||
|
||
Lossless-Kompression **erkennt** diese Redundanz und schreibt sie als **Verweis** kürzer.
|
||
|
||
**Umkehrbar:** beim Dekomprimieren wird die exakte Original-Datei wiederhergestellt.
|
||
|
||
<!--
|
||
- Lossless ist ein Match-und-Verweise-Spiel.
|
||
- Gegeben: 'AAAAAAAA' → kürzer als '8×A'.
|
||
- Gegeben: ein Bild mit großem weißen Bereich → kürzer als 'Pixel 1-10000 sind weiß'.
|
||
- Gegeben: ein Text mit häufigen Wörtern → 'der die das' bekommt kurze Codes (Huffman).
|
||
|
||
Wichtig zu verstehen: keine Information geht verloren. Aus der komprimierten Datei lässt sich das Original *bit-genau* wieder herstellen.
|
||
-->
|
||
|
||
---
|
||
|
||
# RLE — Run-Length-Encoding
|
||
|
||
**Eine Bilderzeile in Schwarz/Weiß:**
|
||
|
||
```
|
||
Original: AAAAA BBB CCCCCCCC AAAAAA
|
||
(5×A, 3×B, 8×C, 6×A)
|
||
|
||
Kodiert: 5A 3B 8C 6A
|
||
```
|
||
|
||
**22 Zeichen → 8 Zeichen.** Faktor: 2,75×.
|
||
|
||
Verlustfrei, weil ich aus `5A 3B 8C 6A` exakt `AAAAABBBCCCCCCCCAAAAAA` zurückbekomme.
|
||
|
||
<!--
|
||
RLE = einfachster Lossless-Algorithmus, gut zum Verstehen des Prinzips am Whiteboard.
|
||
|
||
- Wirkt bei: Schwarz/Weiß-Bildern, Schwarz-auf-Weiß-Text, Faxnachrichten.
|
||
- Wirkt NICHT bei: zufälligen Daten, schon-komprimierten Dateien (kein Muster zum Komprimieren).
|
||
- TIFF und BMP nutzen optional RLE. Faxgeräte nutzen es exzessiv.
|
||
|
||
In der Praxis: moderne Lossless-Algorithmen wie Deflate (ZIP/PNG/gzip) und LZ77 sind viel cleverer als RLE — sie finden auch Wiederholungen auf weite Distanz im Datenstrom. Aber RLE zeigt das Prinzip in seiner einfachsten Form.
|
||
-->
|
||
|
||
---
|
||
|
||
# Wo wird Lossless verwendet?
|
||
|
||
| Anwendung | Format | Warum verlustfrei? |
|
||
|-----------|--------|---------------------|
|
||
| Code-Repository, Backup | **ZIP**, **gzip**, **tar.gz** | Jedes Bit muss exakt zurück. |
|
||
| Foto-Archiv (RAW) | **PNG**, **TIFF**, **RAW** | Nachbearbeitung soll alle Detail haben. |
|
||
| Studio-Master-Track | **FLAC**, **WAV** | Für Mastering muss Originalqualität da sein. |
|
||
| Logo-Grafiken | **PNG**, **SVG** | Scharfe Kanten brauchen Pixelgenauigkeit. |
|
||
|
||
**Faustregel:** Werkzeug → Lossless.
|
||
|
||
<!--
|
||
Anschluss: wenn das Werkzeug ist, mit dem ich weiterarbeite (Foto bearbeiten, Code lesen, Audio mastern), brauche ich die Original-Daten. Lossless garantiert das.
|
||
|
||
PNG vs. JPEG-Konflikt: viele Studis erleben das beim Web-Hochladen. Logo als JPEG → unscharfe Ränder, weil JPEG für Fotos optimiert ist (große Farbflächen kosten wenig, Kanten erzeugen Artefakte). Logo als PNG → scharfe Ränder, weil PNG verlustfrei ist.
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
# Original vs. Fälschung
|
||
|
||
Eine **echte Louis-Vuitton-Tasche** und ein perfekter Fake — auf einem Foto unterscheidbar?
|
||
|
||
Eine **lossless-komprimierte Datei** vs. das Original — bit-genau identisch.
|
||
|
||
**Bei Lossless gibt es keine Fälschung.** Die Kopie ist mathematisch das Original.
|
||
|
||
<!--
|
||
Diese Analogie hat letztes Mal Verwirrung gestiftet (Original-Bag vs Fake). Der Punkt ist:
|
||
|
||
Bei echten Gegenständen (Tasche, Gemälde, Vinyl-Schallplatte) gibt es ein „echtes Original". Eine Fälschung sieht nur ähnlich aus, ist aber nicht das Original.
|
||
|
||
Bei digitalen Daten ist eine lossless-Kopie *exakt* gleich. Es gibt keinen Begriff von „Original" und „Kopie" — beide sind nur Folgen von Byte, und wenn diese Folgen Byte-für-Byte gleich sind, sind sie ununterscheidbar.
|
||
|
||
Das ist die digitale Kopier-Revolution. Vinyl → Kassette → Kassette = Generationsverlust. CD → Festplatte → USB-Stick = identisch.
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Zweiter Weg: Verlustbehaftet (Lossy)
|
||
|
||
<!--
|
||
Prinzip: Irrelevanz raus. Nicht „weniger Wiederholung", sondern „Information, die der Mensch sowieso nicht wahrnimmt, wird gar nicht erst gespeichert".
|
||
|
||
Beispiele:
|
||
- MP3, AAC, OPUS (Audio)
|
||
- JPEG, WebP (Bild)
|
||
- H.264, H.265, AV1 (Video)
|
||
|
||
Trick: Wahrnehmungsforschung — Psychoakustik (was hört der Mensch nicht?) und Psychovisualität (was sieht der Mensch nicht?).
|
||
-->
|
||
|
||
---
|
||
|
||
# Prinzip: Irrelevanz raus
|
||
|
||
Was der Mensch **nicht wahrnehmen** kann, muss man **nicht speichern**.
|
||
|
||
**Lossy-Kompression** wirft genau diese Information weg.
|
||
|
||
**Nicht umkehrbar.** Was weg ist, kommt nie zurück. Aus einem MP3 wird nie wieder ein FLAC.
|
||
|
||
<!--
|
||
Lossy hat einen anderen Charakter als Lossless:
|
||
- Lossless: schaut auf die Daten („wo wiederholt sich was?")
|
||
- Lossy: schaut auf den Empfänger („was nimmt er nicht wahr?")
|
||
|
||
Daraus folgt: Lossy braucht ein Modell vom Empfänger. Genau das liefert die Psychoakustik (Audio) und Psychovisualität (Bild).
|
||
|
||
Konsequenz: aus einem 128-kbit/s-MP3 lässt sich keine CD-Qualität wieder herstellen. Die Daten sind weg. Wenn jemand „Studio-Master 320 kbit/s" sagt: das war nie Studio-Master, das ist MP3 mit höherer Bitrate — die hohen Frequenzen sind trotzdem weg.
|
||
-->
|
||
|
||
---
|
||
|
||
# Was nimmt der Mensch nicht wahr?
|
||
|
||
**Ohr (Audio):**
|
||
- Töne unter ~20 Hz oder über ~20 kHz
|
||
- Leise Töne in der Nähe lauter Töne (Maskierung)
|
||
- Räumlich-zeitliche Maskierung (z.B. ~200 ms nach lautem Knall)
|
||
|
||
**Auge (Bild):**
|
||
- Feine Farb-Detail (Chrominanz) abseits scharfer Helligkeitskanten
|
||
- Kleinste Helligkeits-Differenzen (~1 Stufe in 256 ist unsichtbar)
|
||
- Sehr feine Strukturen jenseits der Sehauflösung
|
||
|
||
Lossy-Algorithmen modellieren diese Wahrnehmungs-Grenzen — und werfen alles davor weg.
|
||
|
||
<!--
|
||
Diese Folie zählt die Beschränkungen unserer Wahrnehmung auf — daraus ergibt sich, was Lossy weglassen darf.
|
||
|
||
Ohr-Phänomene werden in der Psychoakustik formalisiert. Die zwei wichtigsten:
|
||
1. Frequenzmaskierung: lauter 1-kHz-Ton überdeckt benachbarte leise Töne bei 1,1 kHz.
|
||
2. Zeitliche Maskierung: nach einem lauten Knall hört man ~200 ms keine leisen Geräusche.
|
||
|
||
Auge-Phänomene werden in der Psychovisualität formalisiert:
|
||
1. Luminanz vor Chrominanz: Helligkeitsdetail ist scharf wichtig, Farbdetail darf grob sein.
|
||
2. Kontrast-Empfindlichkeit: bei mittlerer Helligkeit sehen wir feiner als ganz hell oder ganz dunkel.
|
||
|
||
Die nächsten beiden Folien visualisieren diese Konzepte.
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
Visualisierung der Maskierung:
|
||
- Hörschwelle (orange gestrichelt): die untere Grenze unseres Hörens, je nach Frequenz unterschiedlich. Am empfindlichsten bei 1–4 kHz, weniger bei sehr tiefen und sehr hohen Frequenzen.
|
||
- Lauter Ton bei 1 kHz, 90 dB („Masker"): macht die umliegenden Frequenzen unhörbar.
|
||
- Maskierungs-Bereich (blau): in diesem Bereich werden Töne, die unter der gestrichelten Kurve liegen, durch den Masker überdeckt.
|
||
- Grüne Punkte: hörbar, müssen kodiert werden.
|
||
- Graue Punkte: nicht hörbar trotz „Vorhandenseins" → werden weggeworfen.
|
||
|
||
MP3-Pipeline:
|
||
1. FFT — Audio in Frequenzen zerlegen
|
||
2. Psychoakustisches Modell anwenden — berechne Maskierungsschwellen
|
||
3. Quantisierung — alles unter Maskierungsschwelle wegwerfen
|
||
4. Huffman-Coding — Rest verlustfrei komprimieren
|
||
|
||
Pointe: das alles passiert ohne dass der Mensch im normalen Hören etwas vermisst. ~90 % der Daten weg.
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
Visualisierung Luminanz vs Chrominanz:
|
||
- Links: 4:4:4 — jedes Pixel speichert Helligkeit (Y) + zwei Farb-Komponenten (Cb blau-differenz, Cr rot-differenz) in voller Auflösung.
|
||
- Rechts: 4:2:0 — Y bleibt voll, Cb und Cr werden auf 1/4 reduziert (2×2 Pixel teilen sich einen Farbwert).
|
||
- Beide Bilder sehen für das Auge identisch aus. Datenmenge halbiert.
|
||
|
||
JPEG, H.264, H.265, WebP, AVIF nutzen alle 4:2:0-Subsampling als Standard.
|
||
|
||
Anekdote: Würde man stattdessen die Luminanz halbieren (Y reduziert, Cb/Cr voll), würde das Bild sofort unscharf aussehen. Das Auge ist scharf für Helligkeitskanten — daher kein Spielraum dort.
|
||
-->
|
||
|
||
---
|
||
|
||
# Wo wird Lossy verwendet?
|
||
|
||
| Anwendung | Format | Reduktion |
|
||
|-----------|--------|-----------|
|
||
| Musikstream (Spotify) | **MP3**, **AAC**, **OGG** | 10× |
|
||
| Foto im Netz (Instagram) | **JPEG**, **WebP** | 10–30× |
|
||
| Video (YouTube, Netflix) | **H.264**, **H.265**, **AV1** | 100–200× |
|
||
| Sprachanruf (WhatsApp Call) | **OPUS**, **AMR** | 50× |
|
||
|
||
**Faustregel:** Konsum → Lossy.
|
||
|
||
<!--
|
||
Wenn du etwas nur „konsumieren" (anschauen, anhören) willst — und nicht weiter bearbeiten — ist Lossy die richtige Wahl. Du sparst Speicher und Bandbreite, ohne dass der Konsum darunter leidet.
|
||
|
||
Sobald du bearbeiten, mastern, archivieren willst → Lossless.
|
||
-->
|
||
|
||
---
|
||
|
||
# Vergleich: Lossless vs. Lossy
|
||
|
||
| Eigenschaft | Verlustfrei (Lossless) | Verlustbehaftet (Lossy) |
|
||
|-------------|------------------------|--------------------------|
|
||
| Was passiert? | Redundanz raus | Irrelevanz raus |
|
||
| Umkehrbar? | Ja, bit-genau | Nein, nie wieder |
|
||
| Trick | Wiederholungen kürzer kodieren | Wahrnehmung modellieren |
|
||
| Typischer Faktor | 2× – 5× | 10× – 100× |
|
||
| Anwendung | Archiv, Werkzeug, Code | Stream, Anzeige, Konsum |
|
||
| Beispiele | ZIP · PNG · FLAC · RAW | MP3 · JPEG · H.264 · WebP |
|
||
|
||
<!--
|
||
Klausurfähig: gegeben ein Anwendungsfall — soll Lossless oder Lossy verwendet werden? Mit Begründung.
|
||
|
||
Beispiele für Klausurfragen:
|
||
- 4K-Stream auf Netflix → Lossy (H.265 oder AV1)
|
||
- RAW-Datei aus der DSLR archivieren → Lossless (RAW selbst, ggf. ZIP)
|
||
- Lecture-Capture-Aufzeichnung für Wiederverwendung → Lossless besser, aber Datenrate hoch
|
||
- Logo-Datei für Print + Web → SVG (vektorgraphisch) oder PNG (lossless raster)
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
Klassisches Bild aus Wikipedia: dieselbe Katze mit fortschreitender JPEG-Kompression.
|
||
|
||
- Ganz links: kaum komprimiert, hohe Qualität
|
||
- Schritt für Schritt: mehr Artefakte, weniger Detail, Quantisierungs-Blöcke werden sichtbar
|
||
- Ganz rechts: extreme Kompression, sichtbare 8×8-Pixel-Blöcke (DCT-Blöcke)
|
||
|
||
Die JPEG-Pipeline funktioniert in 8×8-Blöcken. Bei niedriger Qualität werden hohe Frequenzen innerhalb dieser Blöcke aggressiv quantisiert → die Blöcke werden sichtbar.
|
||
|
||
Studis erkennen das aus dem Alltag:
|
||
- Mehrfach geforwardete WhatsApp-Bilder → JPEG-Generation-Loss
|
||
- Screenshots in Office → manchmal als JPEG gespeichert → Schrift wird unscharf
|
||
-->
|
||
|
||
---
|
||
|
||
# Kompressionsraten in der Praxis
|
||
|
||
| Inhalt | Roh | Komprimiert | Faktor |
|
||
|--------|----:|------------:|-------:|
|
||
| Foto (12 MP) | 36 MB RAW | 3,5 MB JPEG | ~10× |
|
||
| Audio (30 s Stereo) | 5,3 MB WAV | 480 KB MP3 | ~11× |
|
||
| Video (1 Min 4K) | 24 GB roh | 200 MB H.264 | ~120× |
|
||
| Code-Repo (Java) | 15 MB Quellcode | 1,5 MB ZIP | ~10× |
|
||
| Foto (Logo PNG) | 800 KB unkomp. | 80 KB PNG | ~10× |
|
||
|
||
Lossy bringt mehr — *aber Werkzeug muss roh bleiben.*
|
||
|
||
<!--
|
||
Diese Folie liefert Größenordnungen für die häufigsten Kompressions-Szenarien. Studis sollen ein Bauchgefühl bekommen:
|
||
|
||
- Foto: roh ist 10× größer als JPEG
|
||
- Audio: roh ist 10× größer als MP3
|
||
- Video: roh ist 100× größer als H.264. Das ist der Grund, warum Streaming überhaupt funktioniert.
|
||
- Code: ZIP komprimiert um 10× weil viele Wiederholungen (Imports, Whitespace, Standard-Bibliothek-Aufrufe).
|
||
|
||
In Kap 3 schauen wir uns die Pipelines an: WIE machen JPEG/MP3/H.264 das?
|
||
-->
|
||
|
||
---
|
||
|
||
# Entscheidungsmatrix — wann nehme ich was?
|
||
|
||
| Szenario | Empfehlung | Begründung |
|
||
|----------|------------|------------|
|
||
| Foto-Archiv (DSLR) | **RAW** (lossless) | Nachbearbeitung muss alle Detail haben |
|
||
| Foto im Web/Insta | **JPEG / WebP** (lossy) | Konsum, Bandbreite zählt |
|
||
| Studio-Master | **FLAC / WAV** (lossless) | Master soll bit-genau bleiben |
|
||
| Spotify-Track | **AAC / MP3** (lossy) | Konsum, Smartphone-Lautsprecher |
|
||
| Code-Backup | **ZIP / tar.gz** (lossless) | Code muss exakt zurück |
|
||
| Lecture-Video | **H.264** (lossy) | Konsum, Streaming |
|
||
| Logo | **PNG / SVG** (lossless) | Scharfe Kanten brauchen Pixelgenauigkeit |
|
||
|
||
<!--
|
||
Diese Matrix ist die zentrale Entscheidungshilfe. Vermitteln über Beispiele aus dem Studi-Alltag (Insta-Post, Spotify-Premium, GitHub-Repo, Vorlesungs-Aufnahme).
|
||
|
||
Pädagogisches Ziel: am Ende des Kapitels haben Studis ein Bauchgefühl, wann welche Kompression sinnvoll ist. Nicht „auswendig", sondern „begründen können".
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: aufgabe -->
|
||
|
||
# Selbstlernen — ZIP-Test mit drei Dateitypen
|
||
|
||
Drei Dateien gleicher Originalgröße (~1 MB) zippen:
|
||
|
||
1. **Textdatei mit wiederholten Mustern** (z.B. ein Buch als TXT)
|
||
2. **Unkomprimiertes Bitmap (BMP)** desselben Fotos
|
||
3. **JPEG** desselben Fotos
|
||
|
||
**Vergleich:** Wie groß ist die ZIP-Datei in jedem Fall?
|
||
|
||
**Erwartung:** Textdatei wird klein (Wiederholungen), BMP wird klein (Farbflächen), JPEG bleibt fast gleich (schon komprimiert, keine Redundanz mehr).
|
||
|
||
<!--
|
||
Diese Übung liefert die zentrale Aha-Erkenntnis ohne Mathematik:
|
||
|
||
**Schon-komprimierte Dateien lassen sich nicht weiter komprimieren.**
|
||
|
||
Warum? Weil Kompression die Redundanz herausnimmt. Eine bereits komprimierte Datei *hat keine Redundanz mehr*. Das wäre ein Verstoß gegen die Entropie-Grenze (Shannon), aber das brauchen die Studis nicht zu rechnen.
|
||
|
||
Erkenntnis: wer schon JPEG/MP3/H.264-Dateien hat, kann sie nicht „nochmal komprimieren". Wer Backup-ZIP über JPEG-Fotos macht: spart fast nichts.
|
||
|
||
~10 Min Selbstlernen. Ideal für ein Pärchen oder als Hausaufgabe.
|
||
-->
|
||
|
||
---
|
||
|
||
# Warum ZIP auf JPEG nicht mehr komprimiert
|
||
|
||
**JPEG ist bereits maximal lossless-komprimiert.**
|
||
|
||
Die JPEG-Pipeline endet mit **Huffman-Coding** — derselbe Trick wie in ZIP.
|
||
|
||
Was ZIP machen würde (Wiederholungen finden, Häufigkeiten kürzer kodieren), hat JPEG schon getan.
|
||
|
||
**Resultat:** ZIP einer JPEG-Datei ist nur ~1 % kleiner. *Manchmal sogar größer* (durch ZIP-Header-Overhead).
|
||
|
||
<!--
|
||
Pädagogisches Ziel: Studis verstehen, warum „Doppel-Kompression" nichts bringt.
|
||
|
||
Konkret:
|
||
- JPEG-Pipeline = lossy + Huffman (lossless)
|
||
- MP3-Pipeline = lossy + Huffman (lossless)
|
||
- H.264-Pipeline = lossy + CABAC/Huffman (lossless)
|
||
|
||
In allen Fällen endet die Pipeline mit einem optimal-lossless-Schritt. Ein zusätzliches ZIP findet keine Wiederholungen mehr.
|
||
|
||
Folgerung: für gemischte Backups ist ZIP trotzdem nützlich — schon-komprimierte Dateien bleiben gleich, unkomprimierte werden kleiner. „Du verlierst nichts."
|
||
|
||
Übergang zu Kap 3: jetzt schauen wir uns die konkreten Lossy-Pipelines an. Wie genau funktioniert JPEG? Was passiert in MP3? Wie komprimiert H.264 Video?
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
Zusammenfassung:
|
||
|
||
Zwei Wege, ein Ziel: Daten kleiner machen.
|
||
|
||
Verlustfrei (Lossless):
|
||
- Was: Redundanz raus
|
||
- Umkehrbar: ja
|
||
- Verfahren: RLE, Huffman, Deflate
|
||
- Formate: ZIP, PNG, FLAC, RAW
|
||
- Faktor: 2× – 5×
|
||
|
||
Verlustbehaftet (Lossy):
|
||
- Was: Irrelevanz raus
|
||
- Umkehrbar: nein
|
||
- Trick: Psychoakustik (Audio) / Psychovisualität (Bild)
|
||
- Formate: MP3, JPEG, H.264, WebP
|
||
- Faktor: 10× – 100×
|
||
|
||
Entscheidungsmatrix:
|
||
- Archiv/Code → Lossless
|
||
- Stream/Anzeige → Lossy
|
||
|
||
Faustregel: Werkzeug = Lossless. Konsum = Lossy.
|
||
|
||
In Kap 3 schauen wir uns die Pipelines konkret an (JPEG, MP3, H.264) — also wie ein Lossy-Algorithmus überhaupt entscheidet, was wegzuwerfen ist.
|
||
-->
|