Srovnání bezeztrátových formátů pro kompresi obrazu (diskuse)

[Jendа]

1) Čistě pro klid duše, zkusil jsi to pak zase dekomprimovat a ověřit, že je to opravdu shodné s originálem?

2) Jak dopadne bzip2? Na některé obrázky (zkoušel jsem to teda jenom na umělé) je to kupodivu lepší než PNG.

[DaBler]

1) Ano, skript pro kompresi provede také dekompresi a srovnání s originálem.

2) Tohle jsem nezkoušel. Není to přímo formát pro uložení obrazum, ale možná to ještě doplním.

[DaBler]

Tak bzip2 se ukázal nejhorší variantou: 13.915411 bpp (1.724706 : 1)

[X]

pro porovnani s bzip2, neslo by projet dataset pomoci zstd (napr zstd -19) ? diky

[DaBler]

Tak jsem to zkusil (parametry xz -9 -e, zstd --ultra -22, brotli -q 11) a výsledky jsou oproti obrazovým formátům vždy horší:

formát	datový tok [bpp]	kompresní poměr
bzip2	13.915411	1.724706 : 1
xz	14.344152	1.673155 : 1
zstd	15.619418	1.536548 : 1
brotli	14.320850	1.675878 : 1

[Bherzet]

Na ten poslední obrázek (zone_plate) by mohlo fungovat docela dobře i BMP s RLE kompresí :) Akorát „docela dobře“ u RLE komprese znamená jen to, že to bude výrazně menší než nekomprimovaná surová bitmapa (což je u RLE samo o sobě důvod k oslavám), ne že to bude mít lepší kompresní poměr než jiné algoritmy.

[pavele]

Takže za 28 let se podařilo dosáhnout kompresní poměr 2,4 oproti 2,1? Pokrok nezastavíš...

[DaBler]

No, to není úplně pravda. Před 28 lety nebyly takové nástroje jako zopflipng. Takže PNG vytvořená v té době byla (střelím od boku) třeba o 30% větší.

[luky]

Tak treba optipng je z roku 2001...

[Grunt]

A který z nich zvládá bez problémů ještě (max. 8-bitovou) barevnou paletu?

[DaBler]

Tak na osmi a méně bitovou paletu bych použil GIF nebo PNG. Dále WebP zkouší použít paletu, pokud je v obrázku 256 a méně barev. FLIF dělá to stejné, ale bez omezení počtu barev v paletě.

[xsubway]

A jak jsou ty formáty rozšířené? Zjišťoval jsi i statistiku použití?

[DaBler]

Nejsem si vědom, že by se v praxi používalo něco jiného než PNG a JPEG 2000 (pokud se bavíme o těch bezeztrátových variantách samozřejmě). Bezeztrátový JPEG 2000 se používá k archivaci kulturního dědictví (jsem si vědom použití např. v Národní knihovně České republiky).

[❗Červivý Hřib krade❗]

by bylo zajímavý vyzkoušet jak moc sou ty vobrázky v různejch formátech jakoby zranitelný proti náhodnýmu poškození nějakejch pár bitů taky :O :O voni si nejspíž vybrali formát podle tohodle taky :O ;D

[Jendа]

To se řeší tak, že použiješ co nejefektivnější formát, a do ušetřeného místa spočítáš Reed-Solomon, ne? (a ještě by se možná hodilo rozsekat velké obrázky na dlaždice)

[❗Červivý Hřib krade❗]

to ale pak už nebude nějakej normální běžnej obrázkovej formát a bude to záviset na nějakým programu/kodecích ne?? :O :O

nejvíc nejlepší mi připadá mit různě poschovávanejch hrozně moc kopií toho samýho vobrázku a pak kdyžtak principem majority požkozenej vopravovat když se pozná chyba :O :O

[Heron]

Díky za přehled. Sám jsem to řešil před x lety a nakonec jsem skončil u ověřeného png. Není nutně pravda, že komprese trvá dlouho. Ano, pokud člověk chce po nějakém programu (já používám optipng), aby prošel kompletně všechny metody, tak to trvá. Ale kupodivu to zmenší velikost jen o 1% oproti "běžně" optimalizovanému png.

V rámci nějakého interního katalogu obrázků mám v toolchainu toto (python, Pillow):

from PIL import Image 

image.save(newfilename, 'png', optimize=True)

Moc jsem nezkoumal co přesně "optimize=True" vlastně zapíná, protože vliv na rychlost (pocitově) to nemá skoro žádný, ale výsledné png je podle optipng (které trvá klidně i několik minut) cca o 1% větší než to nejlepší.

Potom je docela zajímavá možnost použít nějaký skutečně bitmapový formát, třeba suckless farbfeld (který neřeší vůbec nic a je to jen pole pixelů) a použít nějakou obecnou kompresi (jak už zde byl uveden třeba bzip2 nebo zstd nebo cokoliv).

[Lukas]

Trosku dost mi tam chybi srovnani, co vlastne ten ktery format umi zakodovat. Predevsim bitova hloubka, int vs float, maximalni rozliseni, pocet kanalu apod. Nebo je to je pro ucely archivace porna?

[Ovocuc]

Fajn srovnání, díky za test. Když jsem si to před časem zkoušel, tak jsem měl s webp lepší výsledky než s jpegě2000, ale byl to jinej druh obrázků a neměl jsem Kakadu... Tak jako anti-google nefandu mě to těší :)

Zrovna jsem zjistil, že Google perzentoval "webp2" a snad (když jsem to zběžně četl, tak to bylo takové nejasné) to vypadá, že má nové kompresní techniky, i když nevím, jestli i pro lossless režim.

[DaBler]

Tak jsem ten webp2 vyzkoušel. Konkrétně s -effort 9 -q 100. Docela ta komprese trvala, asi je to ještě hodně vývojová verze. I u bezeztrátové komprese je ale vidět posun. Konkrétně to dělá 10.007292 bpp (2.398251 : 1), což je o něco lepší než WebP, ale stále horší než FLIF.

[Josef Kufner]

Jasným vítězem se stává formát FLIF.

Mi přijde, že výsledek je až nezajímavě vyrovnaný. Nějakých zhruba +/- 10 % kolem běžného PNG. Shrnul bych to tak, že nejlepší je použít bezproblémové a rozšířené PNG, neboť alternativy jsou sice trochu lepší, ale ne o tolik, aby to stálo za námahu.

[_]

24bpp? To není moc zajímavý test.

[kvr]

Ohledně PNG - ZopfliPng sice používá Zopfli náhradu Zlib, ale čekal bych, že hlavní rozdíl bude vycházet z analýzy nejlepšího algoritmu pro porovnání PNG částí (scalines), redukce barev apod. Ostatně, dokumentace říká, že rozdíl proti pngout je téměř zanedbatelný (i když ten používá taky vlastní deflate kompresor).

Jinak pěkné srovnání. Hodilo by se zveřejnit i rychlost komprese. Kéž by se podpora rychle dostala do prohlížečů...

[BioGaia]

Redukce barev? Bavime se o bezstrate. To, ze nektere online png optimizery ti srazi velikost o 50% je prave o tom, ze moc bezstratove nejsou a vyhazuji "to co stejne neuvidis".

[_]

Cely test je na 24 bitech na pixel, takze pokud se jedna o fotografii z moderniho aparatu ci skeneru, je tam ztrata barev implicitne.

[kvr]

Tou redukcí barev jsem nemyslel jejich bezeztrátové osekání, ale snížení bpp, třeba formou palety. PNG se obvykle používá na umělé obrázky, kde je množství použitých barev omezené, proto může mít v některých případech výrazně snížit velikost. Na fotky to samozřejmě nejspíš fungovat nebude (i když tedy citlivost to ovlivnit může), na ty ale ani nebudou moc dobře fungovat algoritmy nad scanlines...

V tomto ohledu je otázka, zda jsou vstupy pro test vůbec vhodné, přinejmenším PNG na fotky dělané není...

[_]

Proč by nebylo dělané na fotky? Můj starý foťáček ukládal fotky do png.

[kvr]

Bo PNG komprese je postavena na opakujících se sekvencích, případně předtím ještě aplikované nějaké operace na jednotlivých řádkách (třeba odečtení barev - takže postupné zesvětlování vyústí v jeden řádek barvy a potom opakující se rozdíl). To se v praxi na fotkách moc nevyskytuje, obvykle jsou tam mírné, ale docela nepravidelné změny. Deflate tam samozřejmě vždycky něco najde, takže oproti BMP to bude pořád obrovský skok dopředu, ale JPEG i s vysokou kvalitou s přehledem zvítězí. ... možná ten starý foťák neměl dobrý procesor na aplikaci JPEG filtrů...

[_]

Ale když si přečteš blog, tak zjistíš, že nic výrazně lepšího na fotografie neexistuje. Když k tomu přičteš kompatibilitu a rozšířenost formátu, tak je PNG nejlepší neztrátový formát pro archivaci hotových fotografií.

Stejně tak na webu, pokud chceš fotku ve 100% kvalitě, nic jiného než PNG nemáš k dispozici.

[j]

"PNG na fotky dělané není"

Presne, autor si zjevne mysli, ze jedinej obrazek je fotka. Kdyz uz by chtel nekdo neco srovnavat, tak taky musi pouzit ruzny obrazky typove, a v pripade kreseb budou vysledky nejspis o dost jiny.

Jinak je celkove videt, ze to je z hlediska velikosti vlastne uplne jedno, a pak je lepsi zvolit format co mozna nejrozsirenejsi, protoze s nim bude nejmin problemu.

---

Dete s tim guuglem dopice!

[DaBler]

Milý anonyme, srovnával jsem různé datasety (včetně kreseb a ilustrací). Pořadí FLIF vs. PNG je vždy stejné. Vyhraje FLIF, optimalizované PNG mu nemůže konkurovat. Dobře je na tom ještě WebP2, které v původním srovnání není. Nejhorší je typicky JPEG XR a AVIF.

[Jendа]

Když jsem před chvílí ukládal ty mapy pro svůj blog, tak GIMP vygeneroval naprosto gigantické PNG, a optipng to okamžitě srazilo o 40 %.

[--]

A jak sibto mel v gimpu nastavene?

[Jendа]

Přílohy:

• nastaveni.png (25255 bytů)
• mapa.png (442904 bytů)

Takhle, ale ani odškrtnutí všeho nepomohlo. Si to zkus. Importuj tento obrázek (mimochodem je to ten neoptimální export), ulož, a pak zkus optipng, sundá to na polovinu.

[Jendа]

Ten vyrobený obrázek je RGBA, ale i nastavení RGB pomůže jenom o trošku.

[Heron]

Většina grafických editorů a bohužel i konverzních nástrojů vůbec PNG neoptimalizuje. Dovoluje nastavit max míru komprese. Některé (FastStone) dovolují nastavit filter, ale jeden na celý obrázek. Takže po každé konverzi nebo exportu je dobré to prohrat optimalizátorem.

[David Ježek]

já bych dodal, že mě se už před hrmadou let osvědčil pngout od kena silvermana. je něco lepšího?

[DaBler]

Ten pngout neznám. Používal jsem pngcrush, optipng a zopflipng. Zopflipng je ve všech případech nejlepší, ale taky trvá obludně dlouho. Oproti tomu optipng je vcelku rychlé a odvede dobrou práci.

[Heron]

Zopflipng je ve všech případech nejlepší, ale taky trvá obludně dlouho.

Já jsem zkoušel tebou doporučené parametry a jelo to hodinu. Potom jsem to stopnul. Nějakej 2MPx screenshot ze hry. To je asi dost nepoužitelné.

optipng -o7 trvá tak minuty. I obyčejný imagemagick convert -quality 100 odvede velmi dobrou práci v jednotkách sekund. (Optipng to zmenší tak o 2%, což už asi nemá smysl řešit.)

pngout má zásadní nevýhodu. Není v žádné distribuci. Ani v BSD portech. To by musel být fakt unikátní zázrak, aby si to lidi kompilovali.

[petr_p]

Jestli myslíš tenhle pngout, tak bude asi tím, že to není z čeho zkompilovat.

[O.V.]

No ono to bude tim, ze PngOut neni open source. Kadopadne binarky jsou k dispozici treba v brew.

brew install jonof/kenutils/pngout

[O.V.]

Dik za tip na ten pngout. I kdyz je to zoufale pomale tak nekdy pekne zabere. Moc se mi libi ze u RGB palety zjisti ze vlastne se pouziva jen 50ty shades of gray. Na nejake davkove spracovani to moc neni, ale pro jednorazove optimalizace kde cas nehraje roli proc ne.

[BioGaia]

Trochu offtopic, skvely clanek porovnani ztratoveho algoritmu AVIF - https://jakearchibald.com/2020/avif-has-landed/

[❗Červivý Hřib krade❗]

tam na tý stránce nevidim nikde rgb24 :O :O

vidim jenom rgb8 a rgb16

[DaBler]

Ještě by tam mohlo být RGB888 ;)

[❗Červivý Hřib krade❗]

nj to mi jako taky mohlo dojít :D

ale stejně chci svejch 72bpp :D :D ;D ;D

[regine]

TIFF - historicky býval nejpouživačnější, hodně existujících archivů. Mám na CD/DVD z fotolabů hodně do TIFF naskovaných negativů.

TIFF soubory, využívající bezeztrátovou kompresi

[_]

Problém TIFFu je, že spíš než formát je to obrovská skupina formátů s obrovským prostorem prostorem pro vzájemnou nekompatibilitu. To je formát spíš pro specializované užití, kde máš prostor definovat různé datové vrstvy a speciální metadata atd. Lékařská data, zpracování obrazu ve vědě apod. A vlastně i ta komprese může být různá, klidně může být v TIFFu použita JPG komprese.

Pro běžného uživatele imho overkill.

[Jendа]

A nebo JBIG2, což vedlo na nejeden clusterfuck.

TIFF je kontejner, takže samotná informace „mám obrázky v TIFFu“ je podobná jako „mám video v Matrosce“. Neříká to mnoho o použitém formátu či kompresi.

[DaBler]

Protože někteří zde v diskuzi namítali, že PNG na fotky dělané není, aktualizoval jsem blogový zápisek a přidal do něj srovnání na ilustracích. Jako dva nejlepší formáty se v tomto případě ukazují WebP2 a FLIF.

[kvr]

Dík! Je vidět, že ta čísla jsou najednou o dost jinde. Ještě by se ty kategorie daly pořád rozdělit, kresby, diagramy a mapy jsou pořád dost jiné.

Ohledně diagramů - tam by vůbec byl nejlepší SVG, velikost bude podobná (v závislosti na antialiasingu), ale hlavní výhoda bude v možnosti zvětšení...