hdm fixes
This commit is contained in:
@@ -8,7 +8,8 @@ footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||
---
|
||||
|
||||
<style>
|
||||
<style>Byte zählen
|
||||
|
||||
:root {
|
||||
--color-foreground: #1a1a2e;
|
||||
--color-highlight: #1e5f8a;
|
||||
@@ -1191,33 +1192,6 @@ Sog. RGB Tuple (geordnete endliche Liste)
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
Kernidee: jedes Byte lässt sich sauber in zwei 4-Bit-Hälften (Nibbles) zerlegen. Jede Hälfte hat 2⁴ = 16 Zustände – und genau 16 Symbole hat Hex (0-F). Deshalb passt Hex perfekt: 1 Nibble = 1 Hex-Ziffer, 1 Byte = 2 Hex-Ziffern. Keine krumme Umrechnung.
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
Warum gerade 8 Bit?
|
||||
- CPU adressiert byteweise — kleinste adressierbare Einheit
|
||||
- Halbe Byte (z.B. 0x0000.5) existieren nicht
|
||||
- Speichercontroller, Bus, CPU-Register alle auf 8-Bit-Häppchen ausgelegt
|
||||
- Einzelne Bit lesen: erst Byte holen, dann mit Bitmaske isolieren (byte & 0b1000_0000)
|
||||
- Hardware-Geschichte: IBM System/360 (1964) setzte 8-Bit-Standard, 7-Bit-ASCII + 1 Paritätsbit
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Hexadezimal
|
||||
@@ -1246,50 +1220,7 @@ Warum gerade 8 Bit?
|
||||
- "Nibble" = 4 Bits = halbes Byte (Wortspiel: nibble = knabbern, byte = beißen)
|
||||
- ASCII geht nur bis 127 — Werte 128–255 sind nicht im ASCII-Raum
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
Hex ↔ Dezimal Lookup-Tabelle: 0–F = 0–15
|
||||
A=10, B=11, C=12, D=13, E=14, F=15
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
1 Byte = 8 Bit = 2 Hex-Ziffern = 1 ASCII-Zeichen
|
||||
- Dieselbe Datei, drei Schreibweisen
|
||||
- Jeder Rahmen = ein Byte
|
||||
- Byte ändern sich nicht, nur unsere Anzeige
|
||||
- ↵ (0x0A) = nicht druckbar → Hex-Editoren zeigen . als Platzhalter
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
Dieselben 8 Byte (PNG-Dateianfang: 89 50 4E 47 0D 0A 1A 0A) — drei Perspektiven:
|
||||
1. Bitstream — was wirklich gespeichert wird (unleserlich)
|
||||
2. Hex — gruppiert in 8-Bit-Häppchen (kompakt)
|
||||
3. Bedeutung — was die Byte signalisieren:
|
||||
- 89: Magic Byte (>127 → "ich bin Binärdatei")
|
||||
- 50 4E 47: P N G (ASCII-Format-Kürzel)
|
||||
- 0D 0A 1A 0A: CR LF EOF LF (erkennt kaputte Übertragung)
|
||||
-->
|
||||
2
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -713,11 +713,6 @@ KLAUSURRELEVANT:
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: klausur -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
<!-- _backgroundColor: #e3f2fd -->
|
||||
|
||||
# JPEG Schritt 6: Huffman-Coding
|
||||
|
||||
**Verlustfreie Kompression der Restwerte**
|
||||
@@ -770,40 +765,6 @@ JPEG verwendet zwei Huffman-Tabellen: eine für DC-Koeffizienten (Durchschnittsw
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: klausur -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
<!-- _backgroundColor: #e3f2fd -->
|
||||
<!--
|
||||
# Huffman-Coding: Beispiel
|
||||
|
||||
**Originaltext:** `ABRACADABRA` (11 Zeichen × 8 Bit = 88 Bit)
|
||||
|
||||
**Häufigkeitsanalyse:**
|
||||
A=5, B=2, R=2, C=1, D=1
|
||||
|
||||
**Huffman-Baum → Codes:**
|
||||
| Zeichen | Häufigkeit | Code |
|
||||
|---------|------------|------|
|
||||
| A | 5 | `0` |
|
||||
| B | 2 | `10` |
|
||||
| R | 2 | `110` |
|
||||
| C | 1 | `1110` |
|
||||
| D | 1 | `1111` |
|
||||
|
||||
**Codiert:** `0 10 110 0 1110 0 1111 0 10 110 0` = **23 Bit**
|
||||
**Kompression:** 88 → 23 Bit = **74% gespart**
|
||||
|
||||
|
||||
- Beispiel Schritt für Schritt durchrechnen
|
||||
- Warum funktioniert's? A kommt 5× vor, bekommt kürzesten Code
|
||||
- Präfix-Eigenschaft: Kein Code ist Anfang eines anderen → eindeutig dekodierbar
|
||||
- Frage: "Was passiert, wenn alle Zeichen gleich häufig sind?" → Keine Ersparnis
|
||||
- In JPEG: Nicht Buchstaben, sondern DCT-Koeffizienten werden so codiert
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
@@ -824,8 +785,6 @@ A=5, B=2, R=2, C=1, D=1
|
||||
# Andere Bildformate
|
||||
## PNG, GIF, WebP, AVIF
|
||||
|
||||
15:33 Uhr weiter
|
||||
|
||||
<!--
|
||||
- JPEG ist nicht für alles geeignet
|
||||
- Jetzt: Alternativen und ihre Stärken
|
||||
|
||||
@@ -119,7 +119,7 @@ Hochschule der Medien Stuttgart
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Kapitel 3 – 23.01.2026
|
||||
# Kapitel 3
|
||||
## Speichermedien & Schnittstellen
|
||||
|
||||
---
|
||||
@@ -369,8 +369,7 @@ Seitdem native Linux-Unterstützung.
|
||||
**Features:**
|
||||
- Journaling (Crash-Sicherheit)
|
||||
- Dateirechte (ACLs)
|
||||
- Kompression, Verschlüsselung
|
||||
- Große Dateien und Volumes
|
||||
- Kompression, Verschlüsselung, große Dateien und Volumes
|
||||
|
||||
**Nachteile:**
|
||||
- Nur Windows schreibt nativ
|
||||
@@ -629,11 +628,6 @@ Millionen von Websites und Spielen verloren.
|
||||
- 30 Jahre Haltbarkeit
|
||||
- Für Cold Storage ideal
|
||||
|
||||
**M-DISC:**
|
||||
- Spezielle DVD/Blu-ray
|
||||
- 1.000+ Jahre Haltbarkeit (Herstellerangabe)
|
||||
- Für kleine, wichtige Daten
|
||||
|
||||
**Cloud:**
|
||||
- Glacier, Backblaze B2
|
||||
- Günstig für Langzeit
|
||||
|
||||
Reference in New Issue
Block a user