Re:Guetzli JPEG encoder
by pornel on Thursday January 12, 2017 @06:11AM
(#13381370)
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)
Re:Guetzli JPEG encoder
by ZeroGravitas on Thursday January 12, 2017 @08:51AM
(#13382140)
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?
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.
Re:Guetzli JPEG encoder
by mrob on Thursday January 12, 2017 @05:01PM
(#13386546)
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.
Re:Guetzli JPEG encoder
by youngtaff on Thursday January 12, 2017 @05:12AM
(#13381167)
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 "
Re:Guetzli JPEG encoder
by ksec on Thursday January 12, 2017 @07:25AM
(#13381683)
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.
Re:Guetzli JPEG encoder
by Veratyr on Thursday January 12, 2017 @01:04PM
(#13384536)
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.
Re:Guetzli JPEG encoder
by ksec on Friday January 13, 2017 @09:22PM
(#13396476)
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.
Re:Guetzli JPEG encoder
by ZeroGravitas on Thursday January 12, 2017 @05:40AM
(#13381266)
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:
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
Is it a limitation of their tool, or are they intending this for sorta-visually-lossless storage of photographs or something?
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.
[1]: https://github.com/google/brotli
[2]: https://github.com/google/gipfeli
"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...
https://github.com/google/guetzli/graphs/contributors
It seems the authors will explain the details behind soon.
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.
I really wish .bpg takes off. But with all the patents issues It seems nothing much is happening.
(And, haha, WebP)
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