Aufgabe 6: Ein JPEG-Decoder

¥¤
¡
©¨
£¢
§¦
Aufgabe 6: Ein JPEG-Decoder
Einleitung
JPEG ist ein populärer Standard zur Kompression von Bildern. Neben verlustfreien Kompressionsalgorithmen
werden auch verlustbehaftete benutzt. Bei diesen wird die besondere Struktur von Bildern
so ausgenutzt, daß der Informationsverlust der Kompression dem menschlichen Betrachter nur wenig
auffällt. JPEG is nach seinen Schöpfern benannt, der Joint Photographic Expert Group.
In JPEG werden verschiedene Techniken kombiniert: Huffman-Kodierung, Quantisierung, Fourier-
Transformation, Differentielle Kodierung und andere.
Ziel dieser Aufgabe ist es, ein C-Programm zu schreiben, welches eine JPEG-Datei der einfachsten
und häufigsten Art (nicht-differentielle Huffman-Kodierung, drei Farbebenen, keine Zusatzfunktionen)
dekodiert und dekomprimiert. Als Ergebnis soll eine Datei im PPM (portable pixmap)-Format erzeugt
werden.
Digitalisierte Bilder: das PPM-Format
Ein digitalisiertes Bild besteht aus einzelnen Bildpunkten, Pixel genannt. PPM ist eine ”naive”Form der
Speicherung dieser Pixel ohne jegliche Komprimierung oder Umordnung der Daten. Eine PPM-Datei
beginnt mit einer Kennung. Das ist eine Zeile, die nur aus den 2 Zeichen ”P6” besteht. Es folgt eine
Zeile, die aus 2 Zahlen besteht, der Breite w und Höhe h des Bildes in Pixel ( z.B. ”608 320”) und eine
weitere Zeile, die für unsere Zwecke nur aus der Zahl ”255” besteht. An diese 3 Zeilen schließt sich ein
Strom von 3 ∗ w ∗ h Bytes an. Jeweils 3 Bytes kodieren Farbe und Helligkeit eines Pixels. Dazu wird
jedes Byte als vorzeichenlose ganze Zahl zwischen 0 und 255 interpretiert. Die 3 Zahlen beschreiben
die Intensität des Rot-, Grün- und Blauanteils (RGB-Kodierung): (0, 0, 0) ist Schwarz, (255, 255, 255)
Weiß, (230, 230, 0) ein helles Gelb etc. Die Pixeldaten stehen einfach ”in Leserichtung” (Zeile für Zeile
von links nach rechts und oben nach unten) hintereinander.
Huffman-Kodierung
Die Huffman-Kodierung ist ein verlustfreier Kompressionsalgorithmus. Ein Alphabet soll so kodiert
werden, daß die häufigere Zeichen durch kürzere Bit-Sequenzen dargestellt werden (ein Prinzip, von
dem sich schon Samuel Morse bei der Erfindung seines Morsealphabets leiten ließ).
Wie bei wohl allen Kompressionsalgorithmen ist das Entpacken wesentlich einfacher als das Packen.
Letzteres erfordert eine umfangreiche Analyse der Input-Daten, ersteres bloß das Anwenden eines mitgelieferten
Rezeptes.
Das Rezept zur Huffman-Dekodierung läßt sich am einfachsten in Form einer Baumstruktur kodieren.
Nehmen wir als Beispiel die Sprache ”Vokalisch”, deren Alphabet die 5 Buchstaben A,E,I,O,U umfaßt.
Der häufigste Buchstabe sei E, gefolgt von O,A,I und U.
0 1
E
A
0
U
0 1
0
1
1
I
O
Der Datenstrom 101111101000 wird mit Hilfe des Huffman-Baums
so dekodiert: Wir starten an der Wurzel des Baumes (wie in der
Informatik üblich, steht der Baum auf dem Kopf) und nehmen die
Bitfolge als Wegbeschreibung: 0 heißt den linken Weg nehmen, 1 den
rechten Weg nehmen. Wenn wir eine Zweigspitze erreicht haben, steht
ein Buchstabe fest und wir beginnen wieder an der Wurzel. Damit
führt uns 1011 zu I, 11 zu O und 1010 zu U, 0 zu E und 0 zu E:
IOUEE.
Obwohl wir es mit einem Code variabler Länge zu tun haben, ist kein spezielles Trennzeichen nötig.
Natürlich ist die Kompression nicht optimal. Sie könnte verbessert werden, indem man Silben aus
2 Buchstaben in den Huffman-Baum aufnimmt, dann Silben aus 3 Buchstaben etc.
1

Der JPEG-Algorithmus verwendet mehrere Huffman-Bäume, allerdings auf recht indirekte Art und
Weise.
Beschreibung des JPEG-Formats
Im Folgenden wird das JPEG-Format beschrieben, wobei die Kapitel dieser Beschreibung (Farbmodell,
Downsampling, Quantisierung, Fourier-Transformation, Huffman-Dekodierung, Analyse der Datei) vom
Dekompressor in umgekehrter Reihenfolge angewandt werden müssen.
Farbmodell
JPEG verwendet nicht das RGB-Farbmodell, sondern eines, das YUV genannt wird: 3 Zahlen beschreiben
Helligkeit (Y), Blauanteil (U) und Rotanteil (V) eines Pixels. Die Umrechnung in RGB ist durch
die lineare Transformation ⎛
⎝ R ⎞ ⎛
G ⎠ = ⎝ 1 0 ⎞ ⎛
8
5
1 − 1 3
− 4 ⎠ ⎝ Y ⎞
5
U ⎠
B 1 2 0 V
möglich.
Implementierungshinweis: Die YUV-Werte, die man nach Fourier-Transformation und Dequantisierung
aus den JPEG-Daten erhält, sind vorzeichenbehaftet, liegen zwischen -128 und 127.
Dasselbe gilt auch für die RGB-Werte, die obige Transformation liefert. Manchmal können sie auch
über diesen Bereich hinausschießen. Um sie z.B. mit der Funktion putc (die ihr Argument zu einem
unsigned char konvertiert) korrekt in eine PPM-Datei ausgeben zu können, empfiehlt es sich:
a) 128 zu addieren,
b) zu testen, ob der Wert nun zwischen 0 und 255 liegt und kleinere Werte durch 0, größere durch
255 zu ersetzen.
Downsampling
• Zentrales Objekt der Kompressionsalgorithmen ist eine ”data unit”. Dies ist eine 8 × 8-Matrix von
Y-, U- oder V-Werten. Im einfachsten Fall beschreibt sie auch einen Bildausschnitt von 8 × 8
Pixeln. Durch eine (verlustbehaftete) Kompressionsmethode namens ”Downsampling” kann sie
jedoch auch die Informationen für bis zu 32×32 Pixel enthalten. Dabei wird jeweils ein kleiner (z.B.
2×2) Block von Pixeln durch ein ”gemitteltes”Pixel ersetzt. Üblicherweise wird das Downsampling
nicht auf die Helligkeit (Y) angewendet, sondern nur auf die Farbkomponenten. Dadurch bleibt
der wahrnehmbare Qualitätsverlust gering.
• Für jede der 3 Farbkomponenten YUV wird das Downsampling beschrieben durch 2 Parameter
(h, w) (height, width): Blöcke aus h × w Pixel wurden duch einen Pixel ersetzt. h und w können
Werte zwischen 1 und 4 annehmen. Beim Entpacken muß also ein ”Upsampling” durchgeführt
werden, bei dem die 8 × 8-Matrix zu einer( 8h × 8w-Matrix ) aufgebläht wird, indem man jeden
Eintrag x durch eine h × w-Blockmatrix x x
ersetzt. Für die Downsampling-Parameter
h Y , h V , h U muß gelten kgV(h i ) = max(h i ) und kgV(w i ) = max(w i ). ∗
x
• Das Bild wird in kleine Rechtecke aus (8∗max(h i )×8∗max(w i )) Pixel zerlegt, die MCUs (Minimal
Coding Units) genannt werden. Nehmen wir an, die Y-Information wird nicht ”downsampled”und
die U- und V-Komponente werden um die Faktoren 2×2 bzw 4×4 ”downsampled”. Dann beschreibt
eine MCU 32 × 32 Pixel des Bildes und sie ist kodiert durch 16 Y-data-units, 4 U-data-units und
eine V-data-unit. In genau dieser Reihenfolge sind sie auch im Datenstrom gespeichert, wobei die
16 Y-data-units (und 4 U-data-units) in ”Lesereihenfolge” zeilenweise von links nach rechts und
oben nach unten abgespeichert sind.
x
∗ kgV: kleinstes gemeinsames Vielfaches. Dies bedeutet einfach, daß die elementaren Quadrate oder Rechtecke, in die das
Bild für die verschiedenen Farbkomponenten zerschnitten wird, ”ineinander aufgehen” müssen.
2

• Der Datenstrom, der das Gesamtbild beschreibt, besteht aus einer Folge von MCUs
([16Y, 4U, 1V ], [16Y, 4U, 1V ], . . .), ebenfalls in ”Lesereihenfolge”.
• Nach der Dekomprimierung hat man ein Bild, dessen Größe ein Vielfaches der MCU-Größe ist.
Um es auf die Größe (H, W ) des Originals zu bringen, muß man eventuell rechts und unten ein
paar Pixel wegschneiden.
Fourier-Transformation und Quantisierung
Der Schlüssel zur hohen Kompressionsrate von JPEG ist, daß die Bilddaten nicht direkt komprimiert,
sondern vorher Fourier-transformiert werden. Die verwendete spezielle Form der Fourier-Transformation
wird als ”Diskrete Cosinus-Transformation” (DCT) bezeichnet. Die DCT führt eine 8 × 8-Matrix von
Farbwerten in eine 8 × 8-Matrix über, deren [0, 0]-Komponente den Mittelwert der Originaldaten beschreibt,
die anderen beschreiben die Amplituden der verschiedenen Schwankungen um diesen Wert.
Zur Rücktransformation sind folgende Schritte nötig:
• Die JPEG-Datei enthält für jede Komponente (Y, U und V) eine Quantisierungstabelle aus 64
ganzen Zahlen. Jede der 64 Zahlen du[i], i=0...63 einer data-unit ist mit der entsprechenden
Zahl aus der Quantisierungstabelle zu multiplizieren. Das Ergebnis ist in Fließkommazahlen
umzuwandeln.
• Aus diesen 64 Zahlen wird jetzt eine 8 × 8-Matrix aufgebaut. Um eine optimale Kompression
zu erreichen, sind diese Zahlen allerdings nicht zeilen- oder spaltenweise angeordnet, sondern im
Zigzag. Das folgende Codestück beschreibt die notwendige Umordnung:
const int zigzag[8][8] ={ { 0, 1, 5, 6,14,15,27,28},
{ 2, 4, 7,13,16,26,29,42},
{ 3, 8,12,17,25,30,41,43},
{ 9,11,18,24,31,40,44,53},
{10,19,23,32,39,45,52,54},
{20,22,33,38,46,51,55,60},
{21,34,37,47,50,56,59,61},
{35,36,48,49,57,58,62,63}};
for(i=0; i

• Der DC-Baum dient nur zum Einlesen des ersten Wertes du[0]:
• Lese Bits vom Datenstrom und laufe durch den DC-Baum, bis eine Spitze erreicht ist. Der
an dieser Spitze gespeicherte Wert s gibt die Anzahl der nun einzulesenden Bits an.
• Die nächsten s Bits aus dem Datenstrom sind als positive ganze Zahl n zu interpretieren.
• Diese Zahl wird in eine vorzeichenbehaftete Zahl konvertiert nach der Vorschrift
m = extend(n, s)
{ n if n ≥ 2
s−1
extend(n, s) =
n + 1 − 2 s otherwise
• Dieser Wert m ist nur dann gleich du[0], wenn es sich um die erste data-unit des Bildes zu
einer Farbkomponente handelt. Sonst ist m die Differenz zum Wert du[0] der vorhergehenden
data-unit derselben Farbkomponente.
• Zur Dekodierung der übrigen 63 Werte wird der AC-Baum verwendet. Die an dessen Spitzen
gespeicherten Bytes (Zahlen x zwischen 0 und 255) sind als zwei 4-Bit-Zahlen (”nibbles”)
(r, s) = (x/16, mod (x, 16)) zu interpretieren. Die Dekodierung erfordert folgende Schritte:
1. Lese Bits aus dem Datenstrom ein, bis eine Spitze (r, s) des AC-Baumes ereicht ist.
2. Wenn r = s = 0, fülle die restlichen Felder von du[] mit Nullen, die data-unit ist fertig
gelesen.
3. Wenn r > 0 ist, werden die nächsten r Felder in du[] mit Nullen gefüllt.
4. Dann werden die die nächsten s Bits aus dem Datenstrom gelesen und das Ergebnis von
extend(n, s) wird in das nächste freie Feld von du[] gespeichert.
5. Wiederhole 1.-4., bis alle Felder von du[] gefüllt sind.
Aufbau einer JPEG-Datei
Eine JPEG-Datei besteht aus einer Folge von Segmenten verschiedenen Typs. Segmente beginnen mit
2 Startbytes, die den Segmenttyp kodieren, gefolgt von 2 Bytes, die die Länge L des Segments (ohne
die beiden Startbytes) angeben und von L − 2 Datenbytes. Eine Ausnahme sind die Segmente ”Start
of Image” (SOI) am Dateianfang und ”End of Image” (EOI) am Dateiende, sie bestehen nur aus den
2 Bytes FFD8 (SOI) und FFD9 (EOI). In der folgenden Übersicht steht ein ∗ für ein Halbbyte (4 Bits),
auch nibble genannt.
SOI Start of Image
FFD8
EOI End of Image
FFD9
COM Comment
FFFE ∗ ∗ ∗∗
L
L-2 Bytes
Kommentartext
DQT Define Quantization Table
FFDB ∗ ∗ ∗∗ ∗∗ 64 Bytes . . . ∗∗ 64 Bytes L = 2 + 65 ∗ n
L i 1 QT 1 i n QT n
SOF Start of Frame
FFC0 ∗ ∗ ∗∗ ∗∗ ∗ ∗ ∗∗ ∗ ∗ ∗∗ ∗∗ 3 Bytes . . . 3 Bytes L = 2 + 6 + 3 ∗ ne
L cd H W ne Ebene 1 Ebene ne
Jede Ebene hat den Aufbau ∗∗ ∗ ∗ ∗∗
i e w h n qt
4

DHT Define Huffman Table
FFC4 ∗ ∗ ∗∗ ∗ ∗ 16 Bytes data . . . ∗ ∗ 16 Bytes data
L tc th ns[i] tc th ns[i]
L = 2 + 1 + 16 + ∑ 15
i=0 ns[i] + . . . + 1 + 16 + ∑ 15
i=0 ns[i]
SOS Start of Scan
FFDA ∗ ∗ ∗∗ ∗∗ 2 Bytes . . . 2 Bytes ∗ ∗ ∗ ∗ ∗∗ data
L nc Komponente 1 Komponente nc 3 Bytes
Jede Komponente hat den Aufbau ∗∗ ∗ ∗
i c td ta
Es gibt noch eine Reihe weiterer Segmente. Wenn Segmente mit den Kennungen FFC1, FFC2, FFC3,
FFC5, FFC6, FFC7, FFC9, FFCA, FFCB, FFCC, FFCD, FFCE oder FFCF auftauchen, soll unser
Entpacker abbrechen. Sie bedeuten, daß noch andere Kompressionsalgorithmen (differentielle arithmetische
Kodierung, differentielle Huffman-Kodierung u.a.) angewendet wurden.
Andere Segmente der Form
FF∗∗ ∗ ∗ ∗∗
L-2 Bytes
können ignoriert werden. Sie könenn z.B. ”thumbnails” (”daumennagelgroße” Varianten des Bildes, die
ein Programm zur Vorschau o.ä. verwenden kann) enthalten.
Beschreibung der Segmente
DQT JPEG-Dateien können bis zu 4 Quantisierungstabellen enthalten (auch wenn die hier besprochene
Variante nur 3 verwendet). Sie können durch mehrere DQT-Segmente oder gemeinsam in einem
DQT-Segment gespeichert sein. Die Anzahl der Tabellen in einem DQT-Segment läßt sich aus der Längenangabe
L ableiten. Jede Tabelle hat eine Nummer i n . Die Tabelle selbst besteht aus 64 Bytes, von
denen jedes eine Zahl zwischen 0 und 255 repräsentiert.
Implementierungshinweis:
int i;
i=getc(filepointer);
liest ein Byte korrekt in diesem Sinne (als Zahl zwischen 0 und 255) ein, weil getc() das eingelesene
Byte als unsigned char interpretiert. Ebenso kann man die durch 2 Bytes kodierten Zahlen (wie
die Längenangabe L) einlesen:
int i,L;
i=getc(filepointer);
L=256*i+getc(filepointer);
SOF
Ein Frame enthält globale Informationen über das Bild.
• dc (1 Byte) enthält die Farbtiefe (color depth). Für unsere Zwecke sollte sie 8 sein: Jeder Farbwert
wird mit 8 Bit (einem Byte) kodiert.
• H und W (je 2 Byte) geben die tatsächliche Größe des Bildes (Höhe und Breite in Pixeln) an.
• ne (1 Byte) gibt die Anzahl der Farbkomponenten an. Unser Dekoder soll nur mit genau 3 Farbkomponenten
umgehen können. Es gibt auch schwarzweiße JPEG-Dateien mit nur einer Farbkomponente.
• Es folgen jeweils 3 Bytes für jede Farbkomponente. Sie enthalten eine Nummer i e und die Downsampling-Parameter
w und h dieser Farbkomponente sowie die Nummer der Quantisierungstabelle
n qt , die für diese Komponente zu verwenden ist. Es ist die Tabelle zu verwenden, für die i n = n qt
gilt.
5

¡
!
"
!
"
!
"
!
"
!
"
#
$
#
$
#
$
#
$
#
$
#
$
§¦
©¨
DHT
Implementierungshinweis: Aus diesen Daten läßt sich die Größe einer MCU sowie die
Anzahl der MCUs berechnen. Hierbei ist daran zu denken, daß man aufrunden muß, wenn H
oder W nicht durch die Höhe oder Breite einer MCU teilbar ist. Die ”nibbles” h und w lassen
sich so einlesen:
int x,h,w;
x=getc(filepointer);
w=x/16;
h=x%16;
• Für jede Farbkomponente Y,U und V werden 2 Huffman-Bäume benötigt, ein DC- und ein AC-
Baum. Die Bäume können in einem odere mehreren DHT-Feldern beschrieben sein. Sie sind numeriert
durch die nibbles tc und th. Wenn tc ungleich 0 ist, dient der Baum als AC-Baum, wenn
tc gleich 0 ist, als DC-Baum. th ist seine Nummer.
• Es folgt eine 16 Bytes lange Liste ns[]. Die Bytes geben an, wieviele Huffman-Kodes der Länge
1 Bit, 2 Bit, . . . 16 Bit abgespeichert sind. (Für unseren Vokal-Beispielbaum hieße das ns =
[1, 1, 1, 2, 0, . . .].) Danach folgt eine Liste der an den Zweigspitzen zu speichernden Daten, nach
aufsteigender Länge der Kodes sortiert. Diese Liste ist somit ∑ 15
i=0
ns[i] Bytes lang.
• Die Daten sind Bytes, Zahlen zwischen 0 und 255. Bei den AC-Bäumen werden sie später als 2
nibbles interpretiert.
• Diese Daten bestimmen einen Baum eindeutig, wenn er so konstruiert wird, daß der Abstand
Spitze-Wurzel von links nach rechts zunimmt.
B
¢£¤¥
A D E F G
%% && ''' (((
&& ''' ((( %%
%% && ((( '''
((( ''' && %%
%% && ((( )) ** '''
)) ** ((( ''' && %%
C
** ))
)) **
** ))
H
++ ,,
,, ++
++ ,,
,, ++
.. /// 000 --
++ ,,
,, -- .. /// 000 ++
-- .. 000 ///
000 /// .. --
Ein Beispiel: Sei ns = [0, 1, 5, 1, 1] und die 8 Bytes
in diesem Baum sind in der Reihenfolge BADEFG-
CH gegeben. Damit sind die Huffman-Kodes B=00,
A=010, D=011, E=100, F=101, G=110, C=1110,
H=11110. Die letzte Spitze bleibt leer.
Implementierungshinweis: Material zu Bäumen und anderen Datenstrukturen findet man
z.B. in R. Sedgewick, Algorithmen in C. Eine Möglichkeit ist, einen Knoten des Baumes als
Struktur mit Zeigern auf die Unterknoten zu definieren und den Baum gemäß den DHT-Daten
durch Aufrufe von createNode zu erzeugen. Dies kann z.B. auch rekursiv geschehen.
struct node { unsigned char Item; struct node *l; struct node *r; };
struct node * createNode(unsigned char a){
struct node * x = malloc(sizeof(struct node));
x->l=0;
x->r=0;
x->Item=a;
return x;
}
SOS Das eigentliche Datenfeld. Bevor es losgeht mit dem Strom Huffman-kodierter und komprimierter
MCUs, folgen nochmal Daten über die Farbkomponenten. Im nc-Byte steht nochmal deren Anzahl, dann
folgt für jede Komponente ein 2-Byte-Feld, das aus 3 Zahlen besteht: einem Index i c und den Nummern
td und ta der für diese Komponente zu verwendenden DC- und AC-Huffmanbäume. Die Daten mit dem
Index i c ergänzen die Daten aus dem SOF-Segment mit dem gleichen Index i e .
Es folgen noch 3 Bytes, deren Inhalt für die hier beschriebene JPEG-Variante irrelevant ist.
Beim Einlesen des folgenden Datenstroms ist eine Besonderheit zu beachten: Er endet, wenn ein neuer
Segment-Markierer kommt, d.h., ein FF-Byte gefolgt von einem Byte ungleich 0. In der Regel wird das
der EOI-Marker FFD9 und auch das Ende der Datei sein.
Nun können solche Sequenzen natürlich auch als Teil der Bilddaten entstehen. Deshalb gilt eine
Sonderregel: Wenn die Bilddaten ein FF-Byte enthalten, wird ihm ein zusätzliches 00-Byte angehängt.
Dieses 00-Byte ist nicht Teil der Bilddaten und muß beim Einlesen herausgefiltert werden.
6