split klausurfragen into per-course files and add erklaerung slides to 223015c
- split slides/klausurfragen.md into course-specific files: - slides/223015b/klausurfragen.md (blocks J-O: dateiformate) - slides/223015c/klausurfragen.md (blocks A-I: it-grundlagen) - add erklaerung slides to 223015c (16 new vertiefung slides) - update erklaerung slides in 223015b with deeper content - update makefile to build klausurfragen per-course - remove global klausurfragen from root index
This commit is contained in:
28
Makefile
28
Makefile
@@ -1,7 +1,7 @@
|
||||
# HdM Slides - Unified Makefile
|
||||
# Supports multiple courses: 223015b (Dateiformate) and 223015c (Internettechnik)
|
||||
|
||||
.PHONY: help dev dev-b dev-c build build-b build-c pdf html klausur clean install deploy qr optimize-images klausurfragen build-klausurfragen deploy-klausurfragen
|
||||
.PHONY: help dev dev-b dev-c build build-b build-c pdf html klausur clean install deploy qr optimize-images
|
||||
|
||||
# Course configuration
|
||||
COURSES = 223015b 223015c
|
||||
@@ -9,11 +9,11 @@ SLIDES_DIR = slides
|
||||
|
||||
# Course-specific settings
|
||||
223015b_NAME = Dateiformate, Schnittstellen, Speichermedien
|
||||
223015b_KAPITEL = 00-intro 01-grundlagen-text-audio 02-bild-audio-video 03-speichermedien-schnittstellen 04-distribution-apis-zukunft 05-vertiefung-offene-fragen klausurfolien
|
||||
223015b_KAPITEL = 00-intro 01-grundlagen-text-audio 02-bild-audio-video 03-speichermedien-schnittstellen 04-distribution-apis-zukunft 05-vertiefung-offene-fragen klausurfolien klausurfragen
|
||||
223015b_DEPLOY_PATH = /home/tengo/html/hdm/223015b
|
||||
|
||||
223015c_NAME = Internettechnologien
|
||||
223015c_KAPITEL = 01-geschichte-grundlagen-html 02-netzwerke-protokolle-css 03-interaktivitaet-javascript klausurfolien
|
||||
223015c_KAPITEL = 01-geschichte-grundlagen-html 02-netzwerke-protokolle-css 03-interaktivitaet-javascript klausurfolien klausurfragen
|
||||
223015c_DEPLOY_PATH = /home/tengo/html/hdm/223015c
|
||||
|
||||
DEPLOY_HOST = tengo@tuttle.uberspace.de
|
||||
@@ -85,18 +85,7 @@ build-b: build/.exists
|
||||
build-c: build/.exists
|
||||
$(call build_course,223015c)
|
||||
|
||||
build-klausurfragen: build/.exists
|
||||
@echo "Building klausurfragen..."
|
||||
@mkdir -p build
|
||||
@if [ -f "$(SLIDES_DIR)/klausurfragen.md" ]; then \
|
||||
echo " Building klausurfragen.md..."; \
|
||||
npx @marp-team/marp-cli "$(SLIDES_DIR)/klausurfragen.md" -o build/klausurfragen.html; \
|
||||
npx @marp-team/marp-cli "$(SLIDES_DIR)/klausurfragen.md" --pdf --allow-local-files -o build/klausurfragen.pdf; \
|
||||
else \
|
||||
echo " Skipping: $(SLIDES_DIR)/klausurfragen.md not found"; \
|
||||
fi
|
||||
|
||||
build: build-b build-c build-klausurfragen
|
||||
build: build-b build-c
|
||||
@echo "All courses built!"
|
||||
|
||||
# HTML only builds
|
||||
@@ -210,20 +199,13 @@ deploy-b: build-b
|
||||
deploy-c: build-c
|
||||
$(call deploy_course,223015c)
|
||||
|
||||
# Deploy klausurfragen (root-level page)
|
||||
deploy-klausurfragen: build-klausurfragen
|
||||
@echo "Deploying klausurfragen..."
|
||||
@scp build/klausurfragen.html $(DEPLOY_HOST):$(HDM_DEPLOY_PATH)/ 2>/dev/null || true
|
||||
@scp build/klausurfragen.pdf $(DEPLOY_HOST):$(HDM_DEPLOY_PATH)/ 2>/dev/null || true
|
||||
@echo "klausurfragen deployed!"
|
||||
|
||||
deploy-index: build-index
|
||||
@echo "Deploying root index..."
|
||||
scp build/index.html $(DEPLOY_HOST):$(HDM_DEPLOY_PATH)/
|
||||
scp build/qr-root.svg $(DEPLOY_HOST):$(HDM_DEPLOY_PATH)/ 2>/dev/null || true
|
||||
@echo "Root index deployed!"
|
||||
|
||||
deploy: build-index deploy-b deploy-c deploy-klausurfragen deploy-index
|
||||
deploy: build-index deploy-b deploy-c deploy-index
|
||||
@echo "All courses deployed!"
|
||||
|
||||
# Clean
|
||||
|
||||
@@ -70,18 +70,23 @@ section.aufgabe footer {
|
||||
}
|
||||
section.erklaerung {
|
||||
font-size: 1.1rem;
|
||||
background: linear-gradient(180deg, #f8fbff 0%, #e8f4fc 100%) !important;
|
||||
border-left: 6px solid #1e5f8a;
|
||||
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.6rem;
|
||||
font-size: 1.5rem;
|
||||
color: #1e5f8a;
|
||||
margin-bottom: 0.5rem;
|
||||
}
|
||||
section.erklaerung h2 {
|
||||
font-size: 1.3rem;
|
||||
color: #1f2937;
|
||||
margin-top: 0;
|
||||
margin-bottom: 0.3rem;
|
||||
}
|
||||
section.erklaerung ul,
|
||||
section.erklaerung ol {
|
||||
@@ -89,11 +94,11 @@ section.erklaerung ol {
|
||||
line-height: 1.4;
|
||||
}
|
||||
section.erklaerung p {
|
||||
font-size: 1.05rem;
|
||||
line-height: 1.5;
|
||||
font-size: 1.0rem;
|
||||
line-height: 1.4;
|
||||
}
|
||||
section.erklaerung table {
|
||||
font-size: 0.95rem;
|
||||
font-size: 0.9rem;
|
||||
}
|
||||
</style>
|
||||
|
||||
@@ -301,23 +306,23 @@ KLAUSURRELEVANT:
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Kompression: Erklaerung
|
||||
# Kompression – Vertiefung
|
||||
|
||||
**Definition:** Kompression reduziert die Dateigroesse durch Entfernen von Redundanz (Lossless) oder Irrelevanz (Lossy).
|
||||
Claude Shannon definierte 1948 die **Entropie** als theoretische Untergrenze der Kompression. Ein Text mit gleichmäßiger Zeichenverteilung hat hohe Entropie (schwer komprimierbar); repetitive Texte haben niedrige Entropie.
|
||||
|
||||
| Typ | Prinzip | Reversibel | Beispiele |
|
||||
|-----|---------|------------|-----------|
|
||||
| **Verlustfrei** | Redundanz entfernen | Ja | ZIP, PNG, FLAC |
|
||||
| **Verlustbehaftet** | Irrelevanz entfernen | Nein | JPEG, MP3, H.264 |
|
||||
**Verlustfreie Kompression** erreicht diese Grenze durch:
|
||||
- **Statistische Kodierung:** Huffman, Arithmetic Coding
|
||||
- **Wörterbuch-Methoden:** LZ77, LZ78, DEFLATE (ZIP, PNG)
|
||||
- Originalzustand ist exakt rekonstruierbar
|
||||
|
||||
**Redundanz:** Wiederholende Muster kompakter darstellen
|
||||
- "AAAA" → "4×A" (Run-Length Encoding)
|
||||
**Verlustbehaftete Kompression** unterschreitet die Grenze, indem sie menschliche Wahrnehmungsgrenzen ausnutzt:
|
||||
|
||||
**Irrelevanz:** Fuer Menschen nicht wahrnehmbare Information entfernen
|
||||
- Psychoakustik: Toene unter Hoerschwelle
|
||||
- Psychovisuell: Farbunterschiede im Randbereich
|
||||
| Sinneskanal | Psychophysisches Modell | Ausnutzung |
|
||||
|-------------|------------------------|------------|
|
||||
| Gehör | Maskierungseffekte, Hörschwelle | MP3: Töne unter Maskierungsschwelle weglassen |
|
||||
| Sehen | Farbauflösung, Kontrastempfindlichkeit | JPEG: Chroma-Subsampling, hohe Frequenzen verwerfen |
|
||||
|
||||
**Merkhilfe:** "Redundanz = Wiederholung, Irrelevanz = Unwichtig"
|
||||
**Shannon-Limit:** Verlustfreie Kompression kann nicht unter die Entropie; verlustbehaftete kann beliebig weit gehen – auf Kosten der Qualität.
|
||||
|
||||
---
|
||||
|
||||
@@ -892,23 +897,22 @@ Eselsbrücke: "Kilo Mega Giga Tera Peta Exa Zetta Yotta"
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Dateneinheiten: Erklaerung
|
||||
# Dateneinheiten – Vertiefung
|
||||
|
||||
**Definition:** Standardisierte Groessenangaben fuer digitale Datenmengen basierend auf SI-Praefixen (Dezimal).
|
||||
Zwei konkurrierende Standards existieren seit der IEC-Normierung 1998:
|
||||
|
||||
| Einheit | Bytes | Potenz | Alltagsbeispiel |
|
||||
|---------|-------|--------|-----------------|
|
||||
| KB | 1.000 | 10³ | Kurze E-Mail |
|
||||
| MB | 1.000.000 | 10⁶ | MP3-Song (~4 MB) |
|
||||
| GB | 1 Milliarde | 10⁹ | HD-Film (~4 GB) |
|
||||
| TB | 1 Billion | 10¹² | Externe Festplatte |
|
||||
| Präfix | SI (Dezimal) | IEC (Binär) | Differenz |
|
||||
|--------|--------------|-------------|-----------|
|
||||
| Kilo | 1.000 (10³) | 1.024 (2¹⁰) KiB | 2,4% |
|
||||
| Mega | 1.000.000 (10⁶) | 1.048.576 MiB | 4,9% |
|
||||
| Giga | 10⁹ | 2³⁰ GiB | 7,4% |
|
||||
| Tera | 10¹² | 2⁴⁰ TiB | 10% |
|
||||
|
||||
**Dezimal vs. Binaer:**
|
||||
- SI (Hersteller): 1 KB = 1.000 Bytes
|
||||
- IEC (Computer): 1 KiB = 1.024 Bytes
|
||||
- Daher: 1 TB Festplatte zeigt nur ~931 GB an
|
||||
**Warum der Unterschied wächst:** (2¹⁰)ⁿ ÷ (10³)ⁿ = 1,024ⁿ. Bei Terabyte sind es bereits 10% Abweichung.
|
||||
|
||||
**Merkhilfe:** "**K**omm **M**it **G**rossem **T**ee, **P**eter **E**xte **Z**ettelt **Y**achten"
|
||||
**Festplatten-Marketing:** Hersteller nutzen SI (dezimal), Betriebssysteme zeigen IEC (binär). Eine „1 TB"-Festplatte zeigt daher nur 931 GiB an – technisch korrekt, aber verwirrend.
|
||||
|
||||
**Historischer Kontext:** RAM wurde immer binär gemessen (2ⁿ Adressen), Festplatten ursprünglich dezimal (physikalische Geometrie). Die IEC führte 1998 KiB/MiB/GiB ein – diese Notation setzt sich langsam durch.
|
||||
|
||||
---
|
||||
|
||||
@@ -982,24 +986,25 @@ VERGLEICH: SSD ~$50/TB, HDD ~$15/TB, LTO ~$5/TB
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Digitaler Wendepunkt: Erklaerung
|
||||
# Digitaler Wendepunkt – Vertiefung
|
||||
|
||||
**Definition:** Der Zeitpunkt, ab dem mehr Daten digital als analog gespeichert wurden.
|
||||
Die Studie von Hilbert & López (Science, 2011) analysierte 60 Speichertechnologien von 1986–2007. Der Wendepunkt 2002 markiert den Moment, ab dem mehr Information digital als analog existierte.
|
||||
|
||||
**Die Meilensteine:**
|
||||
| Jahr | Ereignis |
|
||||
|------|----------|
|
||||
| 1986 | 99% analog, nur 1% digital |
|
||||
| **2002** | **Wendepunkt: 50% digital** |
|
||||
| 2007 | 94% digital, nur 6% analog |
|
||||
| 2025 | ~181 Zettabyte jaehrlich |
|
||||
**Was 1986 „analog" bedeutete:**
|
||||
- Bücher, Zeitungen, Magazine: ~8 EB
|
||||
- Vinyl-Schallplatten, Musikkassetten: ~12 EB
|
||||
- VHS-Kassetten, Filmrollen: ~60 EB
|
||||
|
||||
**Warum Magnetband noch lebt:**
|
||||
- LTO-Tapes: ~5 USD/TB (guenstigstes Archivmedium)
|
||||
- Vergleich: SSD ~50 USD/TB, HDD ~15 USD/TB
|
||||
- Einsatz: AWS Glacier, Filmarchive, Cold Storage
|
||||
**Warum analog stagnierte:** Physische Medien haben Kapazitätsgrenzen. Eine VHS speichert 10 GB; eine Blu-ray (2006) bereits 50 GB auf kleinerer Fläche.
|
||||
|
||||
**Merkhilfe:** "**2002** = **D**igitale **D**ominanz beginnt" (2-0-0-2 = D-D)
|
||||
**LTO-Magnetband überlebt** trotz „alter" Technologie:
|
||||
| Medium | Kosten/TB | Lebensdauer | Energiebedarf |
|
||||
|--------|-----------|-------------|---------------|
|
||||
| SSD | ~50 € | 5–10 Jahre | Dauerstrom |
|
||||
| HDD | ~15 € | 3–5 Jahre aktiv | Dauerstrom |
|
||||
| LTO-9 | ~5 € | 30+ Jahre | Nur beim Zugriff |
|
||||
|
||||
AWS Glacier, Google Coldline und Film-Archive nutzen LTO – langsamer Zugriff, aber unschlagbar günstig und langlebig.
|
||||
|
||||
---
|
||||
|
||||
@@ -1108,23 +1113,22 @@ Visueller Kontrast: Analog vs. Digital
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Analoge Medien: Erklaerung
|
||||
# Analoge Medien – Vertiefung
|
||||
|
||||
**Definition:** Medien, bei denen Information durch kontinuierliche physikalische Groessen (Rillen, Magnetisierung, Licht) gespeichert wird.
|
||||
Analoge Speicherung codiert Information als **kontinuierliche physikalische Größe**: Rillentiefe (Vinyl), Magnetfeldstärke (Tonband), Silberkorn-Dichte (Film). Es gibt keine diskreten Stufen – theoretisch unendliche Auflösung, praktisch begrenzt durch Rauschen.
|
||||
|
||||
| Medium | Typ | Speicherprinzip |
|
||||
|--------|-----|-----------------|
|
||||
| Schallplatte | Audio | Rillen in Vinyl |
|
||||
| Tonband | Audio | Magnetische Partikel |
|
||||
| Film | Video | Lichtempfindliche Emulsion |
|
||||
| VHS | Video | Magnetband |
|
||||
**Generationsverlust** entsteht, weil jede Kopie neues Rauschen addiert:
|
||||
- Schallplatte → Kassette: Frequenzgang leidet, Rauschen steigt
|
||||
- VHS → VHS: Farbsättigung sinkt, Schärfe nimmt ab
|
||||
- 3. Generation: oft unbrauchbar
|
||||
|
||||
**Kernmerkmal Generationsverlust:**
|
||||
- Jede Kopie ist schlechter als das Original
|
||||
- Kassette → Kassette → Kassette = zunehmend schlechter
|
||||
- Das Original bleibt einzigartig
|
||||
| Medium | Typische Auflösung | Dynamik |
|
||||
|--------|-------------------|---------|
|
||||
| Vinyl (audiophil) | ~20–20.000 Hz | ~70 dB |
|
||||
| Tonband (Studio) | ~30–15.000 Hz | ~55 dB |
|
||||
| 35mm Film | ~4K-äquivalent | ~13 Blendenstufen |
|
||||
|
||||
**Distribution:** Physisch (Kauf, Verleih, Kopie von Hand)
|
||||
**Paradox der Analogtechnik:** Das Original ist einzigartig und unersetzlich – aber genau deshalb anfällig. Jedes Abspielen einer Schallplatte trägt mikroskopisch Material ab; jeder Filmdurchlauf riskiert Kratzer.
|
||||
|
||||
---
|
||||
|
||||
@@ -1199,22 +1203,23 @@ Paradox: Gerade die Perfektion wurde zum "Problem"
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Digitale Medien: Erklaerung
|
||||
# Digitale Medien – Vertiefung
|
||||
|
||||
**Definition:** Medien, bei denen Information als diskrete Zahlenwerte (Bits) gespeichert wird.
|
||||
Digitale Speicherung quantisiert kontinuierliche Signale in diskrete Werte. Der **Quantisierungsfehler** (Differenz zum Original) ist der Preis der Digitalisierung – aber einmal digitalisiert, bleibt die Information exakt.
|
||||
|
||||
| Medientyp | Formate | Typische Verwendung |
|
||||
|-----------|---------|---------------------|
|
||||
| Text | PDF, EPUB, DOCX | E-Books, Dokumente |
|
||||
| Bild | JPEG, PNG, WebP | Fotos, Grafiken |
|
||||
| Audio | MP3, FLAC, AAC | Musik, Podcasts |
|
||||
| Video | MP4, MKV, WebM | Filme, Streaming |
|
||||
**Bit-identische Kopien** revolutionierten die Medienindustrie:
|
||||
- Keine Qualitätskette mehr: 1000. Kopie = 1. Kopie = Original
|
||||
- Kosten pro Kopie: praktisch null (nur Speicherplatz)
|
||||
- Perfekte Archivierung: Bits altern nicht (nur der Datenträger)
|
||||
|
||||
**Kernvorteil gegenueber Analog:**
|
||||
- **Identische Kopien** - kein Qualitaetsverlust
|
||||
- Kopie = Original (bit-identisch)
|
||||
| Aspekt | Analog | Digital |
|
||||
|--------|--------|---------|
|
||||
| Kopiervorgang | Physikalischer Prozess | Bit-Kopie |
|
||||
| Qualität pro Generation | Verschlechtert | Identisch |
|
||||
| Fehlerkorrektur | Unmöglich | Möglich (ECC, RAID) |
|
||||
| Formatmigration | Verlust | Verlustfrei möglich |
|
||||
|
||||
**Distribution:** Datentraeger, Download, Streaming, P2P
|
||||
**Die Kehrseite:** Digitale Obsoleszenz. Ein DOCX von 2025 ist in 50 Jahren womöglich unlesbar – während ein Buch von 1525 heute noch lesbar ist. Offene Formate (PDF/A, FLAC, PNG) mildern dieses Risiko.
|
||||
|
||||
---
|
||||
|
||||
@@ -1240,23 +1245,24 @@ Paradox: Gerade die Perfektion wurde zum "Problem"
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Digitale Speichermedien: Erklaerung
|
||||
# Digitale Speichermedien – Vertiefung
|
||||
|
||||
**Definition:** Physische oder virtuelle Medien zur dauerhaften Speicherung digitaler Daten.
|
||||
Jede Technologie hat physikalische Vor- und Nachteile:
|
||||
|
||||
| Kategorie | Technologie | Eigenschaften |
|
||||
|-----------|-------------|---------------|
|
||||
| **Optisch** | CD, DVD, Blu-ray | Laser liest Pits/Lands |
|
||||
| **Magnetisch** | HDD, LTO-Band | Magnetisierte Bereiche |
|
||||
| **Flash** | SSD, USB, SD | Elektrische Ladung in Zellen |
|
||||
| **Cloud** | AWS, Google, Dropbox | Verteilte Server |
|
||||
**Optisch (CD/DVD/Blu-ray):** Laser liest Pits (Vertiefungen) und Lands (Erhöhungen). Robust gegen Magnetfelder, aber empfindlich gegenüber Kratzern und UV-Licht. M-DISC verspricht 1000 Jahre – unter Laborbedingungen.
|
||||
|
||||
**Auswahlkriterien:**
|
||||
- **Geschwindigkeit:** SSD > HDD > Optisch > Band
|
||||
- **Kosten/TB:** Band < HDD < SSD < Cloud
|
||||
- **Haltbarkeit:** Band (~30 Jahre) > Optisch > SSD > HDD
|
||||
**Magnetisch (HDD/LTO):** Magnetisierte Bereiche auf rotierenden Platten oder Band. HDDs haben bewegliche Teile (Verschleiß); LTO-Bänder sind passiv und extrem langlebig, aber sequentieller Zugriff.
|
||||
|
||||
**Merkhilfe:** "**O**ptisch **M**agnetisch **F**lash **C**loud" = OMFC
|
||||
**Flash (SSD/USB/SD):** Elektronen in Floating Gates speichern Bits. Keine beweglichen Teile, aber begrenzte Schreibzyklen (TLC: ~3.000, SLC: ~100.000). Ohne Strom verlieren Zellen nach Jahren ihre Ladung.
|
||||
|
||||
| Szenario | Empfehlung | Grund |
|
||||
|----------|------------|-------|
|
||||
| Betriebssystem | NVMe SSD | Geschwindigkeit |
|
||||
| Videoarchiv | HDD | Kapazität/Preis |
|
||||
| Langzeitarchiv | LTO + M-DISC | Lebensdauer |
|
||||
| Austausch | USB/SD | Portabilität |
|
||||
|
||||
**Cloud** ist physisch HDD/SSD/LTO in Rechenzentren – kein eigenes Medium, sondern Zugriffsmethode.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -70,18 +70,23 @@ section.aufgabe footer {
|
||||
}
|
||||
section.erklaerung {
|
||||
font-size: 1.1rem;
|
||||
background: linear-gradient(180deg, #f8fbff 0%, #e8f4fc 100%) !important;
|
||||
border-left: 6px solid #1e5f8a;
|
||||
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.6rem;
|
||||
font-size: 1.5rem;
|
||||
color: #1e5f8a;
|
||||
margin-bottom: 0.5rem;
|
||||
}
|
||||
section.erklaerung h2 {
|
||||
font-size: 1.3rem;
|
||||
color: #1f2937;
|
||||
margin-top: 0;
|
||||
margin-bottom: 0.3rem;
|
||||
}
|
||||
section.erklaerung ul,
|
||||
section.erklaerung ol {
|
||||
@@ -89,11 +94,11 @@ section.erklaerung ol {
|
||||
line-height: 1.4;
|
||||
}
|
||||
section.erklaerung p {
|
||||
font-size: 1.05rem;
|
||||
line-height: 1.5;
|
||||
font-size: 1.0rem;
|
||||
line-height: 1.4;
|
||||
}
|
||||
section.erklaerung table {
|
||||
font-size: 0.95rem;
|
||||
font-size: 0.9rem;
|
||||
}
|
||||
</style>
|
||||
|
||||
@@ -251,26 +256,19 @@ KLAUSURRELEVANT:
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Rastergrafiken: Erklaerung
|
||||
# Rastergrafik – Vertiefung
|
||||
|
||||
**Definition:** Bilder als zweidimensionales Raster (Array) von Pixeln mit Farbwerten.
|
||||
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 (unkomprimiert):**
|
||||
```
|
||||
Breite × Hoehe × (Farbtiefe ÷ 8) = Bytes
|
||||
```
|
||||
**Speicherberechnung:** `Breite × Höhe × Bytes pro Pixel`
|
||||
|
||||
**Beispiel:** 1920×1080 bei 24 Bit
|
||||
- 1920 × 1080 × 3 = 6.220.800 Bytes ≈ **6,2 MB**
|
||||
| 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 |
|
||||
|
||||
| Farbtiefe | Farben | Anwendung |
|
||||
|-----------|--------|-----------|
|
||||
| 1 Bit | 2 | S/W, Fax |
|
||||
| 8 Bit | 256 | Graustufen, GIF |
|
||||
| 24 Bit | 16,7 Mio | True Color (RGB) |
|
||||
| 32 Bit | 16,7 Mio + Alpha | Transparenz |
|
||||
|
||||
**Merkhilfe:** "24 Bit = 3 Bytes = RGB" (8+8+8)
|
||||
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.
|
||||
|
||||
---
|
||||
|
||||
@@ -332,26 +330,23 @@ KLAUSURRELEVANT:
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Vektorgrafiken: Erklaerung
|
||||
# Vektorgrafik – Vertiefung
|
||||
|
||||
**Definition:** Bilder als mathematische Beschreibung geometrischer Formen (Pfade, Kurven, Formen).
|
||||
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.
|
||||
|
||||
| Eigenschaft | Raster | Vektor |
|
||||
|-------------|--------|--------|
|
||||
| Speicherung | Pixel-Array | Geometrie-Anweisungen |
|
||||
| Skalierung | Qualitaetsverlust | Verlustfrei |
|
||||
| Ideal fuer | Fotos | Logos, Icons |
|
||||
| Formate | JPEG, PNG | SVG, PDF, AI |
|
||||
**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
|
||||
|
||||
**SVG-Beispiel:**
|
||||
```xml
|
||||
<circle cx="50" cy="50" r="40" fill="red"/>
|
||||
```
|
||||
→ Beschreibt WAS, nicht WIE (deklarativ)
|
||||
| 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 |
|
||||
|
||||
**Konvertierung:**
|
||||
- Vektor → Raster: Einfach (Rasterisierung)
|
||||
- Raster → Vektor: Schwierig (Tracing)
|
||||
**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.
|
||||
|
||||
---
|
||||
|
||||
@@ -423,24 +418,21 @@ KLAUSURRELEVANT:
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Psychovisuelle Wahrnehmung: Erklaerung
|
||||
# Psychovisuelle Wahrnehmung – Vertiefung
|
||||
|
||||
**Definition:** Das menschliche Auge hat Schwaechen, die Kompressionsverfahren gezielt ausnutzen.
|
||||
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.
|
||||
|
||||
**Was Menschen schlecht sehen:**
|
||||
| Eigenschaft | Wahrnehmung | JPEG-Strategie |
|
||||
|-------------|-------------|----------------|
|
||||
| Farbe vs. Helligkeit | Helligkeit besser | Farbaufloesung reduzieren |
|
||||
| Hohe Frequenzen | Schlechter | Feine Details verwerfen |
|
||||
| Kleine Unterschiede | Kaum merkbar | Quantisierung |
|
||||
**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
|
||||
|
||||
**Raeumliche Frequenz:**
|
||||
- **Niedrig:** Langsame Aenderung = grosse Flaechen
|
||||
- **Hoch:** Schnelle Aenderung = feine Details, Kanten
|
||||
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.
|
||||
|
||||
**Biologische Grundlage:**
|
||||
- Mehr Staebchen (Helligkeit) als Zapfen (Farbe) im Auge
|
||||
- Aehnlich: Psychoakustik bei MP3 (Maskierungseffekte)
|
||||
| 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 |
|
||||
|
||||
---
|
||||
|
||||
@@ -552,25 +544,27 @@ KLAUSURRELEVANT:
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# JPEG Farbraumkonversion: Erklaerung
|
||||
# Farbraumkonversion – Vertiefung
|
||||
|
||||
**Definition:** Umwandlung von RGB (Rot-Gruen-Blau) in YCbCr (Helligkeit + Farbdifferenzen).
|
||||
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:
|
||||
|
||||
| Kanal | Bedeutung | Behandlung |
|
||||
|-------|-----------|------------|
|
||||
| **Y** | Luminanz (Helligkeit) | Volle Aufloesung behalten |
|
||||
| **Cb** | Blau-Gelb-Differenz | Kann reduziert werden |
|
||||
| **Cr** | Rot-Gruen-Differenz | Kann reduziert werden |
|
||||
```
|
||||
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
|
||||
```
|
||||
|
||||
**Warum diese Trennung?**
|
||||
- Menschliches Auge: empfindlicher fuer Helligkeit als Farbe
|
||||
- Y behaelt volle Aufloesung → Schaerfe erhalten
|
||||
- Cb/Cr reduziert (Chroma Subsampling) → Daten sparen
|
||||
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 4:2:0:**
|
||||
- 4 Pixel teilen sich einen Farbwert
|
||||
- Jeder Pixel behaelt eigene Helligkeit
|
||||
- = 50% Datenreduktion bei kaum sichtbarem Verlust
|
||||
**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.
|
||||
|
||||
---
|
||||
|
||||
@@ -763,25 +757,26 @@ KLAUSURRELEVANT:
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Huffman-Coding: Erklaerung
|
||||
# Huffman-Coding – Vertiefung
|
||||
|
||||
**Definition:** Verlustfreie Kompression durch variable Codelaengen basierend auf Zeichenhaeufigkeit.
|
||||
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.
|
||||
|
||||
**Prinzip:**
|
||||
- Haeufige Zeichen → kurze Codes
|
||||
- Seltene Zeichen → lange Codes
|
||||
- Praefix-frei: Kein Code ist Anfang eines anderen
|
||||
**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
|
||||
|
||||
**Beispiel ABRACADABRA:**
|
||||
| Zeichen | Haeufigkeit | Code |
|
||||
|---------|-------------|------|
|
||||
| A | 5× | `0` (1 Bit) |
|
||||
| B | 2× | `10` (2 Bit) |
|
||||
| R | 2× | `110` (3 Bit) |
|
||||
**Präfixfreiheit:** Kein Code ist Anfang eines anderen → sofort dekodierbar ohne Trennzeichen.
|
||||
|
||||
**Kompression:** 88 Bit → 23 Bit = **74% gespart**
|
||||
| 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) |
|
||||
|
||||
**Einsatz:** JPEG, ZIP, PNG, MP3, DEFLATE
|
||||
JPEG verwendet zwei Huffman-Tabellen: eine für DC-Koeffizienten (Durchschnittswerte), eine für AC-Koeffizienten (Frequenzen). Die Tabellen sind im JPEG-Header gespeichert.
|
||||
|
||||
---
|
||||
|
||||
@@ -931,27 +926,21 @@ KLAUSURRELEVANT:
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# WebP & AVIF: Erklaerung
|
||||
# WebP & AVIF – Vertiefung
|
||||
|
||||
**Definition:** Moderne Bildformate mit besserer Kompression als JPEG.
|
||||
**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.
|
||||
|
||||
| Format | Jahr | Basis | Vorteil |
|
||||
|--------|------|-------|---------|
|
||||
| **WebP** | 2010 | VP8 (Google) | 25-35% kleiner als JPEG |
|
||||
| **AVIF** | 2019 | AV1 | 50% kleiner als JPEG |
|
||||
**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.
|
||||
|
||||
**WebP Features:**
|
||||
- Lossy und Lossless
|
||||
- Transparenz (Alpha)
|
||||
- Animationen (ersetzt GIF)
|
||||
| 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%+ |
|
||||
|
||||
**AVIF Features:**
|
||||
- HDR-Unterstuetzung
|
||||
- Patent-frei (Alliance for Open Media)
|
||||
- Beste Kompression, aber langsamer
|
||||
|
||||
**Browser-Support 2025:** WebP universell, AVIF waechst
|
||||
**Realitaet:** JPEG bleibt dominant (Kompatibilitaet)
|
||||
**Warum JPEG dominiert:** Kameras, Bildbearbeitungssoftware und Content-Management-Systeme sind auf JPEG optimiert. Der Wechsel erfordert Infrastruktur-Updates über die gesamte Pipeline.
|
||||
|
||||
---
|
||||
|
||||
@@ -1077,26 +1066,26 @@ KLAUSURRELEVANT:
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Container vs. Codec: Erklaerung
|
||||
# Container vs. Codec – Vertiefung
|
||||
|
||||
**Definition:** Container und Codec sind zwei verschiedene Konzepte bei Videodateien.
|
||||
**Container** (Multiplexer-Format) organisiert mehrere Datenströme mit Timing-Informationen. Er enthält keine Kompressionslogik, sondern synchronisiert Video, Audio, Untertitel und Metadaten.
|
||||
|
||||
| Begriff | Bedeutung | Beispiele |
|
||||
|---------|-----------|-----------|
|
||||
| **Container** | Dateiformat/"Box" | MP4, MKV, WebM, MOV |
|
||||
| **Codec** | Kompressionsalgorithmus | H.264, H.265, VP9, AV1 |
|
||||
**Codec** (Coder-Decoder) definiert den Kompressionsalgorithmus. Derselbe Container kann verschiedene Codecs enthalten – die Dateiendung verrät den Codec nicht.
|
||||
|
||||
**Container enthaelt:**
|
||||
- Video-Stream (komprimiert mit Codec)
|
||||
- Audio-Stream(s)
|
||||
- Untertitel
|
||||
- Metadaten (Kapitel, Thumbnail)
|
||||
| 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 |
|
||||
|
||||
**Wichtig:** Gleiche Endung ≠ gleicher Inhalt!
|
||||
- film.mp4 kann H.264, H.265 oder AV1 enthalten
|
||||
- Tool-Tipp: **MediaInfo** zeigt beides an
|
||||
**Metadaten im Container:**
|
||||
- Timecodes für Frame-genaue Synchronisation
|
||||
- Kapitelmarken, Thumbnails
|
||||
- Sprach-Tags für Audio/Untertitel
|
||||
- HDR-Metadaten (MaxCLL, MaxFALL)
|
||||
|
||||
**Merkhilfe:** "Container = Schachtel, Codec = Verpackungsart"
|
||||
**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.
|
||||
|
||||
---
|
||||
|
||||
@@ -1329,26 +1318,25 @@ KLAUSURRELEVANT:
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# H.264/AVC: Erklaerung
|
||||
# H.264/AVC – Vertiefung
|
||||
|
||||
**Definition:** Der dominierende Video-Codec seit 2003, der modernes Video-Streaming erst ermoeglichte.
|
||||
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.
|
||||
|
||||
**Warum so erfolgreich?**
|
||||
| Eigenschaft | Bedeutung |
|
||||
|-------------|-----------|
|
||||
| Kompression | ~100:1 moeglich |
|
||||
| Hardware | Decoder in jedem Geraet seit ~2010 |
|
||||
| Verbreitung | YouTube, Netflix, Blu-ray |
|
||||
**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)
|
||||
|
||||
**Technische Features:**
|
||||
- Variable Block-Groessen (16×16 bis 4×4)
|
||||
- Deblocking-Filter (reduziert Blocking-Artefakte)
|
||||
- I-, P-, B-Frames (temporale Kompression)
|
||||
| Profile | Anwendung | Max. Auflösung |
|
||||
|---------|-----------|----------------|
|
||||
| Baseline | Videotelefonie, ältere Geräte | 480p |
|
||||
| Main | Broadcast, Streaming | 1080p |
|
||||
| High | Blu-ray, professionell | 4K |
|
||||
|
||||
**Patent-Situation:**
|
||||
- MPEG-LA Pool: 2000+ Patente
|
||||
- "Internet Broadcast" fuer Endnutzer kostenlos
|
||||
- Hardware-Decoder: ~$0,20/Geraet
|
||||
**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.
|
||||
|
||||
---
|
||||
|
||||
@@ -1462,26 +1450,22 @@ KLAUSURRELEVANT:
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# AV1: Erklaerung
|
||||
# AV1 – Vertiefung
|
||||
|
||||
**Definition:** Der offene, lizenzfreie Video-Codec der Zukunft, entwickelt von der Alliance for Open Media.
|
||||
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.
|
||||
|
||||
**Alliance for Open Media (AOM):**
|
||||
- Gegruendet 2015: Google, Netflix, Amazon, Microsoft, Apple, Mozilla
|
||||
- Ziel: Patent-freier Standard nach H.265-Chaos
|
||||
**Gründungsmitglieder:** Google, Mozilla, Cisco, Netflix, Amazon, Microsoft. Apple trat 2018 bei – historisch, da Apple sonst eigene Standards bevorzugt.
|
||||
|
||||
| Eigenschaft | AV1 |
|
||||
|-------------|-----|
|
||||
| Effizienz | 30% besser als H.265 |
|
||||
| Lizenz | Royalty-free, Open Source |
|
||||
| Features | 8K, HDR, hohe Frame-Rates |
|
||||
| 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 |
|
||||
|
||||
**Stand 2025:**
|
||||
- YouTube, Netflix nutzen AV1 fuer 4K/8K
|
||||
- Hardware-Encoder in aktuellen GPUs
|
||||
- Emmy-Gewinner 2024 fuer technische Innovation
|
||||
**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.
|
||||
|
||||
**Nachteil:** Encoding sehr langsam (Hardware loest das)
|
||||
**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.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -70,18 +70,23 @@ section.aufgabe footer {
|
||||
}
|
||||
section.erklaerung {
|
||||
font-size: 1.1rem;
|
||||
background: linear-gradient(180deg, #f8fbff 0%, #e8f4fc 100%) !important;
|
||||
border-left: 6px solid #1e5f8a;
|
||||
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.6rem;
|
||||
font-size: 1.5rem;
|
||||
color: #1e5f8a;
|
||||
margin-bottom: 0.5rem;
|
||||
}
|
||||
section.erklaerung h2 {
|
||||
font-size: 1.3rem;
|
||||
color: #1f2937;
|
||||
margin-top: 0;
|
||||
margin-bottom: 0.3rem;
|
||||
}
|
||||
section.erklaerung ul,
|
||||
section.erklaerung ol {
|
||||
@@ -89,11 +94,11 @@ section.erklaerung ol {
|
||||
line-height: 1.4;
|
||||
}
|
||||
section.erklaerung p {
|
||||
font-size: 1.05rem;
|
||||
line-height: 1.5;
|
||||
font-size: 1.0rem;
|
||||
line-height: 1.4;
|
||||
}
|
||||
section.erklaerung table {
|
||||
font-size: 0.95rem;
|
||||
font-size: 0.9rem;
|
||||
}
|
||||
</style>
|
||||
|
||||
@@ -266,22 +271,22 @@ Kleine SSD für System + große HDD für Archiv.
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# HDD vs. SSD: Erklaerung
|
||||
# HDD vs. SSD – Vertiefung
|
||||
|
||||
**Kernunterschied:** HDD = mechanisch (Magnetplatten), SSD = elektronisch (Flash-Speicher)
|
||||
**HDD (Hard Disk Drive):** Magnetplatten rotieren mit 5.400–7.200 RPM; ein Schreib-/Lesekopf schwebt nanometerweit über der Oberfläche. Die Zugriffszeit setzt sich zusammen aus Seek Time (Kopf bewegen) + Rotational Latency (warten auf Sektor).
|
||||
|
||||
| Eigenschaft | HDD | SSD |
|
||||
|-------------|-----|-----|
|
||||
| Zugriffszeit | ~10 ms | ~0.1 ms |
|
||||
| Seq. Lesen | ~150 MB/s | ~500-7000 MB/s |
|
||||
| Preis/TB | guenstig | teurer |
|
||||
| Haltbarkeit | mechanisch anfaellig | Schreibzyklen begrenzt |
|
||||
**SSD (Solid State Drive):** NAND-Flash-Zellen speichern Bits als elektrische Ladung. Kein mechanischer Zugriff → konstant schnelle Latenz. Aber: Zellen haben begrenzte Schreibzyklen (P/E Cycles).
|
||||
|
||||
**Entscheidungsregel:**
|
||||
- **SSD:** Haeufiger Zugriff, Geschwindigkeit wichtig (OS, Apps, aktive Projekte)
|
||||
- **HDD:** Grosse Datenmengen, selten genutzt (Archiv, Backup, Cold Storage)
|
||||
| Aspekt | HDD | SATA SSD | NVMe SSD |
|
||||
|--------|-----|----------|----------|
|
||||
| Latenz | 5–10 ms | 0,1 ms | 0,02 ms |
|
||||
| Seq. Lesen | 150 MB/s | 550 MB/s | 7.000 MB/s |
|
||||
| IOPS (4K random) | 100 | 90.000 | 1.000.000 |
|
||||
| TBW (1 TB Modell) | ∞ | 600 TBW | 600 TBW |
|
||||
|
||||
**Merkhilfe:** "Schnell = SSD, Speicher = HDD"
|
||||
**Wear Leveling:** SSD-Controller verteilen Schreibvorgänge gleichmäßig, um einzelne Zellen nicht vorzeitig zu erschöpfen. TRIM informiert den Controller über gelöschte Blöcke.
|
||||
|
||||
**Praxis:** System-SSD für OS/Anwendungen (Geschwindigkeit), HDD für Medienarchiv (Kapazität/Preis). RAID schützt vor Einzelausfällen bei beiden.
|
||||
|
||||
---
|
||||
|
||||
@@ -538,24 +543,23 @@ Warum 1 Offsite?
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# 3-2-1-Backup-Regel: Erklaerung
|
||||
# 3-2-1-Backup-Regel – Vertiefung
|
||||
|
||||
**Definition:** Bewährte Strategie zur Datensicherung gegen unterschiedliche Verlustszenarien.
|
||||
Peter Krogh formulierte die Regel 2005 in „The DAM Book" (Digital Asset Management). Sie schützt gegen unterschiedliche Verlustszenarien:
|
||||
|
||||
| Element | Bedeutung | Schutz gegen |
|
||||
|---------|-----------|--------------|
|
||||
| **3** Kopien | Original + 2 Backups | Hardware-Defekt |
|
||||
| **2** Medientypen | z.B. SSD + HDD | Medienspezifische Fehler |
|
||||
| **1** Offsite | Anderer Ort/Cloud | Lokale Katastrophen |
|
||||
| Bedrohung | Schutz durch | Beispiel |
|
||||
|-----------|--------------|----------|
|
||||
| Hardware-Defekt | 3 Kopien | SSD stirbt → HDD-Backup vorhanden |
|
||||
| Firmware-Bug/Ransomware | 2 Medientypen | Malware infiziert nur ein System |
|
||||
| Feuer/Diebstahl/Flut | 1 Offsite | Haus brennt → Cloud-Backup sicher |
|
||||
|
||||
**Beispiel-Setup:**
|
||||
1. Arbeitsdaten auf SSD (Original)
|
||||
2. Externes Backup auf HDD (lokal)
|
||||
3. Cloud-Backup bei Anbieter (offsite)
|
||||
**Moderne Erweiterung 3-2-1-1-0:**
|
||||
- **+1** Air-Gapped (offline, nicht verbunden)
|
||||
- **+0** Verifizierte Backups (regelmäßig Restore testen)
|
||||
|
||||
**Merkhilfe:** "3 Kopien, 2 Medien, 1 woanders"
|
||||
**Ransomware-Problem:** Vernetzte Backups werden oft mitverschlüsselt. Air-Gapped-Medien (externe HDD im Safe, LTO-Band) bleiben sicher, weil sie physisch getrennt sind.
|
||||
|
||||
**Herkunft:** Peter Krogh, "The DAM Book" (2005) - gilt bis heute als Goldstandard.
|
||||
**Realitäts-Check:** Die meisten Datenverluste entstehen durch menschliche Fehler (versehentliches Löschen), nicht Hardware-Ausfälle. Versionierte Backups (Time Machine, Borg) schützen auch davor – die gelöschte Datei existiert noch in älteren Snapshots.
|
||||
|
||||
---
|
||||
|
||||
|
||||
977
slides/223015b/klausurfragen.md
Normal file
977
slides/223015b/klausurfragen.md
Normal file
@@ -0,0 +1,977 @@
|
||||
---
|
||||
marp: true
|
||||
theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: ""
|
||||
footer: ""
|
||||
title: "Fragenkatalog – Dateiformate (223015b)"
|
||||
---
|
||||
<style>
|
||||
:root {
|
||||
--color-foreground: #1a1a2e;
|
||||
--color-highlight: #1e5f8a;
|
||||
--color-dimmed: #4a4a6a;
|
||||
}
|
||||
section.invert {
|
||||
--color-foreground: #fff;
|
||||
}
|
||||
section {
|
||||
font-size: 1.325rem;
|
||||
}
|
||||
h1 {
|
||||
color: #1e5f8a;
|
||||
}
|
||||
section.invert h1 {
|
||||
color: #fff;
|
||||
}
|
||||
h2 {
|
||||
color: #1f2937; /* dark gray, almost black */
|
||||
}
|
||||
pre {
|
||||
background: #0f0f23;
|
||||
border-radius: 8px;
|
||||
}
|
||||
pre code {
|
||||
background: transparent;
|
||||
color: inherit;
|
||||
}
|
||||
a {
|
||||
color: var(--color-highlight);
|
||||
}
|
||||
section.disable {
|
||||
opacity: 0.3;
|
||||
}
|
||||
</style>
|
||||
|
||||
|
||||
# Klausurfragen – 223015b
|
||||
**Dateiformate, Schnittstellen, Speichermedien · HdM Stuttgart · M. Czechowski**
|
||||
|
||||
<small>Stand: 01.02.2026</small>
|
||||
|
||||
---
|
||||
|
||||
> **Legende – Moodle XML-Typen:**
|
||||
> `[MC]` = `multichoice` (einzelne Auswahl)
|
||||
> `[MM]` = `multichoice` + `<single>false</single>` (Mehrfachauswahl)
|
||||
> `[MATCH]` = `matching` (Zuordnung)
|
||||
> `[ORDER]` = `ordering` (Reihenfolge)
|
||||
> `[ESSAY]` = `essay` (Freitext, manuell bewertet)
|
||||
> `[SHORTANS]` = `shortanswer` (Stichwort/Satz, automatisch geprüft)
|
||||
> `[NUMERIC]` = `numerical` (Zahlenwert ± Toleranz)
|
||||
> `[CLOZE]` = `cloze` (Lückentext, gemischt)`
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK J – Dateiformate: Grundbegriffe
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### J1 – Was bedeutet „komprimieren"?
|
||||
**Thema:** Grundbegriffe – Kompression
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was bedeutet es, eine Datei zu komprimieren?
|
||||
|
||||
- [ ] Die Datei wird auf einem anderen Speichermedium gesichert.
|
||||
- [x] **Die Dateigröße wird durch Entfernung oder Vereinfachung von Daten reduziert.** ✅
|
||||
- [ ] Die Datei wird verschlüsselt, damit sie kleiner aussieht.
|
||||
- [ ] Die Datei wird in ein anderen Format umgewandelt, ohne dass sich die Größe ändert.
|
||||
|
||||
> **Feedback:** Kompression = Dateigröße reduzieren. Zwei Familien: verlustfrei (alle Daten bleiben erhalten, z. B. ZIP, PNG) und verlustbehaftet (Daten werden dauerhaft weggeworfen, z. B. JPEG, MP3).
|
||||
|
||||
---
|
||||
|
||||
### J2 – Verlustfrei vs. verlustbehaftet
|
||||
**Thema:** Grundbegriffe – Kompressionsprimitiven
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jedem Format zu, ob es verlustfrei oder verlustbehaftet komprimiert.
|
||||
|
||||
| Format | Kompressions-Typ |
|
||||
|---|---|
|
||||
| JPEG | Verlustbehaftet |
|
||||
| PNG | Verlustfrei |
|
||||
| MP3 | Verlustbehaftet |
|
||||
| ZIP | Verlustfrei |
|
||||
| FLAC | Verlustfrei |
|
||||
| WebP (lossy) | Verlustbehaftet |
|
||||
|
||||
> **Feedback:** Verlustfrei = Originaldaten perfekt rekonstruierbar (ZIP, PNG, FLAC). Verlustbehaftet = Daten dauerhaft weggeworfen, nicht mehr zurückholbar (JPEG, MP3).
|
||||
|
||||
---
|
||||
|
||||
### J3 – Verlustfrei vs. verlustbehaftet: Erkläre
|
||||
**Thema:** Grundbegriffe – Konzept
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erkläre den Unterschied zwischen verlustfreier und verlustbehafteter Kompression. Nenne je ein konkretes Beispiel und erkläre, warum man in unterschiedlichen Situationen unterschiedliche Kompressionstypen wählt.
|
||||
|
||||
> **Musterlösung:** Verlustfrei: Alle Originaldaten bleiben erhalten – die Datei kann perfekt rekonstruiert werden (z. B. ZIP, PNG). Verlustbehaftet: Daten werden dauerhaft weggeworfen – die Datei kann nicht mehr perfekt hergestellt werden (z. B. JPEG, MP3). Wahl: Fotos fürs Web → JPEG (verlustbehaftet), weil der Unterschied kaum sichtbar ist und die Datei deutlich kleiner wird. Archivierung oder Grafiken → PNG (verlustfrei), weil Qualitätsverlust inakzeptabel wäre.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### J4 – Was bedeutet „skalieren"?
|
||||
**Thema:** Grundbegriffe – Skalierung
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was passiert, wenn ein Rasterbild vergrößert wird?
|
||||
|
||||
- [ ] Neue Pixel werden aus dem Dateiformat automatisch geladen.
|
||||
- [x] **Fehlende Pixel müssen durch Interpolation „erfunden" werden – es entsteht keine neue Information.** ✅
|
||||
- [ ] Das Bild wird verlustfrei größer, weil Pixel automatisch duplifiziert werden.
|
||||
- [ ] Die Dateigröße bleibt gleich, nur der Zoom im Betrachter ändert sich.
|
||||
|
||||
> **Feedback:** Ein Rasterbild hat eine native Auflösung. Alles darüber hinaus = Schätzung (Interpolation). Deshalb werden vergrößerte Rasterbilder unscharf – es gibt einfach keine Daten für die fehlenden Pixel.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### J5 – Was bedeutet „konvertieren"?
|
||||
**Thema:** Grundbegriffe – Konvertierung
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was bedeutet es, eine Datei zu konvertieren?
|
||||
|
||||
- [ ] Die Datei wird komprimiert und umbenannt.
|
||||
- [x] **Die Daten werden von einem Format in ein anderes umgewandelt (z. B. JPEG → PNG, MP4 → WebM).** ✅
|
||||
- [ ] Die Datei wird verschlüsselt und in ein neues Format gepackt.
|
||||
- [ ] Die Dateiendung wird umbenannt, ohne dass sich der Inhalt ändert.
|
||||
|
||||
> **Feedback:** Konvertierung = Format-Umwandlung. Der Inhalt bleibt inhaltlich gleich, aber die Art der Speicherung (Kompression, Struktur) ändert sich. Wichtig: Eine Dateiendung umzubenennen ist KEINE Konvertierung.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### J6 – Was bedeutet „codieren" und „decodieren"?
|
||||
**Thema:** Grundbegriffe – Codec-Konzept
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erkläre, was „codieren" und „decodieren" bedeuten. Erkläre anschließend, warum der Begriff „Codec" aus beiden Wörtern zusammengesetzt ist, und nenne ein konkretes Beispiel.
|
||||
|
||||
> **Musterlösung:** Codieren = Daten in ein bestimmtes Format umwandeln (z. B. Rohvideodaten → H.264-komprimiertes Video). Decodieren = das Gegenteil: komprimierte Daten wieder in abspielbare Form zurückwandeln (z. B. H.264 → Pixeldaten für den Bildschirm). Codec = Co(der) + Dec(oder) – ein Algorithmus, der beides kann. Beispiel: H.264 ist ein Video-Codec: Der Encoder erzeugt die komprimierte Datei, der Decoder im Player spielt sie wieder ab.
|
||||
|
||||
---
|
||||
|
||||
### J7 – Codec vs. Container
|
||||
**Thema:** Grundbegriffe – Codec/Container-Unterschied
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was ist der Unterschied zwischen einem Container und einem Codec bei Videodateien?
|
||||
|
||||
- [ ] Container und Codec sind synonyme Begriffe für das gleiche Konzept.
|
||||
- [x] **Der Container (z. B. MP4) ist die „Verpackung", die verschiedene Streams zusammenpackt. Der Codec (z. B. H.264) bestimmt, wie der Video-Stream komprimiert wird.** ✅
|
||||
- [ ] Der Codec ist die Dateiendung, der Container der Kompressionsalgorithmus.
|
||||
- [ ] Ein Container enthält immer genau einen Codec – es kann keine Kombination geben.
|
||||
|
||||
> **Feedback:** Container ≠ Codec. Ein MP4-Container kann H.264, H.265 oder AV1 enthalten. Gleiche Endung `.mp4`, unterschiedlicher Inhalt. Der Container packt zusammen (Video, Audio, Untertitel, Metadaten), der Codec komprimiert.
|
||||
|
||||
---
|
||||
|
||||
### J8 – Codec vs. Container: Zuordnung
|
||||
**Thema:** Grundbegriffe – Codec/Container-Zuordnung
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne zu: Container oder Codec?
|
||||
|
||||
| Name | Typ |
|
||||
|---|---|
|
||||
| MP4 | Container |
|
||||
| H.264 | Codec |
|
||||
| WebM | Container |
|
||||
| AV1 | Codec |
|
||||
> **Feedback:** Container = Dateiformat, das Streams zusammenpackt (MP4, MKV, WebM). Codec = Kompressionsalgorithmus für einen bestimmten Stream (H.264, AV1, AAC).
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### J9 – Redundanz vs. Irrelevanz
|
||||
**Thema:** Grundbegriffe – Kompressionsprinzipien
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Verlustfreie und verlustbehaftete Kompression arbeiten nach unterschiedlichen Prinzipien. Ordne zu.
|
||||
|
||||
| Prinzip | Kompressionstyp |
|
||||
|---|---|
|
||||
| Redundanz entfernen (wiederholende Muster kompakter darstellen) | Verlustfrei |
|
||||
| Irrelevanz entfernen (für Menschen nicht wahrnehmbar) | Verlustbehaftet |
|
||||
|
||||
> **Feedback:** Der Kernunterschied: Verlustfrei arbeitet mit Redundanz – Wiederholungen werden kompakter gespeichert, aber nichts geht verloren. Verlustbehaftet arbeitet mit Irrelevanz – Daten werden weggeworfen, die Menschen sowieso nicht wahrnehmen können (Psychovisuell bei Bildern, Psychoakustisch bei Audio).
|
||||
|
||||
---
|
||||
|
||||
### J10 – Dateneinheiten: Größenordnungen
|
||||
**Thema:** Grundbegriffe – Speichereinheiten
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ORDER]`
|
||||
|
||||
Sortiere die Dateneinheiten von kleinster zu größter:
|
||||
|
||||
1. Byte
|
||||
2. Kilobyte (KB)
|
||||
3. Megabyte (MB)
|
||||
4. Gigabyte (GB)
|
||||
5. Terabyte (TB)
|
||||
6. Petabyte (PB)
|
||||
|
||||
> **Feedback:** Jede Stufe = Faktor 1.000 (SI-Präfixe). Merkhilfe: „Komm Mit Großem Tee, Peter". Ein einzelnes Foto (12 MP, unkomprimiert) ≈ 36 MB. Ein FullHD-Kinofilm ≈ 1 GB. Ein 4K-Film pro Minute unkomprimiert ≈ 44 GB.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### J11 – Bit und Byte: Umrechnung
|
||||
**Thema:** Grundbegriffe – Bit/Byte-Verhältnis
|
||||
**Punkte:** 1
|
||||
**Typ:** `[NUMERIC]`
|
||||
|
||||
Ein Bit ist die kleinste Informationseinheit. Ein Byte besteht aus wie vielen Bit?
|
||||
|
||||
**Lösung:** **8** (±0)
|
||||
|
||||
> **Feedback:** 1 Byte = 8 Bit. Ein Byte kann einen Wert von 0 bis 255 darstellen (2⁸ − 1). Die Unterscheidung Bit/Byte ist fundamental – Bit wird mit kleinem „b" abgekürzt (b), Byte mit großem „B" (B). Deshalb: 1 Mbit/s ≠ 1 MB/s.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### J12 – 7-Bit ASCII: Wie viele Zeichen?
|
||||
**Thema:** Grundbegriffe – ASCII-Zeichenkodierung
|
||||
**Punkte:** 1
|
||||
**Typ:** `[NUMERIC]`
|
||||
|
||||
Der ASCII-Standard verwendet 7 Bit pro Zeichen. Wie viele verschiedene Zeichen können damit dargestellt werden?
|
||||
|
||||
**Lösung:** **128** (±0)
|
||||
|
||||
> **Feedback:** Bei n Bit gibt es 2ⁿ mögliche Werte. 7 Bit → 2⁷ = 128 Zeichen. Diese umfassen: Ziffern (0–9), Buchstaben (A–Z, a–z), Sonderzeichen und Steuerzeichen. Achtung: Umlaute (ä, ö, ü) sind nicht im ASCII-Sortiment – dafür braucht man z. B. UTF-8.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### J13 – Hexadezimalzahlen: Zwei 4-Bit-Werte
|
||||
**Thema:** Grundbegriffe – Hexadezimal
|
||||
**Punkte:** 2
|
||||
**Typ:** `[NUMERIC]`
|
||||
|
||||
Zwei Hexadezimalzahlen werden jeweils durch 4 Bit dargestellt. Wie viele verschiedene Werte kann eine einzelne Hexadezimalziffer annehmen?
|
||||
|
||||
**Lösung:** **16** (±0)
|
||||
|
||||
> **Feedback:** 4 Bit → 2⁴ = 16 Werte (0–15). Diese werden in Hexadezimal als 0–9 und A–F dargestellt. Zwei Hex-Ziffern zusammen = 8 Bit = 1 Byte → ein Byte lässt sich immer als genau zwei Hex-Ziffern schreiben (z. B. Byte 255 = FF, Byte 10 = 0A).
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### J14 – Ein Pixel, drei Kanäle, 8 Bit
|
||||
**Thema:** Grundbegriffe – Speicherbedarf eines Pixels
|
||||
**Punkte:** 1
|
||||
**Typ:** `[NUMERIC]`
|
||||
|
||||
Ein einzelner Pixel wird durch drei Farbkanäle (R, G, B) mit jeweils 8 Bit Farbtiefe gespeichert. Wie viele Byte Informationen enthalten ein solcher Pixel?
|
||||
|
||||
**Lösung:** **3** (±0)
|
||||
|
||||
> **Feedback:** 3 Kanäle × 8 Bit = 24 Bit = 3 Byte pro Pixel. Das entspricht einer 24-Bit-Farbtiefe (True Color). Diese 3 Byte pro Pixel bilden die Basis für jede Speicherberechnung von Rasterbildern: Breite × Höhe × 3 Bytes = Gesamtgröße unkomprimiert.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK K – Bildformate & Raster vs. Vektor
|
||||
|
||||
---
|
||||
|
||||
### K1 – Was ist ein Pixel?
|
||||
**Thema:** Digitale Bilder – Grundbegriffe
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was ist ein Pixel in einem digitalen Bild?
|
||||
|
||||
- [ ] Ein winziges physisches Kameraobjektiv.
|
||||
- [x] **Ein einzelner Farbpunkt in einem Rasterbild – der kleinste Baustein.** ✅
|
||||
- [ ] Eine Einheit zur Messung der Dateigröße.
|
||||
- [ ] Ein Synonym für eine Farbe im RGB-Farbraum.
|
||||
|
||||
> **Feedback:** Pixel = Picture Element. Ein digitales Rasterbild ist ein 2D-Array aus Pixeln, jeder mit einem Farbwert (z. B. RGB).
|
||||
|
||||
---
|
||||
|
||||
### K2 – Speicherbedarf berechnen
|
||||
**Thema:** Rastergrafiken – Berechnung
|
||||
**Punkte:** 2
|
||||
**Typ:** `[NUMERIC]`
|
||||
|
||||
Ein Bild ist 1920 × 1080 Pixel groß und nutzt 24-Bit-Farbtiefe (True Color). Wie groß ist das Bild unkomprimiert in Megabyte? (Runde auf eine Dezimalstelle)
|
||||
|
||||
**Formel:** Breite × Höhe × (Farbtiefe / 8) = Bytes
|
||||
|
||||
**Lösung:** 1920 × 1080 × 3 = 6.220.800 Bytes ≈ **6,2 MB** (±0,1)
|
||||
|
||||
> **Feedback:** 24 Bit = 3 Bytes pro Pixel (8 Bit pro Kanal: R, G, B). 1920 × 1080 = 2.073.600 Pixel × 3 Bytes = 6.220.800 Bytes. Durch 1.000.000 ≈ 6,2 MB.
|
||||
|
||||
---
|
||||
|
||||
### K3 – Farbtiefe: Bedeutung
|
||||
**Thema:** Rastergrafiken – Farbtiefe
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jeder Farbtiefe ihre Bedeutung zu.
|
||||
|
||||
| Farbtiefe | Bedeutung |
|
||||
|---|---|
|
||||
| 1 Bit | 2 Farben (Schwarz/Weiß) |
|
||||
| 8 Bit | 256 Farben (Graustufen, GIF) |
|
||||
| 24 Bit | 16,7 Millionen Farben (True Color, Standard) |
|
||||
| 32 Bit | 16,7 Millionen Farben + Alpha (Transparenz) |
|
||||
|
||||
> **Feedback:** Bei n Bit gibt es 2ⁿ mögliche Werte. 24 Bit = 8 Bit pro Kanal (R, G, B). 32 Bit = 24 Bit Farbe + 8 Bit Alpha-Kanal für Transparenz.
|
||||
|
||||
---
|
||||
|
||||
### K4 – Was ist Alpha-Transparenz?
|
||||
**Thema:** Rastergrafiken – Transparenz
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was bedeutet ein 32-Bit-Bild gegenüber einem 24-Bit-Bild?
|
||||
|
||||
- [ ] Es hat doppelt so viele Pixel.
|
||||
- [x] **Es hat einen zusätzlichen Alpha-Kanal (8 Bit), der die Transparenz jedes Pixels speichert.** ✅
|
||||
- [ ] Es nutzt eine höhere Auflösung.
|
||||
- [ ] Es kann mehr Dateiformate speichern.
|
||||
|
||||
> **Feedback:** 32 Bit = 24 Bit (RGB) + 8 Bit Alpha. Der Alpha-Kanal bestimmt, wie durchsichtig jeder Pixel ist (0 = vollständig transparent, 255 = vollständig undurchsichtig). Wichtig für PNGs mit Hintergrund-Transparenz.
|
||||
|
||||
---
|
||||
|
||||
### K5 – Raster vs. Vektor: Kern-Unterschied
|
||||
**Thema:** Raster vs. Vektor – Konzept
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was ist der fundamentale Unterschied zwischen Raster- und Vektorgrafiken?
|
||||
|
||||
- [ ] Vektorgrafiken sind immer farbiger als Rastergrafiken.
|
||||
- [x] **Rastergrafiken speichern einzelne Pixel; Vektorgrafiken speichern geometrische Beschreibungen (Pfade, Formen), die beliebig skaliert werden können.** ✅
|
||||
- [ ] Rastergrafiken können keine Farben darstellen, Vektorgrafiken schon.
|
||||
- [ ] Der Unterschied liegt nur in der Dateiendung, nicht im Inhalt.
|
||||
|
||||
> **Feedback:** Raster = „Malen nach Zahlen" (jeder Pixel einzeln). Vektor = „Bauanleitung" (Formen beschreiben). Diese Unterschied bestimmt alles: Skalierung, Dateigröße, Einsatzbereich.
|
||||
|
||||
---
|
||||
|
||||
### K6 – Raster vs. Vektor: Vergleich
|
||||
**Thema:** Raster vs. Vektor – Eigenschaften zuordnen
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jeder Eigenschaft zu: Raster oder Vektor?
|
||||
|
||||
| Eigenschaft | Typ |
|
||||
|---|---|
|
||||
| Skalierung ohne Qualitätsverlust | Vektor |
|
||||
| Ideal für Fotos | Raster |
|
||||
| Dateigröße abhängig von der Auflösung | Raster |
|
||||
| Ideal für Logos und Icons | Vektor |
|
||||
| Speicherung als 2D-Array von Pixeln | Raster |
|
||||
| Dateigröße abhängig von der Komplexität | Vektor |
|
||||
|
||||
> **Feedback:** Raster = Pixel-basiert, auflösungsabhängig, ideal für Fotos. Vektor = Beschreibungs-basiert, beliebig skalierbar, ideal für Grafiken/Logos.
|
||||
|
||||
---
|
||||
|
||||
### K7 – Skalierung: Warum werden Rasterbilder unscharf?
|
||||
**Thema:** Rastergrafiken – Skalierung Transfer
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erkläre, warum ein Rasterbild beim Vergrößern unscharf wird, während ein Vektorbild bei beliebiger Größe scharf bleibt. Nenne einen konkreten Anwendungsfall, in dem diese Eigenschaft ausschlaggebend ist.
|
||||
|
||||
> **Musterlösung:** Ein Rasterbild hat eine feste Auflösung (eine bestimmte Anzahl von Pixeln). Beim Vergrößern müssen neue Pixel „erfunden" werden (Interpolation) – es gibt keine echten Daten für die fehlenden Stellen → Unschärfe. Ein Vektorbild speichert nur Beschreibungen (Pfade, Formen). Beim Vergrößern werden einfach die Koordinaten skaliert – keine Information geht verloren → immer scharf. Anwendungsfall: Ein Logo auf einer Visitenkarte UND auf einem Plakat → SVG nutzen, damit es bei beliebiger Größe scharf bleibt.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### K8 – Vektor → Raster: Wie heißt das?
|
||||
**Thema:** Raster vs. Vektor – Konvertierung
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Wie heißt der Prozess, bei dem eine Vektorgrafik in eine Rastergrafik umgewandelt wird?
|
||||
|
||||
- [ ] Vektorisierung
|
||||
- [x] **Rasterisierung** ✅
|
||||
- [ ] Pixelierung
|
||||
- [ ] Komprimierung
|
||||
|
||||
> **Feedback:** Rasterisierung = Vektor → Raster (trivial, immer möglich). Der umgekehrte Prozess (Raster → Vektor) heißt „Tracing" und funktioniert oft nur unbefriedigend.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### K9 – Interpolation: Welches Verfahren wofür?
|
||||
**Thema:** Rastergrafiken – Interpolationsverfahren
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jedem Interpolationsverfahren seine Eigenschaft zu.
|
||||
|
||||
| Verfahren | Eigenschaft |
|
||||
|---|---|
|
||||
| Nearest Neighbor | Schnell, pixelig – gut für Pixel-Art |
|
||||
| Bilinear | Glättet, Standard-Verfahren |
|
||||
| Bicubic | Hohe Qualität, rechenintensiver |
|
||||
| Lanczos | Beste Qualität, mathematisch komplex |
|
||||
|
||||
> **Feedback:** Bei der Wahl: Pixel-Art → Nearest Neighbor (soll pixelig bleiben). Normale Bilder → Bilinear oder Bicubic. Maximale Qualität bei Fotos → Lanczos.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK L – JPEG: Innenleben
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### L1 – JPEG: Verlustfrei oder verlustbehaftet?
|
||||
**Thema:** JPEG – Grundeigenschaft
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
JPEG ist ein …
|
||||
|
||||
- [x] **…verlustbehaftetes Bildformat. Beim Speichern werden Daten dauerhaft weggeworfen.** ✅
|
||||
- [ ] …verlustfreies Bildformat wie PNG.
|
||||
- [ ] …Videoformat für Streaming.
|
||||
- [ ] …Vektorgrafik-Format.
|
||||
|
||||
> **Feedback:** JPEG = Joint Photographic Experts Group. Verlustbehaftet: Beim Speichern werden Daten dauerhaft weggeworfen – eine gespeicherte JPEG kann nicht perfekt zum Original zurückgeführt werden. Quality 100 ≠ verlustfrei, nur „wenig wegwerfen".
|
||||
|
||||
---
|
||||
|
||||
### L2 – Psychovisuelle Kompression: Das Auge austricksen
|
||||
**Thema:** JPEG – Wahrnehmungsprinzip
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Wie nutzt JPEG die Schwächen des menschlichen Auges aus?
|
||||
|
||||
- [ ] Das Auge kann keine Farben wahrnehmen – daher werden Farben komplett entfernt.
|
||||
- [x] **Das Auge sieht Helligkeit besser als Farbe. JPEG behält die Helligkeit (Y) nahezu vollständig, reduziert aber die Farbauflösung (Cb, Cr) – der Verlust wird kaum wahrgenommen.** ✅
|
||||
- [ ] Das Auge kann keine Details sehen – daher werden alle Details entfernt.
|
||||
- [ ] JPEG nutzt keine Wahrnehmungsforschung, komprimiert rein mathematisch.
|
||||
|
||||
> **Feedback:** Psychovisuelle Kompression = Schwächen des Auges ausnutzen. Kern: Mehr Stäbchen (Helligkeit) als Zapfen (Farbe) im Auge → Helligkeit sichern, Farbe reduzieren. Der Verlust ist für Menschen kaum sichtbar.
|
||||
|
||||
---
|
||||
|
||||
### L3 – Farbraumkonversion: RGB → YCbCr
|
||||
**Thema:** JPEG Schritt 1 – Farbraum
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Warum wird bei JPEG von RGB in YCbCr konvertiert?
|
||||
|
||||
- [ ] YCbCr nutzt weniger Speicher pro Pixel als RGB.
|
||||
- [x] **In YCbCr sind Helligkeit (Y) und Farbe (Cb, Cr) getrennt – die Farbauflösung kann unabhängig von der Helligkeit reduziert werden.** ✅
|
||||
- [ ] RGB kann keine Transparenz darstellen, YCbCr schon.
|
||||
- [ ] Die Konvertierung ist ein verlustfreier Schritt, der die Dateigröße halbiert.
|
||||
|
||||
> **Feedback:** Y = Helligkeit (Luminanz), Cb/Cr = Farbdifferenzen (Chrominanz). Diese Trennung ermöglicht Chroma Subsampling: Helligkeit voll behalten, Farbe reduzieren – ohne sichtbaren Verlust.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### L4 – Chroma Subsampling: Was ist 4:2:0?
|
||||
**Thema:** JPEG Schritt 2 – Subsampling
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was bedeutet das Subsampling-Schema 4:2:0?
|
||||
|
||||
- [ ] 4 Pixel teilen sich eine Helligkeit, aber jeder hat eigene Farbe.
|
||||
- [x] **4 Pixel teilen sich einen Farbwert (Chrominanz), aber jeder hat eine eigene Helligkeit (Luminanz). Die Farbauflösung wird auf 25% reduziert.** ✅
|
||||
- [ ] 4:2:0 bedeutet, dass keine Farbe gespeichert wird – nur Graustufen.
|
||||
- [ ] Die Notation beschreibt die Blockgröße, nicht die Farbauflösung.
|
||||
|
||||
> **Feedback:** 4:2:0 = JPEG-Standard. Von 4 Pixeln wird nur 1 Farbwert gespeichert (2×2-Block teilt Farbe), aber jeder Pixel behält seine eigene Helligkeit. Ergebnis: 50% Datenreduktion, kaum sichtbar.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### L5 – JPEG-Schritte: Richtige Reihenfolge
|
||||
**Thema:** JPEG – Kompressionsablauf
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ORDER]`
|
||||
|
||||
Sortiere die Schritte der JPEG-Kompression in der richtigen Reihenfolge:
|
||||
|
||||
1. Farbraumkonversion (RGB → YCbCr)
|
||||
2. Chroma Subsampling
|
||||
3. Block-Aufteilung (8×8)
|
||||
4. DCT (Frequenzanalyse)
|
||||
5. Quantisierung (hier passiert der Verlust!)
|
||||
6. Huffman-Coding (verlustfrei)
|
||||
|
||||
> **Feedback:** Der einzige verlustbehaftete Schritt ist die Quantisierung (Schritt 5). Alles davor bereitet die Daten vor, alles danach komprimiert die Ergebnisse verlustfrei weiter.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### L6 – Welcher Schritt ist verlustbehaftet?
|
||||
**Thema:** JPEG – Verlust lokalisieren
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Bei welchem Schritt der JPEG-Kompression werden Daten dauerhaft weggeworfen?
|
||||
|
||||
- [ ] Farbraumkonversion (RGB → YCbCr)
|
||||
- [ ] DCT (Discrete Cosine Transform)
|
||||
- [x] **Quantisierung – hier werden unwichtige Frequenzkoeffizienten auf Null gesetzt oder vergröbert.** ✅
|
||||
- [ ] Huffman-Coding
|
||||
|
||||
> **Feedback:** DCT selbst ist verlustfrei und reversibel – es sortiert nur die Daten nach Wichtigkeit. Die Quantisierung ist der einzige verlustbehaftete Schritt: Sie wirft hohe Frequenzen (feine Details) weg. Huffman-Coding danach ist wieder verlustfrei.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### L7 – DCT: Was macht sie?
|
||||
**Thema:** JPEG – DCT-Prinzip
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was leitet die DCT (Discrete Cosine Transform) bei JPEG?
|
||||
|
||||
- [ ] Sie komprimiert die Daten verlustbehaftet.
|
||||
- [x] **Sie wandelt 64 Pixelwerte eines 8×8-Blocks in 64 Frequenzkoeffizienten um – sortiert die Information nach Wichtigkeit (niedrige Frequenz = wichtig, hohe Frequenz = Details).** ✅
|
||||
- [ ] Sie verschlüsselt die Daten für sichere Übertragung.
|
||||
- [ ] Sie reduziert die Farbauflösung des Bildes.
|
||||
|
||||
> **Feedback:** DCT = Herzstück von JPEG, aber selbst verlustfrei. Sie sortiert: Der DC-Koeffizient (0,0) = Durchschnittshelligkeit eines Blocks. Die AC-Koeffizienten = Helligkeitsänderungen. 90% der Information steckt in den ersten 10–15 Koeffizienten.
|
||||
|
||||
---
|
||||
|
||||
### L8 – Huffman-Coding: Prinzip
|
||||
**Thema:** JPEG – Huffman
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Wie funktioniert Huffman-Coding?
|
||||
|
||||
- [ ] Alle Zeichen bekommen gleich lange Codes – einfach und effizient.
|
||||
- [x] **Häufige Werte bekommen kurze Codes, selten vorkommende lange Codes – variable Bitlänge statt fester 8 Bit.** ✅
|
||||
- [ ] Huffman-Coding verschlüsselt die Daten zusätzlich.
|
||||
- [ ] Es funktioniert nur für Texte, nicht für Bilddaten.
|
||||
|
||||
> **Feedback:** Huffman = verlustfrei, optimal für bekannte Häufigkeiten. Präfix-frei: Kein Code ist Anfang eines anderen → eindeutig decodierbar. Auch in ZIP, PNG, MP3 verwendet.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### L9 – JPEG-Artefakte: Benennen
|
||||
**Thema:** JPEG – Artefakte identifizieren
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jedem JPEG-Artefakt seine Beschreibung zu.
|
||||
|
||||
| Artefakt | Beschreibung |
|
||||
|---|---|
|
||||
| Blocking | 8×8-Blöcke werden sichtbar als Rechteckmuster |
|
||||
| Ringing | „Geister" oder Halos an scharfen Kanten |
|
||||
| Posterization | Farbverläufe werden stufig statt fließend |
|
||||
|
||||
> **Feedback:** Alle drei sind Folgen der Quantisierung. Blocking: Weil jeder 8×8-Block unabhängig komprimiert wird. Ringing: DCT hat Probleme mit harten Kanten (Gibbs-Phänomen). Posterization: Zu wenige Bits für feine Farbabstufungen.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK M – Bildformate: PNG, GIF, WebP, SVG
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### M1 – PNG: Verlustfrei oder verlustbehaftet?
|
||||
**Thema:** PNG – Grundeigenschaft
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Wie komprimiert PNG?
|
||||
|
||||
- [ ] Verlustbehaftet – wie JPEG, aber mit besserer Qualität.
|
||||
- [x] **Verlustfrei – die Originaldaten können perfekt rekonstruiert werden.** ✅
|
||||
- [ ] Gar nicht – PNG speichert Daten unkomprimiert.
|
||||
- [ ] PNG nutzt eine Kombination aus verlustfrei und verlustbehaftet.
|
||||
|
||||
> **Feedback:** PNG nutzt DEFLATE-Kompression (wie ZIP) – verlustfrei. Deshalb ist PNG ideal für Grafiken, Screenshots und Bilder mit Transparenz, aber größer als JPEG für Fotos.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### M2 – PNG vs. JPEG: Wann was?
|
||||
**Thema:** Bildformate – Formatwahl
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erklären Sie, wann Sie PNG und wann JPEG wählen würden. Nenne je zwei konkrete Anwendungsfälle und begründen Sie Ihre Wahl.
|
||||
|
||||
> **Musterlösung:** PNG: (1) Screenshots – Texte und Linien bleiben scharf, keine Artefakte. (2) Logos mit Transparenz – PNG unterstützt Alpha-Transparenz, JPEG nicht. JPEG: (1) Fotos fürs Web – deutlich kleiner bei kaum sichtbarem Qualitätsverlust. (2) Social Media – Plattformen re-komprimieren sowieso, PNG würde nur unnötig groß sein.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### M3 – GIF: Wie viele Farben?
|
||||
**Thema:** GIF – Eigenschaften
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Wie viele Farben kann ein GIF-Bild gleichzeitig anzeigen?
|
||||
|
||||
- [ ] 16 Farben
|
||||
- [ ] 16,7 Millionen Farben
|
||||
- [x] **256 Farben (8-Bit-Palette)** ✅
|
||||
- [ ] Unbegrenzt – GIF unterstützt alle Farben.
|
||||
|
||||
> **Feedback:** GIF = 8-Bit-Palette = 256 Farben maximal. Deshalb sehen GIF-Bilder bei Fotos oft banding/posterisiert aus. GIF überlebt heute wegen Animationen.
|
||||
|
||||
---
|
||||
|
||||
### M4 – WebP vs. JPEG: Vorteil?
|
||||
**Thema:** Bildformate – WebP
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was ist der hauptsächliche Vorteil von WebP gegenüber JPEG?
|
||||
|
||||
- [ ] WebP unterstützt Videos, JPEG nicht.
|
||||
- [x] **WebP erzeugt bei gleicher Qualität 25–35% kleinere Dateien als JPEG.** ✅
|
||||
- [ ] WebP ist verlustfrei, JPEG nicht.
|
||||
- [ ] WebP kann keine Fotos speichern, nur Grafiken.
|
||||
|
||||
> **Feedback:** WebP (Google, 2010) kann sowohl lossy als auch lossless komprimieren, unterstützt Transparenz und Animationen. Bei gleicher visueller Qualität sind WebP-Dateien deutlich kleiner als JPEG.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### M5 – SVG: Was ist es?
|
||||
**Thema:** SVG – Grundbegriff
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was ist SVG?
|
||||
|
||||
- [ ] Ein verlustbehaftetes Rasterbild-Format wie JPEG.
|
||||
- [x] **Ein Vektorgrafik-Format, das Bilder als geometrische Beschreibungen (XML) speichert – beliebig skalierbar ohne Qualitätsverlust.** ✅
|
||||
- [ ] Ein Video-Container wie MP4.
|
||||
- [ ] Ein komprimiertes Archivformat wie ZIP.
|
||||
|
||||
> **Feedback:** SVG = Scalable Vector Graphics. Web-Standard für Vektorgrafiken. Beschreibt WAS gezeichnet werden soll (`<circle>`, `<rect>`, `<path>`), nicht wie jeder Pixel aussieht. Ideal für Logos, Icons, Illustrationen.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### M6 – Formatwahl: Szenario zuordnen
|
||||
**Thema:** Bildformate – Formatwahl Transfer
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jedem Szenario das optimale Bildformat zu.
|
||||
|
||||
| Szenario | Format |
|
||||
|---|---|
|
||||
| Ein Foto für eine Webseite (klein, OK-Qualität) | JPEG |
|
||||
| Ein Screenshot einer Benutzeroberfläche | PNG |
|
||||
| Ein Logo, das auf allen Bildschirmgrößen scharf sein muss | SVG |
|
||||
| Ein animiertes Reaktionsbild für einen Chat | GIF |
|
||||
|
||||
> **Feedback:** JPEG = Fotos (klein, lossy OK). PNG = Screenshots, Grafiken mit Transparenz (verlustfrei). SVG = Logos, Icons (skalierbar). GIF = Animationen (256 Farben, aber Animations-Support).
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK N – Video-Kompression
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### N1 – Spatial vs. Temporal Compression
|
||||
**Thema:** Video – Kompressionsprinzipien
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jedem Prinzip seine Beschreibung zu.
|
||||
|
||||
| Prinzip | Beschreibung |
|
||||
|---|---|
|
||||
| Spatial Compression (Intra-Frame) | Komprimiert jedes einzelne Bild für sich (wie JPEG) |
|
||||
| Temporal Compression (Inter-Frame) | Speichert nur die Änderungen zwischen aufeinanderfolgenden Bildern |
|
||||
| Motion Compensation | Beschreibt Bewegung durch Vektoren statt Pixel zu kopieren |
|
||||
|
||||
> **Feedback:** Spatial = räumlich (innerhalb eines Frames). Temporal = zeitlich (zwischen Frames). Motion Compensation = Bewegungsvektoren. 90% eines Frames ist oft identisch mit dem vorherigen – deshalb ist Temporal-Kompression so wirksam.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### N2 – I-Frame, P-Frame, B-Frame: Was ist was?
|
||||
**Thema:** Video – Frame-Typen
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jedem Frame-Typ seine Beschreibung zu.
|
||||
|
||||
| Frame-Typ | Beschreibung |
|
||||
|---|---|
|
||||
| I-Frame (Keyframe) | Vollständiges Bild, unabhängig dekodierbar – keine Referenz auf andere Frames |
|
||||
| P-Frame | Nur Änderungen gegenüber vorherigen Frames speichern (~30% der Größe eines I-Frames) |
|
||||
| B-Frame | Änderungen gegenüber vorherigen UND zukünftigen Frames (~15% der Größe eines I-Frames) |
|
||||
|
||||
> **Feedback:** I = Intra (innerhalb). P = Predicted (aus Vergangenheit). B = Bi-directional (Vergangenheit + Zukunft). B-Frames sind am kleinsten, aber brauchen mehr Rechenleistung zum Decodieren.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### N3 – Was passiert, wenn ein I-Frame beschädigt ist?
|
||||
**Thema:** Video – I-Frame Bedeutung Transfer
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erkläre, warum ein I-Frame bei der Videokompression so wichtig ist. Was passiert, wenn ein einzelner I-Frame in einem Videostream beschädigt wird?
|
||||
|
||||
> **Musterlösung:** Ein I-Frame ist ein vollständiges, unabhängig dekodierbare Bild. Alle nachfolgenden P- und B-Frames referenzieren auf vorherige Frames – letztlich auf das letzte I-Frame. Wenn ein I-Frame beschädigt wird, können alle abhängigen P- und B-Frames bis zum nächsten intakten I-Frame nicht mehr korrekt rekonstruiert werden → Videofehler sichtbar bis zum nächsten Keyframe. Deshalb werden typischerweise alle 1–2 Sekunden neue I-Frames eingefügt.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### N4 – Motion Compensation: Prinzip
|
||||
**Thema:** Video – Motion Compensation
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was beschreibt ein Motion Vector bei der Videokompression?
|
||||
|
||||
- [ ] Die Helligkeit eines einzelnen Pixels.
|
||||
- [x] **Die Verschiebung eines Bildblocks zwischen zwei Frames (z. B. „verschiebe um +20 Pixel nach rechts").** ✅
|
||||
- [ ] Die Kompressionsrate des gesamten Videos.
|
||||
- [ ] Die Anzahl der Farben in einem Frame.
|
||||
|
||||
> **Feedback:** Motion Compensation speichert Bewegung als Vektoren statt Pixel zu kopieren. Wenn sich ein 16×16-Block von (100,200) auf (120,200) bewegt, wird nur „+20, 0" gespeichert – deutlich kleiner als den Block zweimal zu speichern.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### N5 – Video-Codecs: Zeitstrahl
|
||||
**Thema:** Video – Codecs-Übersicht
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ORDER]`
|
||||
|
||||
Sortiere die Video-Codecs nach Veröffentlichungsjahr (alt → neu):
|
||||
|
||||
1. H.264 / AVC (2003)
|
||||
2. H.265 / HEVC (2013)
|
||||
3. VP9 (2013)
|
||||
4. AV1 (2018)
|
||||
|
||||
> **Feedback:** H.264 revolutionierte Streaming. H.265 und VP9 kamen gleichzeitig – H.265 technisch besser, aber Patent-Chaos. AV1 vereint die Industrie: patent-frei, 30% besser als H.265.
|
||||
|
||||
---
|
||||
|
||||
### N6 – AV1: Warum die Zukunft?
|
||||
**Thema:** Video – AV1 Transfer
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erkläre, warum AV1 als „die Zukunft" der Videokompression gilt. Nenne mindestens zwei konkrete Eigenschaften und erkläre, warum H.265 trotz besserer technischer Kompression nicht die gleiche Dominanz erreicht hat.
|
||||
|
||||
> **Musterlösung:** AV1 (2018) ist royalty-free und open source – die Alliance for Open Media vereint Google, Netflix, Amazon, Apple, Mozilla. Es liefert 30% bessere Kompression als H.265 und unterstützt 8K, HDR, hohe Frame-Rates. H.265 scheitert vor allem am Patent-Chaos: Drei konkurrierende Patent-Pools (MPEG-LA, HEVC Advance, Velos Media) erzeugen rechtliche Unsicherheit und unklare Kosten → viele Unternehmen bleiben bei H.264 oder wechseln direkt zu AV1.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK O – Speichermedien & Schnittstellen
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### O1 – KB vs. KiB: Was ist der Unterschied?
|
||||
**Thema:** Speicher – Einheiten
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Eine Festplatte wird als „1 TB" vermarktet, aber Windows zeigt nur ~931 GB an. Warum?
|
||||
|
||||
- [ ] Windows zeigt falsche Werte an – das ist ein Bug.
|
||||
- [x] **Hersteller nutzen dezimale Einheiten (1 TB = 1.000 GB), Windows nutzt binäre Einheiten (1 TiB = 1.024 GiB). Bei TB-Größen entsteht eine ~7% Diskrepanz.** ✅
|
||||
- [ ] Die Festplatte verliert beim Formatieren fast 10% ihrer Kapazität.
|
||||
- [ ] Windows reserviert automatisch 10% als Sicherheitspuffer.
|
||||
|
||||
> **Feedback:** SI (Dezimal): 1 KB = 1.000 Bytes, 1 MB = 1.000 KB. IEC (Binär): 1 KiB = 1.024 Bytes, 1 MiB = 1.024 KiB. Bei 1 TB: 1.000⁴ vs. 1.024⁴ Bytes → ~7% Unterschied. Windows zeigt binäre Werte an, aber mit SI-Bezeichnung (GB statt GiB) → Verwirrung.
|
||||
|
||||
---
|
||||
|
||||
### O2 – HDD vs. SSD: Kern-Unterschied
|
||||
**Thema:** Speichermedien – HDD vs. SSD
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was ist der fundamentale technische Unterschied zwischen HDD und SSD?
|
||||
|
||||
- [ ] HDDs sind elektronisch, SSDs mechanisch.
|
||||
- [x] **HDDs speichern Daten magnetisch auf sich drehenden Plattern (mechanisch). SSDs nutzen Flash-Speicher (elektronisch, keine beweglichen Teile).** ✅
|
||||
- [ ] Beide Technologien funktionieren identisch, der Unterschied liegt nur im Gehäuse.
|
||||
- [ ] HDDs nutzen Flash-Speicher, SSDs magnetische Platten.
|
||||
|
||||
> **Feedback:** HDD = Hard Disk Drive = mechanisch (Platter, Spindel, Schreib-Lese-Kopf). SSD = Solid State Drive = elektronisch (Flash-Speicher). Diese Unterschied bestimmt alles: Geschwindigkeit, Latenz, Geräusche, Haltbarkeit.
|
||||
|
||||
---
|
||||
|
||||
### O3 – HDD vs. SSD: Eigenschaften zuordnen
|
||||
**Thema:** Speichermedien – Vergleich
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jeder Eigenschaft zu: HDD oder SSD?
|
||||
|
||||
| Eigenschaft | Typ |
|
||||
|---|---|
|
||||
| Sequentielle Lesgeschwindigkeit ~150 MB/s | HDD |
|
||||
| Sequentielle Lesgeschwindigkeit ~3.500 MB/s | SSD (NVMe) |
|
||||
| Latenz ~10 ms | HDD |
|
||||
| Latenz ~0,02 ms | SSD |
|
||||
| Günstig pro TB (~15€/TB) | HDD |
|
||||
| Ideal für Betriebssystem | SSD |
|
||||
|
||||
> **Feedback:** Der dramatische Unterschied liegt bei Random Access: SSD ~500× schneller. Deshalb: Betriebssystem auf SSD, Archiv auf HDD. Viele nutzen beides: Kleine SSD für System + große HDD für Daten.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### O4 – USB-C: Stecker oder Protokoll?
|
||||
**Thema:** Schnittstellen – USB-C
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Ein USB-C-Kabel kann langsam sein, obwohl es wie ein „modernes" Kabel aussieht. Warum?
|
||||
|
||||
- [ ] USB-C-Kabel sind immer gleich schnell – die Geschwindigkeit liegt am Gerät.
|
||||
- [x] **USB-C ist nur ein Steckertyp, kein Protokoll. Ein USB-C-Kabel kann USB 2.0 (480 Mbit/s) bis USB4 (40 Gbit/s) sein – am Stecker nicht erkennbar.** ✅
|
||||
- [ ] USB-C-Kabel werden nach einem Jahr automatisch langsamer.
|
||||
- [ ] Die Geschwindigkeit hängt nur vom Betriebssystem ab.
|
||||
|
||||
> **Feedback:** USB-C = Steckerform. Das Protokoll dahinter kann USB 2.0, 3.2 oder USB4 sein. Ein billiges USB-C-Kabel ist oft nur USB 2.0 mit neuem Stecker. Kabel-Spezifikation prüfen!
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### O5 – Dateisysteme: Zuordnung
|
||||
**Thema:** Dateisysteme – Überblick
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jedem Dateisystem seine ideale Anwendung zu.
|
||||
|
||||
| Dateisystem | Ideal für |
|
||||
|---|---|
|
||||
| FAT32 | USB-Sticks, SD-Karten (maximale Kompatibilität) |
|
||||
| NTFS | Windows-Systeme (Journaling, Rechte) |
|
||||
| APFS | macOS, iOS (Snapshots, CoW) |
|
||||
| ext4 | Linux-Systeme (Journaling, stabil) |
|
||||
| exFAT | Große Dateien auf portablen Medien |
|
||||
|
||||
> **Feedback:** FAT32 = kleinster gemeinsamer Nenner, aber max. 4 GB pro Datei. exFAT = FAT32 ohne Größenlimits. NTFS/APFS/ext4 = moderne Systeme mit Journaling. Journaling = bei Absturz werden Änderungen nicht verloren.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### O6 – FAT32: Warum nicht für große Dateien?
|
||||
**Thema:** Dateisysteme – FAT32 Limitation
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Sie versuchen, eine 5-GB-Videodatei auf einen FAT32-formatierten USB-Stick zu kopieren. Was passiert?
|
||||
|
||||
- [ ] Die Datei wird automatisch aufgeteilt in kleinere Teile.
|
||||
- [x] **Der Vorgang fehlschlägt – FAT32 unterstützt keine einzelnen Dateien größer als 4 GB.** ✅
|
||||
- [ ] Die Datei wird automatisch komprimiert, bis sie unter 4 GB ist.
|
||||
- [ ] FAT32 hat keine Dateigrößenbeschränkung.
|
||||
|
||||
> **Feedback:** FAT32-Limit: max. 4 GB pro Datei. Ein 4K-Video oder ISO-Image passt oft nicht. Lösung: USB-Stick mit exFAT oder NTFS formatieren.
|
||||
|
||||
---
|
||||
|
||||
### O7 – Die 3-2-1-Regel
|
||||
**Thema:** Backup – Prinzip
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erkläre die 3-2-1-Regel für Backups. Begründe, warum jede der drei Ziffern wichtig ist.
|
||||
|
||||
> **Musterlösung:** 3 Kopien: Original + 2 Backups. Warum? Das Original kann kaputt gehen, das erste Backup auch – das zweite ist der Sicherheitspuffer. 2 verschiedene Medientypen (z. B. SSD + HDD, oder lokal + Cloud). Warum? Gleiche Medien haben gleiche Schwachstellen (z. B. Batch-Fehler bei HDDs derselben Charge). 1 Kopie an einem anderen Ort (Cloud, anderes Gebäude). Warum? Brand oder Wasserschaden zerstört alles vor Ort; Ransomware verschlüsselt alle angeschlossenen Laufwerke gleichzeitig.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### O8 – Backup-Arten: Unterschiede
|
||||
**Thema:** Backup – Typen
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jedem Backup-Typ seine Beschreibung zu.
|
||||
|
||||
| Backup-Typ | Beschreibung |
|
||||
|---|---|
|
||||
| Full (Vollständig) | Kompletter Datenbestand jedes Mal – einfach, aber langsam und platzhungrig |
|
||||
| Inkrementell | Nur Änderungen seit dem letzten Backup (egal welcher Art) – schnell, aber Wiederherstellung komplex |
|
||||
| Differenziell | Änderungen seit dem letzten Voll-Backup – Mittelweg zwischen beiden |
|
||||
|
||||
> **Feedback:** Typisches Schema: Sonntag Full, Mo–Sa Inkrementell oder Differenziell. Inkrementell = schnellstes Backup, langsamste Wiederherstellung (Kette aufbauen). Full = langsamstes Backup, schnellste Wiederherstellung.
|
||||
@@ -68,6 +68,38 @@ section.aufgabe {
|
||||
section.aufgabe footer {
|
||||
display: none;
|
||||
}
|
||||
section.erklaerung {
|
||||
font-size: 1.1rem;
|
||||
background: repeating-linear-gradient(
|
||||
135deg,
|
||||
#fce4ec,
|
||||
#fce4ec 40px,
|
||||
#fff 40px,
|
||||
#fff 80px
|
||||
) !important;
|
||||
}
|
||||
@media print {
|
||||
section.erklaerung {
|
||||
background: #fce4ec !important;
|
||||
}
|
||||
}
|
||||
section.erklaerung h1 {
|
||||
font-size: 1.5rem;
|
||||
color: #a02060;
|
||||
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 -->
|
||||
@@ -652,6 +684,28 @@ PRÜFUNGSRELEVANT: 5 Komponenten benennen und erklären können, Stored Program
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Von-Neumann-Architektur – Vertiefung
|
||||
|
||||
John von Neumann beschrieb 1945 im „First Draft of a Report on the EDVAC" das Prinzip des **Stored Program Computer**: Programme und Daten teilen sich denselben Speicher und sind damit austauschbar, ohne Hardware-Änderungen.
|
||||
|
||||
**Die 5 Komponenten im Detail:**
|
||||
|
||||
| Komponente | Moderne Entsprechung | Funktion |
|
||||
|------------|---------------------|----------|
|
||||
| Rechenwerk (ALU) | CPU-Kern | Addition, Subtraktion, Logik (AND, OR, NOT) |
|
||||
| Steuerwerk | CPU-Kern | Fetch-Decode-Execute-Zyklus |
|
||||
| Speicherwerk | RAM + ROM | Einheitlicher Adressraum für Code + Daten |
|
||||
| Ein-/Ausgabe | I/O-Controller | USB, PCIe, Netzwerk |
|
||||
| Bus-System | Northbridge/Southbridge (heute: SoC) | Adress-, Daten-, Steuerbus |
|
||||
|
||||
**Von-Neumann-Flaschenhals:** CPU und Speicher teilen einen Bus – die Bandbreite begrenzt die Geschwindigkeit. Moderne CPUs umgehen dies durch Caches (L1/L2/L3), die als Harvard-ähnliche Puffer dienen.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: klausur -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
@@ -689,6 +743,33 @@ PRÜFUNGSRELEVANT: Warum Von-Neumann revolutionär, Unterschied zu Harvard, Beis
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Stored Program Concept – Vertiefung
|
||||
|
||||
Vor Von Neumann mussten Computer für jedes Problem neu verkabelt werden (ENIAC: tagelange Arbeit). Das **Stored Program Concept** machte Programme zu Daten – austauschbar wie Dokumente.
|
||||
|
||||
**Konsequenzen für die Software-Industrie:**
|
||||
- **Betriebssysteme** möglich: Laden verschiedene Programme aus demselben Speicher
|
||||
- **Updates** ohne Hardware-Austausch: Nur Bits ändern, nicht Kabel
|
||||
- **Multitasking**: Mehrere Programme gleichzeitig im Speicher
|
||||
- **Self-Modifying Code**: Programme können sich selbst ändern (Compiler, JIT)
|
||||
|
||||
**Harvard-Architektur (Alternative):**
|
||||
|
||||
| Aspekt | Von Neumann | Harvard |
|
||||
|--------|-------------|---------|
|
||||
| Speicher | Gemeinsam für Code + Daten | Getrennt |
|
||||
| Busse | Ein Bus (Flaschenhals) | Paralleler Zugriff |
|
||||
| Flexibilität | Hoch (Code = Daten) | Geringer |
|
||||
| Einsatz | Desktop, Server, Smartphone | DSP, Mikrocontroller |
|
||||
|
||||
**Modern:** „Modified Harvard" – L1-Cache trennt Code/Daten (Speed), RAM bleibt gemeinsam (Flexibilität).
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Vom Militär zum Netz
|
||||
@@ -1117,6 +1198,34 @@ PRÜFUNGSRELEVANT: Was gehört in <head>, Unterschied zu <body>, wichtigste Meta
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# HTML Metadaten – Vertiefung
|
||||
|
||||
Der `<head>`-Bereich enthält Informationen *über* das Dokument, nicht den sichtbaren Inhalt. Diese Metadaten steuern Browser-Verhalten, Suchmaschinen-Indexierung und Social-Media-Vorschauen.
|
||||
|
||||
**Kritische Meta-Tags:**
|
||||
|
||||
| Tag | Funktion | Beispiel |
|
||||
|-----|----------|----------|
|
||||
| `<title>` | Browser-Tab, Suchergebnis-Titel | `<title>HdM Stuttgart</title>` |
|
||||
| `<meta charset>` | Zeichenkodierung (Umlaute!) | `<meta charset="UTF-8">` |
|
||||
| `<meta viewport>` | Mobile Darstellung | `width=device-width, initial-scale=1` |
|
||||
| `<meta description>` | Suchergebnis-Snippet (max 160 Zeichen) | SEO-kritisch |
|
||||
|
||||
**Open Graph Protocol (Facebook, 2010):**
|
||||
```html
|
||||
<meta property="og:title" content="Artikel-Titel">
|
||||
<meta property="og:image" content="https://example.com/preview.jpg">
|
||||
```
|
||||
Steuert die Vorschau beim Teilen auf Facebook, LinkedIn, WhatsApp, Slack.
|
||||
|
||||
**SEO-Relevanz:** Google nutzt `<title>` und `<meta description>` für Ranking und Snippet-Anzeige. Fehlende Metadaten = schlechtere Auffindbarkeit.
|
||||
|
||||
---
|
||||
|
||||
# HTML-Tags und Attribute
|
||||
|
||||
```html
|
||||
@@ -1340,6 +1449,33 @@ PRÜFUNGSRELEVANT: Arten von Einschränkungen, Screenreader-Beispiele, WCAG
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Web-Zugänglichkeit – Vertiefung
|
||||
|
||||
**a11y** = Accessibility (a + 11 Buchstaben + y). Die WHO schätzt, dass 15% der Weltbevölkerung eine Behinderung haben – das sind über 1 Milliarde potenzielle Nutzer.
|
||||
|
||||
**Arten von Einschränkungen:**
|
||||
|
||||
| Typ | Permanent | Temporär | Situativ |
|
||||
|-----|-----------|----------|----------|
|
||||
| Visuell | Blindheit | Nach Augen-OP | Grelle Sonne |
|
||||
| Motorisch | Amputation | Gebrochener Arm | Baby auf dem Arm |
|
||||
| Auditiv | Taubheit | Ohrenentzündung | Laute Umgebung |
|
||||
| Kognitiv | Legasthenie | Müdigkeit | Ablenkung |
|
||||
|
||||
**Assistive Technologien:**
|
||||
- **Screenreader:** NVDA (Windows, kostenlos), VoiceOver (Apple, integriert), JAWS (kommerziell)
|
||||
- **Braillezeilen:** Taktile Ausgabe, ~40–80 Zeichen
|
||||
- **Switch-Geräte:** Ein-Knopf-Steuerung für motorische Einschränkungen
|
||||
- **Eye-Tracking:** Blicksteuerung für Bewegungsunfähige
|
||||
|
||||
Screenreader lesen den DOM sequenziell – semantisches HTML (`<nav>`, `<main>`, `<button>`) ermöglicht Navigation per Tastenkürzel.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: klausur -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
@@ -1379,6 +1515,35 @@ PRÜFUNGSRELEVANT: EAA kennen, Curb-Cut-Effekt erklären können, Business Case
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Rechtliche Anforderungen – Vertiefung
|
||||
|
||||
Der **European Accessibility Act (EAA)** trat am 28. Juni 2025 in Kraft und betrifft erstmals auch private Unternehmen – nicht nur öffentliche Stellen.
|
||||
|
||||
**Betroffene Sektoren:**
|
||||
- E-Commerce (Online-Shops)
|
||||
- Bankdienstleistungen
|
||||
- Telekommunikation
|
||||
- E-Books und E-Reader
|
||||
- Ticketing und Check-in-Terminals
|
||||
|
||||
**WCAG 2.2 – Konformitätsstufen:**
|
||||
|
||||
| Level | Anforderung | Beispiel |
|
||||
|-------|-------------|----------|
|
||||
| A | Minimum | Alt-Texte für Bilder |
|
||||
| AA | Gesetzlicher Standard | Kontrast 4,5:1, Tastaturnavigation |
|
||||
| AAA | Optimal | Gebärdensprache für Videos |
|
||||
|
||||
**Curb-Cut-Effekt:** Barrierefreiheit hilft allen. Bordsteinabsenkungen für Rollstühle nutzen auch Kinderwagen, Rollkoffer, Fahrräder. Untertitel helfen Gehörlosen, aber auch in lauten Umgebungen oder beim Sprachlernen.
|
||||
|
||||
**Sanktionen:** Bis zu 100.000 € Bußgeld bei Verstößen.
|
||||
|
||||
---
|
||||
|
||||
# WCAG: Der Standard
|
||||
|
||||
**W**eb **C**ontent **A**ccessibility **G**uidelines
|
||||
@@ -1532,6 +1697,38 @@ Echte NutzerInnen einbeziehen = Gold-Standard
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Barrierefreiheit testen – Vertiefung
|
||||
|
||||
Automatisierte Tests finden nur ~30% der Barrierefreiheitsprobleme. Der Rest erfordert manuelles Testen und idealerweise echte Nutzer mit Behinderungen.
|
||||
|
||||
**Tastatur-Test (5 Minuten, jeder kann's):**
|
||||
1. Maus weglegen, nur Tab + Enter + Pfeiltasten nutzen
|
||||
2. Fokus-Indikator immer sichtbar? (kein `outline: none;`!)
|
||||
3. Logische Reihenfolge? (nicht kreuz und quer)
|
||||
4. Alle interaktiven Elemente erreichbar?
|
||||
|
||||
**Automatisierte Tools:**
|
||||
|
||||
| Tool | Typ | Findet |
|
||||
|------|-----|--------|
|
||||
| axe DevTools | Browser-Extension | ~30% der WCAG-Verstöße |
|
||||
| WAVE | Browser-Extension | Struktur-Probleme, Kontrast |
|
||||
| Lighthouse | Chrome DevTools | Performance + Accessibility |
|
||||
| Pa11y | CLI | CI/CD-Integration |
|
||||
|
||||
**Screenreader-Kurztest:**
|
||||
- macOS: `Cmd + F5` (VoiceOver)
|
||||
- Windows: NVDA installieren (kostenlos)
|
||||
- Augen schließen, nur zuhören: Ist die Seite verständlich?
|
||||
|
||||
**Gold-Standard:** Usability-Tests mit Menschen, die Assistive Technologien täglich nutzen.
|
||||
|
||||
---
|
||||
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
|
||||
@@ -71,6 +71,38 @@ section.aufgabe footer {
|
||||
section.glossar {
|
||||
font-size: 1.4rem;
|
||||
}
|
||||
section.erklaerung {
|
||||
font-size: 1.1rem;
|
||||
background: repeating-linear-gradient(
|
||||
135deg,
|
||||
#fce4ec,
|
||||
#fce4ec 40px,
|
||||
#fff 40px,
|
||||
#fff 80px
|
||||
) !important;
|
||||
}
|
||||
@media print {
|
||||
section.erklaerung {
|
||||
background: #fce4ec !important;
|
||||
}
|
||||
}
|
||||
section.erklaerung h1 {
|
||||
font-size: 1.5rem;
|
||||
color: #a02060;
|
||||
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 -->
|
||||
@@ -402,6 +434,31 @@ SPEAKER NOTES:
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# TCP/IP-Modell – Vertiefung
|
||||
|
||||
Das TCP/IP-Modell entstand praktisch aus dem ARPANET (1970er), im Gegensatz zum theoretischen OSI-Modell (7 Schichten, 1984). TCP/IP hat sich durchgesetzt, weil es das reale Internet beschreibt.
|
||||
|
||||
**Schicht-Aufgaben im Detail:**
|
||||
|
||||
| Schicht | Frage | Protokolle | Geräte |
|
||||
|---------|-------|------------|--------|
|
||||
| 4 Anwendung | Was will ich? | HTTP, DNS, SMTP, FTP | – (Software) |
|
||||
| 3 Transport | Kommt es an? Welches Programm? | TCP, UDP | – (Software) |
|
||||
| 2 Internet | Welcher Rechner weltweit? | IP, ICMP | Router |
|
||||
| 1 Netzzugang | Wie zum Nachbarn? | Ethernet, WLAN, PPP | Switch, Access Point |
|
||||
|
||||
**OSI vs. TCP/IP:**
|
||||
- OSI Schicht 5–7 (Session, Presentation, Application) → TCP/IP Schicht 4
|
||||
- OSI Schicht 1–2 (Physical, Data Link) → TCP/IP Schicht 1
|
||||
|
||||
**Warum Schichten?** Abstraktion. HTTP muss nicht wissen, ob Ethernet oder WLAN verwendet wird. Änderungen in einer Schicht betreffen andere nicht.
|
||||
|
||||
---
|
||||
|
||||
# Schichten verpacken Daten
|
||||
|
||||
```
|
||||
@@ -461,6 +518,33 @@ SPEAKER NOTES:
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Dateneinheiten & Encapsulation – Vertiefung
|
||||
|
||||
**Encapsulation** (Verkapselung): Jede Schicht fügt ihren Header hinzu, ohne den Inhalt der oberen Schicht zu verändern.
|
||||
|
||||
**Was jeder Header enthält:**
|
||||
|
||||
| Schicht | Einheit | Header-Inhalte |
|
||||
|---------|---------|----------------|
|
||||
| Anwendung | Daten | HTTP-Header, Cookies, Content-Type |
|
||||
| Transport | Segment | Quell-/Zielport, Sequenznummer, Flags (SYN, ACK) |
|
||||
| Internet | Paket | Quell-/Ziel-IP, TTL, Protokoll (TCP=6, UDP=17) |
|
||||
| Netzzugang | Frame | Quell-/Ziel-MAC, EtherType, CRC-Prüfsumme |
|
||||
|
||||
**Overhead-Rechnung (1 Byte HTTP-Body):**
|
||||
- Ethernet: 14 + 4 Bytes (Header + Trailer)
|
||||
- IP: 20 Bytes (ohne Optionen)
|
||||
- TCP: 20 Bytes (ohne Optionen)
|
||||
- **Minimum: 58 Bytes für 1 Byte Nutzlast**
|
||||
|
||||
**Decapsulation:** Empfänger packt in umgekehrter Reihenfolge aus. Jede Schicht prüft ihren Header (z.B. CRC) und reicht Nutzdaten nach oben.
|
||||
|
||||
---
|
||||
|
||||
# Warum ist das clever?
|
||||
|
||||
**Ohne Schichten:**
|
||||
@@ -640,6 +724,34 @@ SPEAKER NOTES:
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# IP, MAC, Port – Vertiefung
|
||||
|
||||
Drei Adressebenen lösen drei verschiedene Probleme:
|
||||
|
||||
**IP-Adresse (Schicht 2 – Internet):**
|
||||
- Hierarchisch aufgebaut: Netzwerk-Teil + Host-Teil
|
||||
- Router lesen nur den Netzwerk-Teil für Routing-Entscheidungen
|
||||
- IPv4: 32 Bit (z.B. 192.168.1.1), IPv6: 128 Bit
|
||||
|
||||
**MAC-Adresse (Schicht 1 – Netzzugang):**
|
||||
- 48 Bit, vom Hersteller fest vergeben (theoretisch)
|
||||
- Erste 24 Bit = OUI (Organizationally Unique Identifier) = Hersteller
|
||||
- Nur relevant für den **nächsten Hop** – wird bei jedem Router ersetzt
|
||||
- ARP (Address Resolution Protocol) übersetzt IP → MAC
|
||||
|
||||
**Port (Schicht 3 – Transport):**
|
||||
- 16 Bit → 65.535 mögliche Ports
|
||||
- Well-Known Ports (0–1023): HTTP=80, HTTPS=443, SSH=22
|
||||
- Ephemeral Ports (49152–65535): Dynamisch für Client-Verbindungen
|
||||
|
||||
**Warum ändert sich nur MAC?** IP ist das Endziel (Brief-Adresse), MAC ist der aktuelle Bote (wer trägt den Brief gerade?).
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Die Reise eines Klicks
|
||||
@@ -922,6 +1034,36 @@ SPEAKER NOTES:
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# 3-Way-Handshake – Vertiefung
|
||||
|
||||
Der Handshake synchronisiert **Sequenznummern** – essenziell für TCPs Zuverlässigkeit.
|
||||
|
||||
**Warum zufällige Startwerte (ISN)?**
|
||||
- Sicherheit: Verhindert Session-Hijacking durch Raten
|
||||
- Eindeutigkeit: Unterscheidet alte von neuen Verbindungen
|
||||
- ISN = Initial Sequence Number, vom OS zufällig gewählt
|
||||
|
||||
**TCP-Flags im Handshake:**
|
||||
|
||||
| Paket | Flags | Bedeutung |
|
||||
|-------|-------|-----------|
|
||||
| 1 | SYN | Client will Verbindung, sendet seine ISN |
|
||||
| 2 | SYN+ACK | Server akzeptiert, sendet seine ISN, bestätigt Client-ISN+1 |
|
||||
| 3 | ACK | Client bestätigt Server-ISN+1 |
|
||||
|
||||
**Was passiert bei Problemen?**
|
||||
- Kein SYN-ACK → Client wiederholt SYN (Timeout)
|
||||
- SYN-Flood-Attacke: Millionen SYNs ohne ACK → Server-Ressourcen erschöpft
|
||||
- Schutz: SYN-Cookies (Server speichert keinen State bis ACK kommt)
|
||||
|
||||
**Verbindungsabbau:** 4-Way-Handshake (FIN → ACK → FIN → ACK) oder RST für sofortigen Abbruch.
|
||||
|
||||
---
|
||||
|
||||
# Nach dem Handshake
|
||||
|
||||
**Status:** Die TCP-Verbindung steht.
|
||||
@@ -1429,6 +1571,38 @@ SPEAKER NOTES:
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# TCP vs. UDP – Vertiefung
|
||||
|
||||
Beide sind Transport-Protokolle (Schicht 3), aber mit fundamental unterschiedlichen Garantien.
|
||||
|
||||
**TCP (Transmission Control Protocol):**
|
||||
- Verbindungsorientiert (Handshake vor Daten)
|
||||
- Sequenznummern → Reihenfolge garantiert
|
||||
- ACKs + Retransmission → Kein Datenverlust
|
||||
- Flow Control (Sliding Window) → Empfänger nicht überlasten
|
||||
- Congestion Control → Netzwerk nicht überlasten
|
||||
|
||||
**UDP (User Datagram Protocol):**
|
||||
- Verbindungslos (Fire-and-Forget)
|
||||
- Keine Sequenznummern, keine ACKs
|
||||
- Header nur 8 Bytes (TCP: 20+ Bytes)
|
||||
- Anwendung muss selbst für Zuverlässigkeit sorgen
|
||||
|
||||
| Anwendung | Protokoll | Grund |
|
||||
|-----------|-----------|-------|
|
||||
| HTTP/HTTPS | TCP | Vollständigkeit kritisch |
|
||||
| DNS | UDP | Kleine Pakete, schnelle Antwort |
|
||||
| Video-Streaming | UDP/QUIC | Latenz wichtiger als Perfektion |
|
||||
| Online-Gaming | UDP | Echtzeit, veraltete Daten nutzlos |
|
||||
|
||||
**QUIC:** Googles Protokoll kombiniert UDP-Geschwindigkeit mit TCP-ähnlicher Zuverlässigkeit (HTTP/3).
|
||||
|
||||
---
|
||||
|
||||
# Warum UDP bei Video-Calls?
|
||||
|
||||
**Szenario:** Ein Paket geht verloren.
|
||||
|
||||
| TCP | UDP |
|
||||
|-----|-----|
|
||||
| Warten... neu anfordern... warten... | Ignorieren, nächstes Frame zeigen |
|
||||
| Video friert ein | Kurzes Artefakt |
|
||||
@@ -1508,6 +1682,37 @@ Das wird wichtiger, wenn ihr mit REST-APIs arbeitet.
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# HTTP-Methoden – Vertiefung
|
||||
|
||||
HTTP-Methoden definieren die **Semantik** der Anfrage – was der Client vom Server erwartet.
|
||||
|
||||
**CRUD-Mapping (Create, Read, Update, Delete):**
|
||||
|
||||
| Methode | CRUD | Idempotent | Safe | Typischer Einsatz |
|
||||
|---------|------|------------|------|-------------------|
|
||||
| GET | Read | Ja | Ja | Ressource abrufen |
|
||||
| POST | Create | Nein | Nein | Formular, neue Ressource |
|
||||
| PUT | Update | Ja | Nein | Ressource vollständig ersetzen |
|
||||
| PATCH | Update | Nein | Nein | Ressource teilweise ändern |
|
||||
| DELETE | Delete | Ja | Nein | Ressource löschen |
|
||||
|
||||
**Idempotent:** Mehrfaches Ausführen hat denselben Effekt wie einmaliges (GET, PUT, DELETE).
|
||||
**Safe:** Ändert nichts am Server (nur GET, HEAD, OPTIONS).
|
||||
|
||||
**REST-Prinzip:** URLs identifizieren Ressourcen, Methoden definieren Aktionen.
|
||||
```
|
||||
GET /users/42 → Benutzer 42 abrufen
|
||||
PUT /users/42 → Benutzer 42 vollständig ersetzen
|
||||
DELETE /users/42 → Benutzer 42 löschen
|
||||
POST /users → Neuen Benutzer erstellen
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: klausur -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# HTTP Status-Codes
|
||||
|
||||
```http
|
||||
HTTP/1.1 200 OK
|
||||
@@ -1543,6 +1748,31 @@ Status-Codes sagen euch, was passiert ist.
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# HTTP Status-Codes – Vertiefung
|
||||
|
||||
Die erste Ziffer kategorisiert die Antwort:
|
||||
|
||||
| Bereich | Kategorie | Häufige Codes |
|
||||
|---------|-----------|---------------|
|
||||
| 1xx | Informational | 100 Continue, 101 Switching Protocols |
|
||||
| 2xx | Success | 200 OK, 201 Created, 204 No Content |
|
||||
| 3xx | Redirection | 301 Moved Permanently, 302 Found, 304 Not Modified |
|
||||
| 4xx | Client Error | 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found |
|
||||
| 5xx | Server Error | 500 Internal Error, 502 Bad Gateway, 503 Unavailable |
|
||||
|
||||
**Wichtige Unterscheidungen:**
|
||||
- **401 vs. 403:** 401 = nicht authentifiziert (wer bist du?), 403 = nicht autorisiert (du darfst nicht)
|
||||
- **301 vs. 302:** 301 = permanent umgezogen (Cache-fähig), 302 = temporär (nicht cachen)
|
||||
- **304 Not Modified:** Browser hat Cache, Server bestätigt: noch aktuell → spart Bandbreite
|
||||
|
||||
**API-Design:** Korrekte Status-Codes sind wichtig für Clients. `200` bei Fehler mit `{"error": "..."}` im Body ist schlechtes Design.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: klausur -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Zusammenfassung Teil 1
|
||||
|
||||
**Der Ablauf:**
|
||||
1. DNS (UDP:53) → Name zu IP
|
||||
@@ -1579,6 +1809,40 @@ Wie Encapsulation funktioniert.
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Netzwerk-Grundlagen – Vertiefung
|
||||
|
||||
Die vier Kernkonzepte für Web-Entwickler:
|
||||
|
||||
**1. DNS-Auflösung:**
|
||||
- Browser fragt DNS-Resolver (z.B. 8.8.8.8)
|
||||
- Rekursive Abfrage: Root → TLD → Authoritative
|
||||
- Caching auf jeder Ebene (TTL = Time To Live)
|
||||
|
||||
**2. TCP-Verbindungsaufbau:**
|
||||
- 3-Way-Handshake vor jeder HTTP-Anfrage (HTTP/1.1)
|
||||
- Keep-Alive: Verbindung bleibt offen für mehrere Requests
|
||||
- HTTP/2: Multiplexing – viele Requests über eine Verbindung
|
||||
|
||||
**3. HTTP Request/Response:**
|
||||
```
|
||||
Request: Methode + URL + Header + (Body)
|
||||
Response: Status + Header + Body
|
||||
```
|
||||
|
||||
**4. Schichten & Adressen:**
|
||||
| Was bleibt gleich? | Was ändert sich? |
|
||||
|-------------------|------------------|
|
||||
| Ziel-IP | MAC-Adressen (bei jedem Hop) |
|
||||
| Ports | – |
|
||||
|
||||
**Debugging:** Browser DevTools (F12 → Network) zeigt alle Requests, Timing, Header.
|
||||
|
||||
---
|
||||
|
||||
# Werkzeuge zum Selbst-Erkunden
|
||||
|
||||
**Im Browser (F12 → Network-Tab):**
|
||||
- Jeder Request sichtbar
|
||||
- Timing, Headers, Response
|
||||
|
||||
**Im Terminal:**
|
||||
```bash
|
||||
@@ -1870,6 +2134,33 @@ Inline-Styles schlagen alles – außer !important, was ihr vermeiden solltet.
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# CSS Spezifität – Vertiefung
|
||||
|
||||
Spezifität bestimmt, welche CSS-Regel gewinnt, wenn mehrere auf dasselbe Element zutreffen. Sie wird als 4-stellige Zahl berechnet: **(Inline, IDs, Klassen, Elemente)**.
|
||||
|
||||
**Berechnung:**
|
||||
|
||||
| Selektor | Inline | IDs | Klassen | Elemente | Gesamt |
|
||||
|----------|--------|-----|---------|----------|--------|
|
||||
| `p` | 0 | 0 | 0 | 1 | 0,0,0,1 |
|
||||
| `.info` | 0 | 0 | 1 | 0 | 0,0,1,0 |
|
||||
| `p.info` | 0 | 0 | 1 | 1 | 0,0,1,1 |
|
||||
| `#header` | 0 | 1 | 0 | 0 | 0,1,0,0 |
|
||||
| `#header .nav a` | 0 | 1 | 1 | 1 | 0,1,1,1 |
|
||||
|
||||
**Wichtige Regeln:**
|
||||
- Eine Klasse (0,0,1,0) schlägt **jede Anzahl** von Elementen (0,0,0,99)
|
||||
- Eine ID schlägt jede Anzahl von Klassen
|
||||
- `!important` bricht alles → vermeiden, da schwer zu überschreiben
|
||||
|
||||
**Best Practice:** Flache Spezifität anstreben. BEM-Methodik (`.block__element--modifier`) hält Spezifität gleichmäßig niedrig.
|
||||
|
||||
---
|
||||
|
||||
# Box-Modell
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────┐
|
||||
│ margin │
|
||||
│ ┌─────────────────────────────┐ │
|
||||
│ │ border │ │
|
||||
│ │ ┌─────────────────────┐ │ │
|
||||
@@ -2117,6 +2408,37 @@ Das Gegenteil wäre Desktop First mit max-width – aber Mobile First ist heute
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Responsive Design – Vertiefung
|
||||
|
||||
**Mobile First** ist der Standard: Basis-CSS für kleine Screens, dann Erweiterungen für größere.
|
||||
|
||||
**Breakpoints (gängige Werte):**
|
||||
|
||||
| Breakpoint | Gerät | Media Query |
|
||||
|------------|-------|-------------|
|
||||
| < 576px | Smartphone (Portrait) | Basis (kein Query) |
|
||||
| ≥ 576px | Smartphone (Landscape) | `@media (min-width: 576px)` |
|
||||
| ≥ 768px | Tablet | `@media (min-width: 768px)` |
|
||||
| ≥ 992px | Desktop | `@media (min-width: 992px)` |
|
||||
| ≥ 1200px | Large Desktop | `@media (min-width: 1200px)` |
|
||||
|
||||
**Viewport-Meta-Tag (kritisch!):**
|
||||
```html
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||||
```
|
||||
Ohne diesen Tag ignorieren mobile Browser eure Media Queries und rendern die Desktop-Version verkleinert.
|
||||
|
||||
**Moderne Alternativen zu Media Queries:**
|
||||
- `clamp()`: `font-size: clamp(1rem, 2vw, 2rem);`
|
||||
- Container Queries: Reagieren auf Container-Größe statt Viewport
|
||||
- CSS Grid `auto-fit`/`auto-fill`: Automatisches Responsive Layout
|
||||
|
||||
---
|
||||
|
||||
# Zusammenfassung CSS
|
||||
|
||||
**Selektoren:**
|
||||
- Element: `p`
|
||||
- Klasse: `.wichtig`
|
||||
- ID: `#header`
|
||||
- Kombinationen: `nav > a`, `h2 + p`
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@ paginate: true
|
||||
backgroundColor: #fff
|
||||
header: ""
|
||||
footer: ""
|
||||
title: "Fragenkatalog - Klausurvorbereitung"
|
||||
title: "Fragenkatalog – IT-Grundlagen (223015c)"
|
||||
---
|
||||
<style>
|
||||
:root {
|
||||
@@ -42,11 +42,11 @@ a {
|
||||
section.disable {
|
||||
opacity: 0.3;
|
||||
}
|
||||
</style>FA2
|
||||
</style>
|
||||
|
||||
|
||||
# Klausurfragen – 223015b/223015c
|
||||
**IT-Grundlagen/Dateiformate · HdM Stuttgart · M. Czechowski**
|
||||
# Klausurfragen – 223015c
|
||||
**IT-Grundlagen · HdM Stuttgart · M. Czechowski**
|
||||
|
||||
<small>Stand: 01.02.2026</small>
|
||||
|
||||
@@ -392,6 +392,8 @@ Beschreibe die drei Schritte des TCP 3-Way-Handshakes. Erkläre, warum alle drei
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### B18 – TCP Sequenznummern: Wozu?
|
||||
**Thema:** TCP – Sequenznummern
|
||||
**Punkte:** 1
|
||||
@@ -583,6 +585,8 @@ Erkläre, warum HTTP-Status-Codes aus einer dreistelligen Zahl bestehen und was
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### D1 – DNS: Was macht es?
|
||||
**Thema:** DNS – Grundfunktion
|
||||
**Punkte:** 1
|
||||
@@ -599,6 +603,8 @@ Was ist die Hauptfunktion eines DNS-Servers?
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### D2 – DNS: Zeitlicher Ablauf
|
||||
**Thema:** DNS – Rolle im Gesamtablauf
|
||||
**Punkte:** 2
|
||||
@@ -615,6 +621,8 @@ Sie geben `https://hdm-stuttgart.de` in die Adresszeile ein. Was passiert vor de
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### D3 – DNS: Warum zwingend nötig?
|
||||
**Thema:** DNS – Transfer/Begründung
|
||||
**Punkte:** 2
|
||||
@@ -626,6 +634,8 @@ Erkläre in 2–3 Sätzen, warum der DNS-Schritt zwingend vor dem TCP-Handshake
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### D4 – DNS: Lückentext
|
||||
**Thema:** DNS – Terminologie
|
||||
**Punkte:** 1
|
||||
@@ -717,6 +727,8 @@ Ordne jedem Element zu, ob es in `<head>` oder `<body>` gehört.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### F3 – Charset: Was passiert ohne `<meta charset>`?
|
||||
**Thema:** HTML – Zeichenkodierung
|
||||
**Punkte:** 1
|
||||
@@ -838,6 +850,8 @@ Ordne jedem Eingabegerät seine Nutzungsweise zu.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### H2 – Einschränkungen: Temporär vs. situativ
|
||||
**Thema:** Barrierefreiheit – Einschränkungstypen
|
||||
**Punkte:** 2
|
||||
@@ -957,884 +971,3 @@ Eine Person klickt auf einen „Neuen Eintrag erstellen"-Button einer Webanwendu
|
||||
Sie rufen eine Webseite auf und erhalten eine Fehlermeldung. Beschreibe drei verschiedene Szenarien, die zu einer Fehlermeldung führen könnten, und erkläre, in welcher „Schicht" des Ablaufs (DNS, TCP, HTTP) das Problem liegt und wie Sie es erkennen.
|
||||
|
||||
> **Musterlösung:** (1) DNS-Fehler: „Der Server wurde nicht gefunden" → DNS konnte den Namen nicht auflösen (z. B. Tippfehler in der URL oder DNS-Server nicht erreichbar). (2) TCP-Fehler: „Die Verbindung wurde verweigert" → Server existiert (IP bekannt), akzeptiert aber keine Verbindung (nicht gestartet, Port blockiert). (3) HTTP-Fehler: 404 → TCP-Verbindung erfolgreich, aber die angeforderte Ressource existiert nicht auf dem Server.
|
||||
|
||||
---
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK J – Dateiformate: Grundbegriffe
|
||||
|
||||
---
|
||||
|
||||
### J1 – Was bedeutet „komprimieren"?
|
||||
**Thema:** Grundbegriffe – Kompression
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was bedeutet es, eine Datei zu komprimieren?
|
||||
|
||||
- [ ] Die Datei wird auf einem anderen Speichermedium gesichert.
|
||||
- [x] **Die Dateigröße wird durch Entfernung oder Vereinfachung von Daten reduziert.** ✅
|
||||
- [ ] Die Datei wird verschlüsselt, damit sie kleiner aussieht.
|
||||
- [ ] Die Datei wird in ein anderen Format umgewandelt, ohne dass sich die Größe ändert.
|
||||
|
||||
> **Feedback:** Kompression = Dateigröße reduzieren. Zwei Familien: verlustfrei (alle Daten bleiben erhalten, z. B. ZIP, PNG) und verlustbehaftet (Daten werden dauerhaft weggeworfen, z. B. JPEG, MP3).
|
||||
|
||||
---
|
||||
|
||||
### J2 – Verlustfrei vs. verlustbehaftet
|
||||
**Thema:** Grundbegriffe – Kompressionsprimitiven
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jedem Format zu, ob es verlustfrei oder verlustbehaftet komprimiert.
|
||||
|
||||
| Format | Kompressions-Typ |
|
||||
|---|---|
|
||||
| JPEG | Verlustbehaftet |
|
||||
| PNG | Verlustfrei |
|
||||
| MP3 | Verlustbehaftet |
|
||||
| ZIP | Verlustfrei |
|
||||
| FLAC | Verlustfrei |
|
||||
| WebP (lossy) | Verlustbehaftet |
|
||||
|
||||
> **Feedback:** Verlustfrei = Originaldaten perfekt rekonstruierbar (ZIP, PNG, FLAC). Verlustbehaftet = Daten dauerhaft weggeworfen, nicht mehr zurückholbar (JPEG, MP3).
|
||||
|
||||
---
|
||||
|
||||
### J3 – Verlustfrei vs. verlustbehaftet: Erkläre
|
||||
**Thema:** Grundbegriffe – Konzept
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erkläre den Unterschied zwischen verlustfreier und verlustbehafteter Kompression. Nenne je ein konkretes Beispiel und erkläre, warum man in unterschiedlichen Situationen unterschiedliche Kompressionstypen wählt.
|
||||
|
||||
> **Musterlösung:** Verlustfrei: Alle Originaldaten bleiben erhalten – die Datei kann perfekt rekonstruiert werden (z. B. ZIP, PNG). Verlustbehaftet: Daten werden dauerhaft weggeworfen – die Datei kann nicht mehr perfekt hergestellt werden (z. B. JPEG, MP3). Wahl: Fotos fürs Web → JPEG (verlustbehaftet), weil der Unterschied kaum sichtbar ist und die Datei deutlich kleiner wird. Archivierung oder Grafiken → PNG (verlustfrei), weil Qualitätsverlust inakzeptabel wäre.
|
||||
|
||||
---
|
||||
|
||||
### J4 – Was bedeutet „skalieren"?
|
||||
**Thema:** Grundbegriffe – Skalierung
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was passiert, wenn ein Rasterbild vergrößert wird?
|
||||
|
||||
- [ ] Neue Pixel werden aus dem Dateiformat automatisch geladen.
|
||||
- [x] **Fehlende Pixel müssen durch Interpolation „erfunden" werden – es entsteht keine neue Information.** ✅
|
||||
- [ ] Das Bild wird verlustfrei größer, weil Pixel automatisch duplifiziert werden.
|
||||
- [ ] Die Dateigröße bleibt gleich, nur der Zoom im Betrachter ändert sich.
|
||||
|
||||
> **Feedback:** Ein Rasterbild hat eine native Auflösung. Alles darüber hinaus = Schätzung (Interpolation). Deshalb werden vergrößerte Rasterbilder unscharf – es gibt einfach keine Daten für die fehlenden Pixel.
|
||||
|
||||
---
|
||||
|
||||
### J5 – Was bedeutet „konvertieren"?
|
||||
**Thema:** Grundbegriffe – Konvertierung
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was bedeutet es, eine Datei zu konvertieren?
|
||||
|
||||
- [ ] Die Datei wird komprimiert und umbenannt.
|
||||
- [x] **Die Daten werden von einem Format in ein anderes umgewandelt (z. B. JPEG → PNG, MP4 → WebM).** ✅
|
||||
- [ ] Die Datei wird verschlüsselt und in ein neues Format gepackt.
|
||||
- [ ] Die Dateiendung wird umbenannt, ohne dass sich der Inhalt ändert.
|
||||
|
||||
> **Feedback:** Konvertierung = Format-Umwandlung. Der Inhalt bleibt inhaltlich gleich, aber die Art der Speicherung (Kompression, Struktur) ändert sich. Wichtig: Eine Dateiendung umzubenennen ist KEINE Konvertierung.
|
||||
|
||||
---
|
||||
|
||||
### J6 – Was bedeutet „codieren" und „decodieren"?
|
||||
**Thema:** Grundbegriffe – Codec-Konzept
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erkläre, was „codieren" und „decodieren" bedeuten. Erkläre anschließend, warum der Begriff „Codec" aus beiden Wörtern zusammengesetzt ist, und nenne ein konkretes Beispiel.
|
||||
|
||||
> **Musterlösung:** Codieren = Daten in ein bestimmtes Format umwandeln (z. B. Rohvideodaten → H.264-komprimiertes Video). Decodieren = das Gegenteil: komprimierte Daten wieder in abspielbare Form zurückwandeln (z. B. H.264 → Pixeldaten für den Bildschirm). Codec = Co(der) + Dec(oder) – ein Algorithmus, der beides kann. Beispiel: H.264 ist ein Video-Codec: Der Encoder erzeugt die komprimierte Datei, der Decoder im Player spielt sie wieder ab.
|
||||
|
||||
---
|
||||
|
||||
### J7 – Codec vs. Container
|
||||
**Thema:** Grundbegriffe – Codec/Container-Unterschied
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was ist der Unterschied zwischen einem Container und einem Codec bei Videodateien?
|
||||
|
||||
- [ ] Container und Codec sind synonyme Begriffe für das gleiche Konzept.
|
||||
- [x] **Der Container (z. B. MP4) ist die „Verpackung", die verschiedene Streams zusammenpackt. Der Codec (z. B. H.264) bestimmt, wie der Video-Stream komprimiert wird.** ✅
|
||||
- [ ] Der Codec ist die Dateiendung, der Container der Kompressionsalgorithmus.
|
||||
- [ ] Ein Container enthält immer genau einen Codec – es kann keine Kombination geben.
|
||||
|
||||
> **Feedback:** Container ≠ Codec. Ein MP4-Container kann H.264, H.265 oder AV1 enthalten. Gleiche Endung `.mp4`, unterschiedlicher Inhalt. Der Container packt zusammen (Video, Audio, Untertitel, Metadaten), der Codec komprimiert.
|
||||
|
||||
---
|
||||
|
||||
### J8 – Codec vs. Container: Zuordnung
|
||||
**Thema:** Grundbegriffe – Codec/Container-Zuordnung
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne zu: Container oder Codec?
|
||||
|
||||
| Name | Typ |
|
||||
|---|---|
|
||||
| MP4 | Container |
|
||||
| H.264 | Codec |
|
||||
| WebM | Container |
|
||||
| AV1 | Codec |
|
||||
> **Feedback:** Container = Dateiformat, das Streams zusammenpackt (MP4, MKV, WebM). Codec = Kompressionsalgorithmus für einen bestimmten Stream (H.264, AV1, AAC).
|
||||
|
||||
---
|
||||
|
||||
### J9 – Redundanz vs. Irrelevanz
|
||||
**Thema:** Grundbegriffe – Kompressionsprinzipien
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Verlustfreie und verlustbehaftete Kompression arbeiten nach unterschiedlichen Prinzipien. Ordne zu.
|
||||
|
||||
| Prinzip | Kompressionstyp |
|
||||
|---|---|
|
||||
| Redundanz entfernen (wiederholende Muster kompakter darstellen) | Verlustfrei |
|
||||
| Irrelevanz entfernen (für Menschen nicht wahrnehmbar) | Verlustbehaftet |
|
||||
|
||||
> **Feedback:** Der Kernunterschied: Verlustfrei arbeitet mit Redundanz – Wiederholungen werden kompakter gespeichert, aber nichts geht verloren. Verlustbehaftet arbeitet mit Irrelevanz – Daten werden weggeworfen, die Menschen sowieso nicht wahrnehmen können (Psychovisuell bei Bildern, Psychoakustisch bei Audio).
|
||||
|
||||
---
|
||||
|
||||
### J10 – Dateneinheiten: Größenordnungen
|
||||
**Thema:** Grundbegriffe – Speichereinheiten
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ORDER]`
|
||||
|
||||
Sortiere die Dateneinheiten von kleinster zu größter:
|
||||
|
||||
1. Byte
|
||||
2. Kilobyte (KB)
|
||||
3. Megabyte (MB)
|
||||
4. Gigabyte (GB)
|
||||
5. Terabyte (TB)
|
||||
6. Petabyte (PB)
|
||||
|
||||
> **Feedback:** Jede Stufe = Faktor 1.000 (SI-Präfixe). Merkhilfe: „Komm Mit Großem Tee, Peter". Ein einzelnes Foto (12 MP, unkomprimiert) ≈ 36 MB. Ein FullHD-Kinofilm ≈ 1 GB. Ein 4K-Film pro Minute unkomprimiert ≈ 44 GB.
|
||||
|
||||
---
|
||||
|
||||
### J11 – Bit und Byte: Umrechnung
|
||||
**Thema:** Grundbegriffe – Bit/Byte-Verhältnis
|
||||
**Punkte:** 1
|
||||
**Typ:** `[NUMERIC]`
|
||||
|
||||
Ein Bit ist die kleinste Informationseinheit. Ein Byte besteht aus wie vielen Bit?
|
||||
|
||||
**Lösung:** **8** (±0)
|
||||
|
||||
> **Feedback:** 1 Byte = 8 Bit. Ein Byte kann einen Wert von 0 bis 255 darstellen (2⁸ − 1). Die Unterscheidung Bit/Byte ist fundamental – Bit wird mit kleinem „b" abgekürzt (b), Byte mit großem „B" (B). Deshalb: 1 Mbit/s ≠ 1 MB/s.
|
||||
|
||||
---
|
||||
|
||||
### J12 – 7-Bit ASCII: Wie viele Zeichen?
|
||||
**Thema:** Grundbegriffe – ASCII-Zeichenkodierung
|
||||
**Punkte:** 1
|
||||
**Typ:** `[NUMERIC]`
|
||||
|
||||
Der ASCII-Standard verwendet 7 Bit pro Zeichen. Wie viele verschiedene Zeichen können damit dargestellt werden?
|
||||
|
||||
**Lösung:** **128** (±0)
|
||||
|
||||
> **Feedback:** Bei n Bit gibt es 2ⁿ mögliche Werte. 7 Bit → 2⁷ = 128 Zeichen. Diese umfassen: Ziffern (0–9), Buchstaben (A–Z, a–z), Sonderzeichen und Steuerzeichen. Achtung: Umlaute (ä, ö, ü) sind nicht im ASCII-Sortiment – dafür braucht man z. B. UTF-8.
|
||||
|
||||
---
|
||||
|
||||
### J13 – Hexadezimalzahlen: Zwei 4-Bit-Werte
|
||||
**Thema:** Grundbegriffe – Hexadezimal
|
||||
**Punkte:** 2
|
||||
**Typ:** `[NUMERIC]`
|
||||
|
||||
Zwei Hexadezimalzahlen werden jeweils durch 4 Bit dargestellt. Wie viele verschiedene Werte kann eine einzelne Hexadezimalziffer annehmen?
|
||||
|
||||
**Lösung:** **16** (±0)
|
||||
|
||||
> **Feedback:** 4 Bit → 2⁴ = 16 Werte (0–15). Diese werden in Hexadezimal als 0–9 und A–F dargestellt. Zwei Hex-Ziffern zusammen = 8 Bit = 1 Byte → ein Byte lässt sich immer als genau zwei Hex-Ziffern schreiben (z. B. Byte 255 = FF, Byte 10 = 0A).
|
||||
|
||||
---
|
||||
|
||||
### J14 – Ein Pixel, drei Kanäle, 8 Bit
|
||||
**Thema:** Grundbegriffe – Speicherbedarf eines Pixels
|
||||
**Punkte:** 1
|
||||
**Typ:** `[NUMERIC]`
|
||||
|
||||
Ein einzelner Pixel wird durch drei Farbkanäle (R, G, B) mit jeweils 8 Bit Farbtiefe gespeichert. Wie viele Byte Informationen enthalten ein solcher Pixel?
|
||||
|
||||
**Lösung:** **3** (±0)
|
||||
|
||||
> **Feedback:** 3 Kanäle × 8 Bit = 24 Bit = 3 Byte pro Pixel. Das entspricht einer 24-Bit-Farbtiefe (True Color). Diese 3 Byte pro Pixel bilden die Basis für jede Speicherberechnung von Rasterbildern: Breite × Höhe × 3 Bytes = Gesamtgröße unkomprimiert.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK K – Bildformate & Raster vs. Vektor
|
||||
|
||||
---
|
||||
|
||||
### K1 – Was ist ein Pixel?
|
||||
**Thema:** Digitale Bilder – Grundbegriffe
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was ist ein Pixel in einem digitalen Bild?
|
||||
|
||||
- [ ] Ein winziges physisches Kameraobjektiv.
|
||||
- [x] **Ein einzelner Farbpunkt in einem Rasterbild – der kleinste Baustein.** ✅
|
||||
- [ ] Eine Einheit zur Messung der Dateigröße.
|
||||
- [ ] Ein Synonym für eine Farbe im RGB-Farbraum.
|
||||
|
||||
> **Feedback:** Pixel = Picture Element. Ein digitales Rasterbild ist ein 2D-Array aus Pixeln, jeder mit einem Farbwert (z. B. RGB).
|
||||
|
||||
---
|
||||
|
||||
### K2 – Speicherbedarf berechnen
|
||||
**Thema:** Rastergrafiken – Berechnung
|
||||
**Punkte:** 2
|
||||
**Typ:** `[NUMERIC]`
|
||||
|
||||
Ein Bild ist 1920 × 1080 Pixel groß und nutzt 24-Bit-Farbtiefe (True Color). Wie groß ist das Bild unkomprimiert in Megabyte? (Runde auf eine Dezimalstelle)
|
||||
|
||||
**Formel:** Breite × Höhe × (Farbtiefe / 8) = Bytes
|
||||
|
||||
**Lösung:** 1920 × 1080 × 3 = 6.220.800 Bytes ≈ **6,2 MB** (±0,1)
|
||||
|
||||
> **Feedback:** 24 Bit = 3 Bytes pro Pixel (8 Bit pro Kanal: R, G, B). 1920 × 1080 = 2.073.600 Pixel × 3 Bytes = 6.220.800 Bytes. Durch 1.000.000 ≈ 6,2 MB.
|
||||
|
||||
---
|
||||
|
||||
### K3 – Farbtiefe: Bedeutung
|
||||
**Thema:** Rastergrafiken – Farbtiefe
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jeder Farbtiefe ihre Bedeutung zu.
|
||||
|
||||
| Farbtiefe | Bedeutung |
|
||||
|---|---|
|
||||
| 1 Bit | 2 Farben (Schwarz/Weiß) |
|
||||
| 8 Bit | 256 Farben (Graustufen, GIF) |
|
||||
| 24 Bit | 16,7 Millionen Farben (True Color, Standard) |
|
||||
| 32 Bit | 16,7 Millionen Farben + Alpha (Transparenz) |
|
||||
|
||||
> **Feedback:** Bei n Bit gibt es 2ⁿ mögliche Werte. 24 Bit = 8 Bit pro Kanal (R, G, B). 32 Bit = 24 Bit Farbe + 8 Bit Alpha-Kanal für Transparenz.
|
||||
|
||||
---
|
||||
|
||||
### K4 – Was ist Alpha-Transparenz?
|
||||
**Thema:** Rastergrafiken – Transparenz
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was bedeutet ein 32-Bit-Bild gegenüber einem 24-Bit-Bild?
|
||||
|
||||
- [ ] Es hat doppelt so viele Pixel.
|
||||
- [x] **Es hat einen zusätzlichen Alpha-Kanal (8 Bit), der die Transparenz jedes Pixels speichert.** ✅
|
||||
- [ ] Es nutzt eine höhere Auflösung.
|
||||
- [ ] Es kann mehr Dateiformate speichern.
|
||||
|
||||
> **Feedback:** 32 Bit = 24 Bit (RGB) + 8 Bit Alpha. Der Alpha-Kanal bestimmt, wie durchsichtig jeder Pixel ist (0 = vollständig transparent, 255 = vollständig undurchsichtig). Wichtig für PNGs mit Hintergrund-Transparenz.
|
||||
|
||||
---
|
||||
|
||||
### K5 – Raster vs. Vektor: Kern-Unterschied
|
||||
**Thema:** Raster vs. Vektor – Konzept
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was ist der fundamentale Unterschied zwischen Raster- und Vektorgrafiken?
|
||||
|
||||
- [ ] Vektorgrafiken sind immer farbiger als Rastergrafiken.
|
||||
- [x] **Rastergrafiken speichern einzelne Pixel; Vektorgrafiken speichern geometrische Beschreibungen (Pfade, Formen), die beliebig skaliert werden können.** ✅
|
||||
- [ ] Rastergrafiken können keine Farben darstellen, Vektorgrafiken schon.
|
||||
- [ ] Der Unterschied liegt nur in der Dateiendung, nicht im Inhalt.
|
||||
|
||||
> **Feedback:** Raster = „Malen nach Zahlen" (jeder Pixel einzeln). Vektor = „Bauanleitung" (Formen beschreiben). Diese Unterschied bestimmt alles: Skalierung, Dateigröße, Einsatzbereich.
|
||||
|
||||
---
|
||||
|
||||
### K6 – Raster vs. Vektor: Vergleich
|
||||
**Thema:** Raster vs. Vektor – Eigenschaften zuordnen
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jeder Eigenschaft zu: Raster oder Vektor?
|
||||
|
||||
| Eigenschaft | Typ |
|
||||
|---|---|
|
||||
| Skalierung ohne Qualitätsverlust | Vektor |
|
||||
| Ideal für Fotos | Raster |
|
||||
| Dateigröße abhängig von der Auflösung | Raster |
|
||||
| Ideal für Logos und Icons | Vektor |
|
||||
| Speicherung als 2D-Array von Pixeln | Raster |
|
||||
| Dateigröße abhängig von der Komplexität | Vektor |
|
||||
|
||||
> **Feedback:** Raster = Pixel-basiert, auflösungsabhängig, ideal für Fotos. Vektor = Beschreibungs-basiert, beliebig skalierbar, ideal für Grafiken/Logos.
|
||||
|
||||
---
|
||||
|
||||
### K7 – Skalierung: Warum werden Rasterbilder unscharf?
|
||||
**Thema:** Rastergrafiken – Skalierung Transfer
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erkläre, warum ein Rasterbild beim Vergrößern unscharf wird, während ein Vektorbild bei beliebiger Größe scharf bleibt. Nenne einen konkreten Anwendungsfall, in dem diese Eigenschaft ausschlaggebend ist.
|
||||
|
||||
> **Musterlösung:** Ein Rasterbild hat eine feste Auflösung (eine bestimmte Anzahl von Pixeln). Beim Vergrößern müssen neue Pixel „erfunden" werden (Interpolation) – es gibt keine echten Daten für die fehlenden Stellen → Unschärfe. Ein Vektorbild speichert nur Beschreibungen (Pfade, Formen). Beim Vergrößern werden einfach die Koordinaten skaliert – keine Information geht verloren → immer scharf. Anwendungsfall: Ein Logo auf einer Visitenkarte UND auf einem Plakat → SVG nutzen, damit es bei beliebiger Größe scharf bleibt.
|
||||
|
||||
---
|
||||
|
||||
### K8 – Vektor → Raster: Wie heißt das?
|
||||
**Thema:** Raster vs. Vektor – Konvertierung
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Wie heißt der Prozess, bei dem eine Vektorgrafik in eine Rastergrafik umgewandelt wird?
|
||||
|
||||
- [ ] Vektorisierung
|
||||
- [x] **Rasterisierung** ✅
|
||||
- [ ] Pixelierung
|
||||
- [ ] Komprimierung
|
||||
|
||||
> **Feedback:** Rasterisierung = Vektor → Raster (trivial, immer möglich). Der umgekehrte Prozess (Raster → Vektor) heißt „Tracing" und funktioniert oft nur unbefriedigend.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### K9 – Interpolation: Welches Verfahren wofür?
|
||||
**Thema:** Rastergrafiken – Interpolationsverfahren
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jedem Interpolationsverfahren seine Eigenschaft zu.
|
||||
|
||||
| Verfahren | Eigenschaft |
|
||||
|---|---|
|
||||
| Nearest Neighbor | Schnell, pixelig – gut für Pixel-Art |
|
||||
| Bilinear | Glättet, Standard-Verfahren |
|
||||
| Bicubic | Hohe Qualität, rechenintensiver |
|
||||
| Lanczos | Beste Qualität, mathematisch komplex |
|
||||
|
||||
> **Feedback:** Bei der Wahl: Pixel-Art → Nearest Neighbor (soll pixelig bleiben). Normale Bilder → Bilinear oder Bicubic. Maximale Qualität bei Fotos → Lanczos.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK L – JPEG: Innenleben
|
||||
|
||||
---
|
||||
|
||||
### L1 – JPEG: Verlustfrei oder verlustbehaftet?
|
||||
**Thema:** JPEG – Grundeigenschaft
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
JPEG ist ein …
|
||||
|
||||
- [x] **…verlustbehaftetes Bildformat. Beim Speichern werden Daten dauerhaft weggeworfen.** ✅
|
||||
- [ ] …verlustfreies Bildformat wie PNG.
|
||||
- [ ] …Videoformat für Streaming.
|
||||
- [ ] …Vektorgrafik-Format.
|
||||
|
||||
> **Feedback:** JPEG = Joint Photographic Experts Group. Verlustbehaftet: Beim Speichern werden Daten dauerhaft weggeworfen – eine gespeicherte JPEG kann nicht perfekt zum Original zurückgeführt werden. Quality 100 ≠ verlustfrei, nur „wenig wegwerfen".
|
||||
|
||||
---
|
||||
|
||||
### L2 – Psychovisuelle Kompression: Das Auge austricksen
|
||||
**Thema:** JPEG – Wahrnehmungsprinzip
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Wie nutzt JPEG die Schwächen des menschlichen Auges aus?
|
||||
|
||||
- [ ] Das Auge kann keine Farben wahrnehmen – daher werden Farben komplett entfernt.
|
||||
- [x] **Das Auge sieht Helligkeit besser als Farbe. JPEG behält die Helligkeit (Y) nahezu vollständig, reduziert aber die Farbauflösung (Cb, Cr) – der Verlust wird kaum wahrgenommen.** ✅
|
||||
- [ ] Das Auge kann keine Details sehen – daher werden alle Details entfernt.
|
||||
- [ ] JPEG nutzt keine Wahrnehmungsforschung, komprimiert rein mathematisch.
|
||||
|
||||
> **Feedback:** Psychovisuelle Kompression = Schwächen des Auges ausnutzen. Kern: Mehr Stäbchen (Helligkeit) als Zapfen (Farbe) im Auge → Helligkeit sichern, Farbe reduzieren. Der Verlust ist für Menschen kaum sichtbar.
|
||||
|
||||
---
|
||||
|
||||
### L3 – Farbraumkonversion: RGB → YCbCr
|
||||
**Thema:** JPEG Schritt 1 – Farbraum
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Warum wird bei JPEG von RGB in YCbCr konvertiert?
|
||||
|
||||
- [ ] YCbCr nutzt weniger Speicher pro Pixel als RGB.
|
||||
- [x] **In YCbCr sind Helligkeit (Y) und Farbe (Cb, Cr) getrennt – die Farbauflösung kann unabhängig von der Helligkeit reduziert werden.** ✅
|
||||
- [ ] RGB kann keine Transparenz darstellen, YCbCr schon.
|
||||
- [ ] Die Konvertierung ist ein verlustfreier Schritt, der die Dateigröße halbiert.
|
||||
|
||||
> **Feedback:** Y = Helligkeit (Luminanz), Cb/Cr = Farbdifferenzen (Chrominanz). Diese Trennung ermöglicht Chroma Subsampling: Helligkeit voll behalten, Farbe reduzieren – ohne sichtbaren Verlust.
|
||||
|
||||
---
|
||||
|
||||
### L4 – Chroma Subsampling: Was ist 4:2:0?
|
||||
**Thema:** JPEG Schritt 2 – Subsampling
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was bedeutet das Subsampling-Schema 4:2:0?
|
||||
|
||||
- [ ] 4 Pixel teilen sich eine Helligkeit, aber jeder hat eigene Farbe.
|
||||
- [x] **4 Pixel teilen sich einen Farbwert (Chrominanz), aber jeder hat eine eigene Helligkeit (Luminanz). Die Farbauflösung wird auf 25% reduziert.** ✅
|
||||
- [ ] 4:2:0 bedeutet, dass keine Farbe gespeichert wird – nur Graustufen.
|
||||
- [ ] Die Notation beschreibt die Blockgröße, nicht die Farbauflösung.
|
||||
|
||||
> **Feedback:** 4:2:0 = JPEG-Standard. Von 4 Pixeln wird nur 1 Farbwert gespeichert (2×2-Block teilt Farbe), aber jeder Pixel behält seine eigene Helligkeit. Ergebnis: 50% Datenreduktion, kaum sichtbar.
|
||||
|
||||
---
|
||||
|
||||
### L5 – JPEG-Schritte: Richtige Reihenfolge
|
||||
**Thema:** JPEG – Kompressionsablauf
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ORDER]`
|
||||
|
||||
Sortiere die Schritte der JPEG-Kompression in der richtigen Reihenfolge:
|
||||
|
||||
1. Farbraumkonversion (RGB → YCbCr)
|
||||
2. Chroma Subsampling
|
||||
3. Block-Aufteilung (8×8)
|
||||
4. DCT (Frequenzanalyse)
|
||||
5. Quantisierung (hier passiert der Verlust!)
|
||||
6. Huffman-Coding (verlustfrei)
|
||||
|
||||
> **Feedback:** Der einzige verlustbehaftete Schritt ist die Quantisierung (Schritt 5). Alles davor bereitet die Daten vor, alles danach komprimiert die Ergebnisse verlustfrei weiter.
|
||||
|
||||
---
|
||||
|
||||
### L6 – Welcher Schritt ist verlustbehaftet?
|
||||
**Thema:** JPEG – Verlust lokalisieren
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Bei welchem Schritt der JPEG-Kompression werden Daten dauerhaft weggeworfen?
|
||||
|
||||
- [ ] Farbraumkonversion (RGB → YCbCr)
|
||||
- [ ] DCT (Discrete Cosine Transform)
|
||||
- [x] **Quantisierung – hier werden unwichtige Frequenzkoeffizienten auf Null gesetzt oder vergröbert.** ✅
|
||||
- [ ] Huffman-Coding
|
||||
|
||||
> **Feedback:** DCT selbst ist verlustfrei und reversibel – es sortiert nur die Daten nach Wichtigkeit. Die Quantisierung ist der einzige verlustbehaftete Schritt: Sie wirft hohe Frequenzen (feine Details) weg. Huffman-Coding danach ist wieder verlustfrei.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### L7 – DCT: Was macht sie?
|
||||
**Thema:** JPEG – DCT-Prinzip
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was leitet die DCT (Discrete Cosine Transform) bei JPEG?
|
||||
|
||||
- [ ] Sie komprimiert die Daten verlustbehaftet.
|
||||
- [x] **Sie wandelt 64 Pixelwerte eines 8×8-Blocks in 64 Frequenzkoeffizienten um – sortiert die Information nach Wichtigkeit (niedrige Frequenz = wichtig, hohe Frequenz = Details).** ✅
|
||||
- [ ] Sie verschlüsselt die Daten für sichere Übertragung.
|
||||
- [ ] Sie reduziert die Farbauflösung des Bildes.
|
||||
|
||||
> **Feedback:** DCT = Herzstück von JPEG, aber selbst verlustfrei. Sie sortiert: Der DC-Koeffizient (0,0) = Durchschnittshelligkeit eines Blocks. Die AC-Koeffizienten = Helligkeitsänderungen. 90% der Information steckt in den ersten 10–15 Koeffizienten.
|
||||
|
||||
---
|
||||
|
||||
### L8 – Huffman-Coding: Prinzip
|
||||
**Thema:** JPEG – Huffman
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Wie funktioniert Huffman-Coding?
|
||||
|
||||
- [ ] Alle Zeichen bekommen gleich lange Codes – einfach und effizient.
|
||||
- [x] **Häufige Werte bekommen kurze Codes, selten vorkommende lange Codes – variable Bitlänge statt fester 8 Bit.** ✅
|
||||
- [ ] Huffman-Coding verschlüsselt die Daten zusätzlich.
|
||||
- [ ] Es funktioniert nur für Texte, nicht für Bilddaten.
|
||||
|
||||
> **Feedback:** Huffman = verlustfrei, optimal für bekannte Häufigkeiten. Präfix-frei: Kein Code ist Anfang eines anderen → eindeutig decodierbar. Auch in ZIP, PNG, MP3 verwendet.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### L9 – JPEG-Artefakte: Benennen
|
||||
**Thema:** JPEG – Artefakte identifizieren
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jedem JPEG-Artefakt seine Beschreibung zu.
|
||||
|
||||
| Artefakt | Beschreibung |
|
||||
|---|---|
|
||||
| Blocking | 8×8-Blöcke werden sichtbar als Rechteckmuster |
|
||||
| Ringing | „Geister" oder Halos an scharfen Kanten |
|
||||
| Posterization | Farbverläufe werden stufig statt fließend |
|
||||
|
||||
> **Feedback:** Alle drei sind Folgen der Quantisierung. Blocking: Weil jeder 8×8-Block unabhängig komprimiert wird. Ringing: DCT hat Probleme mit harten Kanten (Gibbs-Phänomen). Posterization: Zu wenige Bits für feine Farbabstufungen.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK M – Bildformate: PNG, GIF, WebP, SVG
|
||||
|
||||
---
|
||||
|
||||
### M1 – PNG: Verlustfrei oder verlustbehaftet?
|
||||
**Thema:** PNG – Grundeigenschaft
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Wie komprimiert PNG?
|
||||
|
||||
- [ ] Verlustbehaftet – wie JPEG, aber mit besserer Qualität.
|
||||
- [x] **Verlustfrei – die Originaldaten können perfekt rekonstruiert werden.** ✅
|
||||
- [ ] Gar nicht – PNG speichert Daten unkomprimiert.
|
||||
- [ ] PNG nutzt eine Kombination aus verlustfrei und verlustbehaftet.
|
||||
|
||||
> **Feedback:** PNG nutzt DEFLATE-Kompression (wie ZIP) – verlustfrei. Deshalb ist PNG ideal für Grafiken, Screenshots und Bilder mit Transparenz, aber größer als JPEG für Fotos.
|
||||
|
||||
---
|
||||
|
||||
### M2 – PNG vs. JPEG: Wann was?
|
||||
**Thema:** Bildformate – Formatwahl
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erklären Sie, wann Sie PNG und wann JPEG wählen würden. Nenne je zwei konkrete Anwendungsfälle und begründen Sie Ihre Wahl.
|
||||
|
||||
> **Musterlösung:** PNG: (1) Screenshots – Texte und Linien bleiben scharf, keine Artefakte. (2) Logos mit Transparenz – PNG unterstützt Alpha-Transparenz, JPEG nicht. JPEG: (1) Fotos fürs Web – deutlich kleiner bei kaum sichtbarem Qualitätsverlust. (2) Social Media – Plattformen re-komprimieren sowieso, PNG würde nur unnötig groß sein.
|
||||
|
||||
---
|
||||
|
||||
### M3 – GIF: Wie viele Farben?
|
||||
**Thema:** GIF – Eigenschaften
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Wie viele Farben kann ein GIF-Bild gleichzeitig anzeigen?
|
||||
|
||||
- [ ] 16 Farben
|
||||
- [ ] 16,7 Millionen Farben
|
||||
- [x] **256 Farben (8-Bit-Palette)** ✅
|
||||
- [ ] Unbegrenzt – GIF unterstützt alle Farben.
|
||||
|
||||
> **Feedback:** GIF = 8-Bit-Palette = 256 Farben maximal. Deshalb sehen GIF-Bilder bei Fotos oft banding/posterisiert aus. GIF überlebt heute wegen Animationen.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### M4 – WebP vs. JPEG: Vorteil?
|
||||
**Thema:** Bildformate – WebP
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was ist der hauptsächliche Vorteil von WebP gegenüber JPEG?
|
||||
|
||||
- [ ] WebP unterstützt Videos, JPEG nicht.
|
||||
- [x] **WebP erzeugt bei gleicher Qualität 25–35% kleinere Dateien als JPEG.** ✅
|
||||
- [ ] WebP ist verlustfrei, JPEG nicht.
|
||||
- [ ] WebP kann keine Fotos speichern, nur Grafiken.
|
||||
|
||||
> **Feedback:** WebP (Google, 2010) kann sowohl lossy als auch lossless komprimieren, unterstützt Transparenz und Animationen. Bei gleicher visueller Qualität sind WebP-Dateien deutlich kleiner als JPEG.
|
||||
|
||||
---
|
||||
|
||||
### M5 – SVG: Was ist es?
|
||||
**Thema:** SVG – Grundbegriff
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was ist SVG?
|
||||
|
||||
- [ ] Ein verlustbehaftetes Rasterbild-Format wie JPEG.
|
||||
- [x] **Ein Vektorgrafik-Format, das Bilder als geometrische Beschreibungen (XML) speichert – beliebig skalierbar ohne Qualitätsverlust.** ✅
|
||||
- [ ] Ein Video-Container wie MP4.
|
||||
- [ ] Ein komprimiertes Archivformat wie ZIP.
|
||||
|
||||
> **Feedback:** SVG = Scalable Vector Graphics. Web-Standard für Vektorgrafiken. Beschreibt WAS gezeichnet werden soll (`<circle>`, `<rect>`, `<path>`), nicht wie jeder Pixel aussieht. Ideal für Logos, Icons, Illustrationen.
|
||||
|
||||
---
|
||||
|
||||
### M6 – Formatwahl: Szenario zuordnen
|
||||
**Thema:** Bildformate – Formatwahl Transfer
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jedem Szenario das optimale Bildformat zu.
|
||||
|
||||
| Szenario | Format |
|
||||
|---|---|
|
||||
| Ein Foto für eine Webseite (klein, OK-Qualität) | JPEG |
|
||||
| Ein Screenshot einer Benutzeroberfläche | PNG |
|
||||
| Ein Logo, das auf allen Bildschirmgrößen scharf sein muss | SVG |
|
||||
| Ein animiertes Reaktionsbild für einen Chat | GIF |
|
||||
|
||||
> **Feedback:** JPEG = Fotos (klein, lossy OK). PNG = Screenshots, Grafiken mit Transparenz (verlustfrei). SVG = Logos, Icons (skalierbar). GIF = Animationen (256 Farben, aber Animations-Support).
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK N – Video-Kompression
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### N1 – Spatial vs. Temporal Compression
|
||||
**Thema:** Video – Kompressionsprinzipien
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jedem Prinzip seine Beschreibung zu.
|
||||
|
||||
| Prinzip | Beschreibung |
|
||||
|---|---|
|
||||
| Spatial Compression (Intra-Frame) | Komprimiert jedes einzelne Bild für sich (wie JPEG) |
|
||||
| Temporal Compression (Inter-Frame) | Speichert nur die Änderungen zwischen aufeinanderfolgenden Bildern |
|
||||
| Motion Compensation | Beschreibt Bewegung durch Vektoren statt Pixel zu kopieren |
|
||||
|
||||
> **Feedback:** Spatial = räumlich (innerhalb eines Frames). Temporal = zeitlich (zwischen Frames). Motion Compensation = Bewegungsvektoren. 90% eines Frames ist oft identisch mit dem vorherigen – deshalb ist Temporal-Kompression so wirksam.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### N2 – I-Frame, P-Frame, B-Frame: Was ist was?
|
||||
**Thema:** Video – Frame-Typen
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jedem Frame-Typ seine Beschreibung zu.
|
||||
|
||||
| Frame-Typ | Beschreibung |
|
||||
|---|---|
|
||||
| I-Frame (Keyframe) | Vollständiges Bild, unabhängig dekodierbar – keine Referenz auf andere Frames |
|
||||
| P-Frame | Nur Änderungen gegenüber vorherigen Frames speichern (~30% der Größe eines I-Frames) |
|
||||
| B-Frame | Änderungen gegenüber vorherigen UND zukünftigen Frames (~15% der Größe eines I-Frames) |
|
||||
|
||||
> **Feedback:** I = Intra (innerhalb). P = Predicted (aus Vergangenheit). B = Bi-directional (Vergangenheit + Zukunft). B-Frames sind am kleinsten, aber brauchen mehr Rechenleistung zum Decodieren.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### N3 – Was passiert, wenn ein I-Frame beschädigt ist?
|
||||
**Thema:** Video – I-Frame Bedeutung Transfer
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erkläre, warum ein I-Frame bei der Videokompression so wichtig ist. Was passiert, wenn ein einzelner I-Frame in einem Videostream beschädigt wird?
|
||||
|
||||
> **Musterlösung:** Ein I-Frame ist ein vollständiges, unabhängig dekodierbare Bild. Alle nachfolgenden P- und B-Frames referenzieren auf vorherige Frames – letztlich auf das letzte I-Frame. Wenn ein I-Frame beschädigt wird, können alle abhängigen P- und B-Frames bis zum nächsten intakten I-Frame nicht mehr korrekt rekonstruiert werden → Videofehler sichtbar bis zum nächsten Keyframe. Deshalb werden typischerweise alle 1–2 Sekunden neue I-Frames eingefügt.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### N4 – Motion Compensation: Prinzip
|
||||
**Thema:** Video – Motion Compensation
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was beschreibt ein Motion Vector bei der Videokompression?
|
||||
|
||||
- [ ] Die Helligkeit eines einzelnen Pixels.
|
||||
- [x] **Die Verschiebung eines Bildblocks zwischen zwei Frames (z. B. „verschiebe um +20 Pixel nach rechts").** ✅
|
||||
- [ ] Die Kompressionsrate des gesamten Videos.
|
||||
- [ ] Die Anzahl der Farben in einem Frame.
|
||||
|
||||
> **Feedback:** Motion Compensation speichert Bewegung als Vektoren statt Pixel zu kopieren. Wenn sich ein 16×16-Block von (100,200) auf (120,200) bewegt, wird nur „+20, 0" gespeichert – deutlich kleiner als den Block zweimal zu speichern.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### N5 – Video-Codecs: Zeitstrahl
|
||||
**Thema:** Video – Codecs-Übersicht
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ORDER]`
|
||||
|
||||
Sortiere die Video-Codecs nach Veröffentlichungsjahr (alt → neu):
|
||||
|
||||
1. H.264 / AVC (2003)
|
||||
2. H.265 / HEVC (2013)
|
||||
3. VP9 (2013)
|
||||
4. AV1 (2018)
|
||||
|
||||
> **Feedback:** H.264 revolutionierte Streaming. H.265 und VP9 kamen gleichzeitig – H.265 technisch besser, aber Patent-Chaos. AV1 vereint die Industrie: patent-frei, 30% besser als H.265.
|
||||
|
||||
---
|
||||
|
||||
### N6 – AV1: Warum die Zukunft?
|
||||
**Thema:** Video – AV1 Transfer
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erkläre, warum AV1 als „die Zukunft" der Videokompression gilt. Nenne mindestens zwei konkrete Eigenschaften und erkläre, warum H.265 trotz besserer technischer Kompression nicht die gleiche Dominanz erreicht hat.
|
||||
|
||||
> **Musterlösung:** AV1 (2018) ist royalty-free und open source – die Alliance for Open Media vereint Google, Netflix, Amazon, Apple, Mozilla. Es liefert 30% bessere Kompression als H.265 und unterstützt 8K, HDR, hohe Frame-Rates. H.265 scheitert vor allem am Patent-Chaos: Drei konkurrierende Patent-Pools (MPEG-LA, HEVC Advance, Velos Media) erzeugen rechtliche Unsicherheit und unklare Kosten → viele Unternehmen bleiben bei H.264 oder wechseln direkt zu AV1.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK O – Speichermedien & Schnittstellen
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### O1 – KB vs. KiB: Was ist der Unterschied?
|
||||
**Thema:** Speicher – Einheiten
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Eine Festplatte wird als „1 TB" vermarktet, aber Windows zeigt nur ~931 GB an. Warum?
|
||||
|
||||
- [ ] Windows zeigt falsche Werte an – das ist ein Bug.
|
||||
- [x] **Hersteller nutzen dezimale Einheiten (1 TB = 1.000 GB), Windows nutzt binäre Einheiten (1 TiB = 1.024 GiB). Bei TB-Größen entsteht eine ~7% Diskrepanz.** ✅
|
||||
- [ ] Die Festplatte verliert beim Formatieren fast 10% ihrer Kapazität.
|
||||
- [ ] Windows reserviert automatisch 10% als Sicherheitspuffer.
|
||||
|
||||
> **Feedback:** SI (Dezimal): 1 KB = 1.000 Bytes, 1 MB = 1.000 KB. IEC (Binär): 1 KiB = 1.024 Bytes, 1 MiB = 1.024 KiB. Bei 1 TB: 1.000⁴ vs. 1.024⁴ Bytes → ~7% Unterschied. Windows zeigt binäre Werte an, aber mit SI-Bezeichnung (GB statt GiB) → Verwirrung.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### O2 – HDD vs. SSD: Kern-Unterschied
|
||||
**Thema:** Speichermedien – HDD vs. SSD
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was ist der fundamentale technische Unterschied zwischen HDD und SSD?
|
||||
|
||||
- [ ] HDDs sind elektronisch, SSDs mechanisch.
|
||||
- [x] **HDDs speichern Daten magnetisch auf sich drehenden Plattern (mechanisch). SSDs nutzen Flash-Speicher (elektronisch, keine beweglichen Teile).** ✅
|
||||
- [ ] Beide Technologien funktionieren identisch, der Unterschied liegt nur im Gehäuse.
|
||||
- [ ] HDDs nutzen Flash-Speicher, SSDs magnetische Platten.
|
||||
|
||||
> **Feedback:** HDD = Hard Disk Drive = mechanisch (Platter, Spindel, Schreib-Lese-Kopf). SSD = Solid State Drive = elektronisch (Flash-Speicher). Diese Unterschied bestimmt alles: Geschwindigkeit, Latenz, Geräusche, Haltbarkeit.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### O3 – HDD vs. SSD: Eigenschaften zuordnen
|
||||
**Thema:** Speichermedien – Vergleich
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jeder Eigenschaft zu: HDD oder SSD?
|
||||
|
||||
| Eigenschaft | Typ |
|
||||
|---|---|
|
||||
| Sequentielle Lesgeschwindigkeit ~150 MB/s | HDD |
|
||||
| Sequentielle Lesgeschwindigkeit ~3.500 MB/s | SSD (NVMe) |
|
||||
| Latenz ~10 ms | HDD |
|
||||
| Latenz ~0,02 ms | SSD |
|
||||
| Günstig pro TB (~15€/TB) | HDD |
|
||||
| Ideal für Betriebssystem | SSD |
|
||||
|
||||
> **Feedback:** Der dramatische Unterschied liegt bei Random Access: SSD ~500× schneller. Deshalb: Betriebssystem auf SSD, Archiv auf HDD. Viele nutzen beides: Kleine SSD für System + große HDD für Daten.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### O4 – USB-C: Stecker oder Protokoll?
|
||||
**Thema:** Schnittstellen – USB-C
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Ein USB-C-Kabel kann langsam sein, obwohl es wie ein „modernes" Kabel aussieht. Warum?
|
||||
|
||||
- [ ] USB-C-Kabel sind immer gleich schnell – die Geschwindigkeit liegt am Gerät.
|
||||
- [x] **USB-C ist nur ein Steckertyp, kein Protokoll. Ein USB-C-Kabel kann USB 2.0 (480 Mbit/s) bis USB4 (40 Gbit/s) sein – am Stecker nicht erkennbar.** ✅
|
||||
- [ ] USB-C-Kabel werden nach einem Jahr automatisch langsamer.
|
||||
- [ ] Die Geschwindigkeit hängt nur vom Betriebssystem ab.
|
||||
|
||||
> **Feedback:** USB-C = Steckerform. Das Protokoll dahinter kann USB 2.0, 3.2 oder USB4 sein. Ein billiges USB-C-Kabel ist oft nur USB 2.0 mit neuem Stecker. Kabel-Spezifikation prüfen!
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### O5 – Dateisysteme: Zuordnung
|
||||
**Thema:** Dateisysteme – Überblick
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jedem Dateisystem seine ideale Anwendung zu.
|
||||
|
||||
| Dateisystem | Ideal für |
|
||||
|---|---|
|
||||
| FAT32 | USB-Sticks, SD-Karten (maximale Kompatibilität) |
|
||||
| NTFS | Windows-Systeme (Journaling, Rechte) |
|
||||
| APFS | macOS, iOS (Snapshots, CoW) |
|
||||
| ext4 | Linux-Systeme (Journaling, stabil) |
|
||||
| exFAT | Große Dateien auf portablen Medien |
|
||||
|
||||
> **Feedback:** FAT32 = kleinster gemeinsamer Nenner, aber max. 4 GB pro Datei. exFAT = FAT32 ohne Größenlimits. NTFS/APFS/ext4 = moderne Systeme mit Journaling. Journaling = bei Absturz werden Änderungen nicht verloren.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### O6 – FAT32: Warum nicht für große Dateien?
|
||||
**Thema:** Dateisysteme – FAT32 Limitation
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Sie versuchen, eine 5-GB-Videodatei auf einen FAT32-formatierten USB-Stick zu kopieren. Was passiert?
|
||||
|
||||
- [ ] Die Datei wird automatisch aufgeteilt in kleinere Teile.
|
||||
- [x] **Der Vorgang fehlschlägt – FAT32 unterstützt keine einzelnen Dateien größer als 4 GB.** ✅
|
||||
- [ ] Die Datei wird automatisch komprimiert, bis sie unter 4 GB ist.
|
||||
- [ ] FAT32 hat keine Dateigrößenbeschränkung.
|
||||
|
||||
> **Feedback:** FAT32-Limit: max. 4 GB pro Datei. Ein 4K-Video oder ISO-Image passt oft nicht. Lösung: USB-Stick mit exFAT oder NTFS formatieren.
|
||||
|
||||
---
|
||||
|
||||
### O7 – Die 3-2-1-Regel
|
||||
**Thema:** Backup – Prinzip
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erkläre die 3-2-1-Regel für Backups. Begründe, warum jede der drei Ziffern wichtig ist.
|
||||
|
||||
> **Musterlösung:** 3 Kopien: Original + 2 Backups. Warum? Das Original kann kaputt gehen, das erste Backup auch – das zweite ist der Sicherheitspuffer. 2 verschiedene Medientypen (z. B. SSD + HDD, oder lokal + Cloud). Warum? Gleiche Medien haben gleiche Schwachstellen (z. B. Batch-Fehler bei HDDs derselben Charge). 1 Kopie an einem anderen Ort (Cloud, anderes Gebäude). Warum? Brand oder Wasserschaden zerstört alles vor Ort; Ransomware verschlüsselt alle angeschlossenen Laufwerke gleichzeitig.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### O8 – Backup-Arten: Unterschiede
|
||||
**Thema:** Backup – Typen
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jedem Backup-Typ seine Beschreibung zu.
|
||||
|
||||
| Backup-Typ | Beschreibung |
|
||||
|---|---|
|
||||
| Full (Vollständig) | Kompletter Datenbestand jedes Mal – einfach, aber langsam und platzhungrig |
|
||||
| Inkrementell | Nur Änderungen seit dem letzten Backup (egal welcher Art) – schnell, aber Wiederherstellung komplex |
|
||||
| Differenziell | Änderungen seit dem letzten Voll-Backup – Mittelweg zwischen beiden |
|
||||
|
||||
> **Feedback:** Typisches Schema: Sonntag Full, Mo–Sa Inkrementell oder Differenziell. Inkrementell = schnellstes Backup, langsamste Wiederherstellung (Kette aufbauen). Full = langsamstes Backup, schnellste Wiederherstellung.
|
||||
Reference in New Issue
Block a user