butteraugli

This seems to be optimizing for a "perceptual loss function" over in https://github.com/google/butteraugli/blob/master/butteraugl... Looking at the code to that, it looks like 1500 lines of this: double MaskDcB(double delta) { PROFILER_FUNC; static const double extmul = 0.349376011816; static const double extoff = -0.894711072781; static const double offset = 0.901647926679; static const double scaler = 0.380086095024; static const double mul = 18.0373825149; static const std::array<double, 512> lut = MakeMask(extmul, extoff, mul, offset, scaler); return InterpolateClampNegative(lut.data(), lut.size(), delta); } The code has hundreds of high precision constants. Some even seem to be set to nonsensical values (like kGamma to 0.38) Where did all of them come from? The re

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

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