libretech
351e3dfc23
per user-request einen branch der main-content UND rewrite-content trägt — saubere separierung statt symlink/merge-conflict. struktur: - slides/<course>/ → main-content restored, eigene assets (kein new-demo-leak) - slides/<course>-2026/ → rewrite-content, eigene assets (komplett kopiert + new demos) Makefile: COURSES += 223015b-2026 223015c-2026 dhbw-2026 mit eigenen NAME/KAPITEL/DEPLOY/KLAUSUR-konfig. Klausur für b+c=1, dhbw=leer. Deploy-paths /hdm/223015b-2026 etc. make build durchlaufen für alle 6 decks, 0 fehler. dedup: 223015c+dhbw assets identisch in beiden ordnern (kein neu-demos auf b ergänzt). 223015b 86 → 120 files in -2026 (= +34 neue eroeffner/usb-c-drei-achsen/container-vs-codec/etc).
20 KiB
marp, theme, paginate, backgroundColor, header, footer, title
| marp | theme | paginate | backgroundColor | header | footer | title |
|---|---|---|---|---|---|---|
| true | gaia | true | Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b) | Michael Czechowski – HdM Stuttgart – SoSe 2026 | Kompression |
Kapitel 2
Kompression — Prinzipien und Pipelines
Daten sind unhandlich
Foto-Größenschock
| Variante | Größe | Sichtbarer Unterschied? |
|---|---|---|
| Original aus der iPhone-Kamera (HEIC) | 3,2 MB | — |
| Foto via WhatsApp geteilt | 230 KB | kaum |
| Instagram-Story (komprimiert) | 80 KB | minimal |
| WhatsApp-Profilbild (klein) | 12 KB | sichtbar |
Faktor: bis zu 270×. Wo geht die Information hin?
Erster Weg: Verlustfrei (Lossless)
Prinzip: Redundanz raus
Der Datenstrom enthält oft Wiederholungen — gleiche Pixel, gleiche Buchstaben, gleiche Frequenz-Häppchen.
Lossless-Kompression erkennt diese Redundanz und schreibt sie als Verweis kürzer.
Umkehrbar: beim Dekomprimieren wird die exakte Original-Datei wiederhergestellt.
RLE — Run-Length-Encoding
Eine Bilderzeile in Schwarz/Weiß:
Original: AAAAA BBB CCCCCCCC AAAAAA
(5×A, 3×B, 8×C, 6×A)
Kodiert: 5A 3B 8C 6A
22 Zeichen → 8 Zeichen. Faktor: 2,75×.
Verlustfrei, weil ich aus 5A 3B 8C 6A exakt AAAAABBBCCCCCCCCAAAAAA zurückbekomme.
Wo wird Lossless verwendet?
| Anwendung | Format | Warum verlustfrei? |
|---|---|---|
| Code-Repository, Backup | ZIP, gzip, tar.gz | Jedes Bit muss exakt zurück. |
| Foto-Archiv (RAW) | PNG, TIFF, RAW | Nachbearbeitung soll alle Detail haben. |
| Studio-Master-Track | FLAC, WAV | Für Mastering muss Originalqualität da sein. |
| Logo-Grafiken | PNG, SVG | Scharfe Kanten brauchen Pixelgenauigkeit. |
Faustregel: Werkzeug → Lossless.
Original vs. Fälschung
Eine echte Louis-Vuitton-Tasche und ein perfekter Fake — auf einem Foto unterscheidbar?
Eine lossless-komprimierte Datei vs. das Original — bit-genau identisch.
Bei Lossless gibt es keine Fälschung. Die Kopie ist mathematisch das Original.
Zweiter Weg: Verlustbehaftet (Lossy)
Prinzip: Irrelevanz raus
Was der Mensch nicht wahrnehmen kann, muss man nicht speichern.
Lossy-Kompression wirft genau diese Information weg.
Nicht umkehrbar. Was weg ist, kommt nie zurück. Aus einem MP3 wird nie wieder ein FLAC.
Was nimmt der Mensch nicht wahr?
Ohr (Audio):
- Töne unter ~20 Hz oder über ~20 kHz
- Leise Töne in der Nähe lauter Töne (Maskierung)
- Räumlich-zeitliche Maskierung (z.B. ~200 ms nach lautem Knall)
Auge (Bild):
- Feine Farb-Detail (Chrominanz) abseits scharfer Helligkeitskanten
- Kleinste Helligkeits-Differenzen (~1 Stufe in 256 ist unsichtbar)
- Sehr feine Strukturen jenseits der Sehauflösung
Lossy-Algorithmen modellieren diese Wahrnehmungs-Grenzen — und werfen alles davor weg.
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.
Vergleich: Lossless vs. Lossy
| Eigenschaft | Verlustfrei (Lossless) | Verlustbehaftet (Lossy) |
|---|---|---|
| Was passiert? | Redundanz raus | Irrelevanz raus |
| Umkehrbar? | Ja, bit-genau | Nein, nie wieder |
| Trick | Wiederholungen kürzer kodieren | Wahrnehmung modellieren |
| Typischer Faktor | 2× – 5× | 10× – 100× |
| Anwendung | Archiv, Werkzeug, Code | Stream, Anzeige, Konsum |
| Beispiele | ZIP · PNG · FLAC · RAW | MP3 · JPEG · H.264 · WebP |
Kompressionsraten in der Praxis
| Inhalt | Roh | Komprimiert | Faktor |
|---|---|---|---|
| Foto (12 MP) | 36 MB RAW | 3,5 MB JPEG | ~10× |
| Audio (30 s Stereo) | 5,3 MB WAV | 480 KB MP3 | ~11× |
| Video (1 Min 4K) | 24 GB roh | 200 MB H.264 | ~120× |
| Code-Repo (Java) | 15 MB Quellcode | 1,5 MB ZIP | ~10× |
| Foto (Logo PNG) | 800 KB unkomp. | 80 KB PNG | ~10× |
Lossy bringt mehr — aber Werkzeug muss roh bleiben.
Entscheidungsmatrix — wann nehme ich was?
| Szenario | Empfehlung | Begründung |
|---|---|---|
| Foto-Archiv (DSLR) | RAW (lossless) | Nachbearbeitung muss alle Detail haben |
| Foto im Web/Insta | JPEG / WebP (lossy) | Konsum, Bandbreite zählt |
| Studio-Master | FLAC / WAV (lossless) | Master soll bit-genau bleiben |
| Spotify-Track | AAC / MP3 (lossy) | Konsum, Smartphone-Lautsprecher |
| Code-Backup | ZIP / tar.gz (lossless) | Code muss exakt zurück |
| Lecture-Video | H.264 (lossy) | Konsum, Streaming |
| Logo | PNG / SVG (lossless) | Scharfe Kanten brauchen Pixelgenauigkeit |
Selbstlernen — ZIP-Test mit drei Dateitypen
Drei Dateien gleicher Originalgröße (~1 MB) zippen:
- Textdatei mit wiederholten Mustern (z.B. ein Buch als TXT)
- Unkomprimiertes Bitmap (BMP) desselben Fotos
- JPEG desselben Fotos
Vergleich: Wie groß ist die ZIP-Datei in jedem Fall?
Erwartung: Textdatei wird klein (Wiederholungen), BMP wird klein (Farbflächen), JPEG bleibt fast gleich (schon komprimiert, keine Redundanz mehr).
Warum ZIP auf JPEG nicht mehr komprimiert
JPEG ist bereits maximal lossless-komprimiert.
Die JPEG-Pipeline endet mit Huffman-Coding — derselbe Trick wie in ZIP.
Was ZIP machen würde (Wiederholungen finden, Häufigkeiten kürzer kodieren), hat JPEG schon getan.
Resultat: ZIP einer JPEG-Datei ist nur ~1 % kleiner. Manchmal sogar größer (durch ZIP-Header-Overhead).
