rebuild dev and build system with single marp server

- simplify development: single marp server on port 3000 instead of 3 processes - rename klausur to klausurfolien for better naming - update extract script to use 00-intro.md as template when no 01-*.md exists - update makefile and package.json for new workflow - add comprehensive AGENTS.md guidelines
2026-02-01 18:17:51 +01:00
parent 7e4d4a8a4b
commit 9e12447528
11 changed files with 705 additions and 2337 deletions
--- a/slides/223015b/klausurfolien.md
+++ b/slides/223015b/klausurfolien.md
@@ -0,0 +1,458 @@
+---
+marp: true
+theme: gaia
+paginate: true
+backgroundColor: #fff
+header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
+footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
+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;
+}
+</style>
+
+<!--
+  ╔═══════════════════════════════════════════════════════════════════╗
+  ║  AUTO-GENERATED FILE - DO NOT EDIT MANUALLY                       ║
+  ║                                                                   ║
+  ║  This file is generated by: make klausur                          ║
+  ║  Source: scripts/extract-klausur.sh                               ║
+  ║                                                                   ║
+  ║  To update, edit the source slides and re-run make klausur        ║
+  ╚═══════════════════════════════════════════════════════════════════╝
+-->
+
+<!-- _class: invert -->
+<!-- _header: '' -->
+<!-- _backgroundColor: #000 -->
+
+![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
+
+**Wintersemester 2025/26**
+
+[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
+
+---
+
+<!-- _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
+-->