8 ms·

Guetzli JPEG encoder

81 points by josephscott 10y ago

Roritharr 10y ago
It would be really nice if there were comparison images linked in the readme so we could examine them before testing the claim ourselves.
KayL 10y ago
http://encode.ru/threads/2628-Guetzli-a-new-more-psychovisual-JPEG-encoder http://encode.ru/threads/2628-Guetzli-a-new-more-psychovisua... It seems the authors will explain the details behind soon.
muhblah 10y ago
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
- d33 10y ago
  Well the list of contributors is no secret: https://github.com/google/guetzli/graphs/contributors https://github.com/google/guetzli/graphs/contributors
- piquadrat 10y ago
  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 10y ago
    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#post44950 http://encode.ru/threads/2313-Brotli?p=44950&viewfull=1#post...
gcp 10y ago
How does it compare to mozjpeg? (And, haha, WebP)
- ZeroGravitas 10y ago
  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 10y ago
Take note, this is from Google so they will use it for PageSpeed calculation.
pornel 10y ago
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
- inian 10y ago
  It would be cool if you could share your findings here too! - https://github.com/google/guetzli/issues/10 https://github.com/google/guetzli/issues/10
- ZeroGravitas 10y ago
  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 10y ago
I tried it with my favorite test image: 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 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.
- mrob 10y ago
  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.
ksec 10y ago
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 10y ago
  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 10y ago
    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.
_nalply 10y ago
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.
rasz_pl 10y ago
does it build custom quantization tables? quick look at the code says no :/

81 points by josephscott 10y ago

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

KayL 10y ago

http://encode.ru/threads/2628-Guetzli-a-new-more-psychovisual-JPEG-encoder http://encode.ru/threads/2628-Guetzli-a-new-more-psychovisua... It seems the authors will explain the details behind soon.

muhblah 10y ago

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

d33 10y ago
Well the list of contributors is no secret: https://github.com/google/guetzli/graphs/contributors https://github.com/google/guetzli/graphs/contributors
piquadrat 10y ago
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 10y ago
  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#post44950 http://encode.ru/threads/2313-Brotli?p=44950&viewfull=1#post...

gcp 10y ago

How does it compare to mozjpeg? (And, haha, WebP)

ZeroGravitas 10y ago
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 10y ago

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

pornel 10y ago

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

inian 10y ago
It would be cool if you could share your findings here too! - https://github.com/google/guetzli/issues/10 https://github.com/google/guetzli/issues/10
ZeroGravitas 10y ago
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 10y ago

I tried it with my favorite test image: 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 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.

mrob 10y ago
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.

ksec 10y ago

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 10y ago
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 10y ago
  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.

_nalply 10y ago

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.

rasz_pl 10y ago

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