docAusarbeitung
download 
Denúncia Transcrição
Ausarbeitung
Das Graphics Interchange Format Matthias Kloppenborg 7. Mai 2008 Vorwort Dieser Artikel gibt eine allgemeine Einführung in das GIF. Im ersten Abschnitt wird auf die Geschichte des GIF eingegangen. Die Fähigkeiten von GIF werden kurz angeschnitten und in den nachfolgenden Abschnitten wird auf die Implementierungsdetails eingegangen. Im Speziellen bezieht sich dieses Dokument auf die Spezifikation 89a. Der für die Kompression verwendete LZW-Algorithmus wird ebenfalls anhand eines Beispiels erläutert. Inhaltsverzeichnis 1 Der geschichtliche Hintergrund vom GIF 2 2 Der 2.1 2.2 2.3 2.4 Aufbau einer Datei nach GIF-Spezifikation 89a Der Header . . . . . . . . . . . . . . . . . . . . . . . . . . Die Bildschirmbeschreibung . . . . . . . . . . . . . . . . . Die Farbpaletten . . . . . . . . . . . . . . . . . . . . . . . Die Bildbeschreibung . . . . . . . . . . . . . . . . . . . . . 2.4.1 Das Zeilensprungverfahren im GIF (Abbildung 1) . 2.5 Die Rasterdaten . . . . . . . . . . . . . . . . . . . . . . . 2.6 Der Erweiterungsblock . . . . . . . . . . . . . . . . . . . . 2.6.1 Erweiterung für Grafikkontrolle . . . . . . . . . . . 2.6.2 Erweiterung für Kommentare . . . . . . . . . . . . 2.6.3 Erweiterung für ASCII Text . . . . . . . . . . . . . 2.6.4 Erweiterung für Anwendungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3 3 4 5 5 5 7 7 8 8 9 3 Der Lempel-Ziv-Welch-Algorithmus zur Kompression 10 4 Quellen 10 1 1 1 DER GESCHICHTLICHE HINTERGRUND VOM GIF 2 Der geschichtliche Hintergrund vom GIF CompuServe präsentierte im Jahre 1987 das GIF als freie und offene Spezifikation. Nicht nur die gute Komprimierung und die Fähigkeit, das Zeilensprungverfahren anwenden zu können, ließen das GIF zu einem beliebten Format im World Wide Web werden. Auch die Übertragung von Farbbildern war zur damaligen Zeit nicht Standard und mit den Neuerungen in der Spezifikation 89a vervielfältigten sich die Möglichkeiten. Als nun CompuServe das GIF und damit auch die Spezifikation 87a präsentierte, fiel es zunächst niemandem auf, dass der dort zur Komprimierung eingesetzte LZW-Algorithmus lizenzrechtlich bedenklich war. Die anfängliche Euphorie wich bald einer Phase der Verwirrung und Konfrontation. Der in GIF verwendete LZWAlgorithmus verwendete Prozeduren, die sowohl Unisys als auch IBM im Vorfeld patentiert worden waren. Im Dezember des Jahres 2004 gaben Unisys und CompuServe bekannt, dass Entwickler, die weiterhin mit den von Unisys patentierten Technologien, welche im Zusammenhang mit dem GIF-Format stehen, arbeiten wollten, von nun an Lizenzgebühren zu zahlen hatten. Diese Gebühren, die zu Beginn nur für kommerzielle Software zu zahlen waren, wurden alsbald auch auf kostenlose Software ausgeweitet. Dies war ein zu erwartender Schritt von Unisys, da die kommerziellen Hersteller nach Einführung der Gebühren Teile ihrer Software, die der Erstellung von GIF-Dateien dienten, als kostenlose Erweiterungen zur Verfügung stellten. Verwirrung entstand, da im World Wide Web das Gerücht verbreitet wurde, dass sowohl für Programme zum Erstellen als auch für Programme zum Anzeigen von GIF-Dateien Gebühren zu entrichten wären. Dies führte letztlich dazu, das CompuServe die Planung von GIF24 als freie, offene und gebührenfreie Spezifikation unterstützte, welche dann später zu Gunsten der Entwicklung von PNG verwendet werden konnte. Tatsache ist jedoch, dass Programme, welche GIF-Dateien nur auslesen, nicht von der Gebührenpflicht betroffen sind. Trotz der Entwicklung von PNG und JPEG, finden GIF-Dateien noch heute Verwendung im World Wide Web und sind beliebt durch ihre Fähigkeit zur Animation und Transparenz. 2 DER AUFBAU EINER DATEI NACH GIF-SPEZIFIKATION 89A 2 3 Der Aufbau einer Datei nach GIF-Spezifikation 89a Der Aufbau einer GIF-Datei nach Spezifikation 89a lässt sich anhand einer einfachen Grammatik darstellen. < < < < < < < GIF-Datei > := Header < logischer Bildschirm > < Daten* > GIF-Endsymbol logischer Bildschirm> := Bildschirmbschreibung [globale Farbpalette] Daten > := < Grafikblock > | < spezieller Block > Grafikblock > := [Erweiterung zur Grafikkontrolle] < Block zur Darstellung > Block zur Darstellung> := < Palettengrafik > | < Erweiterung zur Darstellung von ASCII Text > Palettengrafik > := Bildbeschreibung [lokale Farbpalette] Rasterdaten spezieller Block > := Erweiterung für Anwendungen | Erweiterung für Kommentare Die mit < und > geklammerten Begriffe sind Nichtterminale. Die mit [ und ] geklammerten Begriffe sind optional. Das * bedeutet, dass dieser Block mehrfach vorkommen kann. Sind Begriffe durch | getrennt, so ist dies als exklusiv oder zu verstehen. Ungeklammerte Begriffe sind Terminale und werden im Folgenden erläutert. 2.1 Der Header Anhand des Headers, welcher grade einmal sechs Byte groß ist, kann man die GIF-Datei als solche erkennen. In den ersten drei Bytes ist die sogenannte Signatur gespeichert, anhand der man erkennen kann, dass die folgenden Daten eine GIF-Datei beschreiben. Die Versionsnummer beschreibt die Spezifikation, anhand derer die Datei erstellt wurde. Es gibt zwei verschiedene Spezifikationen: 87a und 89a. Neuerungen in der Spezifikation 89a sind z.B der Farbwert für Transparenz, die Fähigkeit der Animation und die Möglichkeit zur Darstellung von ASCII-Text. Header gif 89a • 00101111 • 00110001 • 00101110 • 00111000 • 00111001 • 01100001 2.2 Die Bildschirmbeschreibung Die Bildschirmbeschreibung enthält die globalen Parameter für alle enthaltenen Rasterbilder, so zum Beispiel die Dimensionen des logische Bildschirms, Informationen über die zu verwendeten Farbpaletten, die Hintergrundfarbe des logischen Bildschirms und die Farbtiefe. Aus den ersten vier Bytes lassen sich Höhe und Breite des logischen Bildschirms auslesen. Das anschließende Byte muss bitweise interpretiert werden: Ist das erste Bit auf Eins gesetzt so existiert eine globale Farbpalette und diese folgt auf die Bildschirmbeschreibung. Bei einem Wert von Null existiert diese Farbpalette nicht. Implementierungsabhängig können lokale Farbpaletten verwendet werden oder es wird eine Farbpalette aus dem Speicher verwendet. Die folgenden drei Bits zeigen an, wie viele Bits pro Primärfarbe im Originalbild zur Verfügung standen. Zu dem gespeicherten Wert addiert man eins hinzu, um den korrekten Wert zu erhalten. Speichern diese Bits beispielsweise den Dezimalwert drei, so standen im Originalbild vier Bits pro Primärfarbe zur Verfügung um das Bild herzustellen. Das fünfte Bit gibt an, ob die globale Farbpalette sortiert ist. Die Sortierung hängt ab von der Häufigkeit der Verwendung des Farbindexes in den Rasterdaten. Je öfter der Farbindex verwendet wird, 2 DER AUFBAU EINER DATEI NACH GIF-SPEZIFIKATION 89A 4 desto eher findet man den Wert in der Farbpalette, wenn man diese von Null an aufsteigend durchsucht. Die letzten drei Bits zeigen an, wieviele Bits pro Pixel zur Adressierung der Farbindizes verwendet werden. Aus diesem Wert x lässt sich mit folgender Formel die Größe der Farbpalette errechnen. 2(x+1) (1) Das nächste Byte wird als Verweis auf einen Eintrag in der Farbpalette interpretiert und gibt die Hintergrundfarbe des logischen Bildschirms an. Die Bildschirmbeschreibung endet mit einem Byte, anhand dessen Wert y man näherungsweise das Verhältnis von Pixelhöhe zu Pixelbreite im Ursprungsbild errechnen kann. Die Formel für die Berechnung der Näherung: V erhältnis = (y + 15) : 64 (2) Bei einem Wert y von 255 lautet das Ergebnis der Gleichung ˜4,21, das Verhältnis von Pixelbreite zu Pixelhöhe ist also 4:1. Ist der Wert von y mit 1 angegeben, so lautet das Ergebnis 0.25. Das Verhältnis ist damit 1:4. Liest man an der Stelle ein Nullbyte ein, so gibt es keine Informationen zum Verhältnis. Aufbau der Bildschirmbeschreibung • Breite des Bildschirms in Pixeln 2 Bytes • Höhe des Bildschirms in Pixeln 2 Bytes • 1 Byte – Bit für Globale Farbpalette 1 Bit – Bits pro Primärfarbe im Originalbild 3 Bit – Bit für Sortierung der Farbpalette 1 Bit – Bits pro Pixel 3 Bit • Farbindex für Hintergrundfarbe 1 Byte • Verhältnis von Höhe zu Breite eines Pixels 1 Byte 2.3 Die Farbpaletten Die Farben, die in einer GIF-Datei verwendet werden, werden in Farbpaletten organisiert. Es besteht sowohl die Möglichkeit eine globale Farbpaletten zu beschreiben, als auch lokale Farbpaletten für jedes einzelne Rasterbild zu definieren. Eine Farbpalette kann, egal ob lokal oder global, bis zu 256 Farben speichern. Definiert man sowohl globale als auch lokale Farbpaletten, werden die Farbeinträge der lokalen Farbpaletten verwendet. Um eine Farbe aus dem RGB-Farbraum zu beschreiben verwendet man drei Bytes, jeweils eines pro Grundfarbe. Die Indizes der Farbpalette verweisen nun direkt auf einen solchen Dreierblock von Bytes. Um einen hellen Blauton zu erhalten, wie er zum Beispiel bei der Darstellung eines Himmels genutzt werden könnte, speichert man folgende Werte. Der Aufbau der Farbpaletten • Rotwert: 01101000 = 104 • Grünwert: 10101011 = 171 • Blauwert: 11001100 = 204 Diese drei Werte beschreiben eine Farbe in der Farbpalette und lassen sich anschließend über einen Index adressieren. Der Index lässt sich mit nur einem Byte beschreiben, wodurch die Größe der Farbpalette auf 768 Bytes beschränkt ist. 2 DER AUFBAU EINER DATEI NACH GIF-SPEZIFIKATION 89A 2.4 5 Die Bildbeschreibung Die Bildbeschreibung enthält Informationen zum einzelnen Rasterbild. GIF-Dateien können mehrere einzelne Rasterbilder enthalten, die sich zu einem Gesamtbild oder einer Animation verknüpfen lassen. Jedes Rasterbild kann zur Darstellung auf eine eigene lokale Farbpalette zugreifen, oder die globale Farbpalette verwenden. Das erste Byte der Bildschirmbeschreibung enthält ein Komma, das als Trennsymbol für die einzelnen Rasterbilder dient. Die folgenden vier Bytes geben die Koordinaten an, an denen mit der Darstellung des Rasterbildes begonnen wird. Dabei bezeichnen je zwei Bytes den linken, sowie den oberen Abstand zum Rand des in der Bildschirmbeschreibung definierten logischen Bildschirms. Die Breite, sowie die Höhe des Rasterbildes, werden ebenfalls mit je zwei Bytes angegeben. Das letzte Byte der Bildbeschreibung ist wie folgt aufgeteilt. Das erste Bit zeigt an, ob für das Rasterbild eine eigene lokale Farbpalette definiert ist, ob also nach den Bytes der Bildbeschreibung eine Farbpalette zu erwarten ist. Der Aufbau der Farbpaletten wurde im vorherigen Abschnitt bereits beschrieben. Das zweite Bit zeigt an, wie die Rasterdaten zu interpretieren sind. Ist dieses Bit gesetzt, so sind die Rasterdaten im Zeilensprungverfahren gespeichert. Ist dies nicht der Fall, so können die Rasterdaten sequentiell ausgelesen und dargestellt werden. Das dritte Bit gibt an, ob die lokale Farbpalette sortiert ist. Die folgenden zwei Bits sind laut Spezifikation reserviert und müssen mit Null belegt werden. Die letzten drei Bits geben, genau wie zuvor in der Bildschirmbeschreibung erläutert, an, wieviele Bits pro Pixel zur Adressierung der Farbindizes verwendet werden. Außerdem lässt sich mit der Formel 1, wenn vorhanden, die Größe der lokalen Farbpalette errechnen. Der Aufbau der Bildschirmbeschreibung • Komma als Trennzeichen 00101100 • Abstand, in Pixeln, zum linken Rand des logischen Bildschirms 2 Bytes • Abstand, in Pixeln, zum oberen Rand des logischen Bildschirms 2 Bytes • Breite des Bildes 2 Bytes • Höhe des Bildes 2 Bytes • 1 Byte – Bit für lokale Farbpalette 1 Bit – Bit für Zeilensprungverfahren 1 Bit – Bit für Sortierung 1 Bit – Reserviert mit Null 2 Bits – Bits pro Pixel 3 Bit 2.4.1 Das Zeilensprungverfahren im GIF (Abbildung 1) Bei dieser speziellen Anwendung des Verfahrens wird zunächste nur jede achte, dann jede vierte, anschließend jede zweite Zeile und letztendlich die verbliebenen Zeilen in den Rasterdaten gespeichert. Beim Auslesen werden diese dann jeweils in acht-, vier-, zwei- und einfacher Höhe dargestellt. Dies ermöglicht einen schnellen Bildaufbau, der Betrachter erhält somit zu Beginn eine grobe Übersicht des Bildes, deren Auflösung sich stets verdoppelt, bis das Rasterbild vollends aufgebaut ist. 2.5 Die Rasterdaten Nachdem nun die Rahmendaten für das Rasterbild festgelegt sind, startet die Beschreibung der eigentlichen Bilddaten. Zu Beginn der Rasterdaten steht ein Byte, das die Anzahl an Bits pro Codewort ausgibt. Arbeitet man mit nur 17 Farben, so würde dieses Byte mit 00000101 initialisiert, da fünf Bits zur Darstellung benötigt 2 DER AUFBAU EINER DATEI NACH GIF-SPEZIFIKATION 89A 6 Abbildung 1: Das Zeilensprungverfahren im GIF würden, bei 70 Farben wäre der Wert also 00000111. Das nächste Byte beschreibt, wie viele Bytes in dem nun folgenden Datenblock übertragen werden. An diesem Punkt müsste man nun zeilenweise, von oben beginnend, für jedes Pixel einen Verweis auf eine Farbe aus der Farbpalette speichern. Da dies jedoch zu einer recht großen GIF-Datei führen würde, werden die Rasterdaten laut Spezifikation mit dem Lempel-Ziv-WelchAlgorithmus komprimiert. Dieser Algorithmus dient der Mustererkennung, so dass man eben nicht für jedes einzelne Pixel ein Byte übertragen muss. Für die erkannten Muster generiert der Lempel-Ziv-Welch-Kodierer eine Codetabelle. Reicht die Anzahl an Bits, die zur Übertragung genutzt werden dürfen, nicht mehr aus, so wird einfach ein weiteres Bit hinzugenommen. Dies lässt sich, wie später erläutert wird, leicht in den Dekodierungsvorgang einbauen. Die unkomprimierten Rasterdaten werden auf die so erzeugte Codetabelle abgebildet, und die erzeugte Folge von Codewörtern ersetzt die unkomprimierten Rasterdaten im GIF. Das Besondere am Lempel-Ziv-Welch-Algorithmus ist, dass die Codetabelle nicht Teil der GIF-Datei ist, sondern vom Decoder aus den komprimierten Rasterdaten erstellt werden kann. Die Anzahl an Bits, die für einen Verweis in diese Codetabelle zu Beginn benötigt werden, kann, wie bereits erwähnt, aus dem ersten Byte der Rasterdaten ausgelesen werden. Die komprimierten Rasterdaten, welche ja nun bitweise vorliegen, werden zu Byteketten verbunden und können dann als Datenblock gespeichert werden. Nachdem nun klar ist, wie groß ein Codewort ist und wie viele Bytes sich in einem Datenblock befinden, können die LZW-komprimierten Datenbytes übertragen werden. Am Ende der Rasterdaten steht als Endzeichen ein Nullbyte. Der Aufbau der Rasterdaten – Die Anzahl an Bits pro Codewort zu Beginn sind abhängig von der Größe der zugeordneten Farbpalette • Anzahl an Bits pro Codewort 1 Byte • Anzahl an Bytes im folgenden Datenblock 1 Byte • Datenblock siehe eine Zeile höher – Ist ein Datenblock verarbeitet, so gibt es zwei Möglichkeiten: 0. Es folgt erneut ein Datenblock, dem natürlich wieder ein Byte zur Beschreibung der Länge des Datenblocks voransteht. 1. Endzeichen für Rasterdaten 00000000 2 DER AUFBAU EINER DATEI NACH GIF-SPEZIFIKATION 89A 2.6 7 Der Erweiterungsblock Die Unterschiede zwischen der Spezifikation 87a und 89a sind nicht gravierend. Es finden sich jedoch in der Spezifikation 89a konkrete Implementierungen des in der Spezifikation 87a vorgestellten Erweiterungsblockes. Implementierte Erweiterungen sind: • Erweiterung für Grafikkontrolle (vor Bildbeschreibung) • Erweiterung für Kommentare • Erweiterung für ASCII-Text • Erweiterung für Anwendungen 2.6.1 Erweiterung für Grafikkontrolle Der Erweiterungsblock für die Grafikkontrolle ermöglicht zum Beispiel das Erstellen von Animationen. Das erste Byte enthält, wie bei jeder Erweiterung, die Bits zur Darstellung eines Ausrufezeichens. Um die Erweiterung als Grafikkontrolle zu identifizieren, enthält das nächste Byte den Dezimalwert 249. Das dritte Byte beschreibt die Anzahl an Bytes bis zum Endzeichen. Das folgende Byte wird bitweise betrachtet: Laut Spezifikation sind die ersten drei Bits reserviert und standardmäßig mit Null zu belegen. Die folgenden drei Bits zeigen an, wie mit dem folgenden Rasterbild, beziehungsweise mit dem folgenden ASCII-Text Erweiterungsblock, zu verfahren ist, nachdem die Anzeige stattgefunden hat. Die vordefinierten Werte und ihre Bedeutung werden im Folgenden dargestellt. Nachdem der folgende Block ausgelesen und angezeigt wurde, 0. muss der Decoder nicht reagieren. 1. wird die Anzeige belassen wie sie ist. 2. werden die Pixel des logischen Bildschirms, die zur Anzeige benutzt wurden, wieder auf die Hintergrundfarbe gesetzt. 3. werden die Pixel des logischen Bildschirms, die zur Anzeige benutzt wurden, auf den Wert vor der Anzeige des Blocks gesetzt. Die übrigen Belegungen der drei Bits sind nicht definiert. Das folgende Bit zeigt an, ob während der Anzeige des Bildes eine Eingabe durch den Nutzer erwartet wird. Wie diese Eingabe auszusehen hat, ist abhängig von der Implementierung der Anwendungsprogramme, die mit der GIF-Datei arbeiten wollen. Ist dieses Bit gesetzt, so wartet das Programm bis zum Ablauf der Verzögerungszeit auf Eingaben vom Benutzer und fährt danach fort mit der Verarbeitung weiterer Datenblöcke der GIF-Datei. Es wird empfohlen, dass wenn dieses Bit gesetzt ist, auch eine Verzögerungszeit angegeben wird. Das letzte Bit gibt an, ob im Grafikkontrollblock der Index für die Transparenz gesetzt ist. Im fünften und sechsten Byte, ist der Wert für die Verzögerungszeit gespeichert. Der enthaltene Wert beschreibt die Verzögerungszeit in Hundertstel einer Sekunde. Ist das Bit für Eingaben durch den Benutzer nicht gesetzt, so wird für die Dauer der Verzögerunszeit gewartet, bevor mit der Verarbeitung der folgenden Blöcke begonnen wird. Das vorletzte Byte der Erweiterung zur Grafikkontrolle gibt den Index des transparenten Farbwertes an. Der Abschluss des Erweiterungsblockes ist am letzten Byte zu erkennen, welches den Wert Null speichert. Der Aufbau der Erweiterung zur Grafikkontrolle • Allgemeines Startsymbol für Erweiterungen 00100001 • Symbol zur Identifizierung als Erweiterung zur Grafikkontrolle 11111001 2 DER AUFBAU EINER DATEI NACH GIF-SPEZIFIKATION 89A 8 • Anzahl an Bytes bis zum Endzeichen 00000100 • 1 Byte – Reserviert mit Null 3 Bits – Verfahren nach Anzeige 3 Bits – Nutzereingaben 1 Bit – Transparenz-Bit1 Bit • Verzögerungszeit 2 Bytes • Index für die tranparente Farbe 1 Byte • Endsymbol 00000000 2.6.2 Erweiterung für Kommentare In dem Erweiterungsblock für Kommentare lassen sich Metainformationen zur GIF-Datei abspeichern, wie zum Beispiel eine Beschreibung des Inhaltes oder den Namen des Urhebers. Die Erweiterung beginnt mit dem Startsymbol, zur Identifizierung dient wieder das zweite Bit, das den dezimalen Wert 254 speichert. Anschließend können beliebig viele Datenblöcke folgen, denen ein Byte voransteht, das die Anzahl an Bytes im Datenblock angibt. Der Aufbau der Erweiterung für Kommentare • Allgemeines Startsymbol für Erweiterungen 00100001 • Symbol zur Identifizierung als Erweiterung für Kommentare 11111110 • Anzahl an Bytes im folgenden Datenblock 1 Byte • Datenblock siehe eine Zeile höher • Endsymbol 00000000 2.6.3 Erweiterung für ASCII Text Die Darstellung von Text wird durch diese Erweiterung extrem vereinfacht. Da eine solche Erweiterung in der Spezifikation 87a nicht angedacht war, müssen viele Parameter in diesen Block integriert werden. Das Startsymbol ist wie bei jeder Erweiterung der dezimale Wert 33. Das identifizierende Byte speichert den Dezimalwert 1. Das folgende Byte gibt die Anzahl an Bytes an, die zur Parametrisierung der eigentlichen ASCII-Daten dienen. Dieser Wert ist fest angegeben mit 12 Bytes. Die nächsten Bytes beschreiben die Maße des Gitters, in dem der Text dargestellt wird, linker und rechter Abstand zum Rand des logischen Bildschirms (je zwei Bytes), sowie Breite und Höhe des Gitters in Pixeln (je zwei Bytes). Um nun herausfinden zu können, wieviel Text gespeichert werden kann, benötigt man noch Breite und Höhe der Buchstaben (je 1 Byte). Zur Verwendung des Erweiterungsblocks für Text benötigt man eine globale Farbpalette, denn die folgenden zwei Bytes beschreiben Text- und Hintergrundfarbe und enthalten Verweise auf Einträge in die globale Farbpalette. Nachdem nun alle Parameter angegeben sind, folgen die Datenblöcke mit den eigentlichen ASCII-Kodierungen, denen jeweils ein Byte vorangeht, welches die Länge des Datenblocks angibt. Beendet wird auch diese Erweiterung mit einem Nullbyte. 2 DER AUFBAU EINER DATEI NACH GIF-SPEZIFIKATION 89A 9 Der Aufbau der Erweiterung für ASCII-Text • Allgemeines Startsymbol für Erweiterungen 00100001 • Symbol zur Identifizierung als Erweiterung zur Darstellung von ASCII-Text 00000001 • Anzahl an Bytes der zur Darstellung benötigten Parameter 00001100 • Linker Startpunkt des Gitters, in dem der Text dargestellt wird 2 Bytes • Oberer Startpunkt des Gitters, in dem der Text dargestellt wird 2 Bytes • Breite des Gitters, in dem der Text dargestellt wird 2 Bytes • Höhe des Giters, in dem der Text dargestellt wird 2 Bytes • Breite eines Buchstabens 1 Byte • Höhe eines Buchstabens 1 Byte • Textfarbe 1 Byte • Hintergrundfarbe 1 Byte • Anzahl an Bytes im folgenden Datenblock 1 Byte • Datenblock siehe eine Zeile höher • Endsymbol 00000000 2.6.4 Erweiterung für Anwendungen Die Erweiterungen für Anwendungen dienen zum Beispiel der Darstellung von Endlosschleifen, wie sie oft im Internet zu finden sind. Das erste Byte beschreibt das allgemeine Startymbol für Erweiterungen. Durch den Wert des folgenden Bytes, Dezimalwert 255, ist die Erweiterung für Anwendungen zu erkennen. Die nächsten acht Bytes speichern ASCII-codierte Buchstaben, die sich zur Ausgabe in den Programmen verwenden lassen. Anhand eines Algorithmus können die Anwendungen einen 24-stelligen Binärschlüssel generieren, anhand dessen sich das Programm authentifizieren lässt. Dieser wird in die folgenden drei Bits geschrieben. Es folgen die Blöcke mit den eigentlichen Anwendungsdaten, denen jeweils ein Byte vorangeht, das die Länge des Datenblocks beschreibt. Letztendlich folgt das Nullbyte. Aufbau der Erweiterung für Anwendungen • Allgemeines Startsymbol für Erweiterungen 00100001 • Symbol zur Identifizierung als Erweiterungsblock für Anwendungen 11111111 • Anzahl an Bytes der für die Anwendung benötigten Parameter 00001011 • Bytes zur Identifizierung der Anwendung 8 Bytes • Bytes zur Authentifikation der Anwendung 3 Bytes • Anzahl an Bytes im folgenden Datenblock 1 Byte • Datenblock siehe eine Zeile höher • Endsymbol 00000000 3 DER LEMPEL-ZIV-WELCH-ALGORITHMUS ZUR KOMPRESSION 3 10 Der Lempel-Ziv-Welch-Algorithmus zur Kompression Der LZW-Algorithmus wurde 1984 von Terry A. Welch in der Arbeit A technique for high-performance ” data compression“vorgestellt. Ein Nachteil des Algorithmus ist, das die Symbole immer so groß sind wie der Tabellenindex, das bedeutet, dass uncodierte Symbole mehr Bits benötigen als ursprünglich. Der Algorithmus war einfach und gut dokumentiert und wurde zu einer berühmten Technik um Daten zu komprimieren. So wird LZW nicht nur im GIF, sondern auch in der TIFF-Spezifikation erwähnt, sowie in verschiedenen Komprimierungsprogrammen. Die Funktionsweise des Algorithmus, wie er bei der Erstellung von GIF-Dateien benutzt wird, wird im Folgenden dargestellt. Es wird angenommen, es existiert eine Farbpalette, deren enthaltene Farben mit den Indizes Null und Eins angesprochen werden können. Die Codetabelle wird zu Beginn mit den Werten für die Indizes gefüllt. Zusätzlich erstellt man zwei neue Einträge. Zum Einen einen Code, mit dem die Codetabelle gelöscht werden kann, zum Anderen einen Code, der das Ende der LZW-Daten bedeutet. Diese Codetabelle füllt man nun weiter mit Mustern, die man beim Einlesen der Farbwerte für ein Rasterbild erhält. Dazu liest man die Rasterdaten ein und versucht die gelesenen Werte durch Zeichen in der Codetabelle zu ersetzen. Findet man ein Muster aus dem Eingabestrom in der Symboltabelle, so schreibt man den zugehörigen Code in die komprimierten Daten, und erstellt einen neuen Eintrag in der Codetabelle für dieses Muster, inklusive dem nachfolgenden Zeichen. Ein Beispiel: Erkannt Eingabe 10000101 1 0000101 0 000101 00 0101 0 101 10 1 1 Geschrieben 1 0 <5> 0 <4> 1 Neues Codewort 10 <4> 00 <5> 000<6> 01<7> 101<8> – Wie zu erkennen ist, lassen sich somit mehrere Zeichen mit einer Anzahl an Bits beschreiben, die man für gewöhnlich für nur ein Zeichen verwendet hätte. Den komprimierten Datenstrom zu dekomprimieren erweist sich als schwierig. Schaut man sich Beispiele zur Dekompression im World Wide Web an, so werden diese entweder anhand von unkomprimierten oder anhand von ausgesuchten Daten dargestellt. Nimmt man jedoch ein eigenes einfaches Beispiel, so führt dies zu Problemen, wie in der folgenden Tabelle zu erkennen ist. Eingabe 10< 5 >0< 4 >1 0< 5 >0< 4 >1 < 5 >0< 4 >1 Erster Buchstabe 1 0 ? Geschrieben 1 0 ? Neues Codewort 10 < 4 > ? Der Dekomprimierungsvorgang bricht an dieser Stelle ohne Erfolg ab, da kein geeignetes Zeichen in der Codetabelle gefunden werden kann. 4 Quellen Alle Informationen stammen von folgende Websites und wurden frei vom Englischen ins Deutsche übersetzt. • http://www.cs.duke.edu/courses/spring03/cps296.5/papers/welch 1984 technique for.pdf • http://www.gnu.org/philosophy/gif.html • http://progfree.org/Patents/Gif/origCompuServe.html 4 QUELLEN • http://www.w3.org/Graphics/GIF/spec-gif89a.txt • http://www.w3.org/Graphics/GIF/spec-gif87.txt 11
