diff --git a/.gitignore b/.gitignore index c62e103..a8801eb 100644 --- a/.gitignore +++ b/.gitignore @@ -32,3 +32,4 @@ hdm-internettechnik-slides/ # Temporary files *.tmp *.bak +.idea diff --git a/slides/223015b/02-bild-audio-video.md b/slides/223015b/02-bild-audio-video.md index ceda725..f132c96 100644 --- a/slides/223015b/02-bild-audio-video.md +++ b/slides/223015b/02-bild-audio-video.md @@ -84,21 +84,39 @@ Hochschule der Medien Stuttgart [https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/) + + --- - - ![bg fit](./assets/qr/slides-223015b.png) + + --- # Teil 2: Bild- & Videoformate + + --- # Warum verschiedene Dateiformate? @@ -106,7 +124,7 @@ Hochschule der Medien Stuttgart **Ein Dateiformat definiert:** - Ob und wie Daten komprimiert werden - Welche Metadaten enthalten sind -- Wie Daten *»codiert«"* und *»decodiert«* (*Co·dec*) +- Wie Daten *codiert* und *decodiert* werden (*Co·dec*) | Ziel | Bild | Audio | Dokument | |------|------|-------|----------| @@ -116,8 +134,10 @@ Hochschule der Medien Stuttgart | Skalierbarkeit | SVG | — | PDF | --- @@ -128,8 +148,11 @@ Die Wahl hängt vom Anwendungsfall ab. ![bg](./assets/photo-comparison.png) --- @@ -139,6 +162,12 @@ Rechts: Stark komprimiert (JPEG-Artefakte sichtbar) # Digitale Bilder ## Raster- und Vektorgrafiken + + --- # Was ist ein digitales Bild? @@ -150,10 +179,11 @@ Jeder Pixel speichert einen RGB-Farbwert (3 Bytes). = 2.073.600 Pixel × 3 Bytes = **6,2 MB** --- @@ -180,14 +210,12 @@ Breite × Höhe × Farbtiefe (in Bytes) | 32 | 16,7 Mio. + Alpha | Transparenz | --- @@ -202,18 +230,16 @@ Pixel müssen zusammengefasst werden **Interpolationsverfahren:** - Nearest Neighbor: Schnell, pixelig -- Bilinear: Standard, glättet +- Bilinear: Glättet, Standardverfahren - Bicubic: Hohe Qualität, rechenintensiv -- Lanczos: Beste Qualität +- Lanczos: Beste Qualität, mathematisch komplex --- @@ -235,17 +261,15 @@ Alles darüber ist Schätzung. ``` -SVG beschreibt nicht jeden einzelnen Pixel im Raster, sondern deklariert wie Farben und Formen gesetzt werden. +SVG beschreibt WAS gezeichnet werden soll, nicht WIE jeder Pixel aussieht. --- @@ -259,25 +283,30 @@ Keine Information geht verloren. | **Dateigröße** | Abhängig von Auflösung | Abhängig von Komplexität | | **Formate** | JPEG, PNG, WebP | SVG, PDF, AI | | **Bearbeitung** | Pixel-basiert | Objekt-basiert | -| **Kompression** | meistens verlustbehaftet | Verlustfrei | --- -# Menschliche Sinne -## Psychovisuell komprimieren +# Menschliche Wahrnehmung +## Psychovisuelle Kompression + + --- @@ -294,18 +323,17 @@ Konvertierung: * Niedrige Frequenzen besser als hohe **JPEG nutzt das aus:** -* Farbauflösung reduzieren (aber Helligkeit behalten) +* Farbauflösung reduzieren (Helligkeit behalten) * Glatte Flächen effizient speichern -* Hohe Frequenzen (Details) verwerfen +* Hohe Frequenzen (feine Details) verwerfen --- @@ -313,71 +341,77 @@ Niedrige Frequenzen = langsame Wechsel = große Flächen - ![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 hoher Kompression sichtbar:** +**Bei starker Kompression sichtbar:** * **Posterization:** Farbverläufe werden stufig -* **"Blocking":** - 8×8-Blöcke werden sichtbar (Block-Grenzen) +* **Blocking:** + 8×8-Blöcke werden sichtbar * **Ringing:** - "Ghosting" an scharfen Kanten (Gibbs’sches Phänomen) + "Geister" an scharfen Kanten --- # JPEG-Qualität in der Praxis -| Quality¹ | Typische Größe (12 MP) | Artefakte | +| Quality | Typische Größe (12 MP) | Artefakte | |--------:|----------------------:|-----------| -| 100 | 2-3 MB | Minimal | -| 85-90 | 200-400 KB | Kaum sichtbar | +| 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 ist für den Menschen kaum unterscheidbar. - -¹ je nach Programm unterschiedliche Kompression +**Sweet Spot: 85–90** +~10× Kompression, für Menschen kaum unterscheidbar - - --- -# JPEG -## Vier Schritte der Kompression +# JPEG-Kompression +## Sechs Schritte im Detail + + --- - @@ -385,47 +419,49 @@ Für Archivierung: 90-100 oder gleich PNG/RAW. ![bg right:20%](./assets/Barn-yuv.png) -# JPEG: Schritt 1 – Farbraumkonversion +# JPEG Schritt 1: Farbraumkonversion -**RGB → Y'CbCr** (seltener Y'UV) +**RGB → Y'CbCr** -- **Y** = Helligkeit (Luminanz) – Was das Auge am besten sieht +- **Y** = Helligkeit (Luminanz) - **Cb** = Blau-Gelb-Anteil (Chrominanz) - **Cr** = Rot-Grün-Anteil (Chrominanz) -**Warum diese Trennung?** -Y (Helligkeit) behält volle Auflösung. -Cb/Cr (Farbe) kann reduziert werden – Auge merkt es kaum. +**Warum?** +Y (Helligkeit) behält volle Auflösung +Cb/Cr (Farbe) kann reduziert werden --- -# JPEG: Schritt 2 – Chroma Subsampling +# JPEG Schritt 2: Chroma Subsampling -**Die Notation `J:a:b`** (bezogen auf einen 4×2 Pixel-Block): +**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 | Jedes Pixel hat Farbinfo | 100% | -| 4:2:2 | Jedes 2. Pixel horizontal | 50% | -| 4:2:0 | Jedes 4. Pixel (2×2 Block teilt sich Farbe) | 25% | +| 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** – kaum sichtbarer Qualitätsverlust +**4:2:0 ist JPEG-Standard** --- @@ -435,105 +471,108 @@ Das Auge merkt es kaum, weil Helligkeit erhalten bleibt. ![bg contain 70%](./assets/Common_chroma_subsampling_ratios_YCbCr_CORRECTED.svg.png) ---- - -# JPEG: Schritt 3 – Block-Aufteilung - -**Das Bild wird in 8×8-Pixel-Blöcke zerlegt.** - -Jeder Block wird unabhängig verarbeitet. -Bei 1920×1080: Das sind 240 × 135 = 32.400 Blöcke. - -**Level Shift:** -Alle Pixelwerte werden um −128 verschoben. -Bereich vorher: 0 bis 255 -Bereich nachher: −128 bis +127 - -**Warum −128?** -Die DCT arbeitet besser mit Werten, die um Null zentriert sind. - --- -# JPEG: Schritt 4 – DCT +# JPEG Schritt 3: Block-Aufteilung -**Discrete Cosine Transform** -Jeder 8×8-Block wird von Pixelwerten in 64 Frequenzkoeffizienten umgewandelt. +**Das Bild wird in 8×8-Pixel-Blöcke zerlegt** + +Jeder Block wird unabhängig verarbeitet. +Bei 1920×1080: 240 × 135 = **32.400 Blöcke** + +**Level Shift:** +Pixelwerte um −128 verschieben +- Vorher: 0 bis 255 +- Nachher: −128 bis +127 + +**Warum?** +DCT arbeitet besser mit Werten um Null + + + +--- + +# JPEG Schritt 4: DCT (Discrete Cosine Transform) + +**Jeder 8×8-Block wird transformiert:** +64 Pixelwerte → 64 Frequenzkoeffizienten **Die 64 Koeffizienten:** | Position | Name | Bedeutung | |----------|------|-----------| -| (0,0) | DC | Durchschnittshelligkeit des Blocks | -| Rest | AC | Helligkeitsänderungen (Frequenzen) | +| (0,0) | DC | Durchschnittshelligkeit | +| Rest | AC | Helligkeitsänderungen | -**Energy Compaction – der Schlüssel zur Kompression:** -Bei typischen Fotos landet über 90% der visuellen Information in den ersten 10–15 Koeffizienten (oben links). DCT selbst ist verlustfrei und reversibel! +**Energy Compaction:** +90% der Information in den ersten 10–15 Koeffizienten +DCT selbst ist **verlustfrei** und reversibel! --- -# JPEG: Schritt 5 – Quantisierung +# JPEG Schritt 5: Quantisierung -**Hier passiert der Datenverlust.** +**Hier passiert der Datenverlust!** -Die DCT hat sortiert: Wichtiges von Unwichtigem getrennt +Die DCT hat sortiert – jetzt wird aufgeräumt: +- Wichtige Werte (niedrige Frequenz) → präzise behalten +- Unwichtige Werte (hohe Frequenz) → vergröbern oder Null setzen -**Jetzt wird aufgeräumt:** -- Wichtige Werte (niedrige Frequenz, große Flächen) → präzise behalten -- Unwichtige Werte (hohe Freqzenz, feine Details) → vergröbern oder auf Null setzen +**Ergebnis:** +Von 64 Werten pro Block bleiben oft nur 5–15 übrig +Rest wird zu Nullen → extrem gut komprimierbar -**Das Ergebnis:** -Von den 64 Werten pro Block bleiben oft nur 5–15 übrig. -Der Rest wird zu Nullen (lassen sich extrem gut komprimieren) +**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 5 – Zigzag & RLE +# JPEG Schritt 5b: Zigzag & RLE -**Nach Quantisierung:** Viele Werte sind 0 (v.a. hohe Frequenzen). +**Nach Quantisierung:** Viele Nullen (v.a. bei hohen Frequenzen) **Zigzag-Scan:** Matrix diagonal durchlaufen → Nullen sammeln sich am Ende @@ -546,11 +585,14 @@ Es bedeutet nur: sehr wenig wegwerfen. └────────────────┘ ``` -**RLE:** `0 0 0 0 0 0 0 0` → `(8, 0)` = "8 Nullen" +**RLE (Run-Length Encoding):** +`0 0 0 0 0 0 0 0` → `(8, 0)` = "acht Nullen" --- @@ -560,14 +602,14 @@ Lange Null-Sequenzen sind ideal für RLE. -# JPEG: Schritt 6 – Huffman-Coding +# JPEG Schritt 6: Huffman-Coding **Verlustfreie Kompression der Restwerte** -**Idee:** Statt fester 8 Bit pro Wert → variable Bitlänge -Häufige Werte bekommen kurze Bit-Sequenzen. +**Idee:** Variable Bitlänge statt fester 8 Bit +Häufige Werte → kurze Codes -| Zeichen | Häufigkeit | Code (Bit-Sequenz) | +| Zeichen | Häufigkeit | Code | |---------|------------|------| | e | 40% | `0` (1 Bit) | | a | 25% | `10` (2 Bit) | @@ -576,9 +618,48 @@ Häufige Werte bekommen kurze Bit-Sequenzen. | u | 5% | `1111` (4 Bit) | + + + + + + + + --- @@ -589,10 +670,11 @@ Weil "e" am häufigsten vorkommt, bekommt es den kürzesten Code. ![bg](./assets/jpeg-artifacts.png) --- @@ -602,29 +684,35 @@ Color Banding (Verläufe werden "treppig") # Andere Bildformate ## PNG, GIF, WebP, AVIF +15:33 Uhr weiter + + + --- # PNG: Verlustfrei mit Transparenz **PNG = Portable Network Graphics (1996)** -**Entstehung:** -GIF-Patent-Streit → Community entwickelt Alternative +**Entstehung:** GIF-Patent-Streit → Community entwickelt Alternative **Features:** - Verlustfrei (Lossless) -- Alpha-Transparenz (8-Bit) +- Alpha-Transparenz (8-Bit, 256 Stufen) - Millionen Farben (24/48 Bit) - Patent-frei **Ideal für:** Grafiken, Screenshots, Text, Logos --- @@ -635,51 +723,51 @@ Keine Qualitätsverluste, aber größer als JPEG für Fotos. **Features:** - 256 Farben (8-Bit Palette) -- Verlustfrei (für die gewählte Palette) +- Verlustfrei (innerhalb der Palette) - Animationen -**Das Patent-Drama:** -1994 fordert Unisys Lizenzgebühren für LZW-Kompression. -→ "Burn All GIFs!" Kampagne +**Das Patent-Drama (1994):** +Unisys fordert Lizenzgebühren für LZW-Kompression +→ "Burn All GIFs!"-Kampagne → PNG als Alternative **Heute:** Kulturell unsterblich (Memes, Reaktionen) --- + + + + + # WebP & AVIF: Moderne Alternativen **WebP (Google, 2010):** - Lossy und Lossless - Transparenz und Animationen -- 25-35% kleiner als JPEG +- 25–35% kleiner als JPEG **AVIF (2019):** - Basiert auf AV1-Video-Codec -- 50% kleiner als JPEG, HDR, patent-frei +- 50% kleiner als JPEG +- HDR-Unterstützung, patent-frei -**Browser-Support 2025:** WebP fast universell, AVIF wächst. +**Browser-Support 2025:** WebP universell, AVIF wächst --- @@ -696,11 +784,10 @@ Alte Kameras, alte Software, alte Workflows. | Social Media | Was die Plattform erlaubt | --- @@ -711,8 +798,9 @@ RAW für Fotografen: Maximale Bearbeitungsmöglichkeit. ![bg](./assets/instagram-quality-loss.png) --- @@ -723,7 +811,7 @@ Sichtbare Qualitätsverluste 1. Euer Foto: 12 MP, 8 MB 2. Instagram skaliert: max. 1080px Breite 3. Re-Kompression: JPEG Quality ~75 -4. Ergebnis: 200-400 KB +4. Ergebnis: 200–400 KB **Warum?** - Speicherkosten (Milliarden Fotos) @@ -731,14 +819,11 @@ Sichtbare Qualitätsverluste - Bandbreite (günstiger für alle) --- @@ -748,6 +833,13 @@ nicht auf Social Media verlassen. # Video ## Bilder + Zeit + Audio + + --- # Das Größenproblem bei Video @@ -756,17 +848,17 @@ nicht auf Social Media verlassen. 3840 × 2160 × 3 Bytes = **24,8 MB pro Frame** -× 30 Frames/Sekunde = **744 MB/Sekunde** +× 30 fps = **744 MB/Sekunde** × 60 Sekunden = **44,6 GB pro Minute** **Ein 2-Stunden-Film: über 5 Terabyte** --- @@ -778,28 +870,22 @@ Netflix wäre undenkbar. # Container und Codec -**Container = Das Dateiformat (Beispiel: MP4)** +**Container = Dateiformat (z.B. MP4)** Die "Box", die verschiedene Streams zusammenpackt: - Video-Stream - Audio-Stream(s) - Untertitel - Metadaten -**Codec = Der Kompressionsalgorithmus (Beispiel: AV1)** -Entscheidet, WIE komprimiert wird. - +**Codec = Kompressionsalgorithmus (z.B. H.264)** +Bestimmt, WIE komprimiert wird --- @@ -815,34 +901,29 @@ Tools wie MediaInfo zeigen beide Informationen. | **AVI** (.avi) | Legacy, veraltet | --- -# Video-Codecs +# Video-Codecs im Überblick | Codec | Jahr | Status | |-------|------|--------| -| **MPEG-4** | 1999 | Passender Codec zu .mp4 | | **H.264/AVC** | 2003 | Universal, überall | -| **H.265/HEVC** | 2013 | Effizienter, aber Patente | +| **H.265/HEVC** | 2013 | Effizienter, Patent-Chaos | | **VP9** | 2013 | YouTube, patent-frei | | **AV1** | 2018 | Zukunft, patent-frei | --- @@ -865,11 +946,10 @@ AV1 ist die Antwort: Offen, modern, aber Encoding ist langsam. ``` --- @@ -879,6 +959,12 @@ haben dieselbe Endung, aber unterschiedliche Inhalte. # Video-Kompression ## Raum und Zeit nutzen + --- @@ -888,89 +974,84 @@ haben dieselbe Endung, aber unterschiedliche Inhalte. ![bg fit](./assets/ipb-compression-canon.jpg) --- # Drei Kompressionsprinzipien -* **1. Spatial Compression (Intra-Frame)** - Jedes Bild einzeln komprimieren (wie JPEG) +**1. Spatial Compression (Intra-Frame)** +Jedes Bild einzeln komprimieren (wie JPEG) -* **2. Temporal Compression (Inter-Frame)** - Nur Änderungen zwischen Bildern speichern +**2. Temporal Compression (Inter-Frame)** +Nur Änderungen zwischen Bildern speichern -* **3. Motion Compensation** - Bewegung beschreiben statt Pixel kopieren +**3. Motion Compensation** +Bewegung beschreiben statt Pixel kopieren --- -# 1. Spatial Compression (Intra-Frame) +# Spatial Compression (Intra-Frame) **Jedes Bild einzeln komprimieren – wie JPEG** Analysiert Redundanz *innerhalb* eines Frames: - DCT (Frequenzanalyse) -- Quantisierung (Details entfernen) +- Quantisierung - Entropie-Coding **→ I-Frame (Keyframe)** -Vollständiges Bild, unabhängig dekodierbar. +Vollständiges Bild, unabhängig dekodierbar --- -# 2. Temporal Compression (Inter-Frame) +# Temporal Compression (Inter-Frame) **Nur Änderungen zwischen Bildern speichern** -| Frame-Typ | Referenziert | Größe | -|-----------|--------------|-------| -| **I-Frame** (Intra) | Keine Referenz (Keyframe) | 100% | -| **P-Frame** (Predicted) | Vorherige Frames | ~30% | -| **B-Frame** (Bi-directional) | Vorherige + zukünftige | ~15% | +| 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 +**GOP (Group of Pictures):** +I - B - B - P - B - B - P - B - B - I --- -# 3. Motion Compensation +# Motion Compensation **Bewegung beschreiben statt Pixel kopieren** @@ -983,13 +1064,13 @@ Frame 2: Block an Position (120, 200) → Motion Vector: "verschiebe um (+20, 0)" - --- @@ -998,9 +1079,10 @@ Funktioniert schlecht bei: Szenenwechsel, Konfetti. ![bg fit](./assets/ipb-compression-canon.jpg) --- @@ -1016,26 +1098,26 @@ P/B-Frames speichern nur Unterschiede **Warum dominant?** - Exzellente Kompression (~100:1 möglich) -- Hardware-Support in jedem Gerät seit ~2010 +- 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 Block-Artefakte) +- Deblocking-Filter (reduziert Artefakte) --- # Das Patent-Problem -**H.264 ist nicht frei.** +**H.264 ist nicht frei** **MPEG-LA (Patent Pool):** - 2.000+ Patente von ~30 Unternehmen @@ -1045,16 +1127,13 @@ Selbst billige Smartphones können H.264 abspielen. - Hardware-Decoder: $0,20 pro Einheit - "Internet Broadcast": Kostenlos (YouTube etc.) -**Problem:** Open-Source-Projekte in Grauzone. +**Problem:** Open-Source-Projekte in Grauzone --- @@ -1063,7 +1142,7 @@ Die "Free to View"-Klausel gilt nur für Endnutzer-Streaming. **High Efficiency Video Coding (2013)** -50% bessere Kompression als H.264. +50% bessere Kompression als H.264 **Das Problem: Patent-Chaos** @@ -1072,15 +1151,15 @@ Drei konkurrierende Patent-Pools: - HEVC Advance - Velos Media -Unklare Kosten, rechtliche Unsicherheit. -→ Viele bleiben bei H.264 oder wechseln zu AV1. +Unklare Kosten, rechtliche Unsicherheit +→ Viele bleiben bei H.264 oder wechseln zu AV1 --- @@ -1089,23 +1168,21 @@ Apple nutzt HEVC (iPhone-Videos), Netflix zögert. **VP9 (2013)** -Google kaufte On2 Technologies (2010, $133M). -VP8 → VP9 → (später) AV1 +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 -**Nachteile:** -- Höherer CPU-Aufwand als H.264 +**Nachteil:** Höherer CPU-Aufwand als H.264 --- @@ -1130,54 +1207,29 @@ Google, Netflix, Amazon, Microsoft, Apple, Mozilla... - 8K, HDR, hohe Frame-Rates **Stand 2025:** -YouTube und Netflix nutzen AV1 für 4K/8K +YouTube, Netflix nutzen AV1 für 4K/8K Hardware-Encoder in aktuellen GPUs --- - ![bg contain](./assets/av1-grammy.png) - --- @@ -1189,6 +1241,12 @@ Bandbreite sinkt → Player wechselt auf niedrigere Qualität. **Kontakt:** lb-czechowski@hdm-stuttgart.de **Folien:** [librete.ch/hdm/223015b](https://librete.ch/hdm/223015b/) + + --- # Lizenz & Attribution @@ -1200,8 +1258,13 @@ Diese Präsentation ist lizenziert unter **Creative Commons Attribution-ShareAli Vollständige Lizenz: [creativecommons.org/licenses/by-sa/4.0/](https://creativecommons.org/licenses/by-sa/4.0/) ---- + +--- @@ -1215,15 +1278,15 @@ Vollständige Lizenz: [creativecommons.org/licenses/by-sa/4.0/](https://creative 3. Vergleiche: JPEG (verschiedene Quality) vs. WebP vs. AVIF 4. Beobachte: Dateigröße, Artefakte, Ladezeit -**Fragen:** +**Fragen zum Erkunden:** - Ab welcher Quality werden Artefakte sichtbar? - Wie viel kleiner ist WebP bei gleicher Qualität? --- @@ -1236,17 +1299,17 @@ Ziel: Ein Gefühl für Kompressionsraten entwickeln. 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 + - 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)