branch-coexist: 3 neue decks 223015b-2026 / 223015c-2026 / dhbw-2026 daneben main

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).

slides/223015b/klausurfolien.md

@@ -97,3 +97,525 @@ Hochschule der Medien Stuttgart
 **Sommersemester 2026**
 
 [https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Verlustfrei vs. Verlustbehaftet
+
+| | Verlustfrei (Lossless) | Verlustbehaftet (Lossy) |
+|---|---|---|
+| **Prinzip** | **Redundanz** entfernen | **Irrelevanz** entfernen |
+| **Reversibel** | Ja (Original wiederherstellbar) | Nein (Information unwiederbringlich weg) |
+| **Reduktion** | 30-50% | 80-99% |
+| **Formate** | ZIP, PNG, FLAC, GIF | JPEG, MP3, H.264/H.265 |
+
+**Faustregel:**
+- Medien für EndnutzerInnen → Lossy oft akzeptabel
+- Quellmaterial, Code, Archive → Lossless nötig
+
+<!--
+REDUNDANZ: Wiederholende Muster kompakter darstellen (z.B. "AAAA" → "4×A")
+IRRELEVANZ: Für Menschen nicht wahrnehmbar (Psychoakustik, Psychovisuell)
+
+KLAUSURRELEVANT:
+- Verlustfrei = Original 1:1 wiederherstellbar
+- Verlustbehaftet = Information geht verloren, aber kaum wahrnehmbar
+- Redundanz vs. Irrelevanz ist der Kernunterschied!
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Dateneinheiten
+
+| Einheit | Bytes | Potenz | Beispiel |
+|---------|------:|:------:|----------|
+| **Byte** | 1 | 10⁰ | Farbwerte eines Pixels |
+| **Kilobyte (KB)** | 1.000 | 10³ | Kleiner Programmcode |
+| **Megabyte (MB)** | 1 Million | 10⁶ | Textdokument |
+| **Gigabyte (GB)** | 1 Milliarde | 10⁹ | Kinofilm in FullHD |
+| **Terabyte (TB)** | 1 Billion | 10¹² | ~12h Video in 4K |
+| **Petabyte (PB)** | 1 Billiarde | 10¹⁵ | Netflix-Gesamtarchiv |
+| **Exabyte (EB)** | 1 Trillion | 10¹⁸ | Alle E-Mails weltweit/Tag |
+| **Zettabyte (ZB)** | 1 Trilliarde | 10²¹ | Internet-Traffic 2016 |
+
+<!--
+SI-Präfixe (Dezimal): 1 KB = 1.000 Bytes
+Binär (IEC): 1 KiB = 1.024 Bytes (Kibibyte)
+Windows zeigt oft binär, sagt aber "KB" → Verwirrung!
+1 TB Festplatte = ~931 GiB nutzbar
+
+Eselsbrücke: "Kilo Mega Giga Tera Peta Exa Zetta Yotta"
+→ "Komm Mit Großem Tee, Peter Exte Zettelt Yachten"
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Der digitale Wendepunkt
+
+| Jahr | Analog | Digital | Digital-Anteil |
+|------|--------|---------|----------------|
+| **1986** | 2,6 EB | 0,02 EB | **1%** |
+| **2002** | — | — | **50%** (Wendepunkt) |
+| **2007** | 18 EB | 277 EB | **94%** |
+
+**Perspektive:**
+- 1986: "Petabyte" war ein theoretisches Konzept
+- 2025: ~181 Zettabyte jährlich produziert
+
+**Magnetband lebt:** LTO-Tapes bleiben günstigstes Archivmedium
+(AWS Glacier, Film-Archive, Rechenzentren)
+
+<!--
+PRÜFUNGSRELEVANT:
+ - Wendepunkt 2002
+ - Speichereinheiten (KB→MB→GB→TB→PB→EB→ZB)
+ - Magnetband als Archivmedium
+
+QUELLE: Hilbert & López (2011): "The World's Technological Capacity to Store, Communicate, and Compute Information", Science
+
+METHODIK: 60 analoge + digitale Technologien untersucht (1986-2007)
+
+WENDEPUNKT 2002: Erstmals mehr digital als analog gespeichert
+
+ANALOG damals: Bücher, Zeitungen, Vinyl, VHS, Filmrollen, Fotos
+
+DIGITAL damals: Festplatten, CDs, DVDs, frühe Flash-Speicher
+
+HEUTE: LTO-9 (2021) speichert 18 TB pro Band, ~$5/TB für Cold Storage
+
+VERGLEICH: SSD ~$50/TB, HDD ~$15/TB, LTO ~$5/TB
+
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Analoge Medien
+### Distribution: physisch (Kauf, Verleih, Kopie)
+
+- **Text**
+    - Bücher, Zeitungen, Zeitschriften, Lochkarten
+- **Bild**
+    - Fotografie (Negativ, Dia, Polaroid), Mikrofilm
+- **Audio:**
+    - Schallplatte (Vinyl, Schellack), Tonband, Musikkassette
+- **Video:**
+    - Film (35mm, Super 8), VHS, Betamax
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Digitale Medien
+### Distribution: Datenträger (CD, USB), Download, Streaming, P2P
+
+- **Text**
+    - E-Book (PDF, EPUB), Dokumente (TXT, DOCX)
+- **Bild**
+    - Digitalfoto (JPEG, PNG, RAW, WebP, GIF)
+- **Audio**
+    - Audiodatei (MP3, FLAC, WAV, AAC, OGG)
+- **Video**
+    - Videodatei (MP4, MKV, AVI, WebM)
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Digitale Speichermedien
+
+- **Optische Speicher**
+    - CD, DVD, Blu-ray
+- **Magnetische Speicher**
+    - Festplatte (HDD), Magnetband (LTO)
+- **Flash-Speicher**
+    - SSD, USB-Stick, SD-Karte
+- **Cloud-Speicher**
+    - Dropbox, Google Drive, iCloud, AWS S3
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# 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)
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# 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)
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# 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)
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+![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
+
+<!--
+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)
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# 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
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+<!--
+# 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: "" -->
+
+
+# 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
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# 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
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# 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
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# 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
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Wann HDD, wann SSD?
+
+| Anwendung | Empfehlung |
+|-----------|------------|
+| Betriebssystem | SSD (NVMe) |
+| Anwendungen, Spiele | SSD |
+| Video-Editing (Projekte) | SSD |
+| Foto-Archiv | HDD oder SSD |
+| Backup | HDD |
+| NAS / Server | HDD (oder Mix) |
+| Cold Storage | HDD oder Band |
+
+<!--
+Die Faustregel:
+- Oft genutzt, schnell gebraucht → SSD
+- Selten genutzt, viel Kapazität → HDD
+
+Viele setzen auf beides:
+Kleine SSD für System + große HDD für Archiv.
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Die 3-2-1-Regel
+
+**3** Kopien eurer Daten
+(Original + 2 Backups)
+
+**2** verschiedene Medientypen
+(z.B. SSD + HDD, oder lokal + Cloud)
+
+**1** Kopie an anderem Ort
+(Offsite: Cloud, anderes Gebäude)
+
+<!--
+Herkunft: Peter Krogh, "The DAM Book" (2005)
+
+Warum 3 Kopien?
+- Original kann kaputt gehen
+- Backup 1 auch
+- Backup 2 = Sicherheitspuffer
+
+Warum 2 Medientypen?
+- Gleiche Medien haben gleiche Schwachstellen
+- Batch-Fehler bei HDDs derselben Charge
+
+Warum 1 Offsite?
+- Brand/Wasserschaden zerstört alles vor Ort
+- Ransomware verschlüsselt angeschlossene Laufwerke
+-->