Das Grafikaustausch-Format (GIF; oder) ist ein bitmap Bildformat, das von CompuServe 1987 eingeführt wurde und in weit verbreiteten Gebrauch im World Wide Web wegen seiner breiten Unterstützung und Beweglichkeit seitdem eingetreten ist. Das Format unterstützt bis zu 8 Bit pro Pixel, die so ein einzelnes Image erlauben, in einer Palette von bis zu 256 verschiedenen Farben Verweise anzubringen. Die Farben werden aus dem RGB 24-Bit-Farbenraum gewählt. Es unterstützt auch Zeichentrickfilme und erlaubt eine getrennte Palette von 256 Farben für jeden Rahmen. Die Farbenbeschränkung macht das GIF-Format unpassend, um Farbfotografien und andere Images mit der dauernden Farbe wieder hervorzubringen, aber es ist für einfachere Images wie Grafik oder Firmenzeichen mit festen Gebieten der Farbe gut passend.

GIF Images werden mit Lempel-Ziv-Welch (LZW) lossless Datenkompressionstechnik zusammengepresst, um die Dateigröße zu reduzieren, ohne die Sehqualität zu erniedrigen. Diese Kompressionstechnik wurde 1985 patentiert. Die Meinungsverschiedenheit über den Lizenzvertrag zwischen dem offenen Halter, Unisys, und CompuServe 1994 hat die Entwicklung des Standards von Portable Network Graphics (PNG) gespornt; seitdem sind alle relevanten Patente abgelaufen.

Geschichte

CompuServe hat das GIF-Format 1987 eingeführt, um ein Farbenbildformat für ihre Dateiherunterladen-Gebiete zur Verfügung zu stellen, ihr früheres Format der Verschlüsselung der Lauf-Länge (RLE) ersetzend, das schwarz und nur weiß war. GIF ist populär geworden, weil er LZW Datenkompression verwendet hat, die effizienter war als die Lauf-Länge, die verschlüsselt, der wie PCX und MacPaint formatiert, konnten verwendete und ziemlich große Images deshalb in einer vernünftig kurzen Zeit sogar mit sehr langsamen Modems heruntergeladen werden.

Die ursprüngliche Version des GIF-Formats wurde 87a genannt. 1989 hat CompuServe eine erhöhte Version, genannt 89a ausgedacht, der Unterstützung für Zeichentrickfilm-Verzögerungen hinzugefügt hat (vielfache Images in einem Strom wurden bereits in 87a unterstützt), durchsichtige Hintergrundfarben und Lagerung von anwendungsspezifischem metadata. 89a unterstützt Spezifizierung auch sich vereinigende Textetiketten als Text (sie in den grafischen Daten nicht einbettend), aber weil es wenig Kontrolle über Anzeigeschriftarten gibt, wird diese Eigenschaft nicht weit verwendet. Die zwei Versionen können durch das Schauen auf die ersten sechs Bytes der Datei bemerkenswert sein (die "Zauberzahl" oder "Unterschrift"), die, wenn interpretiert, als ASCII, "GIF87a" und "GIF89a" beziehungsweise lesen.

GIF war eines der ersten zwei Bildformate, die allgemein auf Websites, der andere verwendet sind, der schwarze und weiße XBM seiend. JPEG ist später mit dem Mosaikbrowser gekommen.

Die Eigenschaft, vielfache Images in einer Datei zu versorgen, die durch Kontrolldaten begleitet ist, wird umfassend im Web verwendet, um einfache Zeichentrickfilme zu erzeugen. Die fakultative sich verflechtende Eigenschaft, die Bildansehen-Linien in Unordnung auf solch eine Mode versorgt, wie sogar ein teilweise heruntergeladenes Image, auch die Beliebtheit von geholfenem GIF als ein Benutzer etwas erkennbar war, konnte das Download abbrechen, wenn es nicht war, was erforderlich war.

Artikulation

Die Schöpfer des Formats haben GIF mit einem weichen "G" als im "Gin" ausgesprochen. Eine alternative Artikulation verwendet einen harten "G" als in "der Grafik", das ausgebreitete Akronym widerspiegelnd. Beide Artikulationen werden als richtig durch das englische Wörterbuch von Oxford und das amerikanische Erbe-Wörterbuch gegeben.

Gemäß Steve Wilhite, dem Schöpfer des GIF-Formats, wirft die ursprüngliche Artikulation absichtlich die amerikanische Erdnussbutter-Marke, Jif zurück, und die Angestellten von CompuServe würden häufig sagen, dass "Wählerische Entwickler GIF", Manipulation die Fernsehwerbungen dieser Marke wählen. Diese Artikulation wurde auch von CompuServe in ihrer Dokumentation eines Grafikanzeigeprogramms genannt CompuShow identifiziert.

Gebrauch

• GIFs sind für die scharfkantige Linienkunst (wie Firmenzeichen) mit einer begrenzten Zahl von Farben passend. Das nutzt die lossless Kompression des Formats aus, die flache Gebiete der gleichförmigen Farbe mit gut definierten Rändern bevorzugt.
• GIFs kann verwendet werden, um niedrig-farbige Elfe-Daten für Spiele zu versorgen.
• GIFs kann für kleine Zeichentrickfilme und Filmklammern der niedrigen Entschlossenheit verwendet werden.
• Im Hinblick auf die allgemeine Beschränkung auf die GIF Bildpalette zu 256 Farben wird es als ein Format für die Digitalfotografie nicht gewöhnlich verwendet. Digitalfotografen verwenden Bilddateiformate, die dazu fähig sind, eine größere Reihe von Farben, wie ZANK, ROHSTOFF oder JPEG wieder hervorzubringen.

Dateiformat

Begrifflich beschreibt eine GIF Datei ein fest-großes grafisches Gebiet (der "logische Schirm") bevölkert mit der Null oder mehr "Images". Viele GIF Dateien haben ein einzelnes Image, das den kompletten logischen Schirm füllt. Andere teilen den logischen Schirm in getrennte Subimages. Die Images können auch als Zeichentrickfilm-Rahmen in einer belebten GIF Datei fungieren, aber wieder brauchen diese nicht den kompletten logischen Schirm zu füllen.

GIF Dateien fangen mit einem Kopfball der festen Länge ("GIF87a" oder "GIF89a") das Geben der Version an, die von einer festen Länge Logischer Schirm-Deskriptor gefolgt ist, der die Größe und anderen Eigenschaften des logischen Schirms gibt. Der Schirm-Deskriptor kann auch die Anwesenheit und Größe eines Globalen Farbentisches angeben, der als nächstes wenn Gegenwart folgt.

Danach wird die Datei in Segmente, jeder geteilt, der von einem 1-Byte-Wächter vorgestellt ist:

• Ein Image (eingeführt durch 0x2C, ein Komma)
• Ein Erweiterungsblock (eingeführt durch 0x21, ein Ausrufezeichen)
• Der Trailer (ein einzelnes Byte des Werts 0x3B, ein Strichpunkt), der das letzte Byte der Datei sein sollte.

Ein Image fängt mit einem Bilddeskriptor der festen Länge an, der die Anwesenheit und Größe eines Lokalen Farbentisches angeben kann (der als nächstes wenn Gegenwart folgt). Die Bilddaten folgen: Ein Byte, das die Bit-Breite der unverschlüsselten Symbole gibt (der, sogar für bi-color Images mindestens 2 Bit breit sein muss), gefolgt von einer verbundenen Liste von Subblöcken, die die LZW-verschlüsselten Daten enthalten.

Erweiterungsblöcke (Blöcke, die "sich" 87a Definition über einen Mechanismus "ausstrecken", der bereits in 87a Spekulation definiert ist) bestehen aus dem Wächter, ein zusätzliches Byte, das den Typ der Erweiterung und eine verbundene Liste von Subblöcken mit den Erweiterungsdaten angibt. Erweiterungsblöcke, die ein Image modifizieren (wie die Grafische Kontrollerweiterung, die die fakultative Zeichentrickfilm-Verzögerungszeit und fakultative durchsichtige Hintergrundfarbe angibt) müssen dem Segment mit dem Image sofort vorangehen, auf das sie sich beziehen.

Die verbundenen Listen, die durch die Bilddaten und die Erweiterungsblöcke verwendet sind, bestehen aus der Reihe von Subblöcken, jeder Subblock, der mit einem Byte beginnt, das die Zahl von nachfolgenden Datenbytes im Subblock (1 bis 255) gibt. Die Reihe von Subblöcken wird durch einen leeren Subblock (0 Bytes) begrenzt.

Diese Struktur erlaubt der Datei, grammatisch analysiert zu werden, selbst wenn nicht alle Teile verstanden werden. Ein GIF hat 87a gekennzeichnet kann Erweiterungsblöcke enthalten; die Absicht besteht darin, dass ein Decoder lesen und die Datei ohne die Eigenschaften zeigen kann, die in Erweiterungen bedeckt sind, die es nicht versteht.

Das volle Detail des Dateiformats wird in der GIF Spezifizierung bedeckt.

Paletten

GIF ist Palette-basiert: Die Farben, die in einem Image (ein Rahmen) in der Datei verwendet sind, ließen ihre RGB-Werte in einem Palette-Tisch definieren, der bis zu 256 Einträge halten kann, und sich die Daten für das Image auf die Farben durch ihre Indizes (0-255) im Palette-Tisch beziehen. Die Farbendefinitionen in der Palette können von einem Farbenraum von Millionen von Schatten gezogen werden (2 Schatten, 8 Bit für jede Vorwahl), aber die maximale Zahl von Farben, die ein Rahmen verwenden kann, ist 256. Diese Beschränkung ist angemessen geschienen, als GIF entwickelt wurde, weil wenige Menschen die Hardware gewähren konnten, um mehr Farben gleichzeitig zu zeigen. Einfache Grafik, Linienzeichnungen, Cartoons und Fotographien der grauen Skala brauchen normalerweise weniger als 256 Farben.

Als eine weitere Verbesserung kann jeder Rahmen einen Index als eine "durchsichtige Hintergrundfarbe" benennen: Jedes Pixel hat diesen Index zugeteilt übernimmt die Farbe des Pixels in derselben Position vom Hintergrund, der durch einen vorherigen Rahmen des Zeichentrickfilms bestimmt worden sein kann.

Viele Techniken, das insgesamt genannte Zappeln, sind entwickelt worden, um einer breiteren Reihe von Farben mit einer kleinen Farbenpalette durch das Verwenden von Pixeln von zwei oder mehr Farben näher zu kommen, um Zwischenfarben näher zu kommen. Diese Techniken opfern Raumentschlossenheit, um tieferer Farbenentschlossenheit näher zu kommen. Während nicht ein Teil der GIF Spezifizierung, das Zappeln natürlich in als GIF Images nachher verschlüsselten Images verwendet werden kann. Das ist häufig nicht eine ideale Lösung für GIF Images, beide, weil der Verlust der Raumentschlossenheit normalerweise ein Image kraus auf dem Schirm aussehen lässt, und weil die bibbernden Muster häufig die Verdichtbarkeit der Bilddaten stören, gegen den Hauptzweck von GIF arbeitend.

In den frühen Tagen von grafischen WWW-Browsern waren Grafikkarten mit 8-Bit-Puffern (nur 256 Farben erlaubend), üblich, und es war ziemlich üblich, GIF Images mit der websafe Palette zu machen. Diese gesicherte voraussagbare Anzeige, aber streng beschränkt die Wahl von Farben. Jetzt wo 32-Bit-Grafikkarten, die 24-Bit-Farbe unterstützen, die Norm sind, können Paletten mit den optimalen Farben für individuelle Images bevölkert werden.

Ein kleiner Farbentisch kann für kleine Images genügen, und das Halten des kleinen Farbentisches erlaubt der Datei, schneller heruntergeladen zu werden. Sowohl 87a als auch 89a erlauben Spezifizierungen Farbentische von 2 Farben für jeden n von 1 bis 8. Die meisten Grafikanwendungen werden lesen und GIF Images mit einigen dieser Tabellengrößen zeigen; aber einige unterstützen alle Größen nicht, wenn sie Images schaffen. Tische 2, 16, und 256 Farben werden weit unterstützt.

Wahre Farbe

Obwohl GIF für truecolor Images nicht häufig verwendet wird (weil er zu diesem Zweck nicht entworfen wurde), gibt es mindestens zwei Methoden, die 24 Bit RGB truecolor Images, wenn decodiert, richtig erzeugen können.

GIF, wird sogar in früher GIF87a Spezifizierung auf dem Grundsatz entworfen, vielfache Images auf einen fest-großen logischen Schirm zu machen. Jedes Image kann seine eigene 256-farbige Palette haben, so dass der logische Schirm mit vielfachen kleineren Images mit Ziegeln gedeckt werden kann, die zusammen jede Auswahl an Farben vom RGB 24-Bit-Farbenraum verwenden können.

Eine andere Technik verwendet die in GIF89a eingeführte Durchsichtigkeitseigenschaft: Eine GIF Datei kann als eine Reihe von überlappenden Images des vollen Schirms, jedes Image gebaut werden, das Farben von einem lokalen Farbentisch ausfüllt, die nicht in den vorherigen waren. In diesem Fall werden durchsichtige Pixel verwendet, um Farben vor vorherigen Stufen zu bewahren.

Beispiel GIF Datei

Das Farbe-Programm des Microsofts spart ein kleines schwarzes und weißes Image als die folgende GIF Datei. Farbe macht optimalen Gebrauch des GIF-Formats nicht; wegen des unnötigerweise großen Farbentisches (volle 256 Farben statt der verwendeten 2 versorgend), und Symbol-Breite ist diese GIF Datei nicht eine effiziente Darstellung des 15-Pixel-Images (illustriert vergrößert oben).

Obwohl der Grafikkontrollerweiterungsblock Farbenindex 16 (hexadecimal 10) erklärt, durchsichtig zu sein, wird dieser Index im Image nicht verwendet. Die einzigen Farbenindizes, die in den Bilddaten erscheinen, sind 40 und 255 dezimal, den der Globale Farbentisch zum Schwarzen und Weiß beziehungsweise kartografisch darstellt.

Bemerken Sie, dass die Hexe-Zahlen in den folgenden Tischen in wenig-endian der Byte-Ordnung sind, weil die Format-Spezifizierung vorschreibt.

byte# hexadecimal Text oder

(Hexe) Wert, der Bedeutet

0: 47 49 46

38 39 61 GIF89a Kopfball

Logischer Schirm-Deskriptor

6: 03 00 3 - logische Schirm-Breite in Pixeln

8: 05 00 5 - logische Schirm-Höhe in Pixeln

A: F7 - GCT folgt für 256 Farben mit dem Beschluss 3 x 8 Bit / primären

B: 00 0 - Hintergrund färben sich

#0

C: 00 - Verzug-Pixel-Aspekt-Verhältnis

R G B globaler Farbentisch

D: 00 00 00 0 0 0 - färben sich #0 schwarzer

10: 80 00 00 128 0 0 - färben sich

#1

::

85: 00 00 00 0 0 0 - färben sich #40 schwarzer

::

30A: FF FF FF 255 255 255 - färben sich #255 weißer

30D: 21 F9 Grafische Kontrollerweiterung

30F: 04 4 - folgen 4 Bytes von GCE Daten

310: 01 - gibt es eine durchsichtige Hintergrundfarbe

311: 00 00 - verspäten sich für den Zeichentrickfilm: nicht verwendeter

313: 10 16 - ist Farbe #16 durchsichtiger

314: 00 - Ende von GCE blockieren

315: 2C Bilddeskriptor

316: 00 00 00 00 (0,0) - NW Eckposition des Images im logischen Schirm

31A: 03 00 05 00 (3,5) - Bildbreite und Höhe in Pixeln

31E: 00 - kein lokaler Farbentisch

31F: 08 8 Anfang des Images - LZW Minimum codieren Größe

320: 0B 11 - 11 Bytes von verschlüsselten Bilddaten von LZW folgen

321: 00 51 FC 1B 28 70 A0 C1 83 01 01

32C: 00 - Ende von Bilddaten

32.: 3B GIF Datei terminator

</pre>

Bildcodierung

Die Bildpixel-Farben, gescannt horizontal von der verlassenen Spitze, werden durch LZW umgewandelt, der zu Codes verschlüsselt, die dann in Bytes kartografisch dargestellt werden, um in der Datei zu versorgen. Weil das Beispielimage darüber, zwischen 9-Bit-Codes und Bytes umkehrbar kartografisch darzustellen, unten gezeigt wird.

Binäre 9-Bit-Bytes

(Hexe) (Hexe)

00000000 00

100

0101000|1 51

028

111111|00 FC

0FF

00011|011 1B

103

0010|1000 28

102

011|10000 70

103

10|100000 A0

106

1|1000001 C1

107

10000011 83

00000001 01

101

0000000|1 01

</pre>

Eine geringe Kompression ist offensichtlich: Pixel-Farben definiert am Anfang durch 15 Bytes werden durch 12 Codebytes einschließlich Kontrollcodes genau vertreten.

Der Verschlüsselungsprozess, der die 9-Bit-Codes erzeugt, wird unten gezeigt. Eine lokale Schnur sammelt Pixel-Farbenzahlen von der Palette ohne Produktionshandlung an, so lange die lokale Schnur in einem Codetisch gefunden werden kann. Es gibt spezielle Behandlung der ersten zwei Pixel, die ankommen, bevor der Tisch von seiner anfänglichen Größe um Hinzufügungen von Schnuren wächst. Nach jedem Produktionscode wird die lokale Schnur zur letzten Pixel-Farbe initialisiert (der in den Produktionscode nicht eingeschlossen werden konnte).

Tisch 9 Bit

Schnur-> Code codiert Handlung

#0 | 000. Initialisieren Wurzeltisch von 9-Bit-Codes

Palette |:

Farben |:

#255 | 0FFh

clr | 100.

enden Sie | 101.

| 100. Klarer

Pixel lokal |

färben Sie Palette-Schnur |

SCHWARZ #40 28 | 028. 1. Pixel immer zur Produktion

WEIß #255 FF | Schnur, die im Tisch gefunden ist

28 FF | 102. fügen Immer 1. Schnur zum Tisch hinzu

FF | Initialisieren lokale Schnur

WEIß #255 FF FF | Schnur, die nicht im Tisch gefunden ist

| 0FFh - Produktionscode für die vorherige Schnur

FF FF | 103. - fügen letzte Schnur zum Tisch hinzu

FF | - initialisieren lokale Schnur

WEIß #255 FF FF | Schnur, die im Tisch gefunden ist

SCHWARZ #40 FF FF 28 | Schnur, die nicht im Tisch gefunden ist

| 103. - Produktionscode für die vorherige Schnur

FF FF 28 | 104. - fügen letzte Schnur zum Tisch hinzu

28 | - initialisieren lokale Schnur

WEIß #255 28 FF | Schnur, die im Tisch gefunden ist

WEIß #255 28 FF FF | Schnur, die nicht im Tisch gefunden ist

| 102. - Produktionscode für die vorherige Schnur

28 FF FF | 105. - fügen letzte Schnur zum Tisch hinzu

FF | - initialisieren lokale SchnurWEIß #255 FF FF | Schnur, die im Tisch gefunden ist

WEIß #255 FF FF FF | Schnur, die nicht im Tisch gefunden ist

| 103. - Produktionscode für die vorherige Schnur

FF FF FF | 106. - fügen letzte Schnur zum Tisch hinzu

FF | - initialisieren lokale SchnurWEIß #255 FF FF | Schnur, die im Tisch gefunden ist

WEIß #255 FF FF FF | Schnur, die im Tisch gefunden ist

WEIß #255 FF FF FF FF | Schnur, die nicht im Tisch gefunden ist

| 106. - Produktionscode für die vorherige Schnur

FF FF FF FF | 107. - fügen letzte Schnur zum Tisch hinzu

FF | - initialisieren lokale SchnurWEIß #255 FF FF | Schnur, die im Tisch gefunden istWEIß #255 FF FF FF | Schnur, die im Tisch gefunden ist

WEIß #255 FF FF FF FF | Schnur, die im Tisch gefunden ist

Keine Pixel mehr

107. - Produktionscode für die letzte Schnur

101. Ende

</pre>

Für die Klarheit wird der Tisch oben als gezeigt, Schnuren der zunehmenden Länge gebaut werden. Dieses Schema kann fungieren, aber der Tisch verbraucht einen unvorhersehbaren Betrag des Gedächtnisses. Gedächtnis kann in der Praxis durch die Anmerkung gespart werden, dass jede neue zu versorgende Schnur aus einer vorher versorgten durch einen Charakter vermehrten Schnur besteht. Es ist wirtschaftlich, um an jeder Adresse nur zwei Wörter zu versorgen: eine vorhandene Adresse und ein Charakter.

Der LZW Algorithmus verlangt eine Suche des Tisches für jedes Pixel. Eine geradlinige Suche durch bis zu 4096 Adressen würde das Codieren langsam machen. In der Praxis können die Codes in der Größenordnung vom numerischen Wert versorgt werden; das erlaubt jeder Suche, durch einen SAR (Aufeinander folgendes Annäherungsregister, wie verwendet, in einem ADCs) mit nur 12 Umfang-Vergleichen getan zu werden. Für diese Leistungsfähigkeit ist ein Extratisch erforderlich, um sich zwischen Codes und wirklichen Speicheradressen umzuwandeln; der Extratisch upkeeping ist nur erforderlich, wenn ein neuer Code versorgt wird, der an viel weniger geschieht als Pixel-Rate.

Bildentzifferung

Entzifferung beginnt, indem sie die versorgten Bytes zurück zu 9-Bit-Codes kartografisch dargestellt wird. Diese werden decodiert, um die Pixel-Farben, wie gezeigt, unten wieder zu erlangen. Ein Tisch, der zu im encoder verwendetem demjenigen identisch ist, wird durch das Hinzufügen von Schnuren durch diese Regel gebaut:

Wird eingehender Code im Tisch gefunden?

JA: Fügen Sie Schnur für den lokalen Code hinzu, der vom ersten Byte der Schnur für den eingehenden Code gefolgt ist

NEIN: Fügen Sie Schnur für den lokalen Code hinzu, der von der Kopie seines eigenen ersten Bytes gefolgt ist

Verschiebung

9 Bit----> Lokales Tabellenpixel

codieren Sie Codecode-> spannen Palette-Farbenhandlung

100. 000. | #0 Initialisieren Wurzeltisch von 9-Bit-Codes

: | Palette

: | färbt

0FFh |

#255

100. | clr

101. | beenden

028. | #40 SCHWARZ Decodieren 1. Pixel

0FFh 028. | Eingehender Code, der im Tisch gefunden ist

| #255 WEIß - Produktionsschnur vom Tisch

102. | tragen 28 FF - zum Tisch bei

103. 0FFh | Eingehender Code, der nicht im Tisch gefunden ist

103. | FF FF - tragen zum Tisch bei

| - Produktionsschnur vom Tisch

| #255 WEIßER

| #255 WEIßER

102. 103. | Eingehender Code, der im Tisch gefunden ist

| - Produktionsschnur vom Tisch

| #40 SCHWARZER

| #255 WEIßER

104. | FF FF 28 - tragen zum Tisch bei

103. 102. | Eingehender Code, der im Tisch gefunden ist

| - Produktionsschnur vom Tisch | #255 WEIßER | #255 WEIßER

105. | tragen 28 FF FF - zum Tisch bei

106. 103. | Eingehender Code, der nicht im Tisch gefunden ist

106. | FF FF FF - tragen zum Tisch bei

| - Produktionsschnur vom Tisch | #255 WEIßER | #255 WEIßER | #255 WEIßER

107. 106. | Eingehender Code, der nicht im Tisch gefunden ist

107. | FF FF FF FF - tragen zum Tisch bei

| - Produktionsschnur vom Tisch | #255 WEIßER | #255 WEIßER | #255 WEIßER | #255 WEIßER

101. | Ende

</pre>

LZW codieren Längen

Kürzere Codelängen können für Paletten verwendet werden, die kleiner sind als die 256 Farben im Beispiel. Wenn die Palette nur 64 Farben ist (so sind Farbenindizes 6 Bit breit), können sich die Symbole von 0 bis 63 erstrecken, und die Symbol-Breite kann genommen werden, um 6 Bit mit Codes zu sein, die an 7 Bit anfangen. Tatsächlich braucht die Symbol-Breite nicht die Palette-Größe zu vergleichen: So lange die decodierten Werte immer weniger sind als die Zahl von Farben in der Palette, können die Symbole jede Breite von 2 bis 8, und die Palette-Größe jede Macht 2 von 2 bis 256 sein. Zum Beispiel, wenn nur die ersten vier Farben (schätzt 0 bis 3), der Palette verwendet werden, können die Symbole genommen, um mit Codes 2 Bit breit zu sein, die an 3 Bit anfangen.

Umgekehrt konnte die Symbol-Breite an 8 gesetzt werden, selbst wenn nur 0 schätzt und 1 verwendet werden; diese Daten würden nur einen 2-farbigen Tisch verlangen. Obwohl es nichts in der Verschlüsselung der Datei dieser Weg geben würde, geschieht etwas Ähnliches normalerweise für bi-color Images: Die minimale Symbol-Breite ist 2, selbst wenn nur 0 schätzt und 1 verwendet werden.

Der Codetisch enthält am Anfang Codes, die um ein Bit länger sind als die Symbol-Größe, um die zwei speziellen Codes clr und Ende und Codes für Schnuren anzupassen, die während des Prozesses hinzugefügt werden. Wenn der Tisch voll ist, nimmt die Codelänge zu, um Raum für mehr Schnuren, bis zu einem maximalen Code 4095 = FFF (Hexe) zu geben. Da der Decoder seinen Tisch baut, verfolgt er diese Zunahmen in der Codelänge, und er ist im Stande, eingehende Bytes entsprechend auszupacken.

Unkomprimierter GIF

46 x 46 unkomprimierte GIF mit 7-Bit-Symbolen (128 Farben, 8-Bit-Codes). Klicken Sie auf das Image für eine Erklärung des Codes.]]

Der GIF, der Prozess verschlüsselt, kann modifiziert werden, um eine Datei zu schaffen, die ohne LZW Kompression, aber noch viewable als ein GIF Image ist. Das wurde vorher als eine Weise getan, Patentverletzung zu vermeiden. Unkomprimierter GIF kann auch ein nützliches Zwischenformat für einen Grafikprogrammierer sein, weil individuelle Pixel zugänglich sind, um zu lesen oder zu malen. Es ist nur notwendig, den unkomprimierten GIF durch einen Bildredakteur zu passieren, um es auf einen gewöhnlichen GIF zu reduzieren.

Die modifizierte Verschlüsselungsmethode ist, Gebäude des LZW Tisches zu ignorieren und nur die Wurzelpalette-Codes und die Codes für den KLAREN und HALT auszustrahlen. Diese Technik führt zu einfacherer Verschlüsselung (1 zu 1 Ähnlichkeit zwischen Codewerten und Palette-Codes), aber opfert die ganze Kompression. Der GIF Standarddecoder, der einen unkomprimierten GIF bearbeitet, wird nicht gehindert, Schnuren seinem Tisch zu schreiben, aber die Codebreite muss nie zunehmen, da das eine verschiedene Verpackung von Bit zu Bytes auslöst.

Wenn die Symbol-Breite n, die Codes der Breite n+1 Fall natürlich in zwei Blöcke ist: Der niedrigere Block von 2 Codes, um einzelne Symbole und den oberen Block von 2 Codes zu codieren, die durch den Decoder für Folgen der Länge verwendet werden, die größer ist als eine. Dieses oberen Blocks werden die ersten zwei Codes bereits genommen: 2 für den KLAREN und 2 + 1 für den HALT. Wir müssen auch den Decoder davon abhalten, den letzten Code im oberen Block, 2  1 zu verwenden, weil, wenn der Decoder dieses Ablagefach füllt, es die Codebreite vergrößern wird. So im oberen Block gibt es 2  3 Codes, die für den Decoder verfügbar sind, der keine Zunahme in der Codebreite auslösen wird. Weil der Decoder immer ein Schritt hinten im Aufrechterhalten des Tisches ist, erzeugt es keinen Tabellenzugang nach dem Empfang des ersten Codes vom encoder, aber wird ein für jeden folgenden Code erzeugen. So kann der encoder 2  2 Codes erzeugen, ohne eine Zunahme in der Codebreite auszulösen. Deshalb muss der encoder KLARE Extracodes an Zwischenräumen von 2  2 Codes ausstrahlen oder weniger den Decoder wiederanfangen zu lassen. Der GIF Standard erlaubt solche KLAREN Extracodes an, in die Bilddaten jederzeit eingefügt zu werden. Der zerlegbare Datenstrom wird in Subblöcke verteilt, die jeder von 1 bis 255 Bytes trägt.

Für die Probe 3x5 Image oben vertreten die folgenden 9-Bit-Codes "klar" (100) gefolgt von Bildpixeln in der Ansehen-Ordnung und "dem Halt" (101).

9-Bit-Codes: 100 028 0FF 0FF 0FF 028 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 101

</pre>

Nachdem die obengenannten Codes zu Bytes kartografisch dargestellt werden, unterscheidet sich die unkomprimierte Datei von der komprimierten Datei so:

:

320: 14 folgen 20 unkomprimierte 20-Byte-Bilddaten

321: 00 51 FC FB F7 0F C5 BF 7F FF FE FD FB F7 EF DF BF 7F 01 01

335: 00 - beenden

:</pre>

Kompressionsbeispiel

Das triviale Beispiel eines großen Images der festen Farbe demonstriert die variable Länge LZW in GIF Dateien verwendete Kompression.

------------------------------------------------------------------------------------------------

CODIEREN SIE | PIXEL | BEMERKEN

------------------------------------------------------------------------------------------------

nein. | Wert | Länge | dieser Code | angesammelt | gelten Beziehungen mit N¡ nur für dasselbe -

N¡ | N¡ + 256 | (Bit) | N¡ | N¡ (N¡ + 1)/2 |

Der Code schätzt gezeigt sind in Bytes gepackt, die dann in Blöcke von bis zu 255 Bytes gepackt sind. Ein Block von Bilddaten beginnt mit einem Byte, das die Zahl von Bytes erklärt zu folgen. Der letzte Datenblock für ein Image wird durch ein Nullbyte der Block-Länge gekennzeichnet.

Das Verflechten

Die GIF Spezifizierung erlaubt jedem Image innerhalb des logischen Schirms einer GIF Datei anzugeben, dass es verflochten wird; d. h. dass die Ordnung der Rasterlinien in seinem Datenblock nicht folgend ist. Das erlaubt eine teilweise Anzeige des Images, das anerkannt werden kann, bevor das volle Image gemalt wird.

Ein verflochtenes Image wird von oben bis unten in Streifen 8 Pixel hoch geteilt, und die Reihen des Images werden in der folgenden Ordnung präsentiert:

• Pass 1: Linie 0 (die höchste Linie) von jedem Streifen.
• Pass 2: Linie 4 von jedem Streifen.
• Pass 3: Linien 2 und 6 von jedem Streifen.
• Pass 4: Linien 1, 3, 5, und 7 von jedem Streifen.

Die Pixel innerhalb jeder Linie werden nicht verflochten, aber aufeinander folgend vom linken bis Recht präsentiert. Als mit nichtverflochtenen Images gibt es keine Brechung zwischen den Daten für eine Linie und den Daten für das folgende. Der Hinweis, dass ein Image verflochten wird, wird ein bisschen im Kopfball-Block des Images gesetzt.

Belebter GIF

Grundlegender Zeichentrickfilm wurde zur GIF89a Spekulation über Graphics Control Extension (GCE) hinzugefügt, die verschiedenen Images (Rahmen) in der Datei erlaubt, mit Verzögerungen gemalt zu werden. Eine belebte GIF Datei umfasst mehrere Rahmen, die in der Folge, jeder gezeigt werden, der durch seinen eigenen GCE vorgestellt ist, der die Verzögerung gibt, um zu warten, nachdem der Rahmen gezogen wird. Die globale Information am Anfang der Datei gilt standardmäßig für alle Rahmen. Die Daten werden Strom-orientiert, so hängt der Dateiausgleich des Anfangs jedes GCE von der Länge von vorhergehenden Daten ab. Innerhalb jedes Rahmens die LZW-codierten Bilddaten wird in Subblöcken von bis zu 255 Bytes eingeordnet; die Größe jedes Subblocks wird durch das Byte erklärt, das ihm vorangeht.

Standardmäßig, jedoch, zeigt ein Zeichentrickfilm die Folge von Rahmen nur einmal, anhaltend, wenn der letzte Rahmen gezeigt wird. Da GIF entworfen wird, um Benutzern zu erlauben, neue Blöcke zu definieren, hat Netscape in den 1990er Jahren den Anwendungserweiterungsblock verwendet (hat vorgehabt, Verkäufern zu erlauben, anwendungsspezifische Information zur GIF Datei hinzuzufügen), Netscape Application Block (NAB) durchzuführen.

Dieser Block, gelegt sofort vor allen Zeichentrickfilm-Rahmen, gibt die Zahl von Zeiten an die Folge von Rahmen sollte gespielt werden. (Der Wert 0 bedeutet dauernde Anzeige.) Ist die Unterstützung für diese sich wiederholenden Zeichentrickfilme zuerst in der Netscape Navigator-Version 2.0 erschienen, und hat sich dann zu anderen Browsern ausgebreitet. Die meisten Browser erkennen jetzt an, und Unterstützung SCHNAPPEN, obwohl es nicht ausschließlich ein Teil der GIF89a Spezifizierung ist.

Das folgende Beispiel zeigt die Struktur der Zeichentrickfilm-Datei gezeigt (als ein Daumennagel) an der Oberseite vom Artikel.

byte# hexadecimal Text oder

(Hexe) Wert, der Bedeutet

0: 47 49 46

38 39 61 GIF89a Kopfball

Logischer Schirm-Deskriptor

6: 90 01 400 - Breite in Pixeln

8: 90 01 400 - Höhe in Pixeln

A: F7 - GCT folgt für 256 Farben mit dem Beschluss 3 x 8bits/primary

B: 00 0 - Hintergrund färben sich

#0

C: 00 - Verzug-Pixel-Aspekt-Verhältnis

D: Globaler Farbentisch

:

30D: 21 FF Anwendungserweiterung blockiert

30F: 0B 11 - elf Bytes von Daten folgen

310: 4E 45 54

53 43 41

50 45 NETSCAPE - Anwendungsname-Buchstaben 8

32 2E 30 2.0 - Anwendung "Beglaubigungscode"

31B: 03 3 - noch drei Bytes von Daten

31C: 01 1 - subblockieren Daten Index (immer 1)

31D: FF FF 65535 - nicht unterzeichnete Zahl von Wiederholungen

31F: 00 - Ende der App Erweiterung blockieren

320: 21 F9 Grafische Kontrollerweiterung für den Rahmen

#1

322: 04 4 - folgen vier Bytes von Daten

323: 08 - keine Durchsichtigkeit

324: 09 00 - 0.09 Sec-Verzögerung vor der Malerei folgenden Rahmens

326: 00 - keine durchsichtige Farbe

327: 00 - Ende von GCE blockieren

328: 2C Bilddeskriptor

329: 00 00 00 00 (0,0) - NW Ecke des Rahmens an 0, 0

32.: 90 01 90 01 (400,400) - Rahmenbreite und Höhe: 400 x 400

331: 00 - kein lokaler CT; keine Zwischenzeile

332: 08 codieren 8 LZW Minuten Größe

333: FF 255 - 255 Bytes von verschlüsselten Bilddaten von LZW folgen

334: Daten

433: FF 255 - 255 Bytes von verschlüsselten Bilddaten von LZW folgen

Daten

:

92BA: 00 - Ende von LZW Daten für diesen Rahmen

92BB: 21 F9 Grafische Kontrollerweiterung für den Rahmen

#2

::

153B7B:21 F9 Grafische Kontrollerweiterung für den Rahmen

#44 :

15CF35:3B Datei terminator

</pre>

Die Zeichentrickfilm-Verzögerung für jeden Rahmen wird im GCE in Hundertsteln einer Sekunde angegeben. Etwas Wirtschaft von Daten ist möglich, wo ein Rahmen nur einen Teil der Pixel der Anzeige umschreiben muss, weil der Bilddeskriptor ein kleineres statt des ganzen Images wiederzuscannendes Rechteck definieren kann. Anzeigen, die belebten GIFs nicht unterstützen, zeigen nur den ersten Rahmen.

Internet Explorer verlangsamt GIFs, wenn die Rahmenrate 20 Rahmen pro Sekunde oder höher ist und Microsoft berichten, dass Google Chrom und Safari auch einige GIF Zeichentrickfilme verlangsamen.

Unisys und LZW patentieren Erzwingung

1977 und haben 1978, Jacob Ziv und Abraham Lempel ein Paar von Papieren auf einer neuen Klasse von lossless Datenkompressionsalgorithmen veröffentlicht, die jetzt insgesamt auf als LZ77 und LZ78 verwiesen sind. 1983 haben Frottiertuch-Waliser eine schnelle Variante von LZ78 entwickelt, der Lempel-Ziv-Welch (LZW) genannt wurde.

Waliser haben eine offene Anwendung für die LZW Methode im Juni 1983 abgelegt. Das resultierende Patent, gewährt im Dezember 1985, wurde Sperry Corporation zugeteilt, die sich nachher mit Burroughs Corporation 1986 verschmolzen hat und Unisys gebildet hat. Weitere Patente wurden im Vereinigten Königreich, Frankreich, Deutschland, Italien, Japan und Kanada erhalten.

Im Juni 1984 wurde ein Artikel von Walisern in der Zeitschrift IEEE veröffentlicht, die öffentlich die LZW Technik zum ersten Mal beschrieben hat. LZW ist eine populäre Datenkompressionstechnik geworden und, als das Patent gewährt wurde, ist Unisys in Lizenzverträge mit mehr als hundert Gesellschaften eingetreten.

Die Beliebtheit von LZW hat CompuServe dazu gebracht, es als die Kompressionstechnik für ihr GIF-Format, entwickelt 1987 zu wählen. Zurzeit war CompuServe des Patents nicht bewusst. Unisys ist sich bewusst geworden, dass das GIF-Format die LZW Kompressionstechnik verwendet hat und ins Genehmigen von Verhandlungen mit CompuServe im Januar 1993 eingetreten ist. Die nachfolgende Abmachung wurde am 24. Dezember 1994 bekannt gegeben. Unisys hat festgestellt, dass sie angenommen haben, dass alle kommerziellen Hauptonline-Informationsdienstleistungsgesellschaften, die das LZW-Patent verwenden, die Technologie von Unisys an einer angemessenen Rate lizenziert haben, aber dass sie nicht verlangen würden, dass das Genehmigen oder Gebühren, für nichtkommerzielle, gemeinnützige GIF-basierte Anwendungen, einschließlich derjenigen für den Gebrauch auf den Online-Dienstleistungen bezahlt wird.

Im Anschluss an diese Ansage gab es weit verbreitete Verurteilung von CompuServe und Unisys, und viele Softwareentwickler haben gedroht aufzuhören, das GIF-Format zu verwenden. Das PNG-Format wurde (sieh unten) 1995 als ein beabsichtigter Ersatz entwickelt. Jedoch hat sich das Erreichen der Unterstützung von den Schöpfern von WWW-Browsern und anderer Software für das PNG-Format schwierig erwiesen, und es war nicht möglich, das GIF-Format zu ersetzen, obwohl PNG in der Beliebtheit allmählich zugenommen hat. Die libungif Bibliothek hat GIFs erlaubt, decodiert, aber ohne Gebrauch des Unisys LZW Patent nicht verschlüsselt zu werden.

Im August 1999 hat Unisys die Details ihres Genehmigens der Praxis geändert, die Auswahl für Eigentümer von Nettowebsites von Billboard und Intra bekannt gebend, um Lizenzen auf der Zahlung einer ehemaligen Lizenzgebühr von 5000 $ oder 7500 $ zu erhalten. Solche Lizenzen waren für Website-Eigentümer oder andere GIF Benutzer nicht erforderlich, die lizenzierte Software verwendet hatten, um GIFs zu erzeugen. Dennoch wurde Unisys Tausenden von Online-Angriffen und beleidigenden E-Mails von Benutzern unterworfen, die glauben, dass sie dabei waren, 5000 $ beladen oder darauf verklagt zu werden, GIFs auf ihren Websites zu verwenden. Trotz des Gebens freier Lizenzen zu Hunderten von gemeinnützigen Organisationen, Schulen und Regierungen, war Unisys völlig unfähig, jede gute Werbung zu erzeugen, und hat fortgesetzt, von Personen und Organisationen wie die Liga verurteilt zu werden, um Freiheit Zu programmieren, wer die "Brandwunde der Ganze GIFs" Kampagne angefangen hat.

Das US-LZW-Patent ist am 20. Juni 2003 abgelaufen. Die Kopie-Patente im Vereinigten Königreich, Frankreich, Deutschland und Italien sind am 18. Juni 2004 abgelaufen, die japanischen Kopie-Patente sind am 20. Juni 2004 abgelaufen, und das kanadische Kopie-Patent ist am 7. Juli 2004 abgelaufen. Folglich, während Unisys weitere Patente und offene Anwendungen in Zusammenhang mit Verbesserungen zur LZW Technik hat, kann das GIF-Format jetzt frei verwendet werden.

PNG und andere Alternativen

Portable Network Graphics (PNG) wurde als ein Ersatz für das GIF-Format entworfen, um Verstoß des Patents von Unisys auf der LZW Kompressionstechnik zu vermeiden. PNG bietet bessere Kompression und mehr Eigenschaften an als GIF, Zeichentrickfilm, der die einzige bedeutende Ausnahme ist. PNG ist passender als GIF in Beispielen, wo wahr-farbige Bildaufbereitung und Alpha-Durchsichtigkeit erforderlich sind. MNG wurde als eine PNG-basierte Lösung für Zeichentrickfilme ursprünglich entwickelt, aber ist nicht weit angenommen worden. Das GIF-Format wird noch für den Zeichentrickfilm über PNG bevorzugt, obwohl wahre Belebte Tragbare Netzgrafik unter der Entwicklung durch Mozilla ist und in Firefox 3 unterstützt wird.

Obwohl die Unterstützung für das PNG-Format langsam gekommen ist, unterstützen neue WWW-Browser allgemein PNG. Ältere Versionen von Internet Explorer unterstützen alle Eigenschaften von PNG nicht. Versionen 6 und unterstützen früher Alpha-Kanaldurchsichtigkeit nicht, ohne mit dem Microsoft spezifische HTML-Erweiterungen zu verwenden. Die Gammakorrektur von PNG Images wurde nicht unterstützt, bevor Version 8 und die Anzeige dieser Images in früheren Versionen die falsche Tönung haben können.

PNG Dateien können viel größer sein als GIF Dateien in Situationen, wo ein GIF und eine PNG Datei von derselben Qualitätsbildquelle geschaffen wurden, wie PNG zur Speicherung von mehr Farbentiefe- und Durchsichtigkeitsinformation fähig ist als GIF. Jedoch, für identische 8 Bit (oder tiefer) Bilddaten, sind PNG Dateien normalerweise kleiner als der gleichwertige GIFs wegen der effizienteren in der PNG-Verschlüsselung verwendeten Kompressionstechniken. Die ganze Unterstützung für das GIF-Format wird hauptsächlich durch die komplizierte Leinwand-Struktur kompliziert, die es erlaubt, obwohl das ist, was die Kompaktzeichentrickfilm-Eigenschaften ermöglicht.

2004 wurde eine Erweiterung auf das PNG-Format genannt APNG vorgeschlagen. Es sollte die Fähigkeit zur Verfügung stellen, PNG Dateien zu beleben, während es umgekehrt Vereinbarkeit in Decodern behalten hat, die den Zeichentrickfilm-Klotz nicht verstehen können. Ältere Decoder werden einfach den ersten Rahmen des Zeichentrickfilms machen. MNG, eine Variante von PNG, der Zeichentrickfilm, erreichte Version 1.0 2001 unterstützt, aber wenige Anwendungen unterstützen es. Belebter GIF bleibt weit verwendet, weil viele Anwendungen dazu fähig sind, die Dateien zu schaffen, und es das einzige belebte Bildformat bleibt, das in fast allen modernen WWW-Browsern ohne den Gebrauch einer Einfügefunktion unterstützt ist. Dennoch werden eingebettete Blitz-Gegenstände, MPEGs und andere Videoformate im Platz von belebtem GIFs in vielen Websites verwendet. Andere Annäherungen, wie individuelle Rahmen, die durch AJAX oder SVG Images gedient sind, können über JavaScript oder SMIL belebt werden.

Siehe auch

• Der Vergleich der Grafikdatei formatiert
• Vergleich von Lay-Out-Motoren (Grafik)
• GNU plotutils (unterstützt Pseudo-Gif-Format, das Verschlüsselung der Lauf-Länge aber nicht LZW verwendet)
• Softwarepatent
• Microsoft GIF Animator, ein kostenloses Programm, um einfach zu schaffen, hat GIFs belebt

Links

• GIF89a Spezifizierung
• Die GIF Artikulationsseite
• LZW GIF, der durch Arturo San Emeterio Campos decodiert
• LZW und GIF haben erklärt
• Das Ersetzen eines Wörterbuches mit einer Quadratwurzel - Vorschläge, um GIFs zusammenzupressen, ohne LZW Kompression zu verwenden
• Webgrafik bespricht und illustriert, dass die Unterschiede zwischen GIF, JPEG und PNG formatieren
• Gifology