
Guetzli JPEG encoder - josephscott
https://github.com/google/guetzli
======
pornel
The main innovation here is using advanced simulation of how humans perceive
distortions
([https://github.com/google/butteraugli](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](https://github.com/danielgtaylor/jpeg-archive)

~~~
ZeroGravitas
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?

------
mrob
I tried it with my favorite test image:
[https://commons.wikimedia.org/wiki/File%3ARicardo_Quaresma_%...](https://commons.wikimedia.org/wiki/File%3ARicardo_Quaresma_%28L%29%2C_Pablo_Zabaleta_%28R%29_%E2%80%93_Portugal_vs._Argentina%2C_9th_February_2011.jpg)
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.

~~~
mrob
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.

------
muhblah
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

~~~
piquadrat
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](https://github.com/google/brotli)

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

~~~
youngtaff
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/2313-Brotli?p=44950&viewfull=1#post44950)

------
KayL
[http://encode.ru/threads/2628-Guetzli-a-new-more-
psychovisua...](http://encode.ru/threads/2628-Guetzli-a-new-more-psychovisual-
JPEG-encoder)

It seems the authors will explain the details behind soon.

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

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

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

~~~
Veratyr
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.

~~~
ksec
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.

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

------
gcp
How does it compare to mozjpeg?

(And, haha, WebP)

~~~
ZeroGravitas
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](https://github.com/google/butteraugli)

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

