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

28.11.2020 17:38 | Přečteno: 2218× | Komprese | | poslední úprava: 1.12.2020 19:05

Poslední léta se s formáty pro kompresi obrazu a videa roztrhl pytel (z posledních třeba AV1 nebo VVC). Většina z nich je ale zaměřena na ztrátovou kompresi a bezeztrátový režim podporují jen okrajově. V tomto blogovém zápisku se zaměřím právě na bezeztrátové formáty a klíčovou otázku: „Který z nich je ten nejúčinnější?“

Ke srovnání byl použit dataset 14 obrázků ve vysokém rozlišení ve formátu RGB24. Nekomprimovaný obraz má tedy datový tok 24 bpp (bitů na pixel). Srovnával jsem následující formáty: PNG, JPEG 2000, WebP, H.265, FLIF, JPEG XR, AVIF a FFV1.

PNG

Čistě bezeztrátový formát z roku 1992 původně určený jako náhrada formátu GIF. Je založen na prediktoru následovaném slovníkovou kompresní metodou DEFLATE (kombinace LZ77 a Huffmanova kódování), kterou obvykle implementuje knihovna zlib. Komprese pomocí knihovny zlib je sama o sobě velmi pomalá. Existuje ale několik nástrojů, které umějí vyzkoušet různé parametrizace metody DEFLATE. Tím dosáhnou ještě o něco lepšího kompresního poměru něž zlib za cenu o několik řádů pomalejší komprese. Ve srovnání je použit nástroj zopflipng s parametry --iterations=500 --filters=01234mepb.

JPEG 2000

Formát z roku 2000 založený na diskrétní vlnkové transformaci následované aritmetickým kodérem. Tím se odlišuje od většiny ostatních kompresních metod, které jsou založeny na kódování chyby predikce. Umožňuje volbu bezeztrátové nebo ztrátové kompresní cesty. Komprese je oproti formátu PNG nesrovnatelně rychlejší. Existuje několik implementací tohoto formátu, z nichž za nejkvalitnější považuji komerční knihovnu Kakadu. Ke kompresi byla použita Kakadu verze 8.0.5 s parametry Cblk={64,64} Stiles={8192,8192} Creversible=yes Clayers=1 Clevels=5.

FFV1

FFV1 je bezeztrátový videokodek vyvinutý v rámci projektu FFmpeg původně v roce 2003. Formát je založen na jednoduchém prediktoru a aritmetickém kodéru (range coder). Technické detaily zde. Ke kompresi byl použit FFmpeg 4.3.1 s parametrem -c:v ffv1.

JPEG XR

JPEG XR (HD Photo) je formát z roku 2009 vyvinutý společností Microsoft. Formát nabízí bezeztrátový kompresní režim založený na hierarchické diskrétní kosinové transformaci (DCT) a Huffmanovu kódování. Ke kompresi byl použit referenční software s výchozími parametry.

WebP

WebP je kompresní formát z roku 2010 vyvinutý společností Google. Umožňuje volbu ztrátové nebo bezeztrátové komprese. Bezeztrátová varianta je založena na prediktoru následovaném kombinací LZ77 a Huffmanova kódování. Technické detaily zde. Ke kompresi je použit referenční nástroj cwebp s parametrem -lossless.

H.265

H.265 (také HEVC) je formát pro kompresi videa z roku 2013, který má podporu také pro bezeztrátovou kompresi. Ta je opět založena na prostorové predikci (bez použití DCT). Na jeho Intra profilu jsou založeny obrazové formáty HEIC a BPG. Ke kompresi používám knihovnu x265 verze 3.4 skrze framework FFmpeg s parametry -c:v libx265 -preset placebo -x265-params lossless=1.

FLIF

FLIF je bezeztrátový obrazový formát z roku 2015, který je silně inspirován formátem FFV1. Formát je založen na prediktoru a sofistikovaném aritmetickém kodéru MANIAC. Technické detaily zde (po přihlášení). Ke kompresi je použit referenční kodér s parametry -e -E100 -N -Q100.

AVIF

AVIF je založený na videoformátu AV1 z roku 2018. Nabízí ztrátovou i bezeztrátovou kompresi. Ve srovnání byla použita knihovna libavif verze 0.8.3 s parametry -l -c aom (libaom 2.0.0).

Výsledky

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

Ještě přesné výsledky (průměr přes celý dataset) v tabulce:

formát	datový tok [bpp]	kompresní poměr
PNG	11.461131	2.094034 : 1
JPEG 2000	10.620645	2.259749 : 1
WebP	10.619910	2.259906 : 1
H.265	12.460111	1.926146 : 1
FLIF	9.978515	2.405167 : 1
JPEG XR	11.575239	2.073391 : 1
AVIF	12.039541	1.993431 : 1
FFV1	10.267328	2.337511 : 1
WebP 2	10.007292	2.398251 : 1

Aktualizace

Přidávám ještě jeden experiment. Tentokrát jsem testoval kompresní výkon na ilustracích (tedy ne fotografiích).

Vítězem se stal WebP 2 a těsně za ním se umístil FLIF.

formát	datový tok [bpp]	kompresní poměr
PNG	4.628656	5.185090 : 1
JPEG 2000	6.094012	3.938292 : 1
WebP	4.294325	5.588771 : 1
H.265	7.158238	3.352780 : 1
FLIF	3.774639	6.358223 : 1
JPEG XR	8.097638	2.963827 : 1
AVIF	8.198868	2.927233 : 1
FFV1	5.333731	4.499664 : 1
WebP 2	3.621495	6.627097 : 1

       

Komentáře

[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).

[Pendrekama do nich❗]

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)

[Pendrekama do nich❗]

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/

[Pendrekama do nich❗]

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

vidim jenom rgb8 a rgb16

[DaBler]

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

[Pendrekama do nich❗]

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í...