3 ms·
The main innovation here is using advanced simulation of how humans perceive distortions (https://github.com/google/butteraugli https://github.com/google/butter
by 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 agoIt 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 agoAny 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?