nicht angemeldet
Eigentlich sollte es ja auch funktionieren wenn die
Starttabelle bzw. String Table richtigrum angelegt
wird und dann, wenn es ans Ausgeben des Musters geht,
die Bits vom Niederwertigsten an achterweise abgezählt
und rausgeschoben werden. Der Rest muß dann aufgehoben
werden und ... 2 + 5 = 7 + 1 = 8 ... elende Packerei.Ich denke, daß man um das andersrum denken nicht herumkommen wird. Zumal die Code-Längen von 2 bis 12 Bit das ganze noch mehr durch den Kakao ziehen würden ...
Hi!
Ich muss vorausschicken, dass ich nicht so richtig versucht habe, Eure Diskussion nachzuvollziehen; habe es also nur ueberflogen. Mir scheint, dass Ihr ein Problem mit der Notation der Bits habt, was ihre Reihenfolge betrifft. Ich will mal die Standard-Notation erlautern (unabhaengig von jeglicher GIF-Spezifikation):
Schreibt man die 8 Bits eines Bytes, dann faengt man mit dem hoechsten Bit links an (Bit 7) und hoert mit dem niedrigsten rechts auf (Bit 0), also
7 6 5 4 3 2 1 0.
Verarbeitet man jedoch einen (seriellen) Bit-Strom, schreibt man die Bits so, wie sie der Reihe nach kommen. Presst man diesen Bit-Strom in ein Byte-Schema, sind die niedersten Bits die, die im Bit-Strom zuerst kommen. Beispiel: Gegeben sei der Bit-Strom
010111110101000
Wir wollen diesen in Bytes pressen, wobei wir ein Byte als 5 Bit definieren. Unterteilen wir diesen Bit-Strom also in 5er-Gruppen:
01011 11101 01000
Da im Bit-Strom die niedersten Bits zuerst kommen, in Byte-Schreibweise aber die hoechsten zuerst, muss man diese Bitgruppen einfach umdrehen. Also:
11010 10111 00010
Diese Bytes in Hexa:
1A 17 02
Regel fuer die Praxis: In der Byte-Schreibweise immer von rechts nach links lesen (waehrend der Bit-Strom von links nach rechts gelesen wird).
Jetzt kann ich nicht behaupten, dass dies in der GIF-Spezifikation unbdingt genauso gehandled wird, ich halte es aber fuer sehr wahrscheinlich, da es nunmal standardmaessig so gemacht wird.
Ich hoffe, ich habe jetzt nicht fuer noch mehr Verwirrung gesorgt.
Calocybe