223015b filename-cleanup: dateien umbenannt + Makefile angepasst, build geht durch
git mv: - 01-grundlagen-text-audio.md → 01-datenfundamentale.md (kap 1 datenfundamentale + signal-zu-byte) - 02-bild-audio-video.md → 02-kompression.md (kap 2 kompression prinzipien) - 03-speichermedien-schnittstellen.md → 03-inhalte-bild-audio-video.md (kap 3 inhalte bild/audio/video) - 04-distribution-apis-zukunft.md → 04-speicher-schnittstellen.md (kap 4 speicher + schnittstellen) - 05-vertiefung-offene-fragen.md → 05-distribution-metadaten.md (kap 5 distribution + metadaten) Makefile 223015b_KAPITEL angepasst an neue dateinamen. build-223015b läuft sauber durch alle 5 neuen kapitel-html+pdf. stale html-files in build/ bleiben bis make clean (gitignored, kein commit-impact).
This commit is contained in:
@@ -0,0 +1,550 @@
|
||||
---
|
||||
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.
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: klausur -->
|
||||
|
||||
# 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.
|
||||
-->
|
||||
Reference in New Issue
Block a user