Hlavní navigace

GIF: animace a konkurence

31. 8. 2006
Doba čtení: 14 minut

Sdílet

V závěrečné části miniseriálu věnovaného grafickému formátu GIF si ukážeme, jakým způsobem se může v GIFu pracovat se sekvencemi snímků a s animacemi. Na závěr si řekneme, ve kterých situacích je vhodné použít grafický formát GIF a kdy je naopak vhodnější využít možnosti dalších "konkurenčních" grafických formátů.

Obsah

1. Interaktivní slideshow uložená v jednom souboru typu GIF
2. Animace
3. Anatomie animovaného GIFu
4. Porovnání možností GIFu s dalšími grafickými formáty
5. GIF vs PNG
6. GIF vs JPEG
7. GIF vs video formáty
8. Slovo závěrem

1. Interaktivní slideshow uložená v jednom souboru typu GIF

Poměrně neznámou a prakticky nepoužívanou funkcionalitou, kterou grafický formát GIF nabízí, je možnost uložení interaktivní slideshow (více relativně samostatných obrázků) v jednom souboru typu GIF. V rozšiřujícím grafickém řídicím bloku (Graphic Control Extension), který se může vyskytovat před každým rámcem, je možné nastavením jednoho bitu specifikovat, zda se má prohlížecí program v daném místě zpracování zastavit a čekat na uživatelský vstup (stisk klávesy, klik myší apod.).

V případě, že je současně nastavená i doba pauzy mezi zobrazením jednotlivých rámců (viz animace popsaná dále), bude zobrazování obrázku pokračovat až v případě, že uživatel stiskl klávesu či klikl myší nebo uplynul zadaný čas zpoždění mezi snímky. Pokud není zpoždění mezi snímky zadané, měl by prohlížecí program čekat pouze na uživatelský vstup bez provádění animace. V dokumentaci se dokonce píše, že by uživatel o možnosti pokračovat v zobrazování slideshow měl být informován kvikotem, tj. zasláním znaku 0×07 (BEL) na standardní výstup :-)

Vzhledem k tomu, že interaktivní pauzu mezi rámci podporuje pouze minimum prohlížecích programů, není tato funkcionalita více používána, což je poněkud škoda, protože jen velmi málo rozšířených souborových formátů podporuje takto jednoduše vytvořené slideshow a na webu se musí podobné funkce doprogramovat nebo (v horším případě) nahradit sadou odkazů na další obrázky v sekvenci, což však způsobuje problémy s jejich ukládáním do lokálních souborů. Na dnešním prvním ilustračním obrázku je zobrazen GIF obsahující deset rámců, které by měly být postupně zobrazovány až po uživatelském vstupu. Jen velmi málo programů však GIF zobrazí tímto způsobem – ostatně se můžete přesvědčit sami.

gif4_1

Obrázek 1: GIF s deseti rámci, které by měly být zobrazeny jako interaktivní slideshow

2. Animace

Ke stále trvající popularitě grafického formátu GIF nepochybně patří i jeho schopnost zaznamenat jednoduché animace. Pokud se podíváme do specifikace GIFu 89a, zjistíme, že se do rozšiřujícího grafického řídicího bloku (GCE – Graphic Control Extension) mohou zapsat i informace o délce prodlevy před zobrazením dalšího rámce. Tato délka je zadávána v setinách sekundy, a vzhledem k tomu, že je údaj zapsaný ve dvou bytech, je minimální prodleva rovna 1/100 s a maximální prodleva 655,36 s, což je zhruba 11 minut.

Některé animace vytvářené „na efekt“ používají spíše kratší časování snímků (například 100 ms), profesionálové se však nebrání i delším prodlevám (2 s apod.), což někdy činí animace mnohem zajímavějšími a přitom méně obtěžujícími, nehledě na menší vytížení přenosového pásma. Mimochodem, oněch zmíněných 100 ms je v některých animačních programech nastaveno jako implicitní hodnota a pravděpodobně z toho důvodu je mnoho animací časováno právě tímto zpožděním.

Ovšem samotná prodleva mezi zobrazením jednotlivých rámců postačuje pouze pro tvorbu animace, která proběhne jednou a poté se již neopakuje – ve specifikacích se nic o smyčce v animaci nemluví. Zde však přichází na řadu další užitečná vlastnost GIFů, která spočívá v možnosti zápisu přidaných informací od „třetích stran“. Prohlížeče buď těmto přidaným informacím rozumí (a zpracují je), nebo je ignorují.

To je ve formátu GIF zajištěno tím způsobem, že každá přidaná informace obsahuje hlavičku s její identifikací a délkou. V případě animací se jedná o rozšíření zavedené firmou Netscape pro její (kdysi) slavný webový prohlížeč Netscape Navigator. V tomto rozšíření je vlastně pouze specifikováno, kolikrát se má animace opakovat a popř. zda se má opakovat neustále (v prohlížečích lze většinou animaci GIFů zastavit klávesou Esc, o dalších „dynamických“ efektech používaných na Webu to však neplatí – proto je také GIF jediným animačním formátem, který v prohlížeči povoluji).

gif4_2

Obrázek 2: GIF s deseti rámci zobrazovanými jako animace (kromě toho je v souboru přítomen i rozšiřující textový blok s poznámkou a programu, který GIF vytvořil; všimněte si potenciálně citlivých informací)

Rozšíření firmy Netscape v GIFu má délku 19 bytů (z toho však pouze dva je možné měnit) a následující tvar:

Ofset (dex) Byte či sekvence (hex) Význam sekvence
00 21 označení rozšiřujícího bloku v souboru GIF
01 ff rozšiřující blok aplikace (tzn. není přímo stanoven specifikací)
02 0b délka bloku bez dat (vždy nastavena na 11 bytů)
03 4e 45 54 53 43 41 50 45 řetězec ‚NETSCAPE‘ – jednoznačná identifikace bloku
11 32 2e 30 řetězec ‚2.0‘ – autentizační kód
14 03 délka datové části bloku (3 byty)
15 01 konstanta
16 LO HI celkový počet opakování animace (0-nekonečná smyčka)
18 00 ukončovací značka rozšiřujícího bloku

Jak je z předchozí tabulky patrné, jediné dva byty, které se v tomto rozšiřujícím bloku mohou měnit, jsou byty nesoucí informaci o celkovém počtu opakování animace. V případě zadání nulové hodnoty se jedná o nekonečnou smyčku (tu mají programátoři „moderních“ aplikací ve stále větší oblibě :-).

3. Anatomie animovaného GIFu

Ukažme si nyní, jak vypadají vnitřnosti jednoduchého animovaného GIFu. Nejdříve si uvedeme tvar minimálního souboru s animací obsahující jeden blikající pixel a potom ještě poněkud větší animaci s obrázkem o rozlišení 16×16 pixelů.

Popis nejprve začneme s opravdu minimálním animovaným GIFem. Ten obsahuje pouhé dva rámce, kde každý rámec představuje jeden snímek. Rámce mají rozlišení 1×1 pixel, stejné rozlišení má i celý logický obrázek. Pokud máte dobrý monitor, můžete si tento animovaný GIF prohlédnout na třetím obrázku:

gif4_3

Obrázek 3: Minianimace se dvěma rámci o rozlišení 1×1 pixel

Soubor s obrázkem má délku pouhých 85 bytů. Původně jsem obrázek vytvářel v GIMPu (dvě vrstvy se před uložením po dotazu převedou na animaci), tento program však – pravděpodobně kvůli podpoře průhlednosti – uložil barvovou paletu se čtyřmi barvami, proto jsem provedl ruční úpravu do konečné podoby pomocí hexaeditoru (pozor na to, že některé hexaeditory neumí soubor zkrátit ani prodloužit). Oněch 85 bytů má následující podobu:

0000000: 47 49 46 38 39 61 01 00 01 00 80 00 00 ff ff ff
0000010: 00 00 00 21 ff 0b 4e 45 54 53 43 41 50 45 32 2e
0000020: 30 03 01 00 00 00 21 f9 04 00 0a 00 ff 00 2c 00
0000030: 00 00 00 01 00 01 00 00 02 02 4c 01 00 21 f9 04
0000040: 01 0a 00 01 00 2c 00 00 00 00 01 00 01 00 00 02
0000050: 02 44 01 00 3b 

Význam je následující:

Offset (dec) Byte či sekvence (hex) Význam bytové sekvence
Hlavička souboru typu GIF
00 47 49 46 ASCII řetězec ‚GIF‘ – „magické“ číslo souboru (signatura GIF)
03 38 39 61 ASCII řetězec ‚89a‘ – verze GIFu
Informace o logické obrazovce
06 01 00 šířka logické obrazovky: jeden pixel
08 01 00 výška logické obrazovky: jeden pixel
10 80 bitové pole: povolení globální barvové palety
11 00 index barvy pozadí (my ho nevyužijeme)
12 00 poměr výšky a šířky pixelu: 1÷1
13 ff ff ff první barva v paletě: čistě bílá
16 00 00 00 druhá barva v paletě: zcela černá
Rozšiřující blok Netscape
19 21 označení rozšiřujícího bloku v souboru GIF
20 ff rozšiřující blok aplikace (tzn. není přímo stanoven specifikací)
21 0b délka bloku bez dat (vždy nastavena na 11 bytů)
29 4e 45 54 53 43 41 50 45 řetězec ‚NETSCAPE‘ – identifikace bloku
32 32 2e 30 řetězec ‚2.0‘ – autentizační kód
33 03 délka datové části bloku (3 byty)
34 01 konstanta
36 00 00 celkový počet opakování animace (0-nekonečná smyčka)
37 00 ukončovací značka rozšiřujícího bloku
První snímek animace
38 21 označení rozšiřujícího bloku v souboru GIF
39 f9 identifikace rozšiřujícího bloku jako GCE
40 04 délka GCE (vždy nastavena na hodnotu 4)
41 00 bitové pole s příznaky
42 0a čas zpoždění zobrazení následujícího rámce (100ms)
43 00 vyšší byte hodnoty zpoždění (specifikováno v setinách sekundy)
44 ff index barvy, která bude považována za průhlednou (transparentní)
45 00 ukončení rozšiřujícího bloku
46 2c značka začátku prvního rámce
47 00 00 x-ová pozice levého okraje rámce: nultý sloupec
49 00 00 y-ová pozice horního okraje rámce: nultý řádek
51 01 00 šířka rámce: jeden pixel
53 01 00 výška rámce: jeden pixel
55 00 bitové pole s příznaky: bez barvové palety, bez prokládání a animace
56 02 počáteční velikost LZW kódu v bitech
57 02 velikost bloku zakódovaného pomocí LZW-1
58 4c 01 zakódovaná data rámce (jeden pixel s barvou číslo 1)
60 00 ukončovací znak bloku zakódovaného pomocí LWZ
Druhý snímek animace
61 21 označení rozšiřujícího bloku v souboru GIF
62 f9 identifikace rozšiřujícího bloku jako GCE
63 04 délka GCE (vždy nastavena na hodnotu 4)
64 01 bitové pole s příznaky
65 0a čas zpoždění zobrazení následujícího rámce (100ms)
66 00 vyšší byte hodnoty zpoždění (specifikováno v setinách sekundy)
67 01 index barvy, která bude považována za průhlednou (transparentní)
68 00 ukončení rozšiřujícího bloku
69 2c značka začátku druhého rámce
70 00 00 x-ová pozice levého okraje rámce: nultý sloupec
72 00 00 y-ová pozice horního okraje rámce: nultý řádek
74 01 00 šířka rámce: jeden pixel
76 01 00 výška rámce: jeden pixel
78 00 bitové pole: bez barvové palety, bez prokládání a animace
79 02 počáteční velikost LZW kódu v bitech
80 02 velikost bloku zakódovaného pomocí LZW-1
81 44 01 zakódovaná data rámce (jeden pixel s barvou číslo 0)
83 00 ukončovací znak bloku zakódovaného pomocí LWZ
Finito
84 3b ukončovací znak GIF souboru: ASCII znak ‚;‘

Jak je z předchozí tabulky patrné, jedná se sice o poměrně složitý kód, ale význam všech bytů by nám měl být (po přečtení předchozí části seriálu a výše uvedených kapitol) zřejmý.

Už bez podrobnějšího popisu ještě uvedu druhý animovaný GIF, který má tentokrát dva rámce o rozlišení 16×16 pixelů. Mezi snímky je nastavena sekundová prodleva:

gif4_4

Obrázek 4: Animace se dvěma rámci a prodlevou 1 sec.

Kód obrázku je jen o málo větší – místo 85 bytů je to 115 bytů, a to i s barvovou paletou o čtyřech barvách (tak obrázek vygeneroval GIMP), i když jsou použity pouze dvě barvy. Ve skutečnosti by šlo velikost obrázku snížit na 109 bytů (2 barvy v paletě=3×2 byty):

0000000: 47 49 46 38 39 61 10 00 10 00 a1 02 00 c0 44 28
0000010: 28 c0 a2 ff ff ff ff ff ff 21 ff 0b 4e 45 54 53
0000020: 43 41 50 45 32 2e 30 03 01 00 00 00 21 f9 04 00
0000030: 64 00 ff 00 2c 00 00 00 00 10 00 10 00 00 02 0e
0000040: 84 8f a9 cb ed 0f a3 9c b4 da 8b b3 3e 05 00 21
0000050: f9 04 01 64 00 00 00 2c 00 00 00 00 10 00 10 00
0000060: 00 02 0e 8c 8f a9 cb ed 0f a3 9c b4 da 8b b3 3e
0000070: 05 00 3b 

Na pátém obrázku je ukázána animace, která se má opakovat pouze pětkrát. V rozšiřujícím bloku Netscape je místo nulového počtu opakování (to značí nekonečnou smyčku) uložena hodnota 5, bytově 0×05 0×00. Tuto hodnotu by měly prohlížeče načíst a dodržet, mnohdy se to však neděje a animace probíhá neustále dokola – zde se jedná o chybu prohlížečů, které ignorují nastavení uvedená v bloku Netscape.

gif4_5

Obrázek 5: Animace se dvěma rámci a prodlevou 1 sec., která se má opakovat pouze pětkrát

Bytový rozbor pátého obrázku je následující (zvýrazněny hvězdičkou jsou ty bytové hodnoty, které způsobují opakování animace 5×):

0000000: 47 49 46 38 39 61 10 00 10 00 a1 02 00 c0 44 28
0000010: 28 c0 a2 ff ff ff ff ff ff 21 ff 0b 4e 45 54 53
0000020: 43 41 50 45 32 2e 30 03 01*05*00*00 21 f9 04 00
0000030: 64 00 ff 00 2c 00 00 00 00 10 00 10 00 00 02 0e
0000040: 84 8f a9 cb ed 0f a3 9c b4 da 8b b3 3e 05 00 21
0000050: f9 04 01 64 00 00 00 2c 00 00 00 00 10 00 10 00
0000060: 00 02 0e 8c 8f a9 cb ed 0f a3 9c b4 da 8b b3 3e
0000070: 05 00 3b 

4. Porovnání možností GIFu s dalšími grafickými formáty

V mnoha diskusích, probíhajících zejména v době vymáhání poplatků za patenty na algoritmus LZW, se grafický formát GIF porovnává se svými (mnohdy pouze zdánlivými) konkurenty. Pojďme si nyní říci společné znaky a rozdíly mezi GIFem, PNG, JPEG a formáty pro video.

5. GIF vs PNG

Pravděpodobně nejčastěji bývá grafický formát GIF porovnáván s grafickým formátem PNG. Je to ostatně logické, protože PNG byl zamýšlen jako přímý následovník GIFu. Z uživatelského hlediska je zřejmé, že PNG nabízí některé vlastnosti, které GIF nemá a ani nebude mít – zejména bezproblémovou podporu pro truecolor obrázky. Ty, jak víme z předcházejících částí seriálu, lze uložit i do GIFů, ale prohlížeče s nimi mají velké problémy, především kvůli nerespektování specifikace a dávání přednosti vzájemné kompatibilitě.

PNG má dále podporu pro plný alfa kanál (osmibitovou a vícebitovou průhlednost), zatímco GIF zvládá pouze jednobitovou průhlednost. Další výhody PNG jsou již méně patrné, ale pro mnohé uživatele (zejména profesionální grafiky, ale i lékaře) důležité – podpora více bitů na barvový kanál než obligátních osm a možnost uložení barového profilu zařízení, které PNG vytvořilo.

Proti PNG mluví pouze tři – a z dlouhodobého hlediska dokonce jen dvě – nevýhody:

  1. Nedostatečná podpora alfa kanálu a vícebitové barvové hloubky (>32 bpp) v některých prohlížečích (snad se v tomto ohledu blýská na lepší časy).
  2. Některé menší obrázky, například ikony, jsou při uložení do PNG větší, než obdobný obrázek uložený v GIFu – viz ilustrační obrázky 6–10. Je to způsobeno především poněkud rozsáhlejšími hlavičkami PNG, které však na druhou stranu představují pravděpodobně to nejlepší, čeho je možné v binárním formátu dosáhnout.
  3. PNG nepodporuje rámce, animace ani slideshow. Zde tkví asi největší příčina, proč není formát GIF již plně nahrazen grafickým formátem PNG (absence animací v PNG tkví v tom, že bylo vytvořeno dříve než rozšíření Netscape pro GIFy). Sice existuje alternativa ve formě MNG, ale ta není příliš známá ani rozšířená, takže se tvůrci grafiky (oprávněně) obávají formát MNG plošně nasadit. To ovšem ve smyčce vede ke stále trvající nepodpoře MNG v prohlížečích.

gif4_6

Obrázek 6: Originální logo programu Umlet s osmibitovou barvovou hloubkou – 891 bytů

gif4_7

Obrázek 7: Upravené logo programu Umlet se čtyřbitovou barvovou hloubkou – 144 bytů

gif4_8

Obrázek 8: Originální logo programu Umlet s osmibitovou barvovou hloubkou ve formátu PNG – 930 bytů

gif4_9

Obrázek 9: Upravené logo programu Umlet se čtyřbitovou barvovou hloubkou ve formátu PNG – 206 bytů

gif_4_10

Obrázek 10: Upravené logo programu Umlet s 24bitovou barvovou hloubkou ve formátu PNG – 179 bytů (ano – absence palety někdy vede k nižšímu objemu souboru!)

6. GIF vs JPEG

GIF bývá často porovnáván také s grafickým formátem JPEG. Korektnější by bylo hovořit o formátu JFIF, protože JPEG je „pouze“ způsob transformace obrazových map, ale zde se budeme držet „zdomácnělého“ jména JPEG (ostatně i v MIME se používá jména JPEG). Vzájemné porovnávání GIFu a JPEGu je vlastně velmi jednoduché, protože každý formát má zcela odlišné oblasti použití a jejich „sféry zájmu“ by se neměly překrývat. GIF lze reálně použít pro obrázky s 256 barvami, více barev lze uložit pouze problematicky. Na druhou stranu však GIF umožňuje práci s jednobitovou průhledností, animacemi a zejména se jedná a bezeztrátový formát, kde se informace neztrácí ani při zobrazování ani při dalším ukládání.

Naproti tomu je JPEG vybaven ztrátovou komprimací na bázi diskrétní kosinové transformace (DCT – ta však sama o sobě ztrátová není), podporou pro obrázky ve stupních šedi (zde však nedosahuje tak dobrých komprimačních poměrů) a true color obrázky. Důležité je, že JPEG je primárně určen pro „zpracování“ člověkem, tj. pro prohlížení, kdežto možnosti dalšího strojového zpracování již nebyly brány v potaz. Z tohoto důvodu se akceptuje poměrně velká ztráta obrazové informace, a to jak v barevné oblasti, tak i v oblasti prostorové.

První ztráta obrazové informace se odehrává již při převodu z původního barvového prostoru RGB do interního barvového prostoru JPEGu. Další ztrátu (a to citelnější) způsobuje váhování koeficientů vypočtených pomocí DCT. Nejhorší však je, že se ztráta (zkreslení) projevuje i při opakovaném ukládání obrázku, například pro provedení nějaké operace v grafickém editoru.

To JPEG předurčuje k použití pouze jako finálního formátu (určeného například pro webové stránky), nikoli jako zdrojového či dokonce přenosového typu souboru. Pro tyto účely se volí jiné formáty: TIFF, TGA, PNG apod., v oblasti digitální fotografie se mnohdy pracuje i přímo se zdrojovými daty získanými s CCD čipů fotoaparátů (takzvaný „RAW formát“ – i když se ve skutečnosti o žádný formát nejedná).

Pro mnoho aplikací, ve kterých exceluje GIF, se JPEG nehodí, například se jedná o malé ikony, pixel art, obrázky s texty, grafy a pérovkami apod. Na druhou stranu se JPEG velmi často používá při ukládání objemných fotografií, kde se pozitivně projeví velké komprimační poměry a přitom relativně malé zkreslení (alespoň z pohledu lidského oka a mozku).

7. GIF vs video formáty

V některých případech, například při požadavcích na prezentaci krátkého videa na webových stránkách, musí tvůrce stránek porovnat možnosti grafického formátu GIF se souborovými či streamovými formáty určenými pro ukládání videa a zjistit, který formát je pro jeho aplikaci výhodnější. GIF není v žádném případě vhodný pro ukládání ani přehrávání větších animací, protože osmibitová paleta je mnohdy nedostačující a mezisnímková komprimace je obecně nedostatečná, zejména při práci s „reálným“, tj. zašuměným videem. GIF také nepodporuje ukládání zvukových stop ani přesné časování snímků (o tom jsme se mohli předminule přesvědčit při práci s „true color“ GIFy).

Z těchto důvodů se GIF jakožto obecný formát pro videa neprosadil a je tomu tak dobře, protože pro tuto oblast máme k dispozici formáty mnohem lepší a efektivnější. Kde však GIF našel úspěšné nasazení, je oblast krátkých animací pro webové stránky. Většinou se jedná o opravdu krátké animace, ve kterých se počet snímků (=rámců) pohybuje v řádu desítek. Také rozlišení je poměrně malé, mnohdy menší než dnes již historické VHS. Na druhou stranu je však možné v dobrém animačním programu specializovaném na GIFy vytvořit působivé animace, které jsou i málo objemné (dobrých animačních programů je však málo). Také nesmíme zapomenout na to, že GIFy jsou přímo podporovány webovými prohlížeči bez nutnosti instalovat či konfigurovat pluginy pro videa či Flash.

Zdá se, že pouze někteří profesionální weboví grafici se již naučili využívat prakticky všech možností animovaného GIFu, včetně změny barvové palety a změn disposal method při přepisování rámců. Tito grafici jsou však oproti celé webové komunitě v menšině, takže záplava animovaných GIFů na webu je většinou nekvalitní, a to jak po stránce estetické, tak i po stránce technické (místo změn časování snímků se pouze dva či tři snímky opakují za sebou, nejsou prováděny žádné mezirámcové optimalizace GIFu, rámce většinou obsahují 256 barev, i když by jich mnohdy stačilo méně apod.). To však není problém GIFu jako takového, ale způsobu jeho využití. Podobně (vlastně mnohem hůře) dopadl i formát Flash, který klade na grafiky ještě větší nároky na znalosti jeho interního fungování.

CS24 tip temata

8. Slovo závěrem

V této sérii článků jsme si uvedli poučné informace o dopadu softwarových patentů na jeden z nejpoužívanějších grafických formátů dnešní doby. Také jsme si ukázali, jak je možné využít některé vlastnosti GIFu pro vytváření nestandardních efektů – zobrazení více než 256 barev současně, tvorbu slideshow, zvětšení rozlišení obrázku bez vážnějšího dopadu na zvětšení velikosti souborů, zobrazení BSOD na systémech Windows :-) apod. V závěrečné části jsme si (mimo jiné) provedli porovnání grafického formátu GIF s dalšími často používanými grafickými formáty.

Autor článku

Vystudoval VUT FIT a v současné době pracuje na projektech vytvářených v jazycích Python a Go.