Guetzli, nový JPEG enkodér od Googlu

Google představil nový JPEG enkodér s názvem Guetzli. Obrázky typu JPEG vytvořené pomocí Guetzli mohou být až o 35 % menší. Podrobný popis na arXiv.org. Zdrojové kódy na GitHubu.

16.3.2017 23:55 | Ladislav Hagara | Zajímavý software

Komentáře

[Petr]

Problém je, že se tyhle věci většinou nedostanou do grafických programů a tak není jak ty obrázky vyrábět a výhody využít. WebP neuloží Gimp ani jiný sw co mám, tohle dopadne stejně, nikdo se nebude namáhat to implementovat.

[Rox]

Pisi tam taky, ze je to pomale a spis proof-of-concept. Vzdy muzes gimpem exportovat do png a udelat jpg externim nastrojem. Je to podobne jako png optimizatory, neni nutno optimalizovat kazdy obrazek.

[Grunt]

Když už nic tak GIMP od verze 2.9 má v jpeg export plug-inu volbu pro aritmetické kódování. Problém je že jediné co takový JPEG otevře je zase to co je nalinkované na systémový libjpeg s povoleným aritmetickým kódováním, takže v jiných operačních systémech a tam kde je libjpeg přibundlovaný prostě smůla. Ale jinak i všechny tyhle optimalizované verze jsou implementované v IJG API, takže stačí přelinkovat a mělo by to fungovat v libovolném nástroji.

[Ovoce]

XnView MP podporuje ukládání i čtení webp. Ale je to pomalý jak svině. Osobně to používám jenom pro lossless obrázky (zabere míň místa než PNG nebo J2K).

[pushkin]

Obrázky typu JPEG vytvořené pomocí Guetzli mohou být až o 35 % menší.

Při jaké kvalitě?

[Trubicoid2]

Při stejné kvalitě, kterou měří svojí metrikou

Ale není to progressive, jen baseline a je to pomalý a chce 300MB RÁM na 1MPixel

[roumen]

> chce 300MB RÁM na 1MPixel

Tak pokud mas web s milionem navstevniku a usetris 35% traffic na obrazcich, tak to za to stoji. Pro bezny plebs je to ale v zasade nepodstatne.

[trubicoid2]

treba roumen.cz? :)))

jinak guetzli dela jenom baseline, nedela progressive jako treba mozjpeg, asi casto bude progressive s mozjpeg mensi

navic mozjpeg by mel konvertovat bezestratove, v guetzli si nastavis, jakou jpg kvalitu chces a kdyz to cislo bude vetsi, nez v originale, tak nic neusetris a kdyz bude nizsi, tak zase obrazek bude hnusnejsi

[helb]

v guetzli si nastavis, jakou jpg kvalitu chces a kdyz to cislo bude vetsi, nez v originale, tak nic neusetris a kdyz bude nizsi, tak zase obrazek bude hnusnejsi

Takhle nejak to je i u toho mozjpegu:

-quality N[,...]  Scale quantization tables to adjust image quality.
                  Quality is 0 (worst) to 100 (best); default is 75.

Usetrit tim jde opravdu docela dost. Pouzivam ho pres sorl-thumbnail a optisorl na webu se zhruba milionem a pul navstev za mesic (neni to rouming :)).

Proti predchozimu „neoptimalizacnimu“ konventoru (pillow a imagemagick) to usetri kolem 200-300 GB mesicne. Generuju vic velikosti a prohlizeci je podstrkuju pres srcset. I na mobilnim pripojeni se to tak nacita celkem svizne, s HTTP2 jeste o neco lip.

Naroky na pamet a CPU nejsou nijak hrozny a to to bezi na celkem levny VPSce… Tech 300MB/1Mpx je dost, ale velkym webum s odpovidajicim zazemim by se vyplatilo i to.

[trubicoid2]

Takhle nejak to je i u toho mozjpegu:

no já měl na mysli jpegtran z mozjpeg, ten parametr -quality ani nemá, tedy bezeztrátově optimalizuje jpeg a oproti guetzli umí -progressive

parametr -quality má cjpeg, ale to překódování zhoršuje kvalitu, což může někdy vadit

[Grunt]

Úplně stejné akorát to má menší ringing, jsou-li v bloku ostré hrany (takže nižší SSIM a marketing z toho vykouzlí 35% file size nižší).

[Grunt]

Butteraugli, our perceptual distance metric, as the source of feedback in its optimization process. We reach a 29-45% reduction in data size for a given perceptual distance

Hmm, OK.

[Grunt]

Přílohy:

• orig.png (971740 bytů)
• guetzli_optimized.jpg (103372 bytů)
• libjpeg.jpg (104280 bytů)

No, o něco malilinko lepší to asi je, zvlášť když se to spřáhne ještě s aritmetickým kódováním, ale jestli už někam cpu 100kB nebo 130kB JPEG asi moc běžného smrtelníka netíží. Tohle je dobré opravdu pro Google.

Jinak:

Guetzli should be called with quality >= 84, otherwise the
output will have noticeable artifacts. If you want to
proceed anyway, please edit the source code.
Guetzli processing failed

[andree]

guetzli mi neotvori mozilla ani chromium...

[Grunt]

Je to JPEG s aritmetickým kódováním místo Huffmana. Otevři si to třeba v GIMPu. Pod Linuxem mi to krom GNOMu zvládnou veškeré nástroje (vč prohlížeče).

[Ovoce]

Jako fakt? Tak to by byl docela i pokrok, ale osobně bych řekl že když už se rozbíjí kompatibilita, tak měli přijít s novým formátem - HEVC, nebo webpíp založeným na AV1.

[Grunt]

Příloha:

• Snímek z 2017-03-19 20-40-20.png (746243 bytů)

Čestné skautské. Je to novinka v GIMP unstable (v2.9). Zkus a uvidíš.

[chrono]

Viac zaujímavé je to asi pre väčšie obrázky (nejaká ukážka je napr. tu; originál je mierne ostrejší, ale len keď sa hľadajú jednotlivé výrazné body a to je rozdiel vo veľkosti súborov obrovský)

[Grunt]

To si nemyslím. Čím větší obrázek o to mín v něm ten ringing vadí, protože je maskován a míň vnímatelný.