Skip to content
Snippets Groups Projects
Commit d8bb5b6d authored by Peter Gerwinski's avatar Peter Gerwinski
Browse files

Notizen 6.6.2024

parent 82fc5838
Branches
No related tags found
No related merge requests found
Hide whitespace changes
Inline Side-by-side
20240606/ad-20240606.txt 0 → 100644
+ 250
− 0
View file @ d8bb5b6d
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
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment

Impressum Datenschutzerklärung