Uložení jako progressive JPG

jpegg:
Je to komprese obrázku. Tzn. JPG s mírně sníženou kvalitou. Určený pro web. Dříve (možná i teď, nevím) ho některé prohlížeče nepodporovaly

Normálně se v obrázku ukládají pixely řádek po řádku. V progresivní metodě na přeskáčku a prohlížeč pak vyplní okolí tou samou barvou. Progresivní metoda se hlavně používala pro pomalé připojení, kde bylo rychleji znát co na tom obrázku bude. IE s tím ale měl problémy.

jpegg:
Kvalita výsledného obrázku bude stejná, jde jen o to, jak se bude průběžně načítat, když ti budou přicházet pakety s kousky obrázku.

Reaguji na 1Pupika1989:
„IE s tím ale měl problémy.“
Konkrétně proměňoval zmiňovanou výhodu v nevýhodu — obrázek ukázal celý najednou až po úplném načtení (tzn. pointa obrázku šla vykoukat později, než kdyby byl uložený normálně sekvenčně). Nebyl to zase tak fatální problém, jako je třeba u CMYKu.
Nevím, zda se novější verze polepšily, nemám při ruce dostatečně pomalé připojení a dostatečně velký JPEG.

Zaznělo tu několik nepřesností, popis progresívního JPEGu (možno přeskočit) a jeho zobrazování je ve článku na Root.z Programujeme JPEG: Progresivní JPEG a informace EXIF.

Výsledná kvalita je stejná a moje zkušenost je jiná, než tvrzení ve článku, výsledné soubory jsou menší (cca o 10 %), ale je možné, že závisí na použitém software, jaké používá algoritmy.

Dříve IE progresivní vykreslování nepozoroval. Běžné JPEG obrázky vykresloval postupně shora dolů, ale progresivní JPEG obrázky zobrazil až po přenesení všech dat obrázku. IE9 pravděpodobně progresivní vykreslování podporuje.

„je tam parametr subsampling ... při uložení v PS je OFF , při uložení v InfanView naopak ON.“
To se snad dá změnit. Je to podvzorkování barev, pro fotky přírody je vhodné mít zapnuté podvzorkování barev, na loga g ostrými přechody barev nebo třebas fotky osob s pestrobarevným oblečením je vhodné vypnout podvzorkování barev.

Chamurappi: Předpokládal jsem, že to u JPEGu bude jako u PNG. Buď jen body, nebo jak jsem psal bloky s různým vyhlazováním. Záleží asi na prohlížeči jak si to přebere.

Hezky to je vidět na nuwen.net/png.html

Je to sice PNG, ale princip bude nejspíš stejný. Rýpal jsem se v tom asi před měsícem.

Pro IE byl pak tuším nějaký fix, ale už si to pořádně nepamatuji.

jpegg:
„co se ještě provede, když parametry jsou jako při normálním uložení jpegu?“
Nemám fotošopu, tak si tipnu, že by v tom mohly mít "prsty" rozdílné parametry podvzorkování barev, nebo fotošop uložil nějaká data navíc, třebas ICC profil. Více bych věděl, pokud bys "podezřelý" obrázek nahrál někam na web (třebas http://www.imghosting.cz/) a dal sem odkaz.
Pokud máš IrfanViev, tak něco se dá jistit, pokud obrázek otevřeš a koukneš na Image information (ikonka i v kruhu) na řádek compresssion, příklad:
JPEG, progressive, quality: 71, subsampling ON (2x2)

„Používá se asi jiný algoritmus, že?“
Ne.

"Má v dnešní době ještě vůbec smysl pro web provádět tuto minimalizaci velikosti? "
Ano, 19k a 5k je rozdil, ale 6k a 5k nikoho prilis netrapi.
Ona se tech optimalizaci da udelat cela rada. Treba prevest na png ci gif. Nebo nastavit jinou matici deleni. Ale vzdy je lepsi na vsechno pouzit jeden zpusob. Kdyz to nejaky prohlizec nezvladne spravne zobrazit, tak to cele je spatne a ne nahodne vzorky a abys pak zjistoval, cim to je.

peta:
„Ale vzdy je lepsi na vsechno pouzit jeden zpusob.“
Nesouhlasím, podle mne má každý formát své místo, s trochou zjednodušení:
GIF - animace
JPEG - fotky
PNG - grafika vytvořená v počítači, jako loga, ikony, tlačítka, schémata...
Trochu problém jsou třeba fotky doplněné o grafiku, mi se osvědčilo použít JPEG bez podvzorkování barev.

„Ona se tech optimalizaci da udelat cela rada. Treba prevest na png ci gif.“
Pokud by šlo o převod z JPEGu, nazval bych takové zvěrstvo antioptimalizací.

„Nebo nastavit jinou matici deleni.“
Nevím co máš na mysli, pravděpodobně nastavení velikosti kvantizační matice. Jednak neznám program, který to umí, druhak pochybuji, že se tím dá dosáhnout významné snížení datové velikosti.

jpegg:
„Má v dnešní době ještě vůbec smysl pro web provádět tuto minimalizaci velikosti?“
Já beru web stránku jako celek. 19k a 5k je rozdíl, ale pokud bude na webu jen jeden takový obrázek, tak to moc nevadí. Něco jiného by byla třebas fotogalerie se spoustou náhledů, třebas v http://teststranek.kvalitne.cz/foto/den-nato-2006/ mám 55 náhledů o průměrné velikosti 5,9 kB, pokud by obrázky byly 3× větší, tak by návštěvník s pomalým připojením zbytečně čekal.

Náhledy fotografií se mají ukládat bez EXIFu, u zvětšenin záleží na cílové skupině, pokud jsou zvětšeniny určené pro zájemce o fotografování, je vhodné ukládat zvětšeniny s EXIFem.

Optimální nastavení pro ukládání JPEGu je trochu alchymie, hodně záleží na předloze. U fotek můžeš zkusit pro začátek kvalitu 80 a se zapnutým podvzorkováním barev, pokud bybe s barvami problém, třeba na pestrobarevném oblečení, tak podvzorkování barev vypni.
Pokud jsou na obrázku vidět JPEG artefakty, třebas kolem budov, sloupů, stromů, v obličejích, tak je vhodné kvalitu zvýšit. Někdy je důležitější malá datová velikost a menší množství viditelných artefaktů nevadí.
U JPEGu nemá smysl jít s kvalitou nad 90, zvyšovat kvalitu nad 95 je nerozumné.

Mně se, zvlášť u fotek, osvědčilo ukládat to v něčem, co má dost možností a zároveň živý náhled. Používám Gimp, a vždycky se dívám na datovou velikost, a kvalitu prostě stáhnu tak dolů, aby to ještě bylo koukatelné. Kolikrát zjistíte, že subjektivní rozdíl v kvalitě půlmegabajtového a padesátikilového obrázku je docela malý. Ale i u fotek záleží na situaci - někdy jde dát subsampling na 4:2:0, vůbec to není vidět, a obrázek to zmenší o 20%, jindy to je poznat, nebo to na velikost má minimální efekt... U fotek (a celkově epravidelných obrázků) jde navíc procentuální kvalita většinou stáhnout hodně dolů (třeba i na 40%) a na obrázku to prakticky není vidět.

Jediné co asi platí univerzálně (až na skutečně velmi malé obrázky) je právě ukládat je progresivně, aby se pak obrázky načítaly postupně (nejdřív je to jen barevný flek a postupně se "doostřuje"), a aby se nečekalo, než se to načte zvrchu dolů nebo celé. Vypadá to lépe na pomalém připojení.

Příklad pro ilustraci - zmenšení na 20% původní velikosti, kde je kvalita pořád slušná. Pozor, ta stránka má celkem přes 3MB.

Amunak:
"Vypadá to lépe na pomalém připojení."
Nesouhlasim. Je mi to velmi neprijemne, kdyz si myslim, ze uz se obrazek nacetl a je strasne skaredy a tesne pred odchodem si vsimnu, ze se nadherne vybarvil.

"Kolikrát zjistíte, že subjektivní rozdíl v kvalitě půlmegabajtového a padesátikilového obrázku je docela malý"
Nesouhlasim. Ten rozdil je tam skutecne vyrazny a je to hodne fragmentovane. Ano, pouhym nahledem a letmym pohledem se mohou oba obrazky jevit velmi podobne. Ale na web bych rozhodne pro velky obrazek pouzival co nejmensi zniceni kvality. Ale pro nahledy pouzivam 65-85%, obcas i silne prokladani. U nahledu na kvalite zas tolik nesejde. Musi byt takovy, aby se clovek rozhodl, jestli si to prohledne ve velkem nebo ho to nezajima.

Příklad pro ilustraci
- vsimni si, ze voda je neprirozene krystalicka (v levem dolnim rohu je to asi nejvic videt)
- kdyz si to nazoomujes, je tam hodne znat jpeg ctverecky a to i v prvnim obrazku, coz je pak hodne neprijemne pri tisku nebo operacich s barvami (ostreni, kolorovani, zoom).
Jinak je to myslim hodne pekny priklad, kterym by se jpeg metoda dala dobre prezentovat jako nejlepsi :)

jpegg:
Obecně to platí tak, jak psal Bubák [#14] - JPG na fotky, PNG na grafiku, a GIF pokud možno vůbec, nebo když to jinak nejde, na animace. U PNG není co vymýšlet, tam se vždy aplikuje bezztrátová komprese. GIF je velmi specifický a složitý, co se týče animací; a u toho JPG je, jak jsem psal, asi nejlepší si proztě vyzkoušet různá nastavení a vybrat to co vypadá nejlépe při nejmenší datové velikosti.
Jediný problém bývá rozhodnout se, jestli na obrázek (blízký fotce) který obsahuje nějaký text (to je často případ loga firmy) použít JPG nebo PNG. Já třeba volím obvykle to PNG, protože u JPG jsou u hran (písem) a jednobarevných ploch opravdu vidět. Navíc když jde skutečně o logo, je to něco, co je velmi důležité pro firmu, a ta chce, aby logo vypadalo vždy pokud možno stejně a bylo kvalitní, působilo dobrým dojmem. Horší je to u měnších obrázků s nevýrazným textem... Ale to je pak opravdu jen o použití a citu autora.


peta:
„Je mi to velmi neprijemne, kdyz si myslim, ze uz se obrazek nacetl a je strasne skaredy a tesne pred odchodem si vsimnu, ze se nadherne vybarvil.“
Mně je zase nepříjemné, když si myslím, že už se obrázek načetl, a teprve pak si všimnu, že to bylo foto celé postavy, ne jen obličeje. Můžeš s tím nesouhlasit, ale ucelený dojem ze stránky máš lepší, když tam nejsou prázdná místa, kam se postupně načítají obrázky, ale když je tam flek, který se vybarví. Překvapit by tě to mělo asi poprvé když to vidíš. Ale pokud odcházíš ze stránky dříve, než se vůbec načte, chyba není v progresivním načítání obrázků.

„Ano, pouhym nahledem a letmym pohledem se mohou oba obrazky jevit velmi podobne.“
V reálné situaci nebudeš mít ty obrázky na porovnání, takže ten rozdíl neuvidíš. Detailním pohledem přijdeš na to, že tam občas jsou artefakty po JPEG kompresi, které bys nakonec našel i v tom originálu. V tomhle konkrétním případě se to hodně smyje s šumem, který vytvořil nepříliš kvalitní foťák. Tolik, že to práve ani při velké kompresi není moc poznat.

„Na web bych rozhodne pro velky obrazek pouzival co nejmensi zniceni kvality.“
To nemůžeš takhle univerzálně říct. Když bys to chtěl dávat pro tisk nebo další úpravy, tak určitě (i když od toho bys tam i tak měl mít nějaké download tlačítko, a běžně plnou kvalitu, jež by měla být i v jiném, bezztrátovém formátu, a která bude i tak asi třikrát větší než je nutné, neukazovat). Ale i pro fotogalerie bohatě stačí okolo 60-80% a aplikovat smoothing, který to trochu urovná. Jinak řečeno - pro většinu lidí je důležité, že se jim to rychle načte (a třeba že jim to nežere datový limit), než že tam ani po důkladnějším prohlédnutí nenajdou JPEG artefakty (které i tak nejspíš budou pokládat za chybu foťáku).

„Ale pro nahledy pouzivam 65-85%, obcas i silne prokladani. U nahledu na kvalite zas tolik nesejde. Musi byt takovy, aby se clovek rozhodl, jestli si to prohledne ve velkem nebo ho to nezajima.“
Přesně, náhledy musí být takové, aby se člověk rozhodl, zda ho zajímá větší obrázek. A taky je to extrémně situační. U růží jsem zvolil extrémně zkomprimované náhledy - používají, jestli se nepletu, 32-položkovou barevnou škálu, a asi 20% kvalitu. Na některých to je vidět, ale po rozkliknutí se zobrazí plná kvalita (kterou máme k dispozici). Když jsem přemýšlel, jakou kvalitu zvolit, mohl jsem si vybrat mezi touhle průměrně 3.5KB verzí, a asi 20KB, kde bylo víc barev a všechny náhledy vypadaly obstojně. Když jsem si uvědomil, že by pak někdo stahoval zbhytečně asi 4MB obrázků, které ho možná vůbec nezajímají, zvolil jsem tu menší variantu ;)

"U PNG není co vymýšlet, tak se vždy aplikuje bezztrátová komprese"
To je lez. Uz jen to, ze gimp nabizi pro png jpeg kompresi by ti mohlo ledacos napovedet. Spravne by melo byt, ze podporuje i neztratove metody. Jpeg taky umi neztratove metody.

"GIF je velmi specifický a složitý"
A to jako proc? Bezny gif se komprimuje pomoci lzw. Animovany gif ma navic jen cas a muze/nemusi pouzit body z predchoziho snimku, aby usetril data. Co je na tom slozite? :)

peta:
„To je lez. Uz jen to, ze gimp nabizi pro png jpeg kompresi by ti mohlo ledacos napovedet. Spravne by melo byt, ze podporuje i neztratove metody.“
Opravdu? Kde jsi na to přišel? Docela bych chtěl vidět PNG které nepoužívá bezztrátovou kompresi. GIMP u exportu do PNG žádnou "JPEG kompresi" opravdu nenabízí.


„Jpeg taky umi neztratove metody.“
Tohle bych asi netvrdil; sice existuje jakási lossless JPEG norma, ale běžně se to nepoužívá a bůhví jak je rozšířená implementace a následná podpora prohlížení. Pro tyhle účely je tu právě PNG.

> "GIF je velmi specifický a složitý"
> A to jako proc?
Vysvětlovat práci s formátem GIF pro někoho, kdo se ptá na JPG, je zbytečné. Složité je to z toho pohledu, že pokud chceš vytvářet animace, bude lepší využít na to nějaký specializovaný software. Musíš si taky dát pozor při ukládání a pečlivě rozlišovat výsledné "zkomprimované" gify, kde každý frame animace obsahuje jen několik málo bodů, a nekomprimované originály, které jdou ještě snadno upravovat, ale jsou zbytečně velké pro web.

Tak on datový blok jpegu se uloží bezeztrátově. Ztráta se ale projevuje už před kompresí.

PNG určitě žádnou jpeg kompresi neumí, umí jen Deflate. Navíc má úplně odlišnou interpretaci pixelového bloku. Žádné YCbCr, chromacity má uložené zvlášť. Navíc má PNG tzv. scanline a ne bloky. Teda co si alespoň pamatuji z dokumentace.

Ok, beru zpet, vcera jsem delal vic experimentu, ted koukam, ze slo o tif s tim jpeg. Kazdopadne dole mas compression level. To tam urcite neni jen tak pro nic za nic.
---
Uz to vidim, to souvisi s narocnosti algoritmu.
Ale je tam moznost ztratove komprese, nasel jsem programy, ktere snizuji barevnou hloubku. Neco podobne kdosi zminova, kdyz pouzil muj gif a udelal z neho png, tez zpusob :)

Převést barvy tomu samozřejmě jdou. PNG umí třeba jen 1 bitové barvy. Takže se jich nacpe do bajtu 8. Čili nekomprimovaný řádek o 12 pixelech bude mít 3 bajty (každý řádek ještě obsahuje číslo filtru + na konci je odsazení v podobě nul).

Nicméně k artefaktům jako u Jpegu nemůže dojít. Akorát to bude černobílé.

Při převodu Gifu na PNG se nic nestane, budou totožné.

Ztrátovost PNG nemá, pixely se uloží přesně jako na plátně.

peta:
„Kazdopadne dole mas compression level. To tam urcite neni jen tak pro nic za nic.“
Více pruhů více Adidas. Více compression level, více času trvá mačkání dat, více compression level, více zmačkaná data.

„Ale je tam moznost ztratove komprese, nasel jsem programy, ktere snizuji barevnou hloubku.“
Snížení barevné hloubky je ztrátová operace, ale není to komprese. Mimo to, pokud má obrázek třebas 16 barev a snížím se barevnou hloubku na čtyřbitovou, což je právě 16 barev, tak k žádné ztrátě dat nedojde.
Obdobně odstranění diakritiky z textu je ztrátová operace, ale není to komprese, vystačíš si s ASCII znaky a není třeba unicode.

„Neco podobne kdosi zminova, kdyz pouzil muj gif a udelal z neho png, tez zpusob :)“
Tvůj GIF má čtyřbitovou barevnou hloubkou a obsahuje jen 16 barev z 256 odstínů šedi, já ho uložil jako greyscale, odstíny šedi, takže k žádným ztrátám nemohlo dojít. Zmíněný trik, vhodný jen pro prťavé obrázky, jsem použil, abych se vyhnul použití palety, ta totiž zabírá v souboru místo.

"16 barev a snížím se barevnou hloubku na čtyřbitovou, což je právě 16 barev, tak k žádné ztrátě dat nedojde"
Zalezi na tom. Kdyz tohle udelas v gimpu pro gif, tak on prepocita paletu misto toho, aby ji ocesal. Coz vede k tomu, ze bila neni bila, ale treba jemne sediva.

To bude ale chyba programu, nikoliv formátu. Pokud tedy těch 16 barev je v 4bitovém rozsahu.

1Pupik1989:
„Pokud tedy těch 16 barev je v 4bitovém rozsahu.“
Čtyřbitový rozsah je tento: Základní barvy
Dobrý program při vhodném natavení umí snížit barevnou hloubku šestnácti barevného obrázku z 24 bitové nebo menší barevné hloubky na 4 bitovou, aniž by došlo k posuvu barev.
S GIMPem jsem dělal minimálně a málokdy mám náladu zkoušet, co umí, ale někdy vyzkouším, zda je problém v GIMPu, nebo v nevhodném nastavení.

Já myslel 4 bitový rozsah, aby červený kanál neměl hodnotu 254, pak už by barva neseděla.