zu GIF-Dateiformat

[Jörk Behrends]

So, nochmal Ich!

Mir geht es ja mehr ums Verstehen des Verfahrens.

Da hatte ich bislang so das Gefühl, daß Du Dich da schon ganz gut eingefuchst hast ... Zumindest warst Du ja derjenige, der das Verfahren hier mit Beispielen vorgeführt hat. Soweit ich mir das ganze angeschaut habe, scheint es eigentlich ganz logisch zu funktionieren. Die Tücken liegen dann allerdings in der Sonderbehandlungen, die im GIF-Format vorkommen können (<CC> und so). Auch daß hier variable Bit-Längen verwendet werden ...

Ich habe da mal ein älteres Posting ausgebuddelt, und bin dann doch glatt mit meinem Verständnis gegen die Wand gelaufen:

Die komprimierten Daten sollten (laut PSP) so aussehen:

10 04 31 48 31 07 25 B5 58 73 8F 44 59 98 C6 79 60 04

Dazwischen liegt nur noch der Kompressionsalgorithmus.
Mal sehen ob ich Steve Blackstock nachvollziehen kann.

Das erste was zu machen ist, ist die 'string table'.
Wie wär's mit:

»»                                                 <CC><EOI>

#0 #1 #2 #3 #4 #5 #6 #7 #8 #9 #A #B #C #D #E #F #10  #11
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F  10   11

Der code für <CC> ist auf 10hex gesetzt. In der Beschreibumg
steht, daß dieses der erste auszugebende code sein soll.
In der Tat hat PSP das auch so gemacht.
Und nun?
Das erste Eingangszeichen ist 00hex. Das Zeichen existiert
in der 'string table', [.c.] wird 0, sonst passiert nichts.
Nun holen wir das nächste Zeichen = 01.
Damit ist [.c.]K = 0001. Das Zeichen ist nicht in der 'string
table', wir schreiben eine #0 in den Ausgangastrom und tragen
0001 in #12 der 'string table' ein.

Hmmm, irgendwie komme ich damit nicht klar.
Wenn die eben rausgeschriebene 0 ei Nibble ist, dann ist das
zwar noch als erster Teil der 04 in Ordnung, aber wie zum
Teufel soll ich auf die 4 der 04 kommen?

Tja, dachte ich. Der Fehler ist doch offensichtlich: Wenn als Codelänge 4 angegeben ist, dann muß ich doch (erstmal) immer 5 Bits ausgeben (weder 4 noch 8). Klappte aber auch nicht gleich. Dann habe ich aber noch festgestellt, daß man die Bits hier wohl andersherum lesen muß :-).

Dann kommt alse folgende Starttabelle heraus (niederwertigstes Bit steht links):

0 - 00000
    1 - 10000
    2 - 01000
    3 - 11000
    4 - 00100
    5 - 10100
    6 - 01100
    7 - 11100
    8 - 00010
    9 - 10010
    A - 01010
    B - 11010
    C - 00110
    D - 10110
    E - 01110
    F - 11110
<CC> - 00001
<EOI> - 10001

Bei der Kodierung der ersten 16 "Zeichen" kommen eigentlich nur die entsprechenden Codes heraus. Erst die zweite Zeile gibt dann bekannte Folgen wieder. Für die erste Zeile bekommen wir dann also sowas wie:
<CC> 0 1 2 3 4 5 6 7 8 9 A B C D E F
Binär (wie oben mit fünf Bits)
00001 00000 10000 01000 11000 00100 10100 01100 11100 00010 10010 01010 11010 00110 10110 01110 11110
Jetzt in 8er Gruppen:
00001000 00100000 10001100 00010010 10001100 11100000 10100100 10101101 00011010 11001110 11110xxx
Die jetzt noch invertiert (höchstwertigstes Bit links)
00010000 00000100 00110001 01001000 00110001 00000111 00100101 10110101 01011000 01110011 xxx01111
Und zum Schluß die Nibbles in Hex-Codes
10 04 31 48 31 07 25 B5 58 73 xF
Zum Vergleich die PSP-Ausgabe ...
10 04 31 48 31 07 25 B5 58 73 8F 44 59 98 C6 79 60 04

:-))))) Jörk