(author here), It wasn't available when I started this project. butteraugli was (which guetzli uses internally), but in my opinion they're relatively new and need a bit more rigorous review than I can provide. I ultimately chose SSIM not because it was the most accurate metric in all cases, there have been plenty of advancements since it was published. But I linked a paper comparing several alternatives and saw that SSIM works fine for this use case (all things equal except number of JPEG artifacts), while being much faster, and that was enough proof for me to keep it simple.
In a batch scenario today, one of these could make sense instead of SSIM and/or mozjpeg, but definitely do your own comparisons at equivalent file sizes, required reading: https://kornel.ski/en/faircomparison
We do set a pretty high lower bound to avoid the edge cases inherent in the algorithm and as a result, out of the 30% savings, dynamic quality was only a small portion of that. I wouldn't be surprised that with an offline workload, a more CPU-intensive algorithm can do much better with a lower lower bound.
I found that SSIM scores for images were relatively stable across resolution (same general graph shape, just translated down on the Y-axis). This is mentioned at line 36 of the example dynamic quality code. So we actually generate, compute and compare the SSIMs on much lower resolution candidate images than the final image for speed as well. I'm not sure if this would hold true for something like butteraugli to help open up the possibility for more real-time workloads.
Because it's HORRIBLY slow. Mozjpeg is actually usable for on-the-fly processing, you can run it right in a request handler. Guetzli is waaaay too slow.
Agreed. As a photographer, I use and love Guetzli, and it offers a bona fide size reduction of more than 30% over typical JPEG compression algorithms at a similar visual quality level.
But it's extremely computationally-intensive, taking over a minute to compress a single web-resolution image on my i7 laptop.
I can't see it being practical in a high-volume server scenario.
