Před zhruba dvaceti lety, kdy vznikaly uživatelsky přístupné grafické editory, došlo k obrovské explozi grafických formátů. Podobně jako dnes u kancelářských aplikací, každý výrobce si zavedl vlastní formát, nepřevoditelný na cokoliv jiného. Některé formáty přežily (PCX, BMP, ICO, IMG, TGA) a staly se de facto standardy, některé se alespoň dočkaly převodníku do standardních formátů, jiné zcela zmizely v propadlišti dějin (včetně obrázků v nich uložených). Další byly navrženy jako formáty pro přenos dat, aniž by měly za cíl stát se standardy (PNM, MIFF). Poslední kategorii tvoří ty, jež byly již jako standardy navrženy (GIF, TIFF, JPEG, PNG, MNG, IFF, PostScript).
V prvním dílu jsme se seznámili s knihovnami pro práci s grafickými formáty, dnes se na tyto formáty podíváme podrobněji.
TIFF
Nepsaným standardem pro grafickou práci je TIFF. Původně byl vytvořen firmou Aldus Corporation (nyní již pohlcenou firmou Adobe Systems Incorporated) v roce 1986. Dnes je podporován většinou aplikací a nabízí vše, co k přenosu souborů potřebujeme. Obsahuje podporu všech barevných prostorů, vyšší bitové hloubky, rozlišení a dalších polí. Jde o formát rozšiřitelný, takže aplikace si do něj může ukládat svá vlastní data, aniž by narušila čitelnost souboru v jiné aplikaci.
Existují dva formáty uložení dat v souboru TIFF podle paměťové reprezentace – little endian a big endian. Většina aplikací rozumí oběma, nicméně ten „nativní“ čte rychleji. Hodnoty se v souboru TIFF ukládají jako 8, 16 nebo 32bitová celá čísla, jako 4 nebo 8bajtová reálná čísla, případně jako zlomek dvou 32bitových celých čísel.
Formát umožňuje uložit více obrázků či vrstev v jednom souboru. Hlavička souboru odkazuje na seznam, jehož jednotlivé položky – adresáře obrázkového souboru – popisují jednotlivé obrázky. Skládají se z 12bajtových položek, které obsahují visačku (tag), což je informace o typu uložených dat, a dále vlastní informaci, případně odkaz na místo, kde jsou data uložena.
Kromě vlastních dat mezi nejdůležitější visačky patří bitová hloubka, komprese (je registrováno přes 20 kompresních schémat, mezi široce podporované patří Huffman RLE, CCITT FAX G3 a G4, LZW, Packbits a JPEG, mezi ostatní i OJPEG a JBIG), fotometrická interpretace (nula znamená bílou, nula znamená černou, RGB, indexovaný, maska obrázku, barevná separace, YCbCr – CCIR 601, CIE Lab*, CIE Log2(L), CIE Log2(L) (u',v')), rozlišení a jeho jednotky, umístění vrstvy, barevný profil a další kalibrační údaje, dále mnoho informačních visaček (jméno autora, aplikace, typ skeneru a použité rastrování aj.) a visaček přesně specifikujícich formát obrázkových dat. Zmíním se pouze o jedné z nich – o řadách na pruh (rows per strip). Jde o historickou hodnotu: Rozřezáním obrázku na pruhy a jejich samostatnou kompresí byla omezena paměť pro dekompresi dat za cenu zvětšení souboru. Původní doporučení bylo vybrat takovou hodnotu, aby jeden pruh nepřesáhl 8 kB. Dodnes některé aplikace používají implicitně tuto hodnotu. Máme-li možnost ji zvýšit, udělejme to.
Strukturu souboru si můžeme prohlédnout např. programem tiffinfo.
TIFF a komprese
Nerozumí-li aplikace datům ve speciálních položkách, nic se nestane a obrázek bude načten bez problémů. To však neplatí o kompresi, bitové hloubce a fotometrické interpretaci. Ty jsou pro zpracování dat zcela zásadní. Všechny aplikace rozumějí 8bitovým datům černobílým, v šedích nebo v barvách RGB a bez komprese.
Většina aplikací též zvládá kompresi Packbits (pakování bitů, Macintosh RLE), některé i CCITT Huffman RLE (deflační komprese). Černobílé komprese CCITT T.4 (známou jako fax group 3) a kompresi CCITT T.6 (fax group 4) zvládá mnoho volně šiřitelných a sharewarových aplikací (i když některé inverzně vinou nejasné pasáže ve staré verzi specifikace), ovšem komerční aplikace jsou s implementací této výborné kompresní metody pozadu. Podobně je to i s kompresí ZIP. Obrácená je situace s kompresí LZW (Lempel–Ziv–Welch). Vzhledem k agresivní licenční politice firmy Unisys na americké půdě je tato komprese k dispozici pouze u komerčních aplikací nebo u aplikací vyvinutých mimo USA. Volně šiřitelné programy v USA se musí spokojit s dekompresí. Možnost zapouzdřit JPEG soubor do souboru TIFF je zajímavá velikostí výsledného souboru. Chceme-li mít jistotu, že tam, kam svůj TIFF pošleme, ho otevřou, moc možností nezbývá (jistě nekomprimovaný, možná LZW a Packbits).
Podobná situace je u barevných prostorů a bitových hloubek. Barevný prostor CMYK zvládají aplikace pro předtiskovou přípravu, některé z ostatních jej možná zobrazí. Se soubory v kolorimetrických barevných prostorech je to ještě horší, zvlášť u vyšších bitových hloubek. V praxi je k přenosu dat použitelný nanejvýš osmibitový CIE Lab*. Více než osmibitová data většina aplikací sice otevře, ale méně z nich je dokáže též zapsat.
JPEG
Na rozdíl od formátu TIFF byl JPEG navrhován pouze jako standardní ztrátové kompresní schéma, určené zvlášť na fotografie. Specifikace ISO dokonce ani neobsahovala doporučený formát souboru. To, co dnes známe pod příponou .jpg, je formát zvaný JFIF. Formát měl dvě odlišné verze – v5 a v6. Dnes se názvem JPEG označuje jen v6, pro v5 se používá označení OJPEG. JPEG dosahuje kompresních poměrů u bezztrátové komprese nedosažitelných.
JPEG je navržen bez použití patentovaných technologií.
JPEG běžně ukládá obrázky ve speciálním barevném schématu – YCbCr (jasová informace, světlost barvy, chrominance, v případě CMYK obrázků pak používá schéma Adobe YCCK), jednoduše převoditelném na RGB (resp. CMYK). Kanály Y a Cb se většinou ukládají v plném rozlišení, zatímco kanál Cr se z důvodu úspory často podvzorkovává (přepočítává na menší rozlišení, běžně v poměru 1:2 × 1:2; některé starší aplikace uměly pouze 1:2 × 1:1). Cenou za to je zhoršení kvality ostrých barevných přechodů. Na data se může dále uplatnit prokládání, kdy je obraz uložen jako sekvence po sobě jsoucích částí s postupně se zvyšujícím rozlišením. Tímto postupem zpracovanému obrázku se říká progresivní JPEG a hodí se zejména pro velké obrázky na web – obrázky pak v prohlížeči nenabíhají odshora, ale postupně se „projasňují“.
Na takto předzpracovaná data se používá speciální kódovací mechanismus Discrete Cosine Transform (DCT), dále následuje Huffmannovo kódování (nebo aritmetické entropické kódování), a tato data se pak ukládají do souboru.
Pro neobrazová data formát JPEG vyhradil pouze 17 polí – COM pro komentář a APP0 až APP15 pro speciální účely. APP0 obsahuje informaci o barevném prostoru a rozlišení, APP14 Adobe marker, APP8 pak data standardu SPIFF.
Kvalitu obrázku nejvíce ovlivňuje základní koeficient kompresoru – kvalita. Její interpretace se v jednotlivých aplikacích liší, nejběžnější je škála 0 %–100 %, kde vyšší číslo znamená vyšší kvalitu. Implicitní kvalita bývá 75 %, někdy i 80 %. Ještě vyšší kvalitu lze bez obav použít i na zvětšeniny a fotografie obsahující i písmo (zvlášť zakážeme-li podvzorkování barevného kanálu). Nad 95 % již kvalita viditelně neroste, zato prudce roste velikost souboru. Ani kvalita 100 % ovšem neznamená bezztrátovou kompresi! Stále zde existuje ztráta při výpočtu koeficientů, případně i z podvzorkování.
Pro nižší kvalitu se naopak rozhodneme u náhledů a miniatur, případně u obrázků s předimenzovaným rozlišením. Prakticky použitelné jsou hodnoty zhruba od 25 %. Při nízké kvalitě komprese můžeme úspěšně použít další volbu kompresoru – vyhlazení před kompresí – která za cenu ztráty detailů nabídne vizuálně lepší výsledek.
Opakovaná komprese JPEG
Obecně rozšířenou pověrou je, že dekomprese a opětná komprese obrázku ve formátu JPEG se stejným nastavením vede ke ztrátě kvality. Není to pravda – k veškeré ztrátě dochází pouze při první kompresi a při dalších kompresích již ke ztrátě nedochází, s výjimkou pixelů na okraji obrázku. Existuje i matematický důkaz tohoto tvrzení, ale odkaz na něj jsem bohužel ztratil. Experimentálně jsem si to alespoň ověřil na stonásobné rekompresi.
V případě, že obrázek mezi jednotlivými kompresemi upravujeme, situace již tak příznivá není a ke ztrátě kvality dochází.
