JPEG
JPEG ([ˈdʒeɪpɛɡ]) ist die gebräuchliche Bezeichnung für die 1992 vorgestellte Norm ISO/IEC 10918-1 bzw. CCITT Recommendation T.81, die verschiedene Methoden der Bildkompression beschreibt. Die Bezeichnung „JPEG“ geht auf das Gremium Joint Photographic Experts Group zurück, das die JPEG-Norm entwickelt hat.[1]
JPEG schlägt verschiedene Komprimierungs- und Kodierungsmethoden vor, darunter verlustbehaftete und verlustfreie Kompression, verschiedene Farbtiefen sowie sequenzielle oder progressive Modi (normaler Bildaufbau bzw. allmähliche Verfeinerung). Weithin verbreitet ist nur die verlustbehaftete Komprimierung bei sequenziellem oder progressivem Modus und 8-Bit-Farbkanälen.
Die JPEG-Norm beschreibt lediglich Bildkompressionsverfahren, legt aber nicht fest, wie die so entstandenen Daten gespeichert werden sollen. Gemeinhin werden mit „JPEG-Dateien“ oder „JPG-Dateien“ Dateien im Grafikformat JPEG File Interchange Format (JFIF) bezeichnet. JFIF ist jedoch nur eine Art, JPEG-Daten abzulegen; SPIFF und JNG sind weitere, wenn auch wenig gebräuchliche, Möglichkeiten.
JPEG/JFIF unterstützt eine maximale Bildgröße von 65.535 × 65.535 Pixel.[2]
Übersicht und Standards
Die JPEG-Norm ISO/IEC 10918-1 definiert folgende Modi, von denen nur die farbig unterlegten gebräuchlich sind:
| Aufbau | Sequenziell (Sequential) | Progressiv (Progressive) | Verlustfrei (Lossless) | Hierarchisch (Hierarchical) | |||||||
| Kodierung | Huffman | Arithmetisch | Huffman | Arithmetisch | Huffman | Arithmetisch | |||||
| Bittiefe | 8 Bit | 12 Bit | 8 Bit | 12 Bit | 8 Bit | 12 Bit | 8 Bit | 12 Bit | 2-16 Bit | 2-16 Bit | Bittiefe je nach kombinierten Modi |
Zusätzlich zum in ISO/IEC 10918-1 definierten verlustbehafteten Modus gibt es noch die verbesserte, verlustfreie Komprimierungsmethode JPEG-LS, die in einer anderen Norm festgelegt wurde. Außerdem existiert noch die JBIG-Norm zur Komprimierung von Schwarzweißbildern.
JPEG und JPEG-LS sind in den folgenden Standards definiert:
| ● | JPEG (verlustbehaftet und verlustfrei): | ITU-T T.81 (PDF; 1,1 MB), ISO/IEC IS 10918-1 | |
| ● | JPEG (Erweiterungen): | ITU-T T.84 | |
| ● | JPEG-LS (verlustfrei, verbessert): | ITU-T T.87, ISO/IEC IS 14495-1 |
Die JPEG-Norm trägt den offiziellen Titel Information technology – Digital compression and coding of continuous-tone still images: Requirements and guidelines. Das „Joint“ im Namen stammt von der Zusammenarbeit von ITU, IEC und ISO.
Die JPEG-Komprimierung
Die JPEG-Norm definiert 41 verschiedene Unterdateiformate, von denen aber meist nur eines unterstützt wird (und welches auch fast alle Anwendungsfälle abdeckt).
Die Kompression erfolgt durch das Anwenden mehrerer Verarbeitungsschritte, von denen vier verlustbehaftet sind.
- Farbmodellumrechnung vom (meist) RGB-Farbraum ins YCbCr-Farbmodell (analog zu CCIR 601). (theoretisch verlustfrei, nach CCIR 601 verlustbehaftet).
- Tiefpassfilterung und Unterabtastung der Farbabweichungssignale Cb und Cr (verlustbehaftet).
- Einteilung in 8×8-Blöcke und diskrete Kosinustransformation dieser Blöcke (theoretisch verlustfrei, durch Rundungsfehler aber verlustbehaftet).
- Quantisierung (verlustbehaftet).
- Umsortierung.
- Entropiekodierung.
Die Datenreduktion erfolgt durch die verlustbehafteten Verarbeitungsschritte in Zusammenwirken mit der Entropiekodierung.
Kompressionen bis etwa 1,5–2 Bit/Pixel sind visuell verlustfrei, bei 0,7–1 Bit/Pixel sind noch gute Ergebnisse erzielbar, unter 0,3 Bit/Pixel wird JPEG praktisch unbrauchbar, das Bild wird zunehmend von unübersehbaren Kompressionsartefakten (Blockbildung, stufige Übergänge, Farbeffekte an Graukeilen) überdeckt. Der Nachfolger JPEG 2000 ist wesentlich weniger für diese Art von Artefakten anfällig.
Sieht man als Quellformat 24-Bit-RGB-Dateien an, erhält man Kompressionsraten von 12 bis 15 für visuell verlustfreie Bilder und bis zu 35 für noch gute Bilder. Die Qualität hängt aber neben der Kompressionsrate noch von der Art der Bilder ab. Rauschen und regelmäßige feine Strukturen im Bild verringern die maximal mögliche Kompressionsrate.
Der JPEG Lossless Mode zur verlustfreien Kompression verwendet ein anderes Verfahren (prädiktiver Koder und Entropiekodierung).
Farbmodellumrechnung
Das Ausgangsbild, welches meist als RGB-Bild vorliegt, wird in das YCbCr-Farbmodell umgerechnet. Grundsätzlich wird dabei das YPbPr-Schema nach CCIR 601 verwendet:
- Fehler beim Parsen (Konvertierungsfehler. Der Server („https://wikimedia.org/api/rest_“) hat berichtet: „Cannot get mml. Server problem.“): {\displaystyle {\begin{bmatrix}Y'\\Pb\\Pr\end{bmatrix}}\approx {\begin{bmatrix}0{,}299&0{,}587&0{,}114\\-0{,}168736&-0{,}331264&0{,}5\\0{,}5&-0{,}418688&-0{,}081312\end{bmatrix}}\cdot {\begin{bmatrix}R'\\G'\\B'\end{bmatrix}}}
Da die R′G′B′-Werte bereits digital als 8-Bit-Zahlen im Bereich {0, 1, …, 255} vorliegen, müssen die YPbPr-Komponenten lediglich verschoben (renormiert) werden, wodurch die Komponenten Y′ (Luminanz), Cb (color blueness) und Cr (color redness) entstehen:
- Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle \begin{bmatrix} Y' \\ Cb \\ Cr \end{bmatrix} \approx \begin{bmatrix} 0 \\ 128 \\ 128 \end{bmatrix} + \begin{bmatrix} 0{,}299 & 0{,}587 & 0{,}114 \\ -0{,}168736 & -0{,}331264 & 0{,}5 \\ 0{,}5 & -0{,}418688 & -0{,}081312 \end{bmatrix} \cdot \begin{bmatrix} R'_d \\ G'_d \\ B'_d \end{bmatrix} }
Die Komponenten liegen nun wiederum im Wertebereich {0, 1, …, 255}.
Bei der Umrechnung des Farbmodells entstehen die üblichen Rundungsfehler durch begrenzte Rechengenauigkeit.
Tiefpassfilterung der Farbdifferenzsignale
Die Farbabweichungssignale Cb und Cr werden meist in reduzierter Auflösung gespeichert. Dazu werden sie tiefpassgefiltert und unterabgetastet (im einfachsten Fall durch eine Mittelwertbildung).
Meist wird eine vertikale und horizontale Unterabtastung jeweils um den Faktor 2 verwendet (YCbCr 4:2:0), die die Datenmenge um den Faktor 4 reduziert. Bei dieser Umwandlung wird die Tatsache ausgenutzt, dass die Ortsauflösung des menschlichen Auges für Farben deutlich geringer ist als für Helligkeitsübergänge.
Blockbildung und diskrete Kosinustransformation
Jede Komponente (Y, Cb und Cr) des Bildes wird in 8×8-Blöcke eingeteilt. Diese werden einer zweidimensionalen diskreten Kosinustransformation (DCT) unterzogen:
- Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle F_{xy} = {1 \over 4} C_x C_y \sum_{m=0}^7 \sum_{n=0}^7 f_{mn} \cos \frac{(2m + 1) x \pi}{16} \cos \frac{(2n + 1) y \pi}{16} }
mit
- Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle C_x, C_y = \begin{cases} {1 \over \sqrt{2}} & \text{wenn }x, y = 0 \\ 1 & \text{sonst } \end{cases} }
Diese Transformation lässt sich unter Nutzung der schnellen Fourier-Transformation (FFT) mit sehr wenig Aufwand implementieren. Die DCT ist eine orthogonale Transformation, weist gute Energiekompressionseigenschaften auf und es gibt eine inverse Transformation, die IDCT (was auch bedeutet, dass die DCT verlustfrei ist, es gingen keine Informationen verloren, da die Daten lediglich in eine für die weitere Verarbeitung günstigere Form gebracht wurden).
Quantisierung
Wie bei allen verlustbehafteten Kodierungsverfahren wird die eigentliche Datenreduktion (und Qualitätsverschlechterung) durch eine Quantisierung erreicht. Dazu werden die DCT-Koeffizienten durch die Quantisierungsmatrix geteilt (elementweise dividiert) und danach auf die nächstliegende Ganzzahl gerundet:
- Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle F^Q(x,y) = \operatorname{round}\left(\frac{F(x,y)}{Q(x,y)}\right) }
Bei diesem Rundungsschritt findet eine Irrelevanzreduktion statt. Die Quantisierungsmatrix ist sowohl für die Qualität als auch für die Kompressionsrate verantwortlich. Sie ist in JPEG-Dateien im Header abgespeichert (DQT-Marker).
Optimal ist die Quantisierungsmatrix, wenn sie in etwa die Empfindlichkeit des Auges für die entsprechenden Ortsfrequenzen repräsentiert. Für grobe Strukturen ist das Auge empfindlicher, daher sind die Quantisierungswerte für diese Frequenzen kleiner als die für hohe Frequenzen.
Hier ein Beispiel für eine Quantisierungsmatrix und ihre Anwendung auf einen 8×8-Block aus DCT-Koeffizienten:
- Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle \begin{alignat}{2} Q &= \begin{bmatrix} 10 & 15 & 25 & 37 & 51 & 66 & 82 & 100 \\ 15 & 19 & 28 & 39 & 52 & 67 & 83 & 101 \\ 25 & 28 & 35 & 45 & 58 & 72 & 88 & 105 \\ 37 & 39 & 45 & 54 & 66 & 79 & 94 & 111 \\ 51 & 52 & 58 & 66 & 76 & 89 & 103 & 119 \\ 66 & 67 & 72 & 79 & 89 & 101 & 114 & 130 \\ 82 & 83 & 88 & 94 & 103 & 114 & 127 & 142 \\ 100 & 101 & 105 & 111 & 119 & 130 & 142 & 156 \end{bmatrix} \\ F &= \begin{bmatrix} 782{,}91 & 44{,}93 & 172{,}52 & -35{,}28 & -20{,}58 & 35{,}93 & 2{,}88 & -3{,}85 \\ -122{,}35 & -75{,}46 & -7{,}52 & 55{,}00 & 30{,}72 & -17{,}73 & 8{,}29 & 1{,}97 \\ -2{,}99 & -32{,}77 & -57{,}18 & -30{,}07 & 1{,}76 & 17{,}63 & 12{,}23 & -13{,}57 \\ -7{,}98 & 0{,}66 & 2{,}41 & -21{,}28 & -31{,}07 & -17{,}20 & -9{,}68 & 16{,}94 \\ 3{,}87 & 7{,}07 & 0{,}56 & 5{,}13 & -2{,}47 & -15{,}09 & -17{,}70 & -3{,}76 \\ -3{,}77 & 0{,}80 & -1{,}46 & -3{,}50 & 1{,}48 & 4{,}13 & -6{,}32 & -18{,}47 \\ 1{,}78 & 3{,}28 & 4{,}63 & 3{,}27 & 2{,}39 & -2{,}31 & 5{,}21 & 11{,}77 \\ -1{,}75 & 0{,}43 & -2{,}72 & -3{,}05 & 3{,}95 & -1{,}83 & 1{,}98 & 3{,}87 \end{bmatrix} \\ F^Q &= \begin{bmatrix} 78 & 3 & 7 & -1 & 0 & 1 & 0 & 0 \\ -8 & -4 & 0 & 1 & 1 & 0 & 0 & 0 \\ 0 & -1 & -2 & -1 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 \end{bmatrix} \end{alignat} }
wobei berechnet wird mit:
- Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle F^Q(0,0) = \operatorname{round}\left(\frac{F(0,0)}{Q(0,0)}\right) = \operatorname{round}\left(\frac{782{,}91}{10}\right) = 78 }
- Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle F^Q(0,1) = \operatorname{round}\left(\frac{F(0,1)}{Q(0,1)}\right) = \operatorname{round}\left(\frac{-122{,}35}{15}\right) = -8 }
usw.
Umsortierung und Differenzkodierung des Gleichanteils
Die 64 Koeffizienten der diskreten Cosinus-Transformation werden anhand der Frequenz sortiert. Dadurch ergibt sich eine zickzackförmige Reihenfolge, beginnend mit dem Gleichanteil mit der Frequenz 0. Nach dem englischen Direct Current (für Gleichstrom) wird er mit DC abgekürzt, hier bezeichnet er die mittlere Helligkeit. Die Koeffizienten mit hohem Wert stehen nun meist zuerst und kleine Koeffizienten weiter hinten. Dies optimiert die Eingabe der nachfolgenden Lauflängenkodierung. Die Umsortierreihenfolge sieht folgendermaßen aus:
1 2 6 7 15 16 28 29 3 5 8 14 17 27 30 43 4 9 13 18 26 31 42 44 10 12 19 25 32 41 45 54 11 20 24 33 40 46 53 55 21 23 34 39 47 52 56 61 22 35 38 48 51 57 60 62 36 37 49 50 58 59 63 64
Weiterhin wird der Gleichanteil noch einmal differentiell zum Block links daneben kodiert und auf diese Weise die Abhängigkeiten zwischen benachbarten Blöcken berücksichtigt.
Das obige Beispiel führt zu den folgenden umsortierten Koeffizienten
119 … 78 3 -8 0 -4 7 -1 0 -1 0 0 0 -2 1 0 1 1 -1 0 … 102 5 -5 0 3 -4 2 -1 0 0 0 0 1 1 -1 0 0 -1 0 0 0 0 0 0 0 1 0 … 75 -19 2 -1 0 -1 1 -1 0 0 0 0 0 0 1 … 132 -3 -1 -1 -1 0 0 0 -1 0 …
Die Differenzkodierung des ersten Koeffizienten ergibt dann:
-41 3 -8 0 -4 7 -1 0 -1 0 0 0 -2 1 0 1 1 -1 0 … 24 5 -5 0 3 -4 2 -1 0 0 0 0 1 1 -1 0 0 -1 0 0 0 0 0 0 0 1 0 … -27 -19 2 -1 0 -1 1 -1 0 0 0 0 0 0 1 … 57 -3 -1 -1 -1 0 0 0 -1 0 …
In strukturarmen Regionen (desselben Bildes) können die Koeffizienten auch so aussehen:
35 -2 0 0 0 1 0 … 4 0 1 0 … 0 0 2 0 1 0 … -13 0 -1 … 8 1 0 … -2 0 …
Diese Bereiche lassen sich natürlich besser als strukturreiche Gebiete kodieren. Beispielsweise durch eine Lauflängenkodierung.
Die Zickzack-Umsortierung der DCT-Koeffizienten fällt zwar unter den Schutzbereich des US-Patentes 4,698,672 (und weiterer Anmeldungen und Patente in Europa und Japan). Jedoch wurde 2002 herausgefunden, dass das beanspruchte Verfahren nach dem Stand der Technik nicht neu war, sodass die Ansprüche kaum durchsetzbar gewesen wären.[3] Inzwischen sind die Patente aus der Patentfamilie zu dem genannten US-Patent auch durch Zeitablauf erloschen, wie beispielsweise das EP-Patent 0 266 049 B1 im September 2007.
Entropiekodierung
Als Entropiekodierung wird meist eine Huffman-Kodierung verwendet. Der JPEG-Standard erlaubt auch eine arithmetische Kodierung. Obwohl diese zwischen 5 und 15 Prozent kleinere Dateien generiert, wird sie aus patentrechtlichen Gründen kaum verwendet, zudem ist diese Kodierung deutlich langsamer.
Die JPEG-Dekodierung
Die Dekompression (meist Dekodierung genannt) erfolgt invers zur Kompression:
- Entropie-Dekodierung
- Umsortierung
- Requantisierung
- Inverse Diskrete Kosinustransformation.
- Überabtastung und Tiefpassfilterung der Farbdifferenzsignal U und V (verlustbehaftet)
- Farbmodellumrechnung vom YCbCr-Farbmodell in den Zielfarbraum (meist RGB)
Die Dekompression ist zwar (weitgehend) verlustfrei, allerdings tritt das Inverse-Dekoder-Problem auf. Aus dekodierten Daten ist es nur schwierig möglich, die ursprüngliche Datei zu rekonstruieren. Ein Dekodier-Kodier-Vorgang verändert die Datei und ist damit nicht verlustfrei, es treten wie beim analogen Überspielen Generationsverluste auf.
Die Generationsverluste von JPEG sind allerdings vergleichsweise klein, wenn wieder die gleiche Quantisierungstabelle zum Einsatz kommt und die Blockgrenzen die gleichen sind. Bei geeigneten Randbedingungen kann man sie bei JPEG sogar vermeiden. Bei JPEG-2000 ist das nicht mehr der Fall (überlappende Transformationen, wie sie bei JPEG-2000 wie auch in der Audiodatenkompression zum Einsatz kommen, erfordern dafür utopische Rechenleistungen).
Inverse diskrete Kosinustransformation
Zur DCT existiert die inverse Transformation, die IDCT:
- Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle f_{xy} = {1 \over 4} \sum_{m=0}^7 \sum_{n=0}^7 C_m C_n F_{mn} \cos \left[ \frac{(2x + 1) m \pi}{16} \right] \cos \left[ \frac{(2y + 1) n \pi}{16} \right] }
mit den gleichen Korrekturfaktoren Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle C_k} wie bei der DCT.
Farbmodellumrechnung
Die Rückrechnung vom YCbCr-Farbmodell in den RGB-Farbraum erfolgt über die inverse Matrix der Hinrechnung, sie lautet:
- Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle \begin{bmatrix}R' \\ G' \\ B'\end{bmatrix} = \begin{bmatrix} 1 & 0 & 1{,}402 \\ 1 & -0{,}344136 & -0{,}714136 \\ 1 & 1{,}772 & 0 \end{bmatrix} \cdot \begin{bmatrix}Y' \\ Pb \\ Pr\end{bmatrix} }
mit:
- Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle \begin{bmatrix} Y' \\ Pb \\ Pr \end{bmatrix} = \begin{bmatrix} Y' \\ Cb \\ Cr \end{bmatrix} - \begin{bmatrix} 0 \\ 128 \\ 128 \end{bmatrix} }
Progressives JPEG
Ein JPEG-Bild besteht aus Koeffizienten. Diese speichern keine Pixel, sondern Annäherungen des gesamten Bildinhalts eines 8×8-Bildblocks. Beim Progressive JPEG werden erst die ersten Koeffizienten jedes Bildblocks, dann die zweiten usw. der Reihe nach abgespeichert, so dass die Annäherung an das Originalbild immer besser wird.
Wie beim Interlacing, das bei GIF angewendet wird, liegt der Zweck darin, dem Benutzer, noch bevor die gesamte Datei geladen ist, schnell ein grobes Vorschaubild zu geben. Dies ist besonders dann sinnvoll, wenn das Laden eines Bildes länger als eine halbe bis ganze Sekunde dauert bzw. man nur ein Vorschaubild benötigt. Jedoch werden große Bilder trotzdem meistens im normalen JPEG-Modus zum Download angeboten.
Verlustfreie Nachbearbeitung von JPEG
Verlustfreie visuelle Nachbearbeitung
Das wiederholte Rotieren von JPEG-Bildern mit durch 16 teilbarer Auflösung (z. B. 1024 × 768) bei Verwendung immer der gleichen Quantisierungsmatrix ist dagegen (bei ordnungsgemäßer Implementierung) verlustfrei.
Obwohl eine Dekodierung und Rekodierung meist verlustbehaftet ist, lassen sich einige Bildmanipulationen (prinzipiell) ohne unerwünschte Datenverluste durchführen:
- Bilddrehungen um 90°, 180° und 270°
- horizontale und vertikale Bildspiegelungen
- Beschneiden von Rändern um Vielfache von 16 Pixeln (bzw. 8 Pixel bei Schwarzweißbildern oder Farbbildern ohne Unterabtastung)
Dazu ist die Entropiekodierung und die Zickzack-Umsortierung rückgängig zu machen. Die Operationen erfolgen dann auf Grundlage der DCT-Koeffizienten (Umsortieren, Weglassen nicht benötigter Blöcke). Danach erfolgen wieder die Zickzack-Umsortierung und die Entropiekodierung. Es erfolgen keine verlustbehafteten Arbeitsschritte mehr. Nicht jedes Programm führt diese Operationen verlustfrei durch, es benötigt dazu spezielle dateiformatspezifische Verarbeitungsmodule. Bei den verbreiteten Bildbearbeitungsprogrammen ist das meist nicht der Fall, da diese in der Regel die Datei zunächst in ein Bitmuster dekodieren und dann mit diesen Daten arbeiten.
Beispielsweise das für Windows und Linux verfügbare Konsolenprogramm jpegtran vermag es, alle diese Operationen verlustfrei auszuführen,[4][5] ebenso das GUI-gestützte IrfanView für Windows.
Bilder, deren Auflösung nicht ein Vielfaches von 16 Pixeln (bzw. 8 Pixel bei Schwarzweißbildern oder Farbbildern ohne Unterabtastung) beträgt, sind problematisch. Sie weisen unvollständige Blöcke auf, das heißt, Blöcke, die nicht alle synthetisierten Pixel verwenden. JPEG erlaubt solche Blöcke aber nur am rechten und am unteren Bildrand. Einige dieser Operationen verlangen daher einmalig, dass diese Randstreifen verworfen werden.
Verlustfreie erweiterte Kompression der Daten
Die Firma Dropbox hat ein Programm entwickelt, welches mittels arithmetischen Kodierens den Platzbedarf von bereits vorhandenen JPEG-Dateien nochmals um durchschnittlich ungefähr 20 Prozent verkleinert. Das Programm heißt Lepton und steht unter der Apache-2.0-Lizenz, einer Open-Source-Lizenz.[6]
Visuelle Qualität und verwandte Formate
Die JPEG-Kompression ist für natürliche (Raster-)Bilder entwickelt worden, wie man sie in der Fotografie oder bei computergenerierten Bildern vorfindet.
Ungeeignet ist JPEG für
- digitale Strichzeichnungen (z. B. Screenshots oder Vektorgrafiken), die viele hochfrequente Bildteile (harte Kanten) enthalten,
- Schwarzweißbilder mit 1 Bit pro Bildpunkt,
- gerasterte Bilder (Zeitungsdruck).
Für diese Bilder sind Formate wie GIF, PNG oder JBIG weitaus besser geeignet.
Ein nachträgliches Heraufsetzen des Qualitätsfaktors vergrößert zwar den Speicherbedarf der Bilddatei, bringt aber verlorene Bildinformation nicht mehr zurück. Die Quantisierungstabellen können beliebig gewählt werden und sind nicht genormt. Viele Bildbearbeitungsprogramme lassen aber den Benutzer einen pauschalen Qualitätsfaktor zwischen 0 und 100 auswählen, der gemäß einer Formel in der vom JPEG-Komitee herausgegebenen JPEG-Bibliothek in eine Quantisierungstabelle umgewandelt wird. Auch bei Qualitätsfaktoren wie „100“ oder „100 %“ findet immer noch eine Quantisierung und damit ein – bei für JPEG ungeeigneten Bildern erheblicher – Qualitätsverlust statt.
Eine JPEG-Transformation ist im Allgemeinen nicht idempotent. Das Öffnen und anschließende Speichern einer JPEG-Datei führt zu einer neuen verlustbehafteten Kompression.
Das Beispielbild vergleicht Aufnahmen, die mit unterschiedlichen Qualitätseinstellungen kodiert wurden. Die Porträt-Aufnahme besitzt eine Größe von 200 × 200 Pixeln. Bei einer Farbtiefe von 8 Bit pro Farbe und unkomprimierter Speicherung erzeugt dieses Bild eine 120 Kbyte große Datei (exklusive Header und anderer Meta-Informationen). Die Klötzchenbildung der 8 × 8 Pixel großen Quadrate stellt das rechte Teilbild vergrößert dar. Ein weiteres Problem neben der Klötzchenbildung ist das „Ringing“, eine Konsequenz des schlechten Verhaltens der DCT bei harten Farbübergängen.
Im Profi-Bereich wird JPEG wegen der verlustbehafteten Datenreduktion eher selten verwendet. Stattdessen werden Formate eingesetzt, die verlustfrei komprimieren, ungeachtet des großen Speicherbedarfs. Beispiele sind TIFF, BMP, TGA oder PNG (Vollfarbenmodus). Eine unkomprimierte Aufnahme von 6 Megapixel erfordert bei einer Farbtiefe von 16 Bit pro Grundfarbe und 3 Grundfarben einen Speicherbedarf von 36 Mbyte, der sich bei strukturreichen, körnigen oder verrauschten Bildern durch verlustlose Kompression nur mäßig verkleinern lässt (bei detailreichen Fotos sind Kompressionsraten auf ca. 50 % üblich).[7]
Es ist oft möglich, die Komprimierung vorhandener JPEG-Dateien ohne weitere Verluste zu optimieren und somit die Dateigröße etwas zu verringern. Neuere Versionen einiger Packprogramme sind in der Lage, JPEG-Bilder ohne weitere Verluste um bis zu 25 % zu komprimieren.[8]
Die Bewegtbildkompressionsverfahren MPEG-1 (eng verwandt mit dem Codec Motion JPEG) sowie MPEG-2 bauen auf dem JPEG-Standard auf. Ein Nachfolgeprojekt von JPEG zur Speicherung von Bildern ist JPEG 2000, das über eine bessere Kompression und viele sinnvolle Eigenschaften verfügt, sich aber zumindest bis jetzt nicht in breitem Maße durchsetzen konnte. Ein weiteres potentielles Nachfolgeformat ist JPEG XR, das auf dem von Microsoft entwickelten Format HD Photo basiert, das jedoch bisher ebenfalls nur vereinzelt unterstützt wird.
JPEG XL
Daneben ist mit JPEG XL ein weiteres Nachfolgeformat in Entwicklung.[9] Es integriert eine Reihe von Funktionen, für die bisher andere Bildformate verwendet wurden und bietet eine verbesserte Komprimierung, die auf den experimentellen Formaten PIK und FUIF basiert.[10] Im Januar 2021 wurde ein Format Freeze bekanntgegeben.[11] Im Mai 2021 wurde gemeldet, dass das Format in Vorabversionen von Chrome, Edge und Firefox (noch mit zusätzlichen Schaltern gesichert) ausprobiert werden kann.[12]
Patentfragen
Mehrere Firmen (s. Patent-Trolle) haben bereits versucht, aus ihren (zumeist zu Unrecht erteilten) Patenten Forderungen gegen Softwarehersteller zu erheben, deren Produkte JPEG-Dateien lesen oder erstellen können. Bisher wurden alle entsprechenden Patente nachträglich entzogen. Dennoch konnten die Forderer in außergerichtlichen Einigungen hohe Millionenbeträge einnehmen.
Implementierungen
Eine sehr wichtige Implementierung eines JPEG-Codecs ist die freie Programmbibliothek libjpeg. Sie wurde 1991 erstmals veröffentlicht und war ein Schlüssel für den Erfolg des Standards.[13] Aus ihr entstanden auch die optimierten Abspaltungen libjpg-turbo und MozJPEG. Die Bibliothek und ihre Abkömmlinge werden in einer unüberschaubaren Anzahl von Anwendungen verwendet.
Im Mai 2019 publizierte ITU und ISO/IEC Referenzimplementierungen des JPEG Standards unter ISO/IEC 10918-7[14] und ITU-T T.873[15]. Diese Referenzsoftware besteht aus zwei Implementierungen, nämlich der libjpeg-turbo[16] und einer von der ISO-Arbeitsgruppe SC29WG1 selbst gepflegten Referenzimplementierung und ITU-T T.873[17] die nicht nur den DCT-Prozess von JPEG, sondern auch die selten benutzten verlustlosen und hierarchischen Prozesse implementiert.
Im März 2017 hat Google mit „Guetzli“ einen neuen Open-Source-JPEG-Encoder vorgestellt. Dieser komprimiert Bilddateien besser als bisherige Methoden, so soll Guetzli laut Google um bis zu 35 Prozent kleinere JPEG-Dateien erzeugen als herkömmliche Encoder und dabei weniger störende Kompressionsartefakte bilden. Die Kodiergeschwindigkeit (~0,01 MPixel/s) liegt allerdings um etwa vier Größenordnungen unter der von Standard-JPEG-Encodern (100 MPixel/s) und ist damit in der Praxis nur für sehr häufig benutzte statische Bilder geeignet.[18][19]
Literatur
- Heiner Küsters: Bilddatenkomprimierung mit JPEG und MPEG. Franzis, Poing 1995, ISBN 3-7723-7281-3.
- Thomas W. Lipp: Grafikformate. Microsoft Press, Unterschleißheim 1997, ISBN 3-86063-391-0.
- John Miano: Compressed Image File Formats. Addison-Wesley, Reading 2000, ISBN 0-201-60443-4 (englisch).
- William Pennebaker, Joan Mitchell: JPEG Still Image Data Compression Standard. Chapman & Hall, New York 1993, ISBN 0-442-01272-1 (englisch).
- Tilo Strutz: Bilddatenkompression, Grundlagen, Codierung, Wavelets, JPEG, MPEG. 4., überarbeitete und ergänzte Auflage, Vieweg + Teubner, Wiesbaden 2009, ISBN 978-3-8348-0472-3.
Weblinks
- Offizielle JPEG-Website
- digicam-experts Wie funktioniert die JPEG-Kompromierung?
- faqs.org: Introduction to JPEG
- Recommendation T.81 der ITU (englisch; PDF; 1,01 MB)
- heise.de JPEG: 25 Jahre und kein bisschen alt (abgerufen am 7. Oktober 2016)
Einzelnachweise
- ↑ jpeg.org 20:20, 30. Januar 2016
- ↑ Digital Compression And Coding Of Continuos-Tone Still Images–Requirements And Guidelines
- ↑ Patent-Statement (Memento vom 30. Oktober 2014 im Internet Archive) von jpeg.org
- ↑ jpegtran-Website
- ↑ Ubuntu – Informationen über Paket libjpeg-progs in jaunty (enthält jpegtran)
- ↑ Sebastian Grüner: Komprimierung – Dropbox macht Jpeg-Bilder um fast ein Viertel kleiner. Golem.de, 15. Juli 2016, abgerufen am 19. Juli 2016.
- ↑ Vergleich der Eigenschaften (auch Kompression) von BMP GIF PNG JPEG TIFF PCX TGA, abgerufen am 10. Oktober 2012
- ↑ maximumcompression.com
- ↑ JPEG - JPEG XL. Abgerufen am 11. Juli 2020.
- ↑ How JPEG XL Compares to Other Image Codecs. Abgerufen am 11. Juli 2020 (englisch).
- ↑ heise online: JPEG XL soll JPEG, PNG, GIF und Webp beerben. Abgerufen am 9. Mai 2021.
- ↑ JPEG XL als neues Bildformat im Browser aktivieren (Chrome, Edge, Firefox). 9. Mai 2021, abgerufen am 9. Mai 2021 (deutsch).
- ↑ jpeg.org
- ↑ ISO/IEC 10918-7:2021 – Information technology — Digital compression and coding of continuous-tone still images — Part 7: Reference software. 1. September 2021, abgerufen am 2. Juni 2022 (englisch).
- ↑ T.873 : Information technology - Digital compression and coding of continuous-tone still images: Reference software. 17. Februar 2022, abgerufen am 2. Juni 2022 (englisch).
- ↑ https://www.libjpeg-turbo.org/. 3. Mai 2022, abgerufen am 2. Juni 2022 (englisch).
- ↑ thorfdbg / libjpeg. Abgerufen am 2. Juni 2022 (englisch).
- ↑ Robert Obryk und Jyrki Alakuijala: Announcing Guetzli: A New Open Source JPEG Encoder. Google Research Europe, 16. März 2017, abgerufen am 18. März 2017 (englisch).
- ↑ Daniel Berger: Googles Guetzli-Encoder schrumpft JPEG-Bilder um ein Drittel. In: heise online. Heise Zeitschriften Verlag, 17. März 2017, abgerufen am 18. März 2017.
.png){kind=link}
