Our Default JPEG Setting Lost Above Quality 60
The tuned quantisation table is meant to hold up under heavy compression. Across 320 images at quality 40 to 90 it scored lower everywhere, and was bigger above 60.
Our compression page defaults to a setting called Balanced. It uses Mozjpeg's tuned quantisation tables. The reasoning behind those tables is that they degrade more gracefully when you compress hard. That is what "tuned" means in this context.
Last week we found that at quality 90 it loses to the plain standard tables on both size and score. That was surprising enough that we assumed we had caught it at a bad point on the curve. So we tested the rest of the curve. The first run, and the three interface claims it broke, is here. If you are picking a quality value rather than a table, this is the more useful piece.
The assumption was wrong in a specific way. The tuned table does do what it claims about size: below quality 60 it produces smaller files than the standard one. But it scores lower at every quality we tested, and above 60 it is bigger as well.
What we measured
Same 320 reference images as the last test, same preprocessing: longest side 768 px, saved as PNG, and that PNG is what everything is scored against.
Each reference was encoded at quality 40, 50, 60 and 70, twice: once with the tuned tables and once with the standard ones. Everything else was held identical. The numbers for quality 90 come from the earlier run, on the same images and the same references, so the whole curve is comparable.
Parameters come from src/engine/encode-options.js, the file the site runs, and the metric is SSIMULACRA2 again.
The curve
- q40: tuned 73.0 KB / 60.44 · standard 75.1 KB / 62.89: tuned is 2.9% smaller, scores 2.45 lower
- q50: tuned 86.5 KB / 65.71 · standard 87.7 KB / 67.38: tuned is 1.4% smaller, scores 1.67 lower
- q60: tuned 101.3 KB / 69.64 · standard 101.2 KB / 70.82: dead even on size, scores 1.18 lower
- q70: tuned 122.9 KB / 74.23 · standard 121.2 KB / 75.05: tuned is 1.4% larger, scores 0.82 lower
- q90: tuned 243.1 KB / 86.12 · standard 225.4 KB / 86.74: tuned is 7.3% larger, scores 0.62 lower
Two things stand out. The score gap shrinks as quality rises, and the size gap crosses over at around 60.
What the tuned table actually buys
Below quality 60, it buys about 1.5 to 3 percent of file size. It pays for that with a lower score. A real trade, not a free win. If you are compressing hard because a limit forces you to, that trade might be the right one.
Above quality 60, it buys nothing. There is no size saving and the score is lower. From the point where quality matters more than bytes, which is where most people sit, the standard tables dominate.
Our default sits at quality 80, above the crossover. So the setting we put in front of everyone was the one that is worse on both axes at the position we set it to.
The guess we had, and why it was wrong
Last week we wrote that the tuned table's advantage should show up at low quality, where images are being squeezed hard, and that this would explain why it looked worse at 90.
It does produce smaller files there. It does not look better. We had assumed that "designed for heavy compression" meant "higher quality at the same nominal setting". What it actually means is "smaller at the same nominal setting". Those are different claims, and only one of them is true.
This is the second time in two tests that our writing predicted the wrong direction. It is worth noticing that both times the guess was plausible and the measurement was not optional.
What we changed
The default algorithm is now Size (the standard tables), not Balanced. Balanced stays available for the case it is actually good at: compressing hard and accepting a lower score for a smaller file.
The captions were rewritten to match the curve rather than the single number they used to carry. Balanced's caption no longer claims to be the best trade-off, because it is not one.
The part we are not sure about
SSIMULACRA2 is one metric. It correlates well with human judgement on average, and "on average" is doing work in that sentence. It is possible that the tuned tables are better at something the metric does not see. Rings and blocking in flat gradients are the usual candidates.
If you have an opinion after looking at real images side by side, the address on the about page reaches a person, and we will publish a correction with your example if it contradicts this.
Caveats
768 px images. Most photos people compress are larger.
One library of sources, mostly already-compressed JPEGs, so this is the cost of a second pass.
One build of mozjpeg. Its tables and its trellis code both change between releases.
And five quality points is a curve sketch, not a curve. The crossover is somewhere between 50 and 60 by our data; we did not refine it, and we are not going to claim a precise number we did not measure.
Reproducing it
tools/measure-tables-by-quality.mjs reuses the reference images written by tools/measure-encoders-wide.mjs, so run that one first. Then pass a comma-separated quality list. It took about ten minutes for 320 images across four qualities and two settings.
Per-image numbers are in the JSON the script writes. The summary behind this article is in docs/measurements/tables-by-quality.json.