News for hackers. Stuff that matters.
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)

- 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

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?

Re:Guetzli JPEG encoder by inian on Thursday January 12, 2017 @07:16AM (#13381649)
It would be cool if you could share your findings here too! - https://github.com/google/guetzli/issues/10