Guetzli JPEG encoder | Hacker News Reader

Guetzli JPEG encoder

github.com

81 pointsjosephscott19 comments

The main innovation here is using advanced simulation of how humans perceive distortions (https://github.com/google/butteraugli) and optimizing to that. In principle JPEG was always about removing details humans can't see, but in practice encoders used rough approximations and fixed quality settings. This one goes all-in on accurate measurement and tuning quality settings per image automatically.

In lossy compression quality setting affects file size much more than choice of image format (e.g. there's 15-30% difference in best quality/filesize between old codecs like JPEG/J2K/VP8/JXR, but within each codec's settings range the file size can vary by 300%), so having a codec that picks the lowest good-enough quality is very useful.

Compared to MozJPEG:

- it's tuned for higher-quality images (butteraugli is said to be best for q=90+, MozJPEG's sweet spot is around q=75)

- it's much slower to compress (both produce standard JPEGs, so decoding is fast as usual)

- MozJPEG doesn't automagically pick quality setting, but you can find optimal quality using an external tool, e.g. https://github.com/danielgtaylor/jpeg-archive

It would be cool if you could share your findings here too! - https://github.com/google/guetzli/issues/10

Any thoughts on why they tuned for the 90-95 range? General rules of thumb you find on the internet would suggest mozJPEG is targetting a more useful sweet spot for serving images on the web.

Is it a limitation of their tool, or are they intending this for sorta-visually-lossless storage of photographs or something?

I tried it with my favorite test image: https://commons.wikimedia.org/wiki/File%3ARicardo_Quaresma_%... downsampled to 1280x853 in ImageMagick.

This image is difficult for lossy compressors, because it contains some very unusual chroma signal, with the red dots on the green stripe on the red shirt. Mozjpeg does a slightly better job of preserving the dots at the almost same bitrate (as close as I can get to Guetzli quality 90), but only if you manually specify full chroma resolution. Guetzli does not allow manually choosing the chroma resolution but at least it does not totally destroy the dots by default like Mozjpeg does.

I just found out that Mozjpeg uses arithmetic coding and Guetzli doesn't, so this wasn't a fair comparison. After repacking the Guetzli image using jpegtran the subjective quality at the same bitrate is so similar I can't pick a winner.

I'm pretty sure this encoder is written by a Google employee based in Zurich, like me (but I don't work for Google) ;D

Well the list of contributors is no secret:

https://github.com/google/guetzli/graphs/contributors

Also, it's in line with Brotli[1] and Gipfeli[2], other compression libraries/formats from Google bearing names of Swiss pastries.

[1]: https://github.com/google/brotli

[2]: https://github.com/google/gipfeli

Someone predicted this is Sept 2015

"The names of Google compressors sound so funny: Zopfli, Brotli, ... the next ones will be called Guetzli, Brunsli, Kägi-Fretli, Schoggli oder Läckerli "

http://encode.ru/threads/2313-Brotli?p=44950&viewfull=1#post...

http://encode.ru/threads/2628-Guetzli-a-new-more-psychovisua...

It seems the authors will explain the details behind soon.

It would be really nice if there were comparison images linked in the readme so we could examine them before testing the claim ourselves.

I always laugh about these names. They sound so funny:

Butteräugli = little butter eye

Brötli = little bread roll

Zöpfli = little plaited buttery bread

Gipfeli = little croissant

Güetzli = little home-made cookie

And they even look more funny without the umlauts. They seem a little bit broken without them. Therefore:

Brotli = little bread roll but slightly damaged

Zopfli = little plaited buttery bread but slightly damaged

and so on. But this is only my personal impression.

It is amazing how much more quality improvement we can extract from an decade old codec. In video codec timeline, Jpeg is like in the era of Mpeg-1. And we have Mpeg-2, Mpeg 4 ( Divx / Xvid ), Mpeg 4 AVC, and now HEVC.

I really wish .bpg takes off. But with all the patents issues It seems nothing much is happening.

I'm sure we'll get another image format based on the I-frame compression from a video codec but I agree that BPG is unlikely. More likely is we get something from AV1, which should be patent unencumbered and hopefully perform better.

It wont perform better as we already know that. Given how Internet, and now smartphone is video and image driven, i really wish there is an breakthrough in Video and Image technology. Something that compress the best of Jpeg in 1/10th of its size, but would require either dedicated HW or high end CPU to decode.

does it build custom quantization tables? quick look at the code says no :/

How does it compare to mozjpeg?

(And, haha, WebP)

And the key question here is "What objective measures are they using to make these comparisons?" since testing every change against a scientifically valid subjective test with human subjects is impractical on many levels.

If they have a bad measure, they could be fooling themselves into making things worse, if they have a good measure then lots of people could benefit from tweaking their graphic algorithms to do better against this measure.

The fact that they seem to be putting the code before the justification worries me. Most recent efforts in codec and compression seem to spend a great deal of time and energy on getting this right, as it affects every single decision you make afterwards.

edit: someone else posted a link where this question is answered, they're using this measure:

https://github.com/google/butteraugli

Take note, this is from Google so they will use it for PageSpeed calculation.

Reply on news.ycombinator.com