Existujφ r∙znΘ statistiky, kterΘ s menÜφ Φi v∞tÜφ p°esv∞dΦivostφ vypovφdajφ o vzßjemn²ch pom∞rech velikosti dat na internetu. Nebudeme se zab²vat p°esn²mi Φφsly, uve∩me jen to, co majφ spoleΦnΘ - naprostou v∞tÜinu prostoru zabφrajφ obrßzky, animace a zvuky, kter²m se takΘ souhrnn∞ °φkß multimedißlnφ prvky.
Nejprohlφ₧en∞jÜφmi multimedißlnφmi objekty na internetu jsou samoz°ejm∞ obrßzky. Tento text nepojednßvß o zvuku ani o videu, ale p°inßÜφ nßvod, jak zmenÜit fyzickou velikost obrßzk∙ bez zjevnΘ ztrßty Φi ·jmy na jejich vizußlnφ kvalit∞. Budeme se soust°edit p°edevÜφm na obrßzky na webu, i kdy₧ zde uvedenß metoda je pou₧itelnß obecn∞ nap°φklad i v oblasti digitßlnφ fotografie. Pokusφme se vÜe vysv∞tlit tak, aby byl postup pokud mo₧no nezßvisl² na programu, kter² pro tyto konverze pou₧ijeme. Pokud vÜak budeme n∞jak² program citovat, bude to Adobe Photoshop verze 7.0.
Na ·vod rekapitulace - bity, bajty a barvy...
Zßkladnφm parametrem digitßlnφho obrazu je mno₧stvφ bit∙, kterΘ mß k dispozici pro reprezentaci barevnΘ informace v jednom pixelu. Podle toho se rozliÜujφ Φty°i zßkladnφ druhy obrßzk∙.
Bitmapa mß pro ka₧d² pixel jeden bit, a disponuje tedy pouze dv∞ma barvami. Jak se tyto dv∞ barvy interpretujφ, nezßvisφ na vlastnφ informaci. Nap°φklad kdysi existovaly grafickΘ subsystΘmy, kterΘ produkovaly oran₧ovozelen² obraz, nejΦast∞ji se vÜak u₧φvß Φernobφl². Bitmapa je v podstat∞ extrΘmnφm p°φpadem a nebudeme se jφ dßle zab²vat. Jen malß poznßmka, obrazov² formßt BMP je zkratkou k bitmap, ale ve skuteΦnosti jde o true color (viz dßle).
High color pou₧φvß pro ka₧d² pixel dva bajty, a disponuje tedy 65 536 barvami. N∞kdy se zajφmav∞ Φesky °φkß, ₧e mßme k dispozici 65 kilobarev. Otßzkou je, jak se barvy v high color k≤dujφ. ╚ast² p°φstup je tzv. 5-6-5, p∞t pixel∙ se pou₧ije pro Φervenou slo₧ku R, Üest pro zelenou G a poslednφch p∞t pro modrou B. LidskΘ oko je nejcitliv∞jÜφ na zelenou barvu, proto je rezervovßno vφce bit∙ pro zelenou.
True color je nejdokonalejÜφ z popisovan²ch re₧im∙ a obrßzky mohou b²t reprezentovßny v jednΘ ze dvou variant. True color RGB pracuje se t°emi bajty pro ka₧d² pixel, a mß tedy k dispozici 224 = 16 megabarev. True color RGBA mß k dispozici Φty°i bajty pro ka₧d² pixel a disponuje takΘ 16 megabarvami - Φtvrtß slo₧ka, A neboli alfa, nese informaci o pr∙hlednosti pixelu a nevztahuje se p°φmo k barv∞.
IndexovΘ barvy pou₧φvajφ k reprezentaci barvy jeden bajt na pixel, v jednom obrazu tedy m∙₧eme mφt maximßln∞ 256 r∙zn²ch barev. Majφ vÜak pom∞rn∞ komplikovanou reprezentaci - obrazov²m pixel∙m jsou p°i°azeny hodnoty od nuly do 255. Tyto hodnoty vÜak nenesou p°φmo barevnou informaci, ale jsou pouze odkazem do tzv. vyhledßvacφ tabulky (look-up table), kterΘ se takΘ °φkß paleta (viz obrßzek). Paleta je v pam∞ti poΦφtaΦe obvykle reprezentovßna jako jednorozm∞rnΘ pole, kde ka₧d² prvek obsahuje trojici RGB, definujφcφ p°φsluÜnou barvu. Barevnß paleta m∙₧e obsahovat maximßln∞ 256 odliÜn²ch barev (z nap°. 16 M mo₧n²ch).
Je vÜak 16 777 216 barev, kterΘ poskytuje true color, dostateΦnΘ mno₧stvφ? Ano i ne. ZdravΘ lidskΘ oko dokß₧e rozliÜit p°ibli₧n∞ 170 milion∙ barev, ale v jednom okam₧iku maximßln∞ jen 10 tisφc. Na jeden obrßzek je to tedy vφce ne₧ dost, avÜak obecn∞ barvy true color nedokß₧φ pokr²t vÜe, co m∙₧eme vid∞t prost²m zrakem. UrΦit²m p°iblφ₧enφm by tedy mohly b²t "indexovΘ barvy" s paletou 10 tisφc barev ze 170 milion∙ mo₧n²ch.
Kompresnφ algoritmy
Nenφ to tak dßvno, co si ka₧dß firma k novΘmu grafickΘmu programu vyvinula i nov² grafick² formßt. Tak vzniklo obrovskΘ mno₧stvφ r∙zn²ch formßt∙ a prapodivn²ch koncovek soubor∙, jako BMP, PCX, TGA, TIF, JPG, JP2, LWF, GIF, PNG, SGI, CPT, SCT, CUR, CAL, FMW atd. Tyto formßty se v zßsad∞ liÜφ jen ve t°ech v∞cech - v hlaviΦce souboru, v barevnΘ hloubce (poΦtu barev na pixel), kterou umo₧≥ujφ ulo₧it, a p°edevÜφm v kompresi obrazu, kterou podporujφ. Nenφ bez zajφmavosti, ₧e v souΦasnΘ dob∞ se nejΦast∞ji setkßme se Φty°mi zp∙soby ulo₧enφ. NejjednoduÜÜφ spoΦφvß v prostΘm ulo₧enφ matice obrazu v nekomprimovanΘ podob∞; nijak tedy nezmenÜφ velikost dat, proto se jφm nebudeme zab²vat. Na zb²vajφcφ t°i se vÜak podφvßme detailn∞ji.
Existujφ dv∞ skupiny kompresnφch algoritm∙. Prvnφ z nich nezm∞nφ p∙vodnφ data, tak₧e po rozbalenφ zφskßme naprosto stejnß data, jako jsme m∞li p∙vodn∞. Tyto algoritmy se anglicky naz²vajφ losless, Φesky bezztrßtovΘ. Druhß skupina, ztrßtovΘ Φi lossy algoritmy, nejprve upravφ vstupnφ data tak, ₧e odstranφ tzv. psychovizußlnφ redundanci neboli rysy, kterΘ nejsou vizußln∞ podstatnΘ. Pokusme se vÜe vysv∞tlit na p°φkladu. P°edstavme si, ₧e mßme obraz, v n∞m₧ jsou dva barevnΘ odstφny, jejich₧ rozdφl je minimßlnφ, tak₧e je prost²m okem nerozliÜφte. Co₧ je tedy "zaokrouhlit" na jednu z nich a tak uÜet°it? Takto p°ipraven² obraz se potom daleko ·Φinn∞ji komprimuje. Slovn∞ naznaΦen² postup se naz²vß kvantizace barev.
RLE (Run Length Encoding) je metoda starß vφc ne₧ padesßt let a pou₧φvß se nap°φklad ve faxu. Jejφ princip lze popsat zhruba takto: M∞jme sekvenci znak∙ AAAABBBCCCCC. Ka₧dß opakujφcφ se sekvence se nahradφ dvojicφ, v nφ₧ prvnφ znak znamenß poΦet opakovßnφ a druh² je vlastnφ znak. Pro nßÜ p°φpad dostaneme 4A3B5C. P∙vodnφ sekvence byla dlouhß 13 znak∙, novß pouze 6, kompresnφ faktor je tedy 46 %. RLE je ne p°φliÜ Φasto pou₧φvan² formßt, proto₧e neposkytuje dobrΘ v²sledky p°i kompresi dat obsahujφcφch velk² objem Üumu, nenφ tedy p°φliÜ vhodn² na kompresi fotografiφ. Setkßme se s nφm nap°φklad ve formßtu TGA Φi SGI.
LZW (Lempel-Ziv-Welch) je kompresnφ algoritmus, kter² se pou₧φvß nejen pro digitßlnφ obrßzky, ale takΘ ke kompresi jin²ch dat. Nap°φklad programy ARJ, COMPRESS, Power Archiver, WinZIP, ZOO atd. pou₧φvajφ r∙zn∞ modifikovanΘ verze tohoto algoritmu.
Algoritmus LZW je dosti komplikovan², ale jeho princip je mo₧no shrnout zhruba takto: V posloupnosti Φφsel se vyhledajφ nejΦast∞ji se opakujφcφ dlouhΘ sekvence. Vytvo°φ se p°ekladovß tabulka, pomocφ nφ₧ se tyto posloupnosti nahradφ n∞jak²m jednoduch²m, ale p°edevÜφm velice krßtk²m symbolem. Tato tabulka se ulo₧φ spolu se souborem. Tvorba tabulky, p°edevÜφm vyhledßvßnφ posloupnostφ, je nßroΦn² problΘm, a proto je komprimace zdlouhavß. Proto₧e komprese trvß podstatn∞ dΘle ne₧li dekomprese, °φkß se, ₧e jde o kompresi asymetrickou. LZW je nejlepÜφ algoritmus pou₧φvan² pro obrazy, u n∞ho₧ p°i komprimaci nedochßzφ k ₧ßdnΘ ztrßt∞ informace. Pou₧φvß se nap°φklad ve formßtech TIFF, PNG Φi GIF, proto jsou tyto formßty vhodnΘ pro uchovßnφ d∙le₧it²ch dat.
JPEG (Joint Photographic Expert Group) je bezesporu nejΦast∞jÜφm obrazov²m formßtem. Tento jeÜt∞ komplikovan∞jÜφ algoritmus ne₧li LZW je zalo₧en na diskrΘtnφ kosinovΘ transformaci a zßjemce o detaily odkazuji na literaturu uvedenou v Infotipech. Princip je zhruba tento: Obraz se p°evede do jinΘho barevnΘho prostoru (YUV) a v n∞m se provede v²Üe zmφn∞nß kvantizace barev. Druh²m krokem je odstran∞nφ detail∙ z obrazu. VelkΘ variace (Üum) se nahradφ menÜφmi. JPEG tedy v prvnφ °ad∞ "niΦφ" detaily na slo₧it²ch texturßch, fotografiφch trßvnφku atd. JPEG umo₧≥uje volbu komprese a nastavenφ pom∞rn∞ velkΘho mno₧stvφ parametr∙. Je nutnΘ upozornit na jednu skuteΦnost - i kdy₧ nastavφme kvalitu JPEG obrßzku na 100 %, a tedy kompresi na minimum, JPEG v₧dy provßdφ ztrßtovou kompresi! V₧dy pozm∞nφ obraz, a pokud nßm na n∞jak²ch datech zßle₧φ, musφme se uch²lit k bezztrßtovΘmu formßtu.
Ji₧ dlouhou dobu se vφ o problΘmech formßtu JPEG, a proto existuje nßvrh JPEG 2000, kter² je nejlepÜφm formßtem, jak² znßm. Nap°φklad p°i nastavenφ kvality na 100 % ulo₧φ obraz bez ztrßty dat, podporuje pr∙hlednost (co₧ JPEG neumφ), podporuje indexovΘ barvy (ty JPEG rovn∞₧ nepodporuje) a p°edevÜφm mß daleko lepÜφ kompresnφ pom∞r. "Bude" uveden v roce 2000. PoΦφtalo se s jeho zavedenφm p°edevÜφm v oblasti digitßlnφ fotografie. DemonstraΦnφ programy, kterΘ jsem si stßhl z webu, poskytujφ ·chvatnΘ v²sledky, ale proΦ stßle nenφ JP2, co₧ je oficißlnφ koncovka soubor∙ ve formßtu JPEG 2000, k dispozici, nemßm ani tuÜenφ... (Poznßmka autora po uzßv∞rce: Prßv∞ uvßd∞n² Corel PHOTO-PAINT JP2 podporuje)
Velikost obrazu a barevnß p°esnost
Nynφ se dostßvßme ke kritickΘmu mφstu. Jak² je vliv mno₧stvφ barevnΘ informace, obsahu pixel∙ a pou₧itΘho kompresnφho algoritmu na velikost souboru? Zde musφm uvΘst jednu podstatnou v∞c. Ka₧d² obrazov² soubor, pokud ho chceme zobrazit Φi zpracovßvat, se musφ v pam∞ti poΦφtaΦe rozbalit do nekomprimovanΘ maticovΘ podoby. V²znam tohoto sd∞lenφ nejlΘpe objasnφ p°φklady.
Uva₧me obrßzek v rozliÜenφ 800 x 600 pixel∙ v true color, co₧ je obrazovka postarÜφho notebooku. Jakou bude mφt velikost v pam∞ti? Jednoduch²m nßsobenφm dojdeme k Φφslu 1,4 MB. Mßte na svΘm notebooku ve Windows n∞jakΘ pozadφ? Bu∩te si jisti, ₧e vßm konzumuje prßv∞ toto mno₧stvφ drahΘ operaΦnφ pam∞ti.
Jednφm ze zaruΦen²ch zp∙sob∙, jak "odst°elit" grafick² program, je vyrobit RGBA obrßzek v rozliÜenφ 10 240 x 10 240 pixel∙, kter² je cel² bφl². Po ulo₧enφ ve formßtu JPEG bude mφt n∞jak²ch 5 kB. Pokud se ho pokusφte otev°φt, program, kter² by ho m∞l zobrazit, bude nucen alokovat 400 MB pam∞ti.
Jak na to?
Pro velikost obrazu na disku jsou d∙le₧itΘ dva faktory. Druh informace, nap°φklad jde-li o trßvnφk Φi o jednobarevnou plochu, a poΦet barev. S druhem informace toho moc neud∞lßme, v podstat∞ m∙₧eme jen zmenÜit kvalitu obrazu p°i ulo₧enφ ve formßtu JPEG. Co vÜak m∙₧eme ovlivnit, je mno₧stvφ barev. Obecn∞ platφ, ₧e ka₧d² kompresnφ algoritmus komprimuje dokonaleji obrßzky s ni₧Üφm poΦtem barev. Jin²mi slovy °eΦeno, vezm∞me obrßzek a ulo₧me ho jako JPEG s urΦit²m kompresnφm faktorem, vezm∞me tent²₧ obrßzek, zmenÜeme poΦet barev a ulo₧me ho jako JPEG se stejnou kompresφ. Druh² obrßzek by m∞l b²t menÜφ. Nenφ? Potom je mno₧stvφ detail∙ p°φliÜ vysokΘ. Zkusme totΘ₧ se souborem GIF Φi TIFF. V²sledek bude p°ekvapujφcφ.
Zkusil jsem nßsledujφcφ jednoduch² experiment, m∙₧ete ho vyzkouÜet takΘ. Obrßzek z digitßlnφho fotoaparßtu ve formßtu TIFF jsem zmenÜil na 800 x 600 a ulo₧il ho jako TIFF s LZW kompresφ. Tento obrßzek slou₧φ jako originßl (viz tabulka). PotΘ jsem jej ulo₧il jako JPEG se 100% kvalitou a dßle jsem ho p°evedl na 256, 64 a 32 barev a ulo₧il ho jako TIFF s LZW kompresφ. Zde jsou v²sledky:
Je zjevnΘ, ₧e poΦet barev hraje p°i kompresi klφΦovou roli. ╚φm mΘn∞ barev, tφm je kompresnφ algoritmus efektivn∞jÜφ. Vizußlnφ kvalitu je mo₧nΘ posoudit pouze pohledem, proto nenφ vhodnΘ nasazenφ automatick²ch program∙. Nenφ bez zajφmavosti, ₧e JPEG p°i 100% kvalit∞ zredukoval poΦet barev na mΘn∞ ne₧ polovinu, co₧ odpovφdß v²Üe zmφn∞nΘ poznßmce, ₧e JPEG v₧dy poruÜφ obraz. Tolik na ·vod, poj∩me se nynφ podφvat, jak se barvy z obrßzku vybφrajφ, ani₧ by se originßl p°φliÜ vizußln∞ poÜkodil.
V²b∞r vhodn²ch barev
Kritick²m bodem algoritmu je v²b∞r barev, kterΘ se mohou z p∙vodnφho obrazu vyjmout, neboli barevnß kvantizace. Velk²m problΘmem v∞tÜiny program∙ (Corel PHOTO-PAINT, Adobe Photoshop, ACDSee, Jasc PaintShop atd.) je to, ₧e umo₧≥ujφ redukci barev pouze pro p°echod z true color do indexov²ch barev. Tφm se maximßlnφ poΦet barev v novΘm obraze redukuje na 256. Bylo by vynikajφcφ mφt k dispozici program umo₧≥ujφcφ kvantizaci na 1024, 10 240 atd. Bohu₧el ₧ßdn² takov² program neznßm. Princip algoritm∙, kterΘ se pou₧φvajφ, je vÜak jednotn².
Ve vÜech programech pro kvantizaci barev se pou₧φvajφ metody tzv. shlukovΘ anal²zy. Mno₧in∞ objekt∙, v tomto p°φpad∞ podobn²ch barev, se vybere jedin² zßstupce, kter² ji nejlΘpe reprezentuje. Zp∙sob v²b∞ru zßstupce se m∙₧e liÜit, ale obyΦejn∞ jde o vß₧en² pr∙m∞r. Otßzkou je, jak se podobnΘ barvy vyberou. P°edpoklßdejme, ₧e cel² barevn² prostor zobrazφme ve t°ech dimenzφch. Jedna osa bude Φervenß, druhß zelenß a poslednφ modrß. VÜechny barvy pou₧itΘ v obraze tvo°φ jak²si oblak bod∙. Algoritmus kvantizace pak pracuje nßsledovn∞.
VÜechny barvy se uzav°ou do jedinΘho kvßdru a jeho nejdelÜφ strana se rozd∞lφ tak, aby dva novΘ kvßdry obsahovaly stejnΘ mno₧stvφ barev. Proces se aplikuje rekurzivn∞ a₧ do okam₧iku, kdy zφskßme po₧adovan² poΦet kvßdr∙. VÜe, co je uvnit°, si je podobnΘ. Existuje nep°ebernΘ mno₧stvφ variant tohoto algoritmu, n∞kterΘ zohled≥ujφ citlivost lidskΘho vnφmßnφ na zelenou barvu atp. V podstat∞ jde v₧dy o nalezenφ podobn²ch barev a jejich nßhradu jednφm zßstupcem. R∙znΘ programy pou₧φvajφ r∙znΘ varianty a r∙zn∞ se s nimi tajφ. Patrn∞ nejlepÜφ volby jsem nalezl ve Photoshopu.
Kucha°ka
Jak tedy m∙₧eme zmenÜit fyzickou velikost obrazovΘho souboru? Pou₧ijeme nßsledujφcφ postup:
1) Ulo₧φme originßl na n∞jakΘ bezpeΦnΘ mφsto a dßle pracujeme jen s kopiφ.
2) P°evedeme obraz do indexov²ch barev (Image | Mode | Index color).
a) Vybereme lokßlnφ perceptußlnφ paletu (Local Perceptual).
b) Nastavφme poΦet barev na 256.
c) Nastavφme Dithering na none.
d) Nastavφme Forced na none.
3) Jak vypadß obrßzek? Jde to? Zkusφme jφt na 2) a zmenÜit poΦet barev. Cφlem je mφt jich v obrßzku minimum.
4) Ulo₧φme obrßzek jako GIF, PNG a TIFF.
5) P°evedeme obrßzek zp∞t do true color. Ano, je to pl²tvßnφ, ale mß to sv∙j v²znam - v obraze je nynφ podstatn∞ mΘn∞ barev.
6) Ulo₧φme obraz jako JPEG a nastavφme kompresi tak, aby se obraz p°φliÜ nezm∞nil.
7) ProhlΘdneme si, co mßme na disku, a pou₧ijeme nejmenÜφ a nejhezΦφ obrßzek.
Mal² test na zßv∞r
Abych jen plan∞ nepovφdal, tuto techniku jsme zkusili ov∞°it v praxi. V jednom z p°edm∞t∙, kterΘ uΦφm, jsem na zßklad∞ v²Üe uveden²ch informacφ nechal zpracovat studenty celkem 36 webov²ch strßnek s celkov²m obsahem 857 obrßzk∙. Strßnky byly vybrßny nßhodn∞ tak, aby pokryly stßtnφ instituce, Ükoly, firmy atd. Nebudu uvßd∞t jejich adresy, ale jednalo se o weby ΦeskΘ i ze sv∞ta. Studenti dostali Photoshop 7 a strßnky a pustili se do dφla. Podot²kßm, ₧e bez jakΘkoli apriornφ zkuÜenosti. Cφlem bylo zmenÜit velikost t∞chto strßnek pomocφ v²Üe uveden²ch technik. Hodnocenφ probφhalo tak, ₧e jsem otev°el originßlnφ a zmenÜenou strßnku a hledal chyby. Ze vÜech strßnek jsem naÜel dva vizußln∞ poÜkozenΘ obrßzky, co₧ je 0,2 % celkovΘho objemu. Pom∞rn∞ sluÜn² v²kon sv∞dΦφcφ o jednoduchosti techniky.
A v²sledky? Pr∙m∞rnß komprese byla kolem 40 %. Jin²mi slovy °eΦeno, naprostou v∞tÜinu strßnek bylo mo₧nΘ zmenÜit o vφce ne₧ polovinu. NejΦast∞jÜφ chybou originßl∙ bylo prßv∞ nastavenφ p°φliÜ vysokΘho poΦtu barev, nap°φklad obrßzky slou₧φcφ jako navigace m∞ly texty s vysok²m nastavenφm antialiasingu, co₧ je zbyteΦnΘ a zvyÜuje to poΦet barev., atp. Asi ve 20 % p°φpad∙ bylo vhodnΘ konvertovat obrßzek z JPEG do GIF, tΘm∞° nikdy nebylo v²hodnΘ provΘst opaΦn² proces - fotografie v malΘm rozliÜenφ jsou Φasto menÜφ, pokud se ulo₧φ jako GIF, a ne jako JPEG.
Nejh∙° dopadly weby stßtnφch institucφ a obecn∞ strßnky generovanΘ n∞jak²m automatick²m programem. Strßnky generovanΘ ruΦn∞ byly vesm∞s celkem dob°e komprimovanΘ. Patrn∞ nejv∞tÜφm extrΘmem byla hlavnφ strßnka jednΘ nejmenovanΘ vlßdnφ instituce, kterou se poda°ilo zmenÜit z neuv∞°iteln²ch 489 kB na 105 kB, tedy na 22 % p∙vodnφ velikosti.
Zßv∞r
Co jsem se v tomto Φlßnku pokusil sd∞lit? Mno₧stvφ barev, kterΘ mßme v obraze, je pro kompresnφ algoritmus kritickΘ. VelkΘ mno₧stvφ barev zvyÜuje velikost obrazovΘho souboru a Φasto nenφ pro dostateΦnou vizußlnφ kvalitu obrazu nezbytnΘ. Pokud poΦet barev snφ₧φme, soubor s obrazem ulo₧en²m ve stejnΘm formßtu se m∙₧e podstatn∞ zmenÜit a nikdo si toho nemusφ vÜimnout. Myslφm si, ₧e ka₧d² webov² designΘr by toto m∞l v∞d∞t.
Bed°ich BeneÜ, autor@chip.cz
Infotipy
www.digineff.cz
www.fotografovani.cz/df
www.grafika.cz/photo/
www.jpeg.org
J. Äßra, B. BeneÜ, P. Felkel: Modernφ poΦφtaΦovß grafika, Computer Press 1998.
