1564 lines
41 KiB
Markdown
1564 lines
41 KiB
Markdown
---
|
||
marp: true
|
||
theme: gaia
|
||
paginate: true
|
||
backgroundColor: #fff
|
||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
|
||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||
---
|
||
|
||
<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: #1a1a2e;
|
||
color: #5fb3e4;
|
||
padding: 0.15em 0.4em;
|
||
border-radius: 4px;
|
||
}
|
||
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 {
|
||
font-size: 1.1rem;
|
||
background: repeating-linear-gradient(
|
||
135deg,
|
||
#e3f2fd,
|
||
#e3f2fd 40px,
|
||
#fff 40px,
|
||
#fff 80px
|
||
) !important;
|
||
}
|
||
@media print {
|
||
section.erklaerung {
|
||
background: #e3f2fd !important;
|
||
}
|
||
}
|
||
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: invert -->
|
||
<!-- _header: '' -->
|
||
<!-- _backgroundColor: #000 -->
|
||
|
||
|
||
|
||
# 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/)
|
||
|
||
<!--
|
||
- Willkommen, kurze Vorstellung
|
||
- Heute: Teil 2 – Bilder und Video
|
||
- Ziel: Verstehen, WARUM Formate so funktionieren, nicht nur WAS sie tun
|
||
- Frage zum Einstieg: "Wer hat schon mal ein Bild für Instagram hochgeladen und sich gewundert, warum es danach schlechter aussieht?"
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
- QR-Code scannen für Folien-Link
|
||
- Folien sind CC BY-SA lizenziert – dürft ihr nutzen und teilen
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Teil 2: Bild- & Videoformate
|
||
|
||
<!--
|
||
- Drei große Blöcke heute:
|
||
1. Digitale Bilder (Raster vs. Vektor)
|
||
2. JPEG im Detail (die Magie der Kompression)
|
||
3. Video (warum es nochmal komplizierter ist)
|
||
- Interaktive Demos zwischendurch
|
||
-->
|
||
|
||
---
|
||
|
||
# Warum verschiedene Dateiformate?
|
||
|
||
**Ein Dateiformat definiert:**
|
||
- Ob und wie Daten komprimiert werden
|
||
- Welche Metadaten enthalten sind
|
||
- Wie Daten *codiert* und *decodiert* werden (*Co·dec*)
|
||
|
||
| Ziel | Bild | Audio | Dokument |
|
||
|------|------|-------|----------|
|
||
| Kleine Dateien | JPEG | MP3 | — |
|
||
| Perfekte Qualität | PNG, RAW | FLAC | PDF |
|
||
| Animation/Video | GIF | — | — |
|
||
| Skalierbarkeit | SVG | — | PDF |
|
||
|
||
<!--
|
||
- Kernfrage: Warum nicht EIN Format für alles?
|
||
- Antwort: Jedes Format ist ein Kompromiss
|
||
- Frage an Studierende: "Was wäre wichtiger – kleine Datei oder perfekte Qualität?" → Kommt drauf an!
|
||
- Analogie: Werkzeugkasten – Hammer für Nägel, Schraubenzieher für Schrauben
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
- Links: Original (hochauflösend)
|
||
- Rechts: Stark komprimiert
|
||
- Frage: "Wer sieht die Unterschiede?"
|
||
- Auf Blockartefakte und Unschärfe hinweisen
|
||
- Das ist der Preis für kleine Dateien
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Digitale Bilder
|
||
## Raster- und Vektorgrafiken
|
||
|
||
<!--
|
||
- Zwei fundamental verschiedene Ansätze
|
||
- Raster: "Malen nach Zahlen" – jeder Punkt einzeln
|
||
- Vektor: "Bauanleitung" – Formen beschreiben
|
||
-->
|
||
|
||
---
|
||
|
||
# Was ist ein digitales Bild?
|
||
|
||
Ein digitales Bild ist ein Raster aus Farbpunkten (Pixel).
|
||
Jeder Pixel speichert einen RGB-Farbwert (3 Bytes).
|
||
|
||
**Beispiel: Full HD (1920×1080)**
|
||
= 2.073.600 Pixel × 3 Bytes = **6,2 MB**
|
||
|
||
<!--
|
||
- Pixel = Picture Element
|
||
- RGB = Rot, Grün, Blau (je 0-255)
|
||
- Rechenbeispiel gemeinsam durchgehen
|
||
- Frage: "Wie viele Fotos passen auf ein 64GB Smartphone?" → ca. 10.000 unkomprimiert
|
||
- Pointe: Ohne Kompression wäre Smartphone-Fotografie unmöglich
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: klausur -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
<!-- _backgroundColor: #e3f2fd -->
|
||
|
||
# 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 |
|
||
|
||
<!--
|
||
KLAUSURRELEVANT:
|
||
- Formel: Breite × Höhe × (Farbtiefe / 8) = Bytes
|
||
- Beispielrechnung: 1920 × 1080 × 3 = 6.220.800 Bytes ≈ 6,2 MB
|
||
- Farbtiefe: 2^n Farben bei n Bit
|
||
- 24 Bit = 8 Bit pro Kanal (R, G, B)
|
||
- 32 Bit = 24 Bit + 8 Bit Alpha (Transparenz)
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: erklaerung -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
# 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
|
||
|
||
<!--
|
||
- Kernproblem: Rasterbilder haben EINE native Auflösung
|
||
- Alles darüber = Schätzung, Erfindung
|
||
- Demo-Idee: Bild in Photoshop/GIMP stark vergrößern
|
||
- Nearest Neighbor gut für Pixel-Art (soll pixelig bleiben)
|
||
- Frage: "Warum wird mein Profilbild manchmal unscharf?" → Plattform skaliert
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: klausur -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
<!-- _backgroundColor: #e3f2fd -->
|
||
|
||
# Vektorgrafiken
|
||
|
||
**Speicherung als geometrische Primitive:**
|
||
- Pfade (Bézierkurven mit Kontrollpunkten)
|
||
- Grundformen (Rechteck, Ellipse, Polygon)
|
||
- Text (Glyphen als Outlines)
|
||
|
||
**SVG-Beispiel:**
|
||
```xml
|
||
<circle cx="50" cy="50" r="40" fill="#ff0000"/>
|
||
```
|
||
|
||
<small>SVG beschreibt WAS gezeichnet werden soll, nicht WIE jeder Pixel aussieht.</small>
|
||
|
||
<!--
|
||
KLAUSURRELEVANT:
|
||
- Vektor = Beschreibung (deklarativ)
|
||
- Raster = Pixel für Pixel (imperativ)
|
||
- Rendering-Pipeline: Vektordaten → Rasterisierung → Display
|
||
- Skalierung = Koordinaten multiplizieren → keine Information geht verloren
|
||
- SVG = Scalable Vector Graphics (Web-Standard)
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: erklaerung -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
# 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 |
|
||
|
||
<!--
|
||
- Entscheidungsregel:
|
||
- Foto → immer Raster
|
||
- Logo → immer Vektor
|
||
- Screenshot → meist Raster
|
||
- Konvertierung:
|
||
- Vektor → Raster: trivial (Rasterisierung)
|
||
- Raster → Vektor: schwierig, oft unbefriedigend (Tracing)
|
||
- Frage: "Warum verschickt euch der Grafiker das Logo als .ai oder .svg?"
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Menschliche Wahrnehmung
|
||
## Psychovisuelle Kompression
|
||
|
||
<!--
|
||
- Jetzt wird's spannend: Wie können wir 90% der Daten wegwerfen, ohne dass es auffällt?
|
||
- Antwort: Das menschliche Auge ist kein perfekter Sensor
|
||
- Wir nutzen seine Schwächen aus
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: klausur -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
<!-- _backgroundColor: #e3f2fd -->
|
||
|
||
# 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
|
||
|
||
<!--
|
||
KLAUSURRELEVANT:
|
||
- Mehr Stäbchen (Helligkeit) als Zapfen (Farbe) im Auge
|
||
- "Frequenz" = räumliche Frequenz = wie schnell ändert sich Helligkeit?
|
||
- Niedrig = langsame Änderung = große gleichmäßige Fläche
|
||
- Hoch = schnelle Änderung = feine Details, Kanten
|
||
- Analogie zur Psychoakustik bei MP3 (letztes Mal)
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: erklaerung -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
# 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 |
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
- Kompressionsvergleich am Beispiel
|
||
- Von links nach rechts: zunehmende Kompression
|
||
- Frage: "Ab wo seht ihr deutliche Qualitätsverluste?"
|
||
- Zeigt: Viel Spielraum für "unsichtbare" Kompression
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
# 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
|
||
|
||
<!--
|
||
- Artefakte = sichtbare Spuren der Kompression
|
||
- Blocking: Benachbarte 8×8-Blöcke unabhängig komprimiert
|
||
- Ringing: DCT hat Probleme mit harten Kanten (Gibbs-Phänomen)
|
||
- Posterization: Zu wenig Bits für feine Farbabstufungen
|
||
- Demo: Stark komprimiertes JPEG zoomen
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
- Quality 100 ≠ unkomprimiert (immer noch lossy!)
|
||
- Für Web/Social Media: 60–80 oft ausreichend
|
||
- Für Archivierung: 90–100 oder besser PNG/RAW
|
||
- Faustregel: Quality 85 = guter Kompromiss
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# JPEG-Kompression
|
||
## Sechs Schritte im Detail
|
||
|
||
<!--
|
||
- Jetzt: Unter die Haube schauen
|
||
- JPEG = Joint Photographic Experts Group (1992)
|
||
- Sechs Schritte, davon einer verlustbehaftet
|
||
- Interaktive Demo: https://claude.ai/public/artifacts/452e62f1-8525-442d-aa88-bf3795cab2c5
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: klausur -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
<!-- _backgroundColor: #e3f2fd -->
|
||
|
||
|
||
|
||
# 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
|
||
|
||
<!--
|
||
KLAUSURRELEVANT:
|
||
- YCbCr = auch 3 Werte pro Pixel, aber anders organisiert
|
||
- Statt R-G-B: Helligkeit + 2 Farbdifferenzen
|
||
- Umrechnung ist reversibel (mathematische Transformation)
|
||
- Vorteil: Helligkeit und Farbe getrennt behandelbar
|
||
- Bild zeigt: Y (oben), Cb (Mitte), Cr (unten)
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: erklaerung -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
# 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:
|
||
|
||
```
|
||
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
|
||
```
|
||
|
||
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.
|
||
|
||
**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**
|
||
|
||
<!--
|
||
- Beispiel 4:2:0: 4 Pixel teilen sich einen Farbwert, aber jeder hat eigene Helligkeit
|
||
- Auge merkt es kaum → psychovisuelle Kompression
|
||
- Bereits hier: 50% Datenreduktion ohne sichtbaren Verlust
|
||
- In Video noch wichtiger (weniger Bandbreite)
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
- Visualisierung der Subsampling-Schemata
|
||
- Obere Reihe: Luminanz (Y) – immer voll
|
||
- Untere Reihen: Chrominanz (Cb, Cr) – reduziert
|
||
- 4:2:0 am häufigsten (JPEG, Video)
|
||
-->
|
||
|
||
---
|
||
|
||
# JPEG Schritt 3: Block-Aufteilung
|
||
|
||
**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
|
||
|
||
<!--
|
||
- 8×8 = historischer Kompromiss (Rechenleistung 1992)
|
||
- Unabhängige Verarbeitung = Grund für Blocking-Artefakte
|
||
- Level Shift: Mathematische Vorbereitung für DCT
|
||
- Bei nicht durch 8 teilbaren Dimensionen: Padding am Rand
|
||
-->
|
||
|
||
---
|
||
|
||
# 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 |
|
||
| Rest | AC | Helligkeitsänderungen |
|
||
|
||
**Energy Compaction:**
|
||
90% der Information in den ersten 10–15 Koeffizienten
|
||
DCT selbst ist **verlustfrei** und reversibel!
|
||
|
||
<!--
|
||
- DCT = Herzstück von JPEG
|
||
- Ähnlich wie Fourier-Transformation, aber nur Cosinus
|
||
- Sortiert Information nach "Wichtigkeit"
|
||
- Niedrige Frequenzen (oben links) = wichtig
|
||
- Hohe Frequenzen (unten rechts) = Details, oft verzichtbar
|
||
- NICHT hier passiert der Verlust!
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
KLAUSURRELEVANT:
|
||
- Quantisierung = Division durch Quantisierungsmatrix + Runden
|
||
- Einziger verlustbehafteter Schritt!
|
||
- Quality 100 ≠ verlustfrei, nur "wenig wegwerfen"
|
||
- Quantisierungstabellen basieren auf Wahrnehmungsforschung
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: 'https://newsletter.maartengrootendorst.com/p/a-visual-guide-to-quantization' -->
|
||
|
||
<!--
|
||
- Visualisierung von Quantisierung (hier: Farbreduktion)
|
||
- Prinzip gilt auch für DCT-Koeffizienten
|
||
- Weniger Stufen = weniger Daten = weniger Qualität
|
||
-->
|
||
|
||
---
|
||
|
||
# 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"
|
||
|
||
<!--
|
||
- Zigzag: Clever – sortiert so, dass Nullen am Ende stehen
|
||
- RLE: Klassische verlustfreie Kompression
|
||
- Lange Nullsequenzen → sehr kurze Codes
|
||
- Beispiel: "00000000" (8 Byte) → "(8,0)" (2 Byte)
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: klausur -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
<!-- _backgroundColor: #e3f2fd -->
|
||
|
||
# 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) |
|
||
|
||
<!--
|
||
KLAUSURRELEVANT:
|
||
- Huffman = verlustfrei, optimal für bekannte Häufigkeiten
|
||
- Präfix-frei: Kein Code ist Anfang eines anderen
|
||
- Häufigstes Zeichen = kürzester Code
|
||
- Auch in ZIP, PNG, MP3 verwendet
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: erklaerung -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
# 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.
|
||
|
||
---
|
||
|
||
<!-- _class: klausur -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
<!-- _backgroundColor: #e3f2fd -->
|
||
<!--
|
||
# Huffman-Coding: Beispiel
|
||
|
||
**Originaltext:** `ABRACADABRA` (11 Zeichen × 8 Bit = 88 Bit)
|
||
|
||
**Häufigkeitsanalyse:**
|
||
A=5, B=2, R=2, C=1, D=1
|
||
|
||
**Huffman-Baum → Codes:**
|
||
| Zeichen | Häufigkeit | Code |
|
||
|---------|------------|------|
|
||
| A | 5 | `0` |
|
||
| B | 2 | `10` |
|
||
| R | 2 | `110` |
|
||
| C | 1 | `1110` |
|
||
| D | 1 | `1111` |
|
||
|
||
**Codiert:** `0 10 110 0 1110 0 1111 0 10 110 0` = **23 Bit**
|
||
**Kompression:** 88 → 23 Bit = **74% gespart**
|
||
|
||
|
||
- Beispiel Schritt für Schritt durchrechnen
|
||
- Warum funktioniert's? A kommt 5× vor, bekommt kürzesten Code
|
||
- Präfix-Eigenschaft: Kein Code ist Anfang eines anderen → eindeutig dekodierbar
|
||
- Frage: "Was passiert, wenn alle Zeichen gleich häufig sind?" → Keine Ersparnis
|
||
- In JPEG: Nicht Buchstaben, sondern DCT-Koeffizienten werden so codiert
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
- Zusammenfassung: Typische JPEG-Artefakte
|
||
- Blocking: 8×8-Struktur sichtbar
|
||
- Ringing: Geister um Kanten
|
||
- Color Banding: Farbverläufe werden stufig
|
||
- Alles Folgen der Quantisierung
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Andere Bildformate
|
||
## PNG, GIF, WebP, AVIF
|
||
|
||
15:33 Uhr weiter
|
||
|
||
<!--
|
||
- JPEG ist nicht für alles geeignet
|
||
- Jetzt: Alternativen und ihre Stärken
|
||
-->
|
||
|
||
---
|
||
|
||
# PNG: Verlustfrei mit Transparenz
|
||
|
||
**PNG = Portable Network Graphics (1996)**
|
||
|
||
**Entstehung:** GIF-Patent-Streit → Community entwickelt Alternative
|
||
|
||
**Features:**
|
||
- Verlustfrei (Lossless)
|
||
- Alpha-Transparenz (8-Bit, 256 Stufen)
|
||
- Millionen Farben (24/48 Bit)
|
||
- Patent-frei
|
||
|
||
**Ideal für:** Grafiken, Screenshots, Text, Logos
|
||
|
||
<!--
|
||
- PNG entstand als Reaktion auf GIF-Lizenzprobleme
|
||
- "PNG is Not GIF" (rekursives Akronym)
|
||
- DEFLATE-Kompression (wie ZIP)
|
||
- Keine Qualitätsverluste, aber größer als JPEG für Fotos
|
||
- Transparenz mit 256 Stufen (nicht nur an/aus wie GIF)
|
||
-->
|
||
|
||
---
|
||
|
||
# GIF: Der Meme-Veteran
|
||
|
||
**GIF = Graphics Interchange Format (1987)**
|
||
|
||
**Features:**
|
||
- 256 Farben (8-Bit Palette)
|
||
- Verlustfrei (innerhalb der Palette)
|
||
- Animationen
|
||
|
||
**Das Patent-Drama (1994):**
|
||
Unisys fordert Lizenzgebühren für LZW-Kompression
|
||
→ "Burn All GIFs!"-Kampagne
|
||
→ PNG als Alternative
|
||
|
||
**Heute:** Kulturell unsterblich (Memes, Reaktionen)
|
||
|
||
<!--
|
||
- CompuServe entwickelte GIF 1987
|
||
- LZW = Lempel-Ziv-Welch Kompression
|
||
- Patent lief 2004 aus, aber PNG war da längst etabliert
|
||
- GIF überlebte wegen Animationen
|
||
- Aussprache: "GIF" vs. "JIF" – ewiger Streit (Erfinder sagt "JIF")
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: klausur -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
<!-- _backgroundColor: #e3f2fd -->
|
||
|
||
# WebP & AVIF: Moderne Alternativen
|
||
|
||
**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
|
||
|
||
<!--
|
||
KLAUSURRELEVANT:
|
||
- WebP: VP8-Kompression (Google Video-Codec)
|
||
- AVIF: Alliance for Open Media (Google, Netflix, Amazon, Apple, Mozilla)
|
||
- Beide besser als JPEG, aber Kompatibilität bleibt Problem
|
||
- JPEG bleibt dominant: alte Kameras, Software, Workflows
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: erklaerung -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
# 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 |
|
||
|
||
<!--
|
||
- Kompatibilität schlägt oft Effizienz
|
||
- TIFF für Archivierung: Unkomprimiert oder verlustfrei
|
||
- RAW für Fotografen: Maximale Bearbeitungsfreiheit
|
||
- Frage: "Was passiert, wenn ihr ein PNG auf Instagram hochladet?"
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
- Vorher/Nachher: Original vs. Instagram-Upload
|
||
- Sichtbare Qualitätsverluste
|
||
- Warum? → Nächste Folie
|
||
-->
|
||
|
||
---
|
||
|
||
# Warum Instagram eure Fotos "ruiniert"
|
||
|
||
**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
|
||
|
||
**Warum?**
|
||
- Speicherkosten (Milliarden Fotos)
|
||
- Ladezeiten (Mobile-First)
|
||
- Bandbreite (günstiger für alle)
|
||
|
||
<!--
|
||
- Instagram ist keine Kunstgalerie, sondern Massenplattform
|
||
- Optimiert für Geschwindigkeit, nicht Qualität
|
||
- Facebook, Twitter, TikTok – alle machen das
|
||
- Tipp für Fotografen: Portfolio auf eigener Website
|
||
- Diskussion: Ist das fair? Trade-off Nutzer vs. Plattform
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Video
|
||
## Bilder + Zeit + Audio
|
||
|
||
<!--
|
||
- Jetzt wird's richtig interessant
|
||
- Video = viele Bilder + Ton + Synchronisation
|
||
- Das Größenproblem potenziert sich
|
||
- Interaktive Demo: https://claude.ai/public/artifacts/fd58ac94-6b64-4d93-82be-ffb648ed9897
|
||
-->
|
||
|
||
---
|
||
|
||
# Das Größenproblem bei Video
|
||
|
||
**4K-Video (3840×2160), unkomprimiert:**
|
||
|
||
3840 × 2160 × 3 Bytes = **24,8 MB pro Frame**
|
||
|
||
× 30 fps = **744 MB/Sekunde**
|
||
|
||
× 60 Sekunden = **44,6 GB pro Minute**
|
||
|
||
**Ein 2-Stunden-Film: über 5 Terabyte**
|
||
|
||
<!--
|
||
- Rechnung gemeinsam durchgehen
|
||
- Frage: "Wie groß ist ein Netflix-Film typischerweise?" → 3–7 GB
|
||
- Das ist Faktor 1000 Kompression!
|
||
- Ohne Video-Kompression: Kein Streaming, kein YouTube, keine Blu-rays
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: klausur -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
<!-- _backgroundColor: #e3f2fd -->
|
||
|
||
# Container und Codec
|
||
|
||
**Container = Dateiformat (z.B. MP4)**
|
||
Die "Box", die verschiedene Streams zusammenpackt:
|
||
- Video-Stream
|
||
- Audio-Stream(s)
|
||
- Untertitel
|
||
- Metadaten
|
||
|
||
**Codec = Kompressionsalgorithmus (z.B. H.264)**
|
||
Bestimmt, WIE komprimiert wird
|
||
|
||
<!--
|
||
KLAUSURRELEVANT:
|
||
- Container ≠ Codec (häufiges Missverständnis!)
|
||
- MP4 kann H.264, H.265 oder AV1 enthalten
|
||
- Gleiche Endung, unterschiedlicher Inhalt
|
||
- Tool-Tipp: MediaInfo zeigt beides an
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: erklaerung -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
# Container vs. Codec – Vertiefung
|
||
|
||
**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 | Entwickler | 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 |
|
||
|
||
<!--
|
||
- MP4 = MPEG-4 Part 14, ISO-Standard
|
||
- MKV = Matroska (russische Matrjoschka-Puppen)
|
||
- WebM = Subset von Matroska für HTML5
|
||
- MKV beliebt für Filme mit mehreren Sprachen
|
||
- AVI: Bitte nicht mehr verwenden
|
||
-->
|
||
|
||
---
|
||
|
||
# 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 |
|
||
|
||
<!--
|
||
- H.264: De-facto-Standard seit 20 Jahren, Hardware-Decoder überall
|
||
- H.265: 50% besser, aber drei konkurrierende Patent-Pools
|
||
- VP9: Google kaufte On2 Technologies, forciert über YouTube
|
||
- AV1: Alliance for Open Media – die Tech-Giganten vereint
|
||
-->
|
||
|
||
---
|
||
|
||
# Container + Codec = Video
|
||
|
||
```
|
||
┌─────────────────────────────┐
|
||
│ Container (z.B. MP4) │
|
||
│ ┌────────────────────────┐ │
|
||
│ │ Video-Stream (H.264) │ │
|
||
│ ├────────────────────────┤ │
|
||
│ │ Audio-Stream (AAC) │ │
|
||
│ ├────────────────────────┤ │
|
||
│ │ Untertitel (SRT) │ │
|
||
│ ├────────────────────────┤ │
|
||
│ │ Metadaten │ │
|
||
│ └────────────────────────┘ │
|
||
└─────────────────────────────┘
|
||
```
|
||
|
||
<!--
|
||
- Container = Verpackung
|
||
- Codec = wie der Inhalt komprimiert ist
|
||
- Ein MP4 mit H.264 und ein MP4 mit H.265 haben dieselbe Endung
|
||
- Wichtig für Kompatibilität: Player muss Codec unterstützen
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Video-Kompression
|
||
## Raum und Zeit nutzen
|
||
|
||
<!--
|
||
- Video hat zwei Dimensionen der Redundanz:
|
||
1. Räumlich (innerhalb eines Frames) – wie bei JPEG
|
||
2. Zeitlich (zwischen Frames) – neu!
|
||
- Die zeitliche Redundanz ist der Schlüssel
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
- Visualisierung: I/P/B-Frame-Abhängigkeiten
|
||
- I-Frame = Vollbild (Keyframe)
|
||
- P-Frame = Vorwärts-Referenz
|
||
- B-Frame = Bidirektionale Referenz
|
||
- Mehr dazu auf den nächsten Folien
|
||
-->
|
||
|
||
---
|
||
|
||
# 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 = räumlich, innerhalb eines Bildes
|
||
- Temporal = zeitlich, zwischen Bildern
|
||
- Motion Compensation = Bewegungsvektoren
|
||
- 90% eines Frames oft identisch mit dem vorherigen!
|
||
- Kernidee: Warum zweimal speichern, was sich nicht ändert?
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
- I = Intra = innerhalb
|
||
- I-Frames sind groß, aber wichtig für:
|
||
- Seeking (Springen im Video)
|
||
- Fehlerkorrektur
|
||
- Schnitt
|
||
- Typisch alle 1–2 Sekunden ein I-Frame
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
KLAUSURRELEVANT:
|
||
- I = Intra (vollständig)
|
||
- P = Predicted (vorhergesagt aus Vergangenheit)
|
||
- B = Bi-directional (Vergangenheit + Zukunft)
|
||
- B-Frames sind am kleinsten, aber brauchen mehr Rechenleistung
|
||
- GOP-Länge beeinflusst Seeking-Geschwindigkeit
|
||
-->
|
||
|
||
---
|
||
|
||
# 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)"
|
||
|
||
<!--
|
||
- Macroblocks: Typisch 16×16 oder variable Größen
|
||
- Motion Vectors beschreiben Verschiebung
|
||
- Funktioniert gut bei: Kameraschwenks, bewegte Objekte
|
||
- Funktioniert schlecht bei: Szenenwechsel, Konfetti, Feuerwerk
|
||
- Demo: Video Frame für Frame durchgehen
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
- Nochmal das Bild mit dem neuen Wissen betrachten
|
||
- Pfeile zeigen Abhängigkeiten
|
||
- B-Frames referenzieren in beide Richtungen
|
||
- Frage: "Was passiert, wenn ein I-Frame beschädigt ist?"
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: klausur -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
<!-- _backgroundColor: #e3f2fd -->
|
||
|
||
# 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)
|
||
|
||
<!--
|
||
KLAUSURRELEVANT:
|
||
- H.264 revolutionierte Video-Streaming
|
||
- Ohne H.264 kein Netflix, kein YouTube HD
|
||
- Hardware-Decoder = kein CPU-Aufwand, kein Akku-Drain
|
||
- Selbst billigste Smartphones können H.264 abspielen
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: erklaerung -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
# 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. Endnutzer-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
|
||
|
||
<!--
|
||
- MPEG-LA = Licensing Authority
|
||
- Firefox weigerte sich lange, H.264 zu unterstützen
|
||
- "Free to View" gilt nur für Endnutzer-Streaming
|
||
- Diskussion: Sollten Standards patent-frei sein?
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
- Technisch überlegen, aber Lizenz-Albtraum
|
||
- 4K-Streaming wäre ohne H.265/VP9/AV1 nicht praktikabel
|
||
- Apple nutzt HEVC (iPhone-Videos)
|
||
- Netflix zögerte lange
|
||
- Lehre: Technische Überlegenheit reicht nicht
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
- YouTube forciert VP9: 4K-Videos nur in VP9 oder AV1
|
||
- Hardware-Decoder ab ~2016 in GPUs
|
||
- Google's Strategie: Eigene Infrastruktur als Hebel
|
||
- Frage: Ist es gut, wenn ein Konzern Standards setzt?
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!-- _class: klausur -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
<!-- _backgroundColor: #e3f2fd -->
|
||
|
||
# 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
|
||
|
||
<!--
|
||
KLAUSURRELEVANT:
|
||
- AOM gegründet 2015 – historisch: Konkurrenten vereint
|
||
- Ziel: Nie wieder Patent-Chaos wie bei H.265
|
||
- Problem: Encoding sehr langsam (10–100× vs. H.264)
|
||
- Hardware-Encoder lösen das zunehmend
|
||
- AV1 gewann 2024 einen Emmy für technische Innovation
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: erklaerung -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
# 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.
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: 'https://blog.mozilla.org/en/mozilla/av1-video-codec-wins-emmy/' -->
|
||
|
||
|
||
|
||
<!--
|
||
- AV1 gewann 2024 einen Emmy für technische Innovation
|
||
- Anerkennung für offene Standards
|
||
- Zeigt: Open Source kann Industriestandard werden
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Fragen & Diskussion
|
||
|
||
**Kontakt:** lb-czechowski@hdm-stuttgart.de
|
||
**Folien:** [librete.ch/hdm/223015b](https://librete.ch/hdm/223015b/)
|
||
|
||
<!--
|
||
- Offene Fragen?
|
||
- Welches Thema war am überraschendsten?
|
||
- Hinweis auf Selbstlernaufgaben (nächste Folien)
|
||
-->
|
||
|
||
---
|
||
|
||
# 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/)
|
||
|
||
<!--
|
||
- Folien dürfen verwendet und angepasst werden
|
||
- Bedingung: Namensnennung und gleiche Lizenz
|
||
- Fragen zur Lizenz? → Creative Commons Website
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
# 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?
|
||
|
||
<!--
|
||
- Squoosh: Google-Tool zum Vergleichen von Bildformaten
|
||
- Live-Vergleich mit Schieberegler
|
||
- Ziel: Gefühl für Kompressionsraten entwickeln
|
||
- Bonus: Eigene Fotos testen
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
# 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)
|
||
|
||
<!--
|
||
- Big Buck Bunny: Open-Source-Film der Blender Foundation
|
||
- Frei verfügbar, ideal zum Experimentieren
|
||
- MediaInfo zeigt alle technischen Details
|
||
- HandBrake: GUI für FFmpeg, einfacher zu bedienen
|
||
- Experiment: Gleiches Video, verschiedene Codecs vergleichen
|
||
-->
|