This announcement makes sense to me, having done something similar before personally (1). The difference between a screenshot of a photo saved as a PNG and a JPG is huge, usually over 1MB, and I'm sure Twitter gets plenty of these.
Publishing their thresholds for the JPG vs PNG size comparison instead of referring to it just an internal metric would clear up some disconnect. Plus, I'd love to improve the static values I chose if there is better data available. I doubt the people working on this project wanted to change any PNG unless it's clear cut but the line has to go somewhere. These will be better handled by JPG.
Numbers about avg file size would be awesome too, how much data will this save in a typical user session?
(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.
Mixed emotions... after the free upgrade to 2GB, I feel like I'll be losing something. But saving $10/month is probably worth it for my low-traffic sites. And I was running at 1GB just a few months ago anyway!
Publishing their thresholds for the JPG vs PNG size comparison instead of referring to it just an internal metric would clear up some disconnect. Plus, I'd love to improve the static values I chose if there is better data available. I doubt the people working on this project wanted to change any PNG unless it's clear cut but the line has to go somewhere. These will be better handled by JPG.
Numbers about avg file size would be awesome too, how much data will this save in a typical user session?
1 - https://engineeringblog.yelp.com/2017/06/making-photos-small... (Section: Large PNG Detection)