Every compressor, including one I built, carries a set of claims in its interface. "Tuned quantisation tables." "Lossless." "Higher quality." I had repeated all five of these without measuring any of them, so I spent a few evenings measuring them on 320 real images with SSIMULACRA2 against the decoded original.
Three of the five did not survive contact.
1. "Tuned quantisation tables produce better files"
Mozjpeg ships two sets of tables: baseline, and a "tuned" set that is supposed to be better.
At quality 90, on the same 320 images, the tuned tables needed 8.3% more bytes and scored 0.6 points lower. Not a trade-off, a straight loss.
The reason is visible once you plot the whole curve. The tuned tables are optimised for heavy compression, where blocking artifacts dominate. Below quality 60 they do win. Above it the curves cross and never come back. A preset named "balanced" that is worse on both axes at the quality most people pick is not balanced.
2. "Converting between formats is roughly free"
Take a JPEG, encode it to WebP at quality 90, decode it, encode it back to JPEG at 90. Compare that against encoding the original straight to JPEG at 90. Same final format, same quality, same encoder. The only difference is the detour.
Cost: 8.20 points on average, and it was worse on all 320 images.
Meanwhile the WebP really was 32.9% smaller. So WebP is not the problem. The problem is the round trip, and the returned JPEG is 9.4% smaller than the control, which is the part that fools people. It is smaller because there is less in it.
3. "If a file looks bad, re-save it at higher quality"
This is the one that surprised me. Take a JPEG compressed at quality 45. Re-save it at 90. You would expect recovery, or at best no change.
All 320 images came out slightly worse, by 0.43 points on average. And the file went from 96.3 KB to 183.7 KB, which is 90.9% larger, for a result that still sits 20.5 points below a clean encode from the original.
A quality-45 image is full of compression artifacts. An encoder at quality 90 cannot tell them from detail, so it spends bits reproducing them faithfully, then quantises again on the way out. You pay twice and lose a fraction.
4. "PNG recompression is lossless, so nothing changes"
This one mostly held. On 261 PNG files, oxipng saved 12.7% at the median, and 253 of 261 came back byte-identical in RGBA.
The other 8 were cut-out product images with transparent backgrounds. In all 8 the difference was colour values stored underneath fully transparent pixels. Zero visible pixels changed, and composited over white every one was byte-identical to the original. So the claim is true at the level that matters and false at the level of "the bytes are the same", which is a distinction worth making rather than glossing.
5. "Photos leak your location"
I scanned 1,086 JPEGs from my own folders.
Zero had usable GPS coordinates. 32% had some EXIF at all, 20.6% XMP, 20% ICC.
What the scan did find was metadata that nobody thinks about: the largest single file had 90.7% of its bytes in the metadata block, over 2 MB of thumbnail and edit history attached to a small image. The privacy story is real, but it is about size and editing history far more than about coordinates.
The data
All five measurements, plus the encoder preset comparison, are downloadable as JSON under CC BY 4.0, one file per study with per-image records where the study produced them:
compressdog.com/measurements/datasets
Five of the six have per-file rows. The metadata scan is aggregate only, and says so on the page. If you rerun any of them and get a different answer, I would like to hear about it: the scripts are named on each article, and the caveats are on the page rather than buried.
The one thing I would ask is that if you cite a number, link the datasets page rather than the JSON file. That way a reader can find the method and the limits along with the figure.
Top comments (0)