diff --git a/slides/223015b/02-bild-audio-video.md b/slides/223015b/02-bild-audio-video.md index 97d7d09..87e4532 100644 --- a/slides/223015b/02-bild-audio-video.md +++ b/slides/223015b/02-bild-audio-video.md @@ -5,7 +5,7 @@ paginate: true backgroundColor: #fff header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)" footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026" -title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege +title: Kompression --- - - - + -![bg cover opacity:0.2](./assets/radek-grzybowski-eBRTYyjwpRY-unsplash.jpg) - -# Dateiformate, Schnittstellen, Speichermedien & Distributionswege - -**223015b** · Modul "Technik 1" · 1. Semester -Digital- und Medienwirtschaft -Hochschule der Medien Stuttgart - -[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/) +# 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? -![bg fit](./assets/qr/slides-223015b.png) - - --- -# Teil 2: Bild- & Videoformate +# Daten sind unhandlich --- -# Warum verschiedene Dateiformate? +# Foto-Größenschock -**Ein Dateiformat definiert:** -- Ob und wie Daten komprimiert werden -- Welche Metadaten enthalten sind -- Wie Daten *codiert* und *decodiert* werden (*Co·dec*) +| 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 | -| Ziel | Bild | Audio | Dokument | -|------|------|-------|----------| -| Kleine Dateien | JPEG | MP3 | — | -| Perfekte Qualität | PNG, RAW | FLAC | PDF | -| Animation/Video | GIF | — | — | -| Skalierbarkeit | SVG | — | PDF | +**Faktor: bis zu 270×.** *Wo geht die Information hin?* --- @@ -167,789 +119,278 @@ Hochschule der Medien Stuttgart -![bg](./assets/photo-comparison.png) +![bg fit](./assets/demos/kap02-eroeffner.png) --- -# Digitale Bilder -## Raster- und Vektorgrafiken +# Erster Weg: Verlustfrei (Lossless) --- -# Was ist ein digitales Bild? +# Prinzip: Redundanz raus -Ein digitales Bild ist ein Raster aus Farbpunkten (Pixel). -Jeder Pixel speichert einen RGB-Farbwert (3 Bytes). +Der Datenstrom enthält oft **Wiederholungen** — gleiche Pixel, gleiche Buchstaben, gleiche Frequenz-Häppchen. -**Beispiel: Full HD (1920×1080)** -= 2.073.600 Pixel × 3 Bytes = **6,2 MB** +Lossless-Kompression **erkennt** diese Redundanz und schreibt sie als **Verweis** kürzer. + +**Umkehrbar:** beim Dekomprimieren wird die exakte Original-Datei wiederhergestellt. --- - - - - +# RLE — Run-Length-Encoding -# Rastergrafiken - -**Aufbau:** Liste von Pixeln mit Farbwerten (2D-Array) - -**Speicherbedarf (unkomprimiert):** -Breite × Höhe × Farbtiefe (in Bytes) - -**Beispiele:** JPEG, PNG, WebP - -| Bits (Farbtiefe) | Farben | Anwendung | -|-----:|-------:|-----------| -| 1 | 2 | Schwarz/Weiß (Fax) | -| 8 | 256 | Graustufen, GIF | -| 24 | 16,7 Mio. | True Color (Standard) | -| 32 | 16,7 Mio. + Alpha | Transparenz | - - - ---- - - - - - -# Rastergrafik – Vertiefung - -Ein Pixel ist die kleinste adressierbare Einheit. Bei 24-Bit-Farbtiefe speichert jeder Pixel drei 8-Bit-Werte (0–255) für Rot, Grün und Blau. Diese additive Farbmischung erzeugt 256³ = 16,7 Millionen mögliche Farbtöne. - -**Speicherberechnung:** `Breite × Höhe × Bytes pro Pixel` - -| Auflösung | Farbtiefe | Berechnung | Größe | -|-----------|-----------|------------|-------| -| 1920×1080 | 24 Bit (3 B) | 2.073.600 × 3 | 6,2 MB | -| 4K (3840×2160) | 24 Bit | 8.294.400 × 3 | 24,9 MB | -| 4K | 32 Bit (4 B) | 8.294.400 × 4 | 33,2 MB | - -Der Alpha-Kanal (32 Bit) speichert Transparenz als Wert von 0 (unsichtbar) bis 255 (vollständig sichtbar). PNG nutzt dies für weiche Kanten; JPEG unterstützt keinen Alpha-Kanal. - ---- - -# Das Problem der Skalierung - -**Vergrößern:** -Fehlende Pixel müssen erfunden werden (Interpolation) - -**Verkleinern:** -Pixel müssen zusammengefasst werden - -**Interpolationsverfahren:** -- Nearest Neighbor: Schnell, pixelig -- Bilinear: Glättet, Standardverfahren -- Bicubic: Hohe Qualität, rechenintensiv -- Lanczos: Beste Qualität, mathematisch komplex - - - ---- - - - - - - -# Vektorgrafiken - -**Speicherung als geometrische Primitive:** -- Pfade (Bézierkurven mit Kontrollpunkten) -- Grundformen (Rechteck, Ellipse, Polygon) -- Text (Glyphen als Outlines) - -**SVG-Beispiel:** -```xml - -``` - -SVG beschreibt WAS gezeichnet werden soll, nicht WIE jeder Pixel aussieht. - - - ---- - - - - - -# Vektorgrafik – Vertiefung - -Vektorgrafiken speichern keine Pixel, sondern mathematische Beschreibungen: Koordinaten, Kurvenparameter (Bézier-Kontrollpunkte), Füllfarben, Strichstärken. Der Renderer berechnet die Pixel erst bei der Ausgabe – daher beliebig skalierbar. - -**Bézier-Kurven** (Pierre Bézier, 1962, für Renault-Karosserien entwickelt): -- Definiert durch Ankerpunkte und Kontrollpunkte -- Kubische Bézier: 2 Anker + 2 Kontrollpunkte -- Mathematisch exakt reproduzierbar - -| Aspekt | Raster | Vektor | -|--------|--------|--------| -| Skalierung 10× | Pixel sichtbar | Perfekt scharf | -| Foto-Realismus | Gut geeignet | Unpraktikabel | -| Dateigröße Logo | Wächst mit Auflösung | Konstant (~5 KB) | -| Editierbarkeit | Destruktiv | Nicht-destruktiv | - -**Rasterisierung:** GPU wandelt Vektordaten in Pixel um. Geschieht bei jeder Darstellung neu – deshalb ist ein 4K-Monitor schärfer als ein 1080p-Monitor bei gleichem SVG. - ---- - -# Raster- und Vektorgrafiken - -| | Raster | Vektor | -|---|---|---| -| **Optimal für** | Fotos, komplexe Bilder | Logos, Icons, Illustrationen | -| **Skalierung** | Qualitätsverlust | Verlustfrei | -| **Dateigröße** | Abhängig von Auflösung | Abhängig von Komplexität | -| **Formate** | JPEG, PNG, WebP | SVG, PDF, AI | -| **Bearbeitung** | Pixel-basiert | Objekt-basiert | - - - ---- - - - -# Menschliche Wahrnehmung -## Psychovisuelle Kompression - - - ---- - - - - - - -# Die Schwächen des Auges - -**Menschen sehen:** -* Helligkeit besser als Farbe -* Große Flächen besser als feine Details -* Niedrige Frequenzen besser als hohe - -**JPEG nutzt das aus:** -* Farbauflösung reduzieren (Helligkeit behalten) -* Glatte Flächen effizient speichern -* Hohe Frequenzen (feine Details) verwerfen - - - ---- - - - - - -# Psychovisuelle Wahrnehmung – Vertiefung - -Die Netzhaut enthält ~120 Mio. Stäbchen (Helligkeitswahrnehmung) aber nur ~6 Mio. Zapfen (Farbwahrnehmung). Dieses 20:1-Verhältnis erklärt, warum JPEG Farbinformationen stärker reduzieren kann als Helligkeitsinformationen. - -**Räumliche Frequenz** beschreibt, wie schnell sich die Helligkeit über eine Bildfläche ändert: -- **Niedrig:** Himmel, Wand – große einheitliche Flächen -- **Hoch:** Haare, Texturen, Schrift – schnelle Wechsel - -Das Auge ist ein Tiefpassfilter: Hohe Frequenzen (feine Details) werden schwächer wahrgenommen. JPEG verwirft daher zuerst die hohen Frequenzen – der Qualitätsverlust bleibt meist unsichtbar. - -| Biologisches Limit | Ausnutzung in JPEG | -|-------------------|-------------------| -| Farbauflösung ~20× geringer | Chroma Subsampling (4:2:0) | -| Hohe Frequenzen unscharf | DCT + Quantisierung | -| Kontrast-Maskierung | Artefakte in Texturen versteckt | - ---- - - - - -![bg contain 50%](./assets/Felis_silvestris_silvestris_small_gradual_decrease_of_quality_-_JPEG_compression.jpg) - - - ---- - -![bg contain right:34%](./assets/Posterization_example.jpg) - -# Grenzen der Kompression: JPEG-Artefakte - -**Bei starker Kompression sichtbar:** - -* **Posterization:** - Farbverläufe werden stufig - -* **Blocking:** - 8×8-Blöcke werden sichtbar - -* **Ringing:** - "Geister" an scharfen Kanten - - - ---- - -# JPEG-Qualität in der Praxis - -| Quality | Typische Größe (12 MP) | Artefakte | -|--------:|----------------------:|-----------| -| 100 | 2–3 MB | Minimal | -| 85–90 | 200–400 KB | Kaum sichtbar | -| 60 | ~100 KB | Bei genauem Hinsehen | -| 30 | ~50 KB | Deutlich sichtbar | - -**Sweet Spot: 85–90** -~10× Kompression, für Menschen kaum unterscheidbar - - - ---- - - - -# JPEG-Kompression -## Sechs Schritte im Detail - - - ---- - - - - - - -![bg right:20%](./assets/Barn-yuv.png) - -# JPEG Schritt 1: Farbraumkonversion - -**RGB → Y'CbCr** - -- **Y** = Helligkeit (Luminanz) -- **Cb** = Blau-Gelb-Anteil (Chrominanz) -- **Cr** = Rot-Grün-Anteil (Chrominanz) - -**Warum?** -Y (Helligkeit) behält volle Auflösung -Cb/Cr (Farbe) kann reduziert werden - - - ---- - - - - - -# Farbraumkonversion – Vertiefung - -RGB→YCbCr nutzt die Biologie des menschlichen Auges: 120 Mio. Stäbchen (Helligkeit) vs. nur 6 Mio. Zapfen (Farbe) – ein 20:1-Verhältnis. Die Transformation erfolgt über eine lineare Matrix: +**Eine Bilderzeile in Schwarz/Weiß:** ``` -Y = 0.299·R + 0.587·G + 0.114·B -Cb = −0.169·R − 0.331·G + 0.500·B + 128 -Cr = 0.500·R − 0.419·G − 0.081·B + 128 +Original: AAAAA BBB CCCCCCCC AAAAAA + (5×A, 3×B, 8×C, 6×A) + +Kodiert: 5A 3B 8C 6A ``` -Die Gewichtung (G dominiert mit 59%) entspricht der spektralen Empfindlichkeit des Auges bei Tageslicht. Y enthält alle Schärfeinformation; Cb/Cr können reduziert werden. +**22 Zeichen → 8 Zeichen.** Faktor: 2,75×. -**Chroma Subsampling – Notation J:a:b** (bezogen auf 4×2 Pixel): - -| Schema | Farbdaten | Einsatz | -|--------|-----------|---------| -| 4:4:4 | 100% | Postproduktion, Grafik | -| 4:2:2 | 50% | Broadcast, Pro-Video | -| 4:2:0 | 25% | JPEG, H.264, Streaming | - -Bei 4:2:0 teilen sich 4 Pixel einen Farbwert, behalten aber individuelle Helligkeit → 50% Dateneinsparung bei kaum sichtbarem Unterschied. - ---- - -# JPEG Schritt 2: Chroma Subsampling - -**Notation `J:a:b`** (bezogen auf 4×2 Pixel-Block): -- **J** = Referenzbreite (immer 4) -- **a** = Farbsamples in Zeile 1 -- **b** = Farbsamples in Zeile 2 - -| Schema | Bedeutung | Farbdaten | -|--------|-----------|-----------| -| 4:4:4 | Volle Farbauflösung | 100% | -| 4:2:2 | Halbe horizontale Auflösung | 50% | -| 4:2:0 | Viertel Auflösung (2×2 teilt Farbe) | 25% | - -**4:2:0 ist JPEG-Standard** +Verlustfrei, weil ich aus `5A 3B 8C 6A` exakt `AAAAABBBCCCCCCCCAAAAAA` zurückbekomme. --- - - +# Wo wird Lossless verwendet? -![bg contain 70%](./assets/Common_chroma_subsampling_ratios_YCbCr_CORRECTED.svg.png) +| 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. --- -# JPEG Schritt 3: Block-Aufteilung +![bg right:40% contain](./assets/lv-original-vs-fake.jpg) -**Das Bild wird in 8×8-Pixel-Blöcke zerlegt** +# Original vs. Fälschung -Jeder Block wird unabhängig verarbeitet. -Bei 1920×1080: 240 × 135 = **32.400 Blöcke** +Eine **echte Louis-Vuitton-Tasche** und ein perfekter Fake — auf einem Foto unterscheidbar? -**Level Shift:** -Pixelwerte um −128 verschieben -- Vorher: 0 bis 255 -- Nachher: −128 bis +127 +Eine **lossless-komprimierte Datei** vs. das Original — bit-genau identisch. -**Warum?** -DCT arbeitet besser mit Werten um Null +**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. -# JPEG Schritt 4: DCT (Discrete Cosine Transform) +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. -**Jeder 8×8-Block wird transformiert:** -64 Pixelwerte → 64 Frequenzkoeffizienten - -**Die 64 Koeffizienten:** - -| Position | Name | Bedeutung | -|----------|------|-----------| -| (0,0) | DC | Durchschnittshelligkeit | -| Rest | AC | Helligkeitsänderungen | - -**Energy Compaction:** -90% der Information in den ersten 10–15 Koeffizienten -DCT selbst ist **verlustfrei** und reversibel! - - - ---- - -# JPEG Schritt 5: Quantisierung - -**Hier passiert der Datenverlust!** - -Die DCT hat sortiert – jetzt wird aufgeräumt: -- Wichtige Werte (niedrige Frequenz) → präzise behalten -- Unwichtige Werte (hohe Frequenz) → vergröbern oder Null setzen - -**Ergebnis:** -Von 64 Werten pro Block bleiben oft nur 5–15 übrig -Rest wird zu Nullen → extrem gut komprimierbar - -**Quality-Einstellung:** -Hoch = mehr Werte behalten = größere Datei -Niedrig = mehr Nullen = kleinere Datei, mehr Artefakte - - - ---- - -![bg fit](./assets/quantized-image-8-colors.jpg) - - - - - - ---- - -# JPEG Schritt 5b: Zigzag & RLE - -**Nach Quantisierung:** Viele Nullen (v.a. bei hohen Frequenzen) - -**Zigzag-Scan:** Matrix diagonal durchlaufen -→ Nullen sammeln sich am Ende - -``` -┌────────────────┐ -│ 1 2 6 7 ... │ Niedrig → Hoch -│ 3 5 8 ... │ (diagonal) -│ 4 9 ... │ -└────────────────┘ -``` - -**RLE (Run-Length Encoding):** -`0 0 0 0 0 0 0 0` → `(8, 0)` = "acht Nullen" - - - ---- - - - - - - -# JPEG Schritt 6: Huffman-Coding - -**Verlustfreie Kompression der Restwerte** - -**Idee:** Variable Bitlänge statt fester 8 Bit -Häufige Werte → kurze Codes - -| Zeichen | Häufigkeit | Code | -|---------|------------|------| -| e | 40% | `0` (1 Bit) | -| a | 25% | `10` (2 Bit) | -| i | 20% | `110` (3 Bit) | -| o | 10% | `1110` (4 Bit) | -| u | 5% | `1111` (4 Bit) | - - - ---- - - - - - -# Huffman-Coding – Vertiefung - -David Huffman entwickelte 1952 als Student am MIT einen optimalen Algorithmus für präfixfreie Codes – ursprünglich als Hausaufgabe, die zur Veröffentlichung führte. - -**Algorithmus (Bottom-Up-Baumkonstruktion):** -1. Alle Symbole nach Häufigkeit sortieren -2. Die zwei seltensten Symbole zu einem Knoten kombinieren -3. Wiederholen bis nur noch die Wurzel übrig ist -4. Codes ablesen: links = 0, rechts = 1 - -**Präfixfreiheit:** Kein Code ist Anfang eines anderen → sofort dekodierbar ohne Trennzeichen. - -| Eigenschaft | Huffman | Arithmetisch | -|-------------|---------|--------------| -| Einheit | Ganze Bits | Fraktionale Bits | -| Optimalität | Optimal für ganze Bits | Näher an Entropie | -| Geschwindigkeit | Schneller | Langsamer | -| JPEG-Einsatz | Standard (Baseline) | Optional (selten) | - -JPEG verwendet zwei Huffman-Tabellen: eine für DC-Koeffizienten (Durchschnittswerte), eine für AC-Koeffizienten (Frequenzen). Die Tabellen sind im JPEG-Header gespeichert. - ---- - - - - - - - ---- - - - - -![bg](./assets/jpeg-artifacts.png) - - --- -# Andere Bildformate -## PNG, GIF, WebP, AVIF - -15:33 Uhr weiter +# Zweiter Weg: Verlustbehaftet (Lossy) --- -# PNG: Verlustfrei mit Transparenz +# Prinzip: Irrelevanz raus -**PNG = Portable Network Graphics (1996)** +Was der Mensch **nicht wahrnehmen** kann, muss man **nicht speichern**. -**Entstehung:** GIF-Patent-Streit → Community entwickelt Alternative +**Lossy-Kompression** wirft genau diese Information weg. -**Features:** -- Verlustfrei (Lossless) -- Alpha-Transparenz (8-Bit, 256 Stufen) -- Millionen Farben (24/48 Bit) -- Patent-frei - -**Ideal für:** Grafiken, Screenshots, Text, Logos +**Nicht umkehrbar.** Was weg ist, kommt nie zurück. Aus einem MP3 wird nie wieder ein FLAC. --- -# GIF: Der Meme-Veteran +# Was nimmt der Mensch nicht wahr? -**GIF = Graphics Interchange Format (1987)** +**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) -**Features:** -- 256 Farben (8-Bit Palette) -- Verlustfrei (innerhalb der Palette) -- Animationen +**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 -**Das Patent-Drama (1994):** -Unisys fordert Lizenzgebühren für LZW-Kompression -→ "Burn All GIFs!"-Kampagne -→ PNG als Alternative - -**Heute:** Kulturell unsterblich (Memes, Reaktionen) +Lossy-Algorithmen modellieren diese Wahrnehmungs-Grenzen — und werfen alles davor weg. + +--- + + + + +![bg fit](./assets/demos/psychoakustik-grafik.png) + + + +--- + + + + +![bg fit](./assets/demos/psychovisualitaet-grafik.png) + + + +--- + +# 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. + + --- - - - -# WebP & AVIF: Moderne Alternativen +# Vergleich: Lossless vs. Lossy -**WebP (Google, 2010):** -- Lossy und Lossless -- Transparenz und Animationen -- 25–35% kleiner als JPEG - -**AVIF (2019):** -- Basiert auf AV1-Video-Codec -- 50% kleiner als JPEG -- HDR-Unterstützung, patent-frei - -**Browser-Support 2025:** WebP universell, AVIF wächst +| 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. ---- - - - - - -# WebP & AVIF – Vertiefung - -**WebP** entstand 2010 aus Googles VP8-Videocodec (On2 Technologies, für $133M gekauft). Statt I-Frames für Video werden sie als Einzelbilder verwendet. WebP nutzt Intra-Frame-Prediction, die benachbarte Blöcke zur Vorhersage verwendet – effizienter als JPEGs blockweise DCT. - -**AVIF** basiert auf dem AV1-Videocodec, entwickelt 2015–2018 von der Alliance for Open Media (Google, Apple, Netflix, Amazon, Microsoft, Mozilla). Nach dem Patent-Chaos von H.265/HEVC vereinten sich die Konkurrenten für einen lizenzfreien Standard. - -| Aspekt | WebP | AVIF | -|--------|------|------| -| Basis-Codec | VP8/VP9 | AV1 | -| Kompression vs. JPEG | 25–35% besser | 50% besser | -| HDR/Wide Gamut | Nein | Ja (10/12 Bit) | -| Encoding-Geschwindigkeit | Schnell | Sehr langsam | -| Browser-Support 2025 | 97%+ | 93%+ | - -**Warum JPEG dominiert:** Kameras, Bildbearbeitungssoftware und Content-Management-Systeme sind auf JPEG optimiert. Der Wechsel erfordert Infrastruktur-Updates über die gesamte Pipeline. - ---- - -# Formatwahl in der Praxis - -| Anwendung | Format | -|-----------|--------| -| Fotos fürs Web | JPEG (85), WebP | -| Screenshots | PNG | -| Logos, Icons | SVG, PNG | -| Animationen | GIF, WebP, APNG | -| Archivierung | TIFF, PNG, RAW | -| Social Media | Was die Plattform erlaubt | - - --- @@ -957,202 +398,120 @@ KLAUSURRELEVANT: -![bg](./assets/instagram-quality-loss.png) +![bg fit](./assets/Felis_silvestris_silvestris_small_gradual_decrease_of_quality_-_JPEG_compression.jpg) --- -# Warum Instagram eure Fotos "ruiniert" +# Kompressionsraten in der Praxis -**Die Upload-Pipeline:** -1. Euer Foto: 12 MP, 8 MB -2. Instagram skaliert: max. 1080px Breite -3. Re-Kompression: JPEG Quality ~75 -4. Ergebnis: 200–400 KB +| 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× | -**Warum?** -- Speicherkosten (Milliarden Fotos) -- Ladezeiten (Mobile-First) -- Bandbreite (günstiger für alle) +Lossy bringt mehr — *aber Werkzeug muss roh bleiben.* --- - +# Entscheidungsmatrix — wann nehme ich was? -# Video -## Bilder + Zeit + Audio +| 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 | --- -# Das Größenproblem bei Video + -**4K-Video (3840×2160), unkomprimiert:** +# Selbstlernen — ZIP-Test mit drei Dateitypen -3840 × 2160 × 3 Bytes = **24,8 MB pro Frame** +Drei Dateien gleicher Originalgröße (~1 MB) zippen: -× 30 fps = **744 MB/Sekunde** +1. **Textdatei mit wiederholten Mustern** (z.B. ein Buch als TXT) +2. **Unkomprimiertes Bitmap (BMP)** desselben Fotos +3. **JPEG** desselben Fotos -× 60 Sekunden = **44,6 GB pro Minute** +**Vergleich:** Wie groß ist die ZIP-Datei in jedem Fall? -**Ein 2-Stunden-Film: über 5 Terabyte** +**Erwartung:** Textdatei wird klein (Wiederholungen), BMP wird klein (Farbflächen), JPEG bleibt fast gleich (schon komprimiert, keine Redundanz mehr). --- - - - - +# Warum ZIP auf JPEG nicht mehr komprimiert -# Container und Codec +**JPEG ist bereits maximal lossless-komprimiert.** -**Container = Dateiformat (z.B. MP4)** -Die "Box", die verschiedene Streams zusammenpackt: -- Video-Stream -- Audio-Stream(s) -- Untertitel -- Metadaten +Die JPEG-Pipeline endet mit **Huffman-Coding** — derselbe Trick wie in ZIP. -**Codec = Kompressionsalgorithmus (z.B. H.264)** -Bestimmt, WIE komprimiert wird +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. -# Container vs. Codec – Vertiefung +Folgerung: für gemischte Backups ist ZIP trotzdem nützlich — schon-komprimierte Dateien bleiben gleich, unkomprimierte werden kleiner. „Du verlierst nichts." -**Container** (Multiplexer-Format) organisiert mehrere Datenströme mit Timing-Informationen. Er enthält keine Kompressionslogik, sondern synchronisiert Video, Audio, Untertitel und Metadaten. - -**Codec** (Coder-Decoder) definiert den Kompressionsalgorithmus. Derselbe Container kann verschiedene Codecs enthalten – die Dateiendung verrät den Codec nicht. - -| Container | Entwicklung | Typische Codecs | Besonderheit | -|-----------|------------|-----------------|--------------| -| MP4 | ISO/MPEG | H.264, H.265, AAC | Web-Standard, DRM-fähig | -| MKV | Matroska | Alle | Beliebig viele Streams, Kapitel | -| WebM | Google | VP9, AV1, Opus | HTML5-optimiert, lizenzfrei | -| MOV | Apple | ProRes, H.264 | Professionelle Produktion | - -**Metadaten im Container:** -- Timecodes für Frame-genaue Synchronisation -- Kapitelmarken, Thumbnails -- Sprach-Tags für Audio/Untertitel -- HDR-Metadaten (MaxCLL, MaxFALL) - -**Praktisches Problem:** Eine `.mp4`-Datei mit AV1-Codec spielt auf älteren Geräten nicht ab, obwohl sie MP4 „unterstützen" – der Hardware-Decoder fehlt für AV1. - ---- - -# Gängige Container - -| Container | Verwendung | -|-----------|------------| -| **MP4** (.mp4) | Web, Streaming, universell | -| **MKV** (.mkv) | Archiv, viele Streams, offen | -| **MOV** (.mov) | Apple-Ökosystem | -| **WebM** (.webm) | Web, nur VP9/AV1 + Opus | -| **AVI** (.avi) | Legacy, veraltet | - - - ---- - -# Video-Codecs im Überblick - -| Codec | Jahr | Status | -|-------|------|--------| -| **H.264/AVC** | 2003 | Universal, überall | -| **H.265/HEVC** | 2013 | Effizienter, Patent-Chaos | -| **VP9** | 2013 | YouTube, patent-frei | -| **AV1** | 2018 | Zukunft, patent-frei | - - - ---- - -# Container + Codec = Video - -``` -┌─────────────────────────────┐ -│ Container (z.B. MP4) │ -│ ┌────────────────────────┐ │ -│ │ Video-Stream (H.264) │ │ -│ ├────────────────────────┤ │ -│ │ Audio-Stream (AAC) │ │ -│ ├────────────────────────┤ │ -│ │ Untertitel (SRT) │ │ -│ ├────────────────────────┤ │ -│ │ Metadaten │ │ -│ └────────────────────────┘ │ -└─────────────────────────────┘ -``` - - - ---- - - - -# Video-Kompression -## Raum und Zeit nutzen - - --- @@ -1160,394 +519,32 @@ KLAUSURRELEVANT: -![bg fit](./assets/ipb-compression-canon.jpg) +![bg fit](./assets/demos/summary-kap02.png) - ---- - -# Drei Kompressionsprinzipien - -**1. Spatial Compression (Intra-Frame)** -Jedes Bild einzeln komprimieren (wie JPEG) - -**2. Temporal Compression (Inter-Frame)** -Nur Änderungen zwischen Bildern speichern - -**3. Motion Compensation** -Bewegung beschreiben statt Pixel kopieren - - - ---- - -# Spatial Compression (Intra-Frame) - -**Jedes Bild einzeln komprimieren – wie JPEG** - -Analysiert Redundanz *innerhalb* eines Frames: -- DCT (Frequenzanalyse) -- Quantisierung -- Entropie-Coding - -**→ I-Frame (Keyframe)** -Vollständiges Bild, unabhängig dekodierbar - - - ---- - -# Temporal Compression (Inter-Frame) - -**Nur Änderungen zwischen Bildern speichern** - -| Frame-Typ | Referenziert | Typische Größe | -|-----------|--------------|----------------| -| **I-Frame** | Nichts (Keyframe) | 100% | -| **P-Frame** | Vorherige Frames | ~30% | -| **B-Frame** | Vorherige + zukünftige | ~15% | - -**GOP (Group of Pictures):** -I - B - B - P - B - B - P - B - B - I - - - ---- - -# Motion Compensation - -**Bewegung beschreiben statt Pixel kopieren** - -**Beispiel:** Ein 16×16 Pixel-Block - -Frame 1: Block an Position (100, 200) -Frame 2: Block an Position (120, 200) - -**Statt Block zweimal speichern:** -→ Motion Vector: "verschiebe um (+20, 0)" - - - ---- - - - - -![bg fit](./assets/ipb-compression-canon.jpg) - - - ---- - - - - - - -# H.264 / AVC - -**Advanced Video Coding (2003)** - -**Warum dominant?** -- Exzellente Kompression (~100:1 möglich) -- Hardware-Decoder in jedem Gerät seit ~2010 -- YouTube, Netflix, Blu-ray – alles H.264 - -**Features:** -- Variable Block-Größen (16×16 bis 4×4) -- Deblocking-Filter (reduziert Artefakte) - - - ---- - - - - - -# H.264/AVC – Vertiefung - -H.264 (2003) ermöglichte erst YouTube (2005), Netflix-Streaming (2007) und Blu-ray. Vor H.264 war MPEG-2 Standard – H.264 erreichte bei gleicher Qualität die halbe Bitrate. - -**Technische Innovationen:** -- **Variable Blockgrößen:** 16×16 bis 4×4 Macroblocks (MPEG-2: nur 16×16) -- **Intra-Prediction:** Blöcke werden aus Nachbarn vorhergesagt -- **In-Loop Deblocking:** Filter reduziert Blockartefakte vor der Referenzierung -- **CABAC:** Arithmetic Coding ersetzt Huffman (10–15% effizienter) - -| Profile | Anwendung | Max. Auflösung | -|---------|-----------|----------------| -| Baseline | Videotelefonie, ältere Geräte | 480p | -| Main | Broadcast, Streaming | 1080p | -| High | Blu-ray, professionell | 4K | - -**Hardware-Ubiquität:** Seit 2010 hat jedes Smartphone, jede GPU, jeder Smart-TV einen H.264-Hardware-Decoder. Encoding in Echtzeit braucht keine CPU – das ermöglichte erst mobiles Video-Streaming und Videotelefonie. - -**Patent-Pool (MPEG-LA):** ~2.000 Patente von 30+ Unternehmen. Endnutzungs-Streaming ist lizenzfrei; Hardware-Hersteller zahlen ~$0,20/Gerät. - ---- - -# Das Patent-Problem - -**H.264 ist nicht frei** - -**MPEG-LA (Patent Pool):** -- 2.000+ Patente von ~30 Unternehmen -- Apple, Microsoft, Sony, Panasonic... - -**Lizenzgebühren:** -- Hardware-Decoder: $0,20 pro Einheit -- "Internet Broadcast": Kostenlos (YouTube etc.) - -**Problem:** Open-Source-Projekte in Grauzone - - - ---- - -# H.265 / HEVC: Effizienter, aber... - -**High Efficiency Video Coding (2013)** - -50% bessere Kompression als H.264 - -**Das Problem: Patent-Chaos** - -Drei konkurrierende Patent-Pools: -- MPEG-LA -- HEVC Advance -- Velos Media - -Unklare Kosten, rechtliche Unsicherheit -→ Viele bleiben bei H.264 oder wechseln zu AV1 - - - ---- - -# VP9: Googles Antwort - -**VP9 (2013)** - -Google kaufte On2 Technologies (2010, $133M) -VP8 → VP9 → AV1 - -**Eigenschaften:** -- Ähnliche Effizienz wie H.265 -- Patent-frei (laut Google) -- YouTube nutzt VP9 für 4K - -**Nachteil:** Höherer CPU-Aufwand als H.264 - - - ---- - -![bg contain right:28%](./assets/AV1.png) - - - - - - -# AV1: Die offene Zukunft - -**AV1 (2018)** - -**Alliance for Open Media:** -Google, Netflix, Amazon, Microsoft, Apple, Mozilla... - -**Eigenschaften:** -- 30% besser als H.265 -- Royalty-free, Open Source -- 8K, HDR, hohe Frame-Rates - -**Stand 2025:** -YouTube, Netflix nutzen AV1 für 4K/8K -Hardware-Encoder in aktuellen GPUs - - - ---- - - - - - -# AV1 – Vertiefung - -Die **Alliance for Open Media** (2015) vereinte Konkurrenten nach dem Patent-Chaos von H.265/HEVC. Drei separate Patent-Pools (MPEG-LA, HEVC Advance, Velos Media) machten H.265-Lizenzierung unberechenbar – die Industrie wollte einen garantiert lizenzfreien Standard. - -**Gründungsmitglieder:** Google, Mozilla, Cisco, Netflix, Amazon, Microsoft. Apple trat 2018 bei – historisch, da Apple sonst eigene Standards bevorzugt. - -| Technische Innovation | Beschreibung | -|----------------------|--------------| -| Superblocks | Bis 128×128 Pixel (H.264: max 16×16) | -| Prediction Modes | 56 Intra-Modi (H.264: 9) | -| Transform | 10 verschiedene Transformtypen | -| Film Grain Synthesis | Filmkorn wird als Parameter übertragen | - -**Encoding-Performance:** Software-Encoding ist 50–200× langsamer als H.264. Erst Hardware-Encoder (Intel ab Gen 12, NVIDIA RTX 40, Apple M3) machen Echtzeit-Encoding praktikabel. - -**Adoption 2025:** YouTube und Netflix nutzen AV1 für 4K/8K-Streams. 2024 gewann AV1 einen Emmy für technische Innovation – offene Standards können Industriestandard werden. - ---- - - - - -![bg contain](./assets/av1-grammy.png) - - - ---- - - - -# Fragen & Diskussion - -**Kontakt:** lb-czechowski@hdm-stuttgart.de -**Folien:** [librete.ch/hdm/223015b](https://librete.ch/hdm/223015b/) - - - ---- - -# Lizenz & Attribution - -Diese Präsentation ist lizenziert unter **Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)** - -- Erlaubt Teilen & Anpassen mit Namensnennung -- Adaptionen müssen unter gleicher Lizenz geteilt werden - -Vollständige Lizenz: [creativecommons.org/licenses/by-sa/4.0/](https://creativecommons.org/licenses/by-sa/4.0/) - - - ---- - - - - -![bg contain right:25%](./assets/qr/squoosh.png) - -# Selbstlernen: Bildkompression - -1. Öffne [squoosh.app](https://squoosh.app) -2. Lade ein Foto hoch -3. Vergleiche: JPEG (verschiedene Quality) vs. WebP vs. AVIF -4. Beobachte: Dateigröße, Artefakte, Ladezeit - -**Fragen zum Erkunden:** -- Ab welcher Quality werden Artefakte sichtbar? -- Wie viel kleiner ist WebP bei gleicher Qualität? - - - ---- - - - - -# Selbstlernen: Video analysieren - -1. Video herunterladen (z.B. Big Buck Bunny) -2. Mit MediaInfo analysieren: Container, Codec, Bitrate -3. Optional: Mit HandBrake konvertieren - - H.264 vs. H.265 bei gleicher Qualität - - Größe und Encoding-Zeit vergleichen - -**Tools:** -- [MediaInfo](https://mediaarea.net/MediaInfoOnline) (Online oder Desktop) -- [HandBrake](https://handbrake.fr) (Desktop) - -