GIF
.gif) En animerad GIF av en roterande jordglob
| |
| Filnamnstillägg |
.gif
|
|---|---|
| Internet mediatyp |
bild/gif
|
| Skriv kod | GIFf |
| Uniform Type Identifier (UTI) | com.compuserve.gif |
| Magiskt nummer |
GIF87a / GIF89a
|
| Utvecklad av | CompuServe |
| Initial release | 15 juni 1987 |
| Senaste släppningen | 89a 1989 |
| Typ av format | förlustfritt bitmappsbildformat _ |
| Hemsida | |
The Graphics Interchange Format ( GIF ; / ɡ ɪ f / GHIF eller / dʒ ɪ f / JIF , se uttal ) är ett bitmappsbildformat som utvecklades av ett team på onlinetjänsteleverantören CompuServe ledd av den amerikanske datavetaren Steve Wilhite och släpptes den 15 juni 1987. Det är i utbredd användning på World Wide Web på grund av dess breda stöd och portabilitet mellan applikationer och operativsystem.
Formatet stöder upp till 8 bitar per pixel för varje bild, vilket gör att en enda bild kan referera till sin egen palett med upp till 256 olika färger valda från 24 -bitars RGB-färgrymden . Den stöder också animationer och tillåter en separat palett med upp till 256 färger för varje bildruta. Dessa palettbegränsningar gör GIF mindre lämpligt för att återge färgfotografier och andra bilder med färggradienter, men väl lämpade för enklare bilder som grafik eller logotyper med solida färgområden.
GIF-bilder komprimeras med Lempel-Ziv-Welch ( LZW) förlustfri datakomprimeringsteknik för att minska filstorleken utan att försämra den visuella kvaliteten.
Historia
CompuServe introducerade GIF den 15 juni 1987 för att tillhandahålla ett färgbildformat för deras filnedladdningsområden. Detta ersatte deras tidigare körlängdskodningsformat , som endast var svartvitt. GIF blev populärt eftersom det använde Lempel–Ziv–Welch- datakomprimering . Eftersom detta var mer effektivt än körlängdskodningen som användes av PCX och MacPaint , kunde ganska stora bilder laddas ner ganska snabbt även med långsamma modem .
Den ursprungliga versionen av GIF hette 87a. Den här versionen stödde redan flera bilder i en ström.
1989 släppte CompuServe en förbättrad version, kallad 89a. Denna version lade till:
- stöd för animeringsförseningar
- genomskinliga bakgrundsfärger
- lagring av applikationsspecifik metadata
- tillåta textetiketter som text (inte bädda in dem i grafiska data). Eftersom det finns liten kontroll över skärmteckensnitt används den här funktionen sällan.
De två versionerna kan särskiljas genom att titta på de första sex byten av filen (det " magiska numret " eller signaturen), som, när den tolkas som ASCII , läser "GIF87a" respektive "GIF89a".
CompuServe uppmuntrade antagandet av GIF genom att tillhandahålla nedladdningsbara konverteringsverktyg för många datorer. I december 1987, till exempel, kunde en Apple IIGS- användare se bilder skapade på en Atari ST eller Commodore 64 . GIF var ett av de två första bildformaten som ofta användes på webbplatser, det andra var det svartvita XBM .
I september 1995 lade Netscape Navigator 2.0 till möjligheten för animerade GIF-filer att loopa .
Medan GIF utvecklades av CompuServe , använde den Lempel–Ziv–Welch (LZW) förlustfria datakomprimeringsalgoritm som patenterades av Unisys 1985. Kontroverser om licensavtalet mellan Unisys och CompuServe 1994 stimulerade utvecklingen av Portable Network Graphics (PNG) standard. Under 2004 löpte alla patent relaterade till den proprietära komprimeringen som används för GIF ut.
Funktionen att lagra flera bilder i en fil, tillsammans med kontrolldata, används flitigt på webben för att producera enkla animationer .
Den valfria sammanflätningsfunktionen , som lagrar bildskanningslinjer ur funktion på ett sådant sätt att även en delvis nedladdad bild var något igenkännbar, hjälpte också GIF:s popularitet, eftersom en användare kunde avbryta nedladdningen om det inte var vad som krävdes.
I maj 2015 lade Facebook till stöd för GIF. I januari 2018 lade Instagram också till GIF-klistermärken i berättelseläget.
Terminologi
Som substantiv finns ordet GIF i de nyare utgåvorna av många ordböcker. 2012 kände den amerikanska flygeln av Oxford University Press även GIF som ett verb , vilket betyder "att skapa en GIF-fil", som i "GIFing var det perfekta mediet för att dela scener från sommar-OS ". Pressens lexikografer röstade fram det till årets ord och sa att GIF-filer har utvecklats till "ett verktyg med seriösa tillämpningar inklusive forskning och journalistik".
Uttal
Uttalet av den första bokstaven i GIF har varit omtvistat sedan 1990-talet. De vanligaste uttalen på engelska är / dʒ ɪ f / ( 
lyssna ) (med ett mjukt g som i gin ) och / ɡ ɪ f / ( lyssna ) (med ett hårt g som i gåva ), som skiljer sig åt i fonem som representeras av bokstaven G. _ Skaparna av formatet uttalade förkortningen GIF som / dʒ ɪ f / , med ett mjukt g , med Wilhite som sa att han avsåg att uttalet medvetet skulle återspegla det amerikanska jordnötssmörsmärket Jif , och CompuServe-anställda skulle ofta skämta "kräsna utvecklare väljer GIF", en parodi på Jifs tv-reklam. Ordet uttalas dock allmänt som / ɡ ɪ f / , med ett hårt g , och undersökningar har generellt visat att detta hårda g -uttal är vanligare.
Dictionary.com citerar båda uttalen, och indikerar / dʒ ɪ f / som det primära uttalet, medan Cambridge Dictionary of American English erbjuder endast hård- g uttalet. Merriam-Webster's Collegiate Dictionary och Oxford Dictionaries citerar båda uttalen, men placera det hårda g först: / ɡ ɪ f , dʒ ɪ f / . New Oxford American Dictionary gav endast / dʒ ɪ f / i sin andra upplaga men uppdaterade den till / dʒ ɪ f , ɡ ɪ f / i den tredje upplagan.
Oenigheten om uttalet har lett till en het internetdebatt. I samband med att Wilhite fick ett livstidsprestationspris vid 2013 års Webby Awards- ceremonin, avvisade Wilhite offentligt det hårda uttalet ; hans tal ledde till mer än 17 000 inlägg på Twitter och dussintals nyhetsartiklar. Vita huset och tv-programmet Jeopardy! deltog också i debatten 2013. I februari 2020, samarbetade The JM Smucker Company , ägarna av varumärket Jif, med den animerade bilddatabasen och sökmotorn Giphy för att släppa en begränsad upplaga "Jif vs. GIF" ( hashtaggat som #JIFvsGIF ) burk med jordnötssmör som hade en etikett som humoristiskt förklarade att det mjuka- g- uttalet uteslutande syftar på jordnötssmöret, och GIF ska uteslutande uttalas med det hård- g -uttalet.
Användande
GIF:er är lämpliga för skarpkantade streckteckningar med ett begränsat antal färger, till exempel logotyper. Detta drar fördel av formatets förlustfria komprimering, som gynnar platta områden med enhetlig färg med väldefinierade kanter. De kan också användas för att lagra spritedata i låg färg för spel. GIF:er kan användas för små animationer och lågupplösta videoklipp, eller som reaktioner i onlinemeddelanden som används för att förmedla känslor och känslor istället för att använda ord. De är populära på sociala medieplattformar som Tumblr, Facebook och Twitter.
Filformat
Begreppsmässigt beskriver en GIF-fil ett grafiskt område med fast storlek ("den logiska skärmen") fylld med noll eller fler "bilder". Många GIF-filer har en enda bild som fyller hela den logiska skärmen. Andra delar upp den logiska skärmen i separata underbilder. Bilderna kan också fungera som animationsramar i en animerad GIF-fil, men återigen behöver dessa inte fylla hela den logiska skärmen.
GIF-filer börjar med en rubrik med fast längd ("GIF87a" eller "GIF89a") som ger versionen, följt av en logisk skärmbeskrivning med fast längd som ger pixeldimensionerna och andra egenskaper hos den logiska skärmen. Skärmbeskrivningen kan också specificera närvaron och storleken av en Global Color Table (GCT), som följer nästa om den finns.
Därefter delas filen in i segment, vart och ett introducerat av en 1-byte sentinel:
- En bild (introducerad av 0x2C, ett ASCII-komma ',
') - Ett förlängningsblock (introducerat av 0x21, ett ASCII-utropstecken '!
') - Trailern (en enda byte med värdet 0x3B, ett ASCII-semikolon
';'), som bör vara den sista byten i filen.
En bild börjar med en bildbeskrivning med fast längd, som kan specificera närvaron och storleken på en lokal färgtabell (som följer härnäst om den finns). Bilddatan följer: en byte som ger bitbredden för de okodade symbolerna (som måste vara minst 2 bitar breda, även för tvåfärgade bilder), följt av en länkad lista med underblock som innehåller LZW-kodade data.
Tilläggsblock (block som "förlänger" 87a-definitionen via en mekanism som redan definierats i 87a-specifikationen) består av vaktposten, en extra byte som anger typen av anknytning och en länkad lista med underblock med anknytningsdata. Tilläggsblock som modifierar en bild (som Graphic Control Extension som anger den valfria animationsfördröjningstiden och valfri transparent bakgrundsfärg) måste omedelbart föregå segmentet med bilden de refererar till.
De länkade listorna som används av bilddatan och förlängningsblocken består av serier av delblock, där varje delblock börjar med en byte som ger antalet efterföljande databytes i delblocket (1 till 255). Serien av delblock avslutas med ett tomt delblock (en 0 byte).
Denna struktur gör att filen kan tolkas även om inte alla delar förstås. En GIF märkt 87a kan innehålla förlängningsblock; avsikten är att en avkodare kan läsa och visa filen utan de funktioner som täcks av tilläggen den inte förstår.
Den fullständiga detaljen av filformatet täcks i GIF-specifikationen.
Paletter
GIF är palettbaserad: färgerna som används i en bild (en ram) i filen har sina RGB- värden definierade i en paletttabell som kan innehålla upp till 256 poster, och data för bilden hänvisar till färgerna genom deras index ( 0–255) i paletttabellen. Färgdefinitionerna i paletten kan hämtas från en färgrymd av miljontals nyanser (2 24 nyanser, 8 bitar för varje primär), men det maximala antalet färger som en ram kan använda är 256. Denna begränsning verkade rimlig när GIF utvecklades eftersom få människor hade råd med hårdvaran för att visa fler färger samtidigt. Enkel grafik, linjeteckningar, tecknade serier och fotografier i gråskala behöver vanligtvis färre än 256 färger.
Varje bildruta kan ange ett index som en "genomskinlig bakgrundsfärg": alla pixlar som tilldelas detta index får färgen på pixeln i samma position som bakgrunden, vilket kan ha bestämts av en tidigare animeringsram.
Många tekniker, gemensamt kallade dithering , har utvecklats för att approximera ett bredare spektrum av färger med en liten färgpalett genom att använda pixlar med två eller fler färger för att approximera mellan färgerna. Dessa tekniker offrar rumslig upplösning för att approximera djupare färgupplösning. Även om det inte ingår i GIF-specifikationen, kan vibrering användas i bilder som sedan kodas som GIF-bilder. Detta är ofta inte en idealisk lösning för GIF-bilder, både för att förlusten av rumslig upplösning vanligtvis får en bild att se suddig ut på skärmen, och för att vibrerande mönster ofta stör komprimerbarheten av bilddata, vilket motverkar GIF:s huvudsyfte.
I början av grafiska webbläsare [ när? ] , var grafikkort med 8-bitars buffertar (som endast tillåter 256 färger) vanliga och det var ganska vanligt att göra GIF-bilder med den webbsäkra paletten . [ enligt vem? ] Detta säkerställde förutsägbar visning, men begränsade kraftigt valet av färger. När 24-bitars färg blev normen kunde paletter istället fyllas med de optimala färgerna för enskilda bilder.
En liten färgtabell kan räcka för små bilder, och att hålla färgtabellen liten gör att filen kan laddas ner snabbare. Både 87a- och 89a-specifikationerna tillåter färgtabeller med 2 n färger för alla n från 1 till 8. De flesta grafikapplikationer läser och visar GIF-bilder med någon av dessa tabellstorlekar; men vissa stöder inte alla storlekar när du skapar bilder. Tabeller med 2, 16 och 256 färger stöds brett.
Äkta färg
Även om GIF nästan aldrig används för äkta färgbilder , är det möjligt att göra det. En GIF-bild kan innehålla flera bildblock, som var och en kan ha sin egen palett med 256 färger, och blocken kan sida vid sida för att skapa en komplett bild. Alternativt introducerade GIF89a-specifikationen idén om en "transparent" färg där varje bildblock kan inkludera sin egen palett med 255 synliga färger plus en transparent färg. En komplett bild kan skapas genom att lagra bildblock med den synliga delen av varje lager som syns genom de transparenta delarna av lagren ovanför.
För att rendera en fullfärgsbild som en GIF måste originalbilden delas upp i mindre områden med högst 255 eller 256 olika färger. Var och en av dessa regioner lagras sedan som ett separat bildblock med sin egen lokala palett och när bildblocken visas tillsammans (antingen genom sida vid sida eller genom skiktning av delvis genomskinliga bildblock), visas den kompletta, fullfärgsbilden. Att till exempel bryta en bild i brickor på 16 gånger 16 pixlar (totalt 256 pixlar) säkerställer att ingen ruta har mer än den lokala palettgränsen på 256 färger, även om större brickor kan användas och liknande färger slås samman vilket resulterar i viss färgförlust information.
Eftersom varje bildblock kan ha sin egen lokala färgtabell kan en GIF-fil med många bildblock vara mycket stor, vilket begränsar användbarheten av fullfärgs-GIF. Dessutom hanterar inte alla GIF-renderingsprogram korrekt sida vid sida eller lager. Många renderingsprogram tolkar brickor eller lager som animationsramar och visar dem i sekvens som en animering med de flesta webbläsare som automatiskt visar ramarna med en fördröjningstid på 0,1 sekunder eller mer. [ bättre källa behövs ]
Exempel på GIF-fil
|
Microsoft Paint sparar en liten svart-vit bild som följande GIF-fil (illustrerad förstorad). Paint utnyttjar inte GIF optimalt; på grund av den onödigt stora färgtabellen (som lagrar hela 256 färger istället för de använda 2) och symbolbredden, är denna GIF-fil inte en effektiv representation av 15-pixelbilden. Även om Graphic Control Extension-blocket förklarar att färgindex 16 (hexadecimalt 10) är transparent, används inte det indexet i bilden. De enda färgindex som visas i bilddata är decimal 40 och 255, som den globala färgtabellen mappar till svart respektive vitt. |
 Exempelbild (förstorad), verklig storlek 3 pixlar bred och 5 hög |
Observera att hex-numren i följande tabeller är i little-endian byteordning, som formatspecifikationen föreskriver.
| Byte # (hex) | Hexadecimal | Text eller värde | Menande | |||||||
|---|---|---|---|---|---|---|---|---|---|---|
| 0 | 47 49 46 38 39 61 | GIF89a | Rubrik | |||||||
| 6 | 03 00 | 3 | Logisk skärmbredd | |||||||
| 8 | 05 00 | 5 | Logisk skärmhöjd | |||||||
| A | F7 | GCT följer för 256 färger med upplösning 3 × 8 bitar/primär, de lägsta 3 bitarna representerar bitdjupet minus 1, den högsta sanna biten betyder att GCT är närvarande | ||||||||
| B | 00 | 0 | Bakgrundsfärg: index #0; #000000 svart | |||||||
| C | 00 | 0 | Standardbildförhållande för pixlar, 0:0 | |||||||
| D | 00 00 00 |
|
Global färgtabell, färg #0: #000000, svart | |||||||
| 10 | 80 00 00 |
|
Global färgtabell, färg #1: transparent bit, används inte i bilden | |||||||
| ... | ... | ... | Global Color Table sträcker sig till 30A | |||||||
| 30A | FF FF FF |
|
Global färgtabell, färg #255: #ffffff, vit | |||||||
| 30D | 21 F9 | Graphic Control Extension (kommentarfält föregår detta i de flesta filer) | ||||||||
| 30F | 04 | 4 | Mängd GCE-data, 4 byte | |||||||
| 310 | 01 | Transparent bakgrundsfärg; detta är ett bitfält, den lägsta biten betyder transparens | ||||||||
| 311 | 00 00 | Fördröjning för animering i hundradelar av en sekund; inte använd | ||||||||
| 313 | 10 | 16 | Färgnummer för transparent pixel i GCT | |||||||
| 314 | 00 | Slutet på GCE-blocket | ||||||||
| 315 | 2C | Bildbeskrivning | ||||||||
| 316 | 00 00 00 00 | (0, 0) | Bildens nordvästra hörnposition i logisk skärm | |||||||
| 31A | 03 00 05 00 | (3, 5) | Bildens bredd och höjd i pixlar | |||||||
| 31E | 00 | 0 | Lokal färgtabellbit, 0 betyder ingen | |||||||
| 31F | 08 | 8 | Bildens början, LZW minsta kodstorlek | |||||||
| 320 | 0B | 11 | Mängden LZW-kodad bild följer, 11 byte | |||||||
| 321 | 00 51 FC 1B 28 70 A0 C1 83 01 01 | <image data> | 11 byte bilddata, se fält 320 | |||||||
| 32C | 00 | 0 | Slut på bilddatablock | |||||||
| 32D | 3B | Filavslutning | ||||||||
Bildkodning
Bildpixeldata, skannade horisontellt uppifrån till vänster, omvandlas genom LZW-kodning till koder som sedan mappas till byte för lagring i filen. Pixelkoderna matchar vanligtvis inte bytens 8-bitars storlek, så koderna packas i bytes med ett "little-Endian"-schema: den minst signifikanta biten av den första koden lagras i den minst signifikanta biten av första byte, högre ordningsbitar av koden till högre ordningsbitar av byte, som spills över till lågordningens bitar av nästa byte vid behov. Varje efterföljande kod lagras med början vid den minst signifikanta biten som inte redan används.
Denna byteström lagras i filen som en serie "underblock". Varje delblock har en maximal längd på 255 byte och är prefixerat med en byte som indikerar antalet databyte i delblocket. Serien av underblock avslutas av ett tomt underblock (en enda 0 byte, vilket indikerar ett underblock med 0 databyte).
För exempelbilden ovan visas den reversibla mappningen mellan 9-bitars koder och bytes nedan.
| 9-bitars kod | Byte | ||
|---|---|---|---|
| Hexadecimal | Binär | Binär | Hexadecimal |
| 100 | 1 00000000 | 00000000 | 00 |
| 028 | 00 0101000 | 0101000 1 | 51 |
| 0FF | 011 111111 | 111111 00 | FC |
| 103 | 1000 00011 | 00011 011 | IB |
| 102 | 10 000 0010 | 0010 1000 | 28 |
| 103 | 100 000 011 | 011 10000 | 70 |
| 106 | 1000001 10 | 10 100 000 | A0 |
| 107 | 10000011 1 | 1 1000001 | C1 |
| 10000011 | 83 | ||
| 101 | 1 00000001 | 00000001 | 01 |
| 0000000 1 | 01 | ||
En lätt komprimering är uppenbar: pixelfärger som initialt definieras av 15 byte representeras exakt av 12 kodbyte inklusive kontrollkoder. Kodningsprocessen som producerar 9-bitarskoderna visas nedan. En lokal sträng ackumulerar pixelfärgnummer från paletten, utan någon utdataåtgärd så länge den lokala strängen kan hittas i en kodtabell. Det finns en speciell behandling av de två första pixlarna som kommer innan tabellen växer från sin ursprungliga storlek genom tillägg av strängar. Efter varje utdatakod initieras den lokala strängen till den senaste pixelfärgen (som inte kunde inkluderas i utdatakoden).
Tabell 9-bitars sträng --> kodkod Åtgärd #0 | 000h Initiera rottabellen för 9-bitars kodpaletten | : färger | : #255 | 0FFh clr | 100h slut | 101h | 100h Clear Pixel Local | färgpalett sträng | SVART #40 28 | 028h 1:a pixel alltid för att mata ut WHITE #255 FF | Sträng som finns i tabell 28 FF | 102h Lägg alltid till den första strängen i tabellen FF | Initiera lokal sträng WHITE #255 FF FF | Sträng hittades inte i tabell | 0FFh - utgångskod för föregående sträng FF FF | 103h - lägg till senaste strängen i tabellen FF | - initiera lokal sträng WHITE #255 FF FF | Sträng som finns i tabellen SVART #40 FF FF 28 | Sträng hittades inte i tabell | 103h - utgångskod för föregående sträng FF FF 28 | 104h - lägg till den senaste strängen i tabell 28 | - initiera lokal sträng WHITE #255 28 FF | Sträng som finns i tabellen WHITE #255 28 FF FF | Sträng hittades inte i tabell | 102h - utgångskod för föregående sträng 28 FF FF | 105h - lägg till senaste strängen i tabellen FF | - initiera lokal sträng WHITE #255 FF FF | Sträng som finns i tabellen WHITE #255 FF FF FF | Sträng hittades inte i tabell | 103h - utgångskod för föregående sträng FF FF FF | 106h - lägg till senaste strängen i tabellen FF | - initiera lokal sträng WHITE #255 FF FF | Sträng som finns i tabellen WHITE #255 FF FF FF | Sträng som finns i tabellen WHITE #255 FF FF FF FF | Sträng hittades inte i tabell | 106h - utgångskod för föregående sträng FF FF FF FF| 107h - lägg till senaste strängen i tabellen FF | - initiera lokal sträng WHITE #255 FF FF | Sträng som finns i tabellen WHITE #255 FF FF FF | Sträng som finns i tabellen WHITE #255 FF FF FF FF | Sträng hittad i tabell Inga fler pixlar 107h - utdatakod för sista sträng 101h Slut
För tydlighetens skull visas tabellen ovan som byggd av strängar med ökande längd. Det schemat kan fungera men tabellen förbrukar en oförutsägbar mängd minne. Minne kan sparas i praktiken genom att notera att varje ny sträng som ska lagras består av en tidigare lagrad sträng utökad med ett tecken. Det är ekonomiskt att lagra endast två ord på varje adress: en befintlig adress och ett tecken.
LZW-algoritmen kräver en sökning i tabellen för varje pixel. En linjär sökning genom upp till 4096 adresser skulle göra kodningen långsam. I praktiken kan koderna lagras i numeriskt värde; detta gör att varje sökning kan göras av ett SAR (Successive Approximation Register, som används i vissa ADCs ), med endast 12 magnitudjämförelser. För denna effektivitet behövs en extra tabell för att konvertera mellan koder och faktiska minnesadresser; den extra bordshanteringen behövs endast när en ny kod lagras, vilket sker med mycket mindre än pixelhastighet.
Bildavkodning
Avkodningen börjar med att mappa de lagrade byten tillbaka till 9-bitarskoder. Dessa avkodas för att återställa pixelfärgerna som visas nedan. En tabell som är identisk med den som används i kodaren byggs genom att lägga till strängar enligt denna regel:
| Ja | lägg till sträng för lokal kod följt av första byte av sträng för inkommande kod |
| Nej | lägg till sträng för lokal kod följt av kopia av sin egen första byte |
shift 9-bitar ----> Lokal tabell Pixelkod kod kod --> sträng Palett färg Åtgärd 100h 000h | #0 Initiera rottabellen med 9-bitars koder : | palett : | färger 0FFh | #255 100h | clr 101h | slut 028h | #40 SVART Avkoda 1:a pixel 0FFh 028h | Inkommande kod finns i tabell | #255 WHITE - utgångssträng från tabell 102h | 28 FF - lägg till tabell 103h 0FFh | Inkommande kod hittades inte i tabell 103h | FF FF - lägg till i tabell | - utdatasträng från tabell | #255 VIT | #255 VIT 102h 103h | Inkommande kod finns i tabell | - utdatasträng från tabell | #40 SVART | #255 VIT 104h | FF FF 28 - lägg till bordet 103h 102h | Inkommande kod finns i tabell | - utdatasträng från tabell | #255 VIT | #255 VIT 105h | 28 FF FF - lägg till tabell 106h 103h | Inkommande kod hittades inte i tabell 106h | FF FF FF - lägg till i tabell | - utdatasträng från tabell | #255 VIT | #255 VIT | #255 VIT 107h 106h | Inkommande kod hittades inte i tabell 107h | FF FF FF FF - lägg till i tabell | - utdatasträng från tabell | #255 VIT | #255 VIT | #255 VIT | #255 VIT 101h | Slutet
LZW-kodlängder
Kortare kodlängder kan användas för paletter som är mindre än de 256 färgerna i exemplet. Om paletten bara är 64 färger (så färgindex är 6 bitar breda) kan symbolerna variera från 0 till 63, och symbolbredden kan tas till 6 bitar, med koder som börjar på 7 bitar. Faktum är att symbolbredden inte behöver matcha palettstorleken: så länge som de avkodade värdena alltid är mindre än antalet färger i paletten, kan symbolerna vara vilken bredd som helst från 2 till 8, och palettstorleken vilken potens av 2 från 2 till 256. Till exempel, om endast de fyra första färgerna (värdena 0 till 3) i paletten används, kan symbolerna anses vara 2 bitar breda med koder som börjar på 3 bitar.
Omvänt kan symbolbredden sättas till 8, även om endast värdena 0 och 1 används; dessa data skulle bara kräva en tvåfärgstabell. Även om det inte skulle vara någon mening med att koda filen på det sättet, händer något liknande vanligtvis för tvåfärgade bilder: den minsta symbolbredden är 2, även om endast värdena 0 och 1 används.
Kodtabellen innehåller initialt koder som är en bit längre än symbolstorleken för att kunna rymma de två specialkoderna clr och end samt koder för strängar som läggs till under processen. När tabellen är full ökar kodlängden för att ge plats för fler strängar, upp till en maximal kod 4095 = FFF(hex). När avkodaren bygger sin tabell spårar den dessa ökningar i kodlängd och den kan packa upp inkommande bytes därefter.
Okomprimerad GIF
|
GIF-kodningsprocessen kan modifieras för att skapa en fil utan LZW-komprimering som fortfarande kan visas som en GIF-bild. Denna teknik introducerades ursprungligen som ett sätt att undvika patentintrång. Okomprimerad GIF kan också vara ett användbart mellanformat för en grafikprogrammerare eftersom enskilda pixlar är tillgängliga för läsning eller målning. En okomprimerad GIF-fil kan konverteras till en vanlig GIF-fil helt enkelt genom att skicka den genom en bildredigerare.
Den modifierade kodningsmetoden ignorerar att bygga LZW-tabellen och avger endast rotpalettkoderna och koderna för CLEAR och STOP. Detta ger en enklare kodning (en 1-till-1-överensstämmelse mellan kodvärden och palettkoder) men offrar all komprimering: varje pixel i bilden genererar en utdatakod som indikerar dess färgindex. Vid bearbetning av en okomprimerad GIF kommer en standard GIF-avkodare inte att hindras från att skriva strängar till sin ordbokstabell, men kodbredden får aldrig öka eftersom det utlöser en annan packning av bitar till byte.
Om symbolbredden är n faller koderna med bredd n +1 naturligt in i två block: det nedre blocket med 2 n koder för kodning av enstaka symboler och det övre blocket med 2 n koder som kommer att användas av avkodaren för sekvenser av längd större än en. Av det övre blocket är de två första koderna redan tagna: 2 n för CLEAR och 2 n + 1 för STOP. Avkodaren måste också förhindras från att använda den sista koden i det övre blocket, 2 n +1 − 1 , för när avkodaren fyller den luckan kommer den att öka kodens bredd. I det övre blocket finns alltså 2 n − 3 koder tillgängliga för dekodern som inte kommer att utlösa en ökning av kodbredden. Eftersom avkodaren alltid ligger ett steg efter när det gäller att underhålla tabellen, genererar den inte en tabellpost när den tar emot den första koden från kodaren, utan genererar en för varje efterföljande kod. Således kan kodaren generera 2 n − 2 koder utan att utlösa en ökning av kodbredden. Därför måste kodaren avge extra CLEAR-koder med intervaller på 2 n − 2 koder eller mindre för att få avkodaren att återställa kodningsordlistan. GIF-standarden tillåter att sådana extra CLEAR-koder infogas i bilddata när som helst. Den sammansatta dataströmmen är uppdelad i underblock som vart och ett bär från 1 till 255 byte.
För exempel på 3×5-bilden ovan representerar följande 9-bitarskoder "clear" (100) följt av bildpixlar i skanningsordning och "stopp" (101).
100 028 0FF 0FF 0FF 028 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 101
Efter att ovanstående koder har mappats till byte, skiljer sig den okomprimerade filen från den komprimerade filen så här:
| Byte # (hex) | Hexadecimal | Text eller värde | Menande |
|---|---|---|---|
| 320 | 14 | 20 | 20 byte okomprimerad bilddata följer |
| 321 | 00 51 FC FB F7 0F C5 BF 7F FF FE FD FB F7 EF DF BF 7F 01 01 | ||
| 335 | 00 | 0 | Slut på bilddata |
Exempel på komprimering
Det triviala exemplet på en stor bild av solid färg visar den variabel längd LZW-komprimering som används i GIF-filer.
| Koda | Pixels | Anteckningar | |||
|---|---|---|---|---|---|
| Nej. N i | Värde N i + 256 | Längd (bitar) | Denna kod N i | Ackumulerat N i (N i + 1) / 2 | Relationer som använder N i gäller endast för pixlar i samma färg tills kodningstabellen är full. |
| 0 | 100h | 9 | Rensa kodtabell | ||
| 1 | FFh | 1 | 1 | Överst till vänster pixelfärg vald som det högsta indexet för en palett med 256 färger | |
| 2 | 102h | 2 | 3 | ||
| 3 ⋮ 255 | 103h ⋮ 1FFh | 3 ⋮ 255 | 6 ⋮ 32640 | Senaste 9-bitarskoden | |
| 256 ⋮ 767 | 200h ⋮ 3FFh | 10 | 256 ⋮ 767 | 32896 ⋮ 294528 | Sista 10-bitars koden |
| 768 ⋮ 1791 | 400h ⋮ 7FFh | 11 | 768 ⋮ 1791 | 295296 ⋮ 1604736 | Senaste 11-bitars koden |
| 1792 ⋮ 3839 | 800h ⋮ FFFh | 12 | 1792 ⋮ 3839 | 1606528 ⋮ 7370880 | Kodtabellen full |
| ⋮ | FFFh | 3839 | Den maximala koden kan upprepas för fler pixlar i samma färg. 2559 + 1/3 × Total datakomprimering närmar sig 8/12 asymptotiskt 3839 = | ||
| 101h | Slut på bilddata | ||||
Kodvärdena som visas packas i byte som sedan packas i block på upp till 255 byte. Ett block med bilddata börjar med en byte som deklarerar antalet byte som ska följas. Det sista datablocket för en bild markeras med en blocklängd noll byte.
Interlacing
GIF-specifikationen tillåter varje bild på den logiska skärmen i en GIF-fil att ange att den är sammanflätad; dvs att ordningen på rasterlinjerna i dess datablock inte är sekventiell. Detta möjliggör en partiell visning av bilden som kan kännas igen innan hela bilden målas.
En sammanflätad bild är uppdelad uppifrån och ned i remsor 8 pixlar höga, och bildraderna presenteras i följande ordning:
- Pass 1: Rad 0 (den översta raden) från varje remsa.
- Pass 2: Rad 4 från varje remsa.
- Pass 3: Linje 2 och 6 från varje remsa.
- Pass 4: Rad 1, 3, 5 och 7 från varje remsa.
Pixlarna inom varje linje är inte sammanflätade, utan presenteras i följd från vänster till höger. Som med icke-interlaced bilder, finns det ingen brytning mellan data för en rad och data för nästa. Indikatorn på att en bild är sammanflätad är en bit inställd i motsvarande bildbeskrivningsblock.
Animerad GIF
Även om GIF inte utformades som ett animationsmedium, föreslog dess förmåga att lagra flera bilder i en fil naturligtvis att man använde formatet för att lagra ramarna i en animationssekvens. För att underlätta visningen av animationer lade GIF89a-specifikationen till Graphic Control Extension (GCE), som gör att bilderna (ramarna) i filen kan målas med tidsfördröjningar, vilket bildar ett videoklipp . Varje bildruta i en animerad GIF introduceras av sin egen GCE som anger tidsfördröjningen att vänta efter att ramen har ritats. Global information i början av filen gäller som standard för alla ramar. Datan är strömorienterad, så filförskjutningen vid starten av varje GCE beror på längden på föregående data. Inom varje ram är den LZW-kodade bilddatan anordnad i underblock på upp till 255 byte; storleken på varje delblock deklareras av byten som föregår det.
Som standard visar en animering sekvensen av bildrutor endast en gång, och slutar när den sista bildrutan visas. För att möjliggöra en loop av en animation Netscape på 1990-talet applikationsextensionsblocket (avsett att tillåta leverantörer att lägga till applikationsspecifik information till GIF-filen) för att implementera Netscape Application Block (NAB). Detta block, placerat omedelbart före sekvensen av animerade bildrutor, anger antalet gånger sekvensen av bildrutor ska spelas upp (1 till 65535 gånger) eller att den ska upprepas kontinuerligt (noll anger loop för alltid). Stöd för dessa återkommande animationer dök först upp i Netscape Navigator version 2.0 och spreds sedan till andra webbläsare. De flesta webbläsare känner nu igen och stöder NAB, även om det inte är strikt en del av GIF89a-specifikationen.
Följande exempel visar strukturen för animationsfilen Rotating earth (large).gif som visas (som en miniatyrbild) i artikelns infobox.
| Byte # (hex) | Hexadecimal | Text eller värde | Menande |
|---|---|---|---|
| 0 | 47 49 46 38 39 61 | GIF89a | Logisk skärmbeskrivning |
| 6 | 90 01 | 400 | Bredd i pixlar |
| 8 | 90 01 | 400 | Höjd i pixlar |
| A | F7 | GCT följer för 256 färger med upplösning 3 × 8 bitar/primär | |
| B | 00 | 0 | Bakgrundsfärg: #000000, svart |
| C | 00 | 0 | Standardbildförhållande för pixlar, 0:0 |
| D | 00 | Global färgtabell | |
| ⋮ | |||
| 30D | 21 FF | Applikationsförlängning | |
| 30F | 0B | 11 | Storlek på block inklusive programnamn och verifieringsbyte (alltid 11) |
| 310 | 4E 45 54 53 43 41 50 45 32 2E 30 | NETSCAPE2.0 | 8-byte applikationsnamn plus 3 verifieringsbyte |
| 31B | 03 | 3 | Antal byte i följande underblock |
| 31C | 01 | 1 | Index för det aktuella dataunderblocket (alltid 1 för NETSCAPE-blocket) |
| 31D | F F F F | 65535 | Osignerat antal repetitioner |
| 31F | 00 | Slutet på underblockskedjan för applikationsförlängningsblocket | |
| 320 | 21 F9 | Grafisk kontrollförlängning för ram #1 | |
| 322 | 04 | 4 | Antal byte (4) i det aktuella underblocket |
| 323 | 04 |
000..... ...001.. ......0. .......0 |
Reserverade, 5 lägre bitar är bitfält Avfallsmetod 1: kassera inte Ingen användarinmatning Transparent färg, 0 betyder ej given |
| 324 | 09 00 | 9 | Ramfördröjning: 0,09 sekunders fördröjning innan nästa ram målas |
| 326 | FF | Transparent färgindex (oanvänd i denna ram) | |
| 327 | 00 | Slut på underblockskedja för grafisk kontrollförlängningsblock | |
| 328 | 2C | Bildbeskrivning av ram #1 | |
| 329 | 00 00 00 00 | (0, 0) | Bildens nordvästra hörnposition på logisk skärm: (0, 0) |
| 32D | 90 01 90 01 | (400, 400) | Ramens bredd och höjd: 400 × 400 pixlar |
| 331 | 00 | 0 | Lokal färgtabell: 0 betyder ingen & ingen sammanflätning |
| 332 | 08 | 8 | Minsta LZW-kodstorlek för bilddata för bildruta #1 |
| 333 | FF | 255 | Antal byte av LZW-bilddata i följande underblock: 255 byte |
| 334 | ... | <image data> | Bilddata, 255 byte |
| 433 | FF | 255 | Antal byte av LZW-bilddata i följande underblock, 255 byte |
| 434 | ... | <image data> | Bilddata, 255 byte |
| ⋮ | Upprepa för nästa block | ||
| 92C0 | 00 | Slutet på underblockskedjan för denna ram | |
| 92C1 | 21 F9 | Grafisk kontrollförlängning för ram #2 | |
| ⋮ | Upprepa för nästa bildrutor | ||
| EDABD | 21 F9 | Grafisk kontrollförlängning för ram #44 | |
| ⋮ | Bildinformation och data för ram #44 | ||
| F48F5 | 3B | Trailer: Sista byten i filen, signalerar EOF |
Animationsfördröjningen för varje bildruta anges i GCE i hundradelar av en sekund. Viss dataekonomi är möjlig där en bildruta bara behöver skriva om en del av bildpunkterna på skärmen, eftersom bildbeskrivningen kan definiera en mindre rektangel som ska skannas om istället för hela bilden. Webbläsare eller andra skärmar som inte stöder animerade GIF-filer visar vanligtvis bara den första bildrutan.
Storleken och färgkvaliteten på animerade GIF-filer kan variera avsevärt beroende på vilket program som används för att skapa dem. Strategier för att minimera filstorleken inkluderar att använda en gemensam global färgtabell för alla bildrutor (snarare än en komplett lokal färgtabell för varje bildruta) och att minimera antalet pixlar som täcks av på varandra följande bildrutor (så att endast pixlarna som ändras från en bildruta till nästa ingår i den senare ramen). Mer avancerade tekniker innebär att modifiera färgsekvenser för att bättre matcha den befintliga LZW-ordboken, en form av förlustkomprimering . Att helt enkelt packa en serie oberoende rambilder till en sammansatt animering tenderar att ge stora filstorlekar. Verktyg är tillgängliga för att minimera filstorleken givet en befintlig GIF.
Metadata
Metadata kan lagras i GIF-filer som ett kommentarblock, ett vanlig textblock eller ett programspecifikt programtilläggsblock. Flera grafikredigerare använder inofficiella programtilläggsblock för att inkludera data som används för att generera bilden, så att den kan återställas för vidare redigering.
Alla dessa metoder kräver tekniskt att metadata delas upp i underblock så att applikationer kan navigera i metadatablocket utan att känna till dess interna struktur.
Metadatastandarden Extensible Metadata Platform (XMP) introducerade ett inofficiellt men nu utbrett "XMP Data"-programtilläggsblock för att inkludera XMP-data i GIF-filer. Eftersom XMP-data är kodad med UTF-8 utan NUL-tecken, finns det inga 0 byte i datan. Istället för att dela upp data i formella delblock, avslutas förlängningsblocket med en "magisk trailer" som dirigerar alla program som behandlar data som delblock till en slutlig 0 byte som avslutar delblockkedjan.
Unisys och LZW patenttillämpning
1977 och 1978 publicerade Jacob Ziv och Abraham Lempel ett par artiklar om en ny klass av förlustfria datakomprimeringsalgoritmer, nu gemensamt kallade LZ77 och LZ78 . 1983 Terry Welch en snabb variant av LZ78 som fick namnet Lempel–Ziv–Welch (LZW).
Welch lämnade in en patentansökan för LZW-metoden i juni 1983. Det resulterande patentet, US4558302, beviljat i december 1985, tilldelades Sperry Corporation som därefter slogs samman med Burroughs Corporation 1986 och bildade Unisys . Ytterligare patent erhölls i Storbritannien, Frankrike, Tyskland, Italien, Japan och Kanada.
Utöver ovanstående patent innehåller Welchs patent från 1983 även hänvisningar till flera andra patent som påverkade det, inklusive:
- två japanska patent från 1980 från NEC :s Jun Kanatsu,
- US patent 4 021 782 (1974) från John S. Hoerning,
- US patent 4 366 551 (1977) från Klaus E. Holtz och
- ett tyskt patent från 1981 från Karl Eckhart Heinz.
I juni 1984 publicerades en artikel av Welch i tidningen IEEE som offentligt beskrev LZW-tekniken för första gången. LZW blev en populär datakomprimeringsteknik och när patentet beviljades ingick Unisys licensavtal med över hundra företag.
Populariteten hos LZW fick CompuServe att välja den som komprimeringsteknik för deras version av GIF, utvecklad 1987. Vid den tiden kände CompuServe inte till patentet. Unisys blev medveten om att versionen av GIF använde LZW-komprimeringstekniken och inledde licensförhandlingar med CompuServe i januari 1993. Det efterföljande avtalet tillkännagavs den 24 december 1994. Unisys uppgav att de förväntade sig att alla stora kommersiella onlineinformationstjänstföretag anställde LZW-patent för att licensiera teknologin från Unisys till en rimlig takt, men att de inte skulle kräva licenser, eller avgifter som ska betalas, för icke-kommersiella, icke-vinstdrivande GIF-baserade applikationer, inklusive de för användning på onlinetjänsterna .
Efter detta tillkännagivande kom det ett omfattande fördömande av CompuServe och Unisys, och många mjukvaruutvecklare hotade att sluta använda GIF. PNG -formatet (se nedan) utvecklades 1995 som en avsedd ersättning. Det visade sig dock vara svårt att få stöd från tillverkare av webbläsare och annan programvara för PNG-formatet och det var inte möjligt att ersätta GIF, även om PNG gradvis har ökat i popularitet. Därför utvecklades GIF-variationer utan LZW-komprimering. Till exempel libungif-biblioteket, baserat på Eric S. Raymonds giflib, tillåter skapande av GIF:er som följde dataformatet men undvek komprimeringsfunktionerna, vilket undviker användningen av Unisys LZW-patent. En från Dr. Dobb från 2001 beskrev ett sätt att uppnå LZW-kompatibel kodning utan att göra intrång i dess patent.
I augusti 1999 ändrade Unisys detaljerna i sin licensieringspraxis och tillkännagav möjligheten för ägare av vissa icke-kommersiella och privata webbplatser att erhålla licenser mot betalning av en engångslicensavgift på $5000 eller $7500. Sådana licenser krävdes inte för webbplatsägare eller andra GIF-användare som hade använt licensierad programvara för att skapa GIF:er. Ändå utsattes Unisys för tusentals onlineattacker och kränkande e-postmeddelanden från användare som trodde att de skulle debiteras $5 000 eller stämmas för att de använde GIF-filer på deras webbplatser. Trots att Unisys gav gratislicenser till hundratals ideella organisationer, skolor och regeringar kunde Unisys inte generera någon bra publicitet och fortsatte att fördömas av individer och organisationer som League for Programming Freedom som startade kampanjen "Burn All GIFs " år 1999.
Förenta staternas LZW-patent gick ut den 20 juni 2003. Motpartspatenten i Storbritannien, Frankrike, Tyskland och Italien gick ut den 18 juni 2004, de japanska patenten gick ut den 20 juni 2004 och det kanadensiska patentet gick ut den 7 juli 2004. , medan Unisys har ytterligare patent och patentansökningar relaterade till förbättringar av LZW-tekniken, har LZW självt (och följaktligen GIF) varit gratis att använda sedan juli 2004.
Alternativ
PNG
Portable Network Graphics (PNG) designades som en ersättning för GIF för att undvika intrång i Unisys patent på LZW-komprimeringstekniken. PNG erbjuder bättre komprimering och fler funktioner än GIF, animering är det enda betydande undantaget. PNG är mer lämpligt än GIF i de fall där sanna färgbilder och alfatransparens krävs.
Även om stödet för PNG-format kom långsamt, stöder nya webbläsare PNG. Äldre versioner av Internet Explorer stöder inte alla funktioner i PNG. Versioner 6 och tidigare stöder inte alfakanaltransparens utan att använda Microsoft-specifika HTML-tillägg. Gammakorrigering av PNG-bilder stöddes inte före version 8, och visningen av dessa bilder i tidigare versioner kan ha fel nyans.
För identiska 8-bitars (eller lägre) bilddata är PNG-filer vanligtvis mindre än motsvarande GIF-filer, på grund av de mer effektiva komprimeringsteknikerna som används vid PNG-kodning. Fullständigt stöd för GIF kompliceras främst av den komplexa arbetsytan den tillåter, även om det är detta som möjliggör de kompakta animeringsfunktionerna.
Animationsformat
Videor löser många problem som GIF presenterar genom vanlig användning på webben. De inkluderar drastiskt mindre filstorlekar , möjligheten att överträffa 8-bitars färgbegränsningen och bättre ramhantering och komprimering genom codecs . Praktiskt taget universellt stöd för GIF-formatet i webbläsare och avsaknad av officiellt stöd för video i HTML -standarden gjorde att GIF blev framträdande i syfte att visa korta videoliknande filer på webben.
- MNG ("Multiple-image Network Graphics") utvecklades ursprungligen som en PNG-baserad lösning för animationer. MNG nådde version 1.0 2001, men få applikationer stöder det.
- APNG ("Animerad bärbar nätverksgrafik") föreslogs av Mozilla 2006. APNG är en förlängning av PNG-formatet som ett alternativ till MNG-formatet. APNG stöds av de flesta webbläsare från och med 2019. APNG ger möjligheten att animera PNG-filer, samtidigt som bakåtkompatibiliteten bibehålls i avkodare som inte kan förstå animationsbiten (till skillnad från MNG). Äldre avkodare återger helt enkelt den första bildrutan i animationen.
- PNG-gruppen avvisade officiellt APNG som en officiell förlängning den 20 april 2007.
- Det har kommit flera efterföljande förslag på ett enkelt animerat grafikformat baserat på PNG med flera olika tillvägagångssätt. Ändå är APNG fortfarande under utveckling av Mozilla och stöds i Firefox 3.0 medan MNG-stöd togs bort. APNG stöds för närvarande av alla större webbläsare inklusive Chrome (sedan version 59.0), Opera, Firefox och Edge.
- Inbäddade Adobe Flash- objekt och
- MPEG- filer användes på vissa webbplatser för att visa enkel video, men krävde användning av ett extra webbläsarplugin.
- Andra alternativ för webbanimering inkluderar servering av individuella ramar med AJAX , eller
- animera SVG ("Skalbar vektorgrafik")-bilder med JavaScript eller SMIL ("Synchronized Multimedia Integration Language"). [ citat behövs ]
- Med introduktionen av brett stöd för HTML5-videotaggen (
<video>) i de flesta webbläsare, använder vissa webbplatser en loopad version av videotaggen som genereras av JavaScript- funktioner. Detta ger utseendet av en GIF, men med storleken och hastighetsfördelarna med komprimerad video.
- Anmärkningsvärda exempel är Gfycat och Imgur och deras GIFV-metaformat, som egentligen är en videotagg som spelar en loopad MP4- eller WebM- komprimerad video.
- HEIF ("High Efficiency Image File Format") är ett bildfilformat, färdigställt 2015, som använder en diskret cosinustransform (DCT) förlustkompressionsalgoritm baserad på HEVC -videoformatet och relaterat till JPEG -bildformatet. Till skillnad från JPEG stöder HEIF animering.
- Jämfört med GIF-formatet, som saknar DCT-komprimering, tillåter HEIF betydligt effektivare komprimering. HEIF lagrar mer information och producerar animerade bilder av högre kvalitet till en liten bråkdel av en motsvarande GIF-storlek.
- VP9 stöder endast alfakompositering med 4:2:0 chroma subsampling i YUV A420 pixelformat, vilket kan vara olämpligt för GIF:er som kombinerar transparens med rastrerad vektorgrafik med fina färgdetaljer.
Används
I april 2014 lade 4chan till stöd för tysta WebM- videor som är mindre än 3 MB i storlek och 2 minuter långa, och i oktober 2014 började Imgur konvertera alla GIF-filer som laddats upp till webbplatsen till video och ge länken till HTML-spelaren utseendet på en faktisk fil med filtillägget .gifv .
I januari 2016 började Telegram koda om alla GIF-filer till MPEG-4 -videor som "kräver upp till 95 % mindre diskutrymme för samma bildkvalitet."
Se även
- AVIF
- Cinemagraph , ett delvis animerat fotografi ofta i GIF
- Rensa GIF , en teknik som används för att kontrollera innehållsåtkomst
- Jämförelse av grafikfilformat
- GIF-konst , en form av digital konst associerad med GIF
- GIFBuilder , tidigt animerat GIF- skapande program
- GNU plotutils (stöder pseudo-GIF, som använder körlängdskodning snarare än LZW)
- Microsoft GIF Animator , historiskt program för att skapa enkla animerade GIF-filer
- Programvarupatent
externa länkar
- GIFLIB-projektet
- spec-gif89a.txt GIF 89a-specifikation på w3.org
- GIF 89a-specifikationen omformaterad till HTML
- LZW och GIF förklaras
- Animerade GIF :er: en sex minuters dokumentär producerad av Off Book (webbserie)
- GifCities (GeoCities Animated GIF-sökmotor)
