From d8bb5b6d1cb0605a38365d8dd6f932fc87abc21e Mon Sep 17 00:00:00 2001
From: Peter Gerwinski <peter.gerwinski@hs-bochum.de>
Date: Wed, 12 Jun 2024 08:07:00 +0200
Subject: [PATCH] Notizen 6.6.2024
---
20240606/ad-20240606.txt | 250 +++++++++++++++++++++++++++++++++++++++
1 file changed, 250 insertions(+)
create mode 100644 20240606/ad-20240606.txt
diff --git a/20240606/ad-20240606.txt b/20240606/ad-20240606.txt
new file mode 100644
index 0000000..5d78501
--- /dev/null
+++ b/20240606/ad-20240606.txt
@@ -0,0 +1,250 @@
+Bildkompressionsalgorithmus, selbst entwickelt, 06.06.2024, 17:22:52
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+verlustbehafteter Algorithmus: Informationen gehen dauerhaft verloren.
+--> Rekonstruktionen durch KI sind notwendigerweise fehlerhaft.
+
+Anzahl der Pixel verkleinern: mehrere Pixel zu 1 zusammenfassen, Farben mitteln
+--> Reduktion der Größe --> Wir verlieren Bildschärfe.
+Farbspektrum minimieren --> Wir verlieren Farbinformation.
+
+Verlustfreie Kompression, 06.06.2024, 17:27:57
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Kann es einen verlustfreien Kompressionsalgorithmus geben, der _immer_ zu einem
+kürzeren Ergebnis führt?
+--> Nein, denn dann könnte man dieses Ergebnis weiter verkleinern,
+ bis man zwangsläufig irgendwann bei 0 Bit (leere Datei) ankommt.
+--> Nein, denn es gibt 2^n verschiedene Nachrichten mit n Bits,
+ aber nur 2^(n-1) verschiedene Nachrichten mit n - 1 Bits.
+ --> Sobald ich Bits weg-komprimiere, kann ich nicht mehr alle
+ möglichen Nachrichten darstellen.
+
+Huffman-Kodierung:
+ - Bestimmung der relativen Häufigkeit der Symbole
+ (z.B. Text in deutscher Sprache: e ist am häufigsten, y eher selten)
+ - Erstellung eines binären Baumes: häufige Symbole ganz oben (Wurzel),
+ seltene Symbole unten (Blätter).
+ - Zuordnung von Bitfolgen gemäß dem Baum:
+ kurze Folgen für häufige, lange für seltene
+
+Auch Morse-Code ist eine Art Huffman-Kodiering, allerdings
+mit einem (mindestens) ternären Baum:
+es gibt nicht nur "0" und "1", sondern "kurz", "lang" und "Pause"
+
+
+ .----- jeweils 3 Abzweigungen
+ v
+
+ kurz + Pause: e
+ + kurz + Pause: i
+ |
+ + lang + Pause: a
+ + kurz + Pause: r
+
+ lang + Pause: t
+
+ Pause: Leerzeichen
+
+Nachteil der Huffman-Kodierung:
+Man muß den Codierungsbaum ("Morse-Alphabet") mitsenden -
+oder sich vorher auf einen "Universal"-Codierungsbaum einigen.
+
+Lempel-Ziv-Welch-Algorithmus: Baum wächst mit, 06.06.2024, 17:45:25
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+8-Bit-Daten komprimieren: Wir senden zunächst 9-Bit-Code.
+Die unteren 8 Bit entsprechen den Daten.
+
+Beispiel: BARBARAS RHABARBERBAR (21 Zeichen)
+sende: B (+0-Bit)
+ A merke: BA = 256
+ R merke: AR = 257
+ BA merke: RBA = 258
+ R merke: BAR = 259
+ A merke: RA = 260
+ S merke: AS = 261
+ _ (Leerzeichen) merke: S_ = 262
+ R merke: _R = 263
+ H merke: RH = 264
+ A merke: HA = 265
+ BAR merke: ABAR = 266
+ B merke: BARB = 267
+ E merke: BE = 268
+ RBA merke: ERBA = 269
+ R merke: RBAR = 270
+ ---------
+ 16 · 9 Bit ^^^^^^^^^^^^^^^^^
+ gesendet Wenn das überläuft: von 9 Bit auf 10 erweitern
+ = 18 Bytes
+
+Differenzbildung, 06.06.2024, 17:59:53
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Beispiel: Linie in Pixelgrafik
+ 100 nach rechts -.
+ 1 rauf |
+ 5 nach rechts |
+ 1 rauf |
+ 2 nach rechts |
+ 1 rauf |
+ 1 nach rechts |
+ 1 rauf } Diese Zahlen sind leicht zu komprimieren, z.B.:
+ 1 nach rechts | - mit LZW
+ 1 rauf | - y als 4-Bit-Zahlen mit Vorzeichen,
+ 1 nach rechts | x als 3-Bit-Zahlen mit Vorzeichen,
+ 2 rauf | + Escape-Symbol für "Ausreißer" (z.B. die 100 am Anfang)
+ 1 nach rechts |
+ 1 rauf |
+ 1 nach rechts |
+ 3 rauf -'
+
+Davon kann man auch noch mal Differenzen bilden:
+ 100
+ -99
+ +4
+ -4
+ +1
+ 0
+ 0
+ 0
+ 0
+ ...
+--> In manchen Fällen wird das Ergebnis dadurch noch leichter zu komprimieren.
+
+Besondere Praxisrelevanz: Video-Komprimierung
+Video-Formate haben Key-Frames (ganzes Bild abgespeichert).
+Bilder zwischen den Key-Frames werden als Differenzen dazu abgespeichert.
+(zusätzlich: Vektoren für Scrolling, z.B. bei Kameraschwenks)
+
+Weitere Nutzen von Key-Frames:
+ - Resynchronisation bei Ausfällen (z.B. beim Streamen)
+ - Nutzung von verlustbehafteter Komprimierung möglich
+
+Verlustbehaftete Kompression: JPEG, 06.06.2024, 18:19:14
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Farbmodell umrechnen: statt Rot/Grün/Blau verwenden wir:
+ - Kontrast (Graustufenbild) - gut sichtbar, in voller Auflösung speichern
+ - Differenz Blau/Gelb ("color blueness") - schlecht sichtbar, in halber Auflösung speichern
+ - Differenz Rot/trün ("color redness") - schlecht sichtbar, in halber Auflösung speichern
+--> Bereits hierdurch: Komprimierung um den Faktor ...
+ vorher: 24 Bit pro Pixel
+ nachher: 8 Bit (Graustufen) + 1/4 von 8 Bit (redness) + 1/4 von 8 Bit (blueness)
+ = 12 Bit pro Pixel
+ ... Faktor 2.
+
+Räumliche Fourier-Transformation
+ - 8x8 Pixel, jeweils eine Zahl speichern, z.B. von 0 bis 255 --> 64 Bytes
+--> 64 Basisvektoren für den Vektorraum aller auf diese Weise möglichen Bilder
+
+ . .
+ | 1 | Zeile 1, Spalte 1
+ | 0 | Zeile 1, Spalte 2
+ | 0 |
+ | 0 |
+ | 0 |
+ a1 = | 0 | 64 Komponenten für ein Bild aus 8x8 Pixeln
+ | · |
+ | · |
+ | · |
+ | 0 |
+ | 0 | Zeile 64, Spalte 64
+ ` '
+
+ . .
+ | 0 | Zeile 1, Spalte 1
+ | 0 | Zeile 1, Spalte 2
+ | 0 |
+ | 0 |
+ | 0 |
+ a64 = | 0 | 64 Komponenten für ein Bild aus 8x8 Pixeln
+ | · |
+ | · |
+ | · |
+ | 0 |
+ | 1 | Zeile 8, Spalte 8
+ ` '
+
+
+ Bild = x0 · a1 + x1 · a2 + ... + x64 · a64
+
+Trick: Verwende eine andere Basis --> Fourier-Transformation
+
+ . .
+ | 1 | Zeile 1, Spalte 1
+ | 1 | Zeile 1, Spalte 2
+ | 1 |
+ | 1 |
+ | 1 |
+ b1 = | 1 | 64 Komponenten für ein Bild aus 8x8 Pixeln
+ | · |
+ | · |
+ | · |
+ | 1 |
+ | 1 | Zeile 64, Spalte 64
+ ` '
+
+ . .
+ | 1 | Zeile 1, Spalte 1
+ | 0 | Zeile 1, Spalte 2
+ | 1 |
+ | 0 |
+ | 1 |
+ | 0 |
+ | 1 |
+ | 0 | Zeile 1, Spalte 8
+ | 0 | Zeile 2, Spalte 1
+ | 1 |
+ | 0 |
+ | 1 |
+ | 0 |
+ | 1 |
+ | · |
+ | · |
+ | · |
+ b64 = | 0 | 64 Komponenten für ein Bild aus 8x8 Pixeln
+ | · |
+ | · |
+ | · |
+ | 1 |
+ | 0 |
+ | 1 |
+ | 0 | Zeile 8, Spalte 8
+ ` '
+
+Siehe: https://de.wikipedia.org/wiki/Datei:Dctjpeg.png
+
+Stelle das Bild bzgl. der Basis b (statt a) dar
+--> andere Zahlen, z.B. y1 bis y64 (statt x1 bis x64)
+
+Trick: lasse alls Basisvektoren "unten rechts" "einfach so" weg.
+--> Was man schlechter sehen kann, verschwindet.
+(Siehe auch: https://de.wikipedia.org/wiki/Datei:JPEG_ZigZag.jpg)
+
+Danach: Differenz bilden
+
+Danach: Huffman-Kodierung
+
+Bemerkungen zur Kompression, 06.06.2024, 18:43:55
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ - "Eine Datei wird durch wiederholtes Kopieren immer schlechter."
+ --> Nein, wird sie nicht.
+
+ - "Komprimieren lohnt sich nicht. Mein Netz ist schnell genug."
+ --> Doch. Es lohnt sich.
+
+ - Eine Datei wird durch Komprimieren und Dekomprimieren ...
+ --> nicht schlechter (bei verlustfreier Kompression)
+ --> schlechter (bei verlustbehafteter Kompression)
+
+ - Pixel- vs. Vektorgrafik
+
+ Für Strichzeichnungen (z.B. Schaltpläne, UML-Diagramme, ...)
+ --> Vektorgrafik verwenden. PDF (kann auch Pixelgrafik enthalten!), SVG, PS, EPS, ...
+ Pixelgrafik hat geringere Qualität und verbraucht viel mehr Speicherplatz.
+
+ Für Fotos und Vergleichbares: verlustbehaftet komprimieren. JPEG
+ --> In der Regel ist eine Auflösung von 300 dpi zu empfehlen.
+ dpi = dots per inch = Pixel pro 2.54cm
+ z.B. für ein Bild der Breite 5.08cm: 600 Bildpunkte
+
+ Für pixelgenaue Nicht-Foto-Grafiken: verlustfrei komprimieren. PNG
+
+ - E-Mail-Attachments sind Base64-codiert (6 von 8 Bit)
+ und damit viel größer als die Original-Daten
--
GitLab