Colour bars exist because hard edges between saturated colours are where an encoder gets caught. Image: Chris319, Wikimedia Commons, CC BY-SA 4.0.
Colour bars exist because hard edges between saturated colours are where an encoder gets caught. Image: Chris319, Wikimedia Commons, CC BY-SA 4.0.
Eight real AI art files from this gallery, encoded across the subsampling ladder with the byte count and the pixel error recorded at every step. The setting everybody argues about turns out to be a wash, and the setting nobody changes is worth three times as much.
The last guide on this site ended with a caveat: every file in it was photographic, so line art, flat colour and anime style output would move the numbers and could reverse the conclusion. That caveat has been sitting there for a day. This is the answer to it.
Eight images were pulled straight off this gallery, all of them 1024 by 1024 AI output, and run through the chroma subsampling ladder. The question is the one that turns up in every encoder config and almost never gets measured: does turning chroma subsampling off actually cost you anything worth having.
A JPEG stores brightness and colour separately. Brightness, the luma channel, always gets stored at full resolution. Colour, the two chroma channels, can be thrown away at a lower resolution because human vision is much worse at resolving colour detail than brightness detail. 4:4:4 keeps colour at full resolution. 4:2:2 halves it horizontally. 4:2:0 halves it in both directions, so each colour sample covers four pixels. Almost every default in almost every tool is 4:2:0, which is why almost nobody has ever looked at what it buys.
Eight PNG sources from the live gallery, all 1024 by 1024, encoded straight to memory with Pillow at three subsampling modes and several quality settings. Nothing was written to disk, so the filesystem never touched a byte count. Every encoded file was decoded back and compared against the source pixels, and the error figure is the root mean square difference across all three channels on the 0 to 255 scale, sampled at a fixed stride across the whole image. Zero is pixel identical. Under 3 is invisible on a normal screen.
These sources are true PNGs rather than re-compressed JPEGs, so unlike the photographic test, no prior generation of lossy compression is baked into the error numbers here. That makes this the cleaner of the two experiments.
Total bytes across all eight images, at three quality settings.
| Quality | 4:4:4 | 4:2:2 | 4:2:0 |
|---|---|---|---|
| 75 | 1,187,646 | 1,068,022 (−10.07%) | 990,019 (−16.64%) |
| 82 | 1,461,249 | 1,301,945 (−10.90%) | 1,200,365 (−17.85%) |
| 90 | 2,045,212 | 1,808,277 (−11.58%) | 1,664,444 (−18.62%) |
So the honest headline number is 18.62 percent at quality 90. That is more than subsampling saves on photographs, where the same test on five photographic files came in at 11.19 percent, and the reason is not mysterious: AI output carries larger areas of saturated, smoothly varying colour than a photograph does, and that is exactly the content chroma subsampling eats cheaply.
The per image spread ran from 15.0 percent on the softest, most desaturated file to 21.7 percent on the most saturated one. Every single image saved something. None saved anything close to half.
Eighteen percent is a real saving. The question is whether it is the cheapest eighteen percent available, and it is not, because you can buy the same bytes by lowering quality instead and keeping colour at full resolution.
| Encoding | Mean size | Mean RMSE |
|---|---|---|
| JPEG q90, 4:4:4 | 255,652 bytes (249.7 KB) | 1.95 |
| JPEG q90, 4:2:0 | 208,056 bytes (203.2 KB) | 2.31 |
| JPEG q85, 4:4:4 | 203,397 bytes (198.6 KB) | 2.33 |
| JPEG q84, 4:4:4 | 195,762 bytes (191.2 KB) | 2.42 |
| JPEG q82, 4:4:4 | 182,656 bytes (178.4 KB) | 2.55 |
Read the two bolded rows. Quality 90 with 4:2:0 costs 208,056 bytes at an error of 2.31. Quality 85 with full chroma costs 203,397 bytes at an error of 2.33. That is 2.24 percent fewer bytes for 0.02 more error.
They are the same row. Two settings that look like completely different philosophies land within a rounding error of each other on both axes. Running it per image, the quality that makes 4:4:4 fit the 4:2:0 budget was 84, 85 or 87 depending on the file, with 85 hitting it on five of the eight.
Because RMSE cannot tell you where the error went, and the two settings put it in completely different places.
Dropping quality spreads a little more error across everything, mostly in the luma channel, mostly in high frequency texture. Subsampling puts almost all of its error in one place: colour boundaries. A hard edge between two saturated colours, which in AI art means hair against a background, a bright iris against sclera, a neon rim light against skin, is precisely where a chroma sample covering four pixels has to guess.
So the measurement says the two are equivalent and the eye does not, and that is not a contradiction. It is the known limitation of a single scalar error metric, and it is the reason this comparison is worth doing with your own gallery open next to it rather than trusting the number.
The practical read: if your output has hard saturated colour edges, take 4:4:4 at quality 85. If it is soft, painterly, low saturation work, 4:2:0 at quality 90 is free. Neither choice is worth an argument, because both land at roughly 200 KB.
Here is the number that should end the discussion. The same eight files, encoded as WebP at quality 80.
| Encoding | Mean size | Versus JPEG q90 4:2:0 |
|---|---|---|
| JPEG q90, 4:2:0 | 208,056 bytes | baseline |
| JPEG q85, 4:4:4 | 203,397 bytes | 2 percent smaller |
| WebP q80 | 85,764 bytes (83.8 KB) | 59 percent smaller |
Fifty nine percent. The per image range was 53.1 percent to 62.9 percent and every one of the eight came in above half.
That is more than three times what the entire subsampling decision is worth. Two people can spend an afternoon arguing 4:4:4 against 4:2:0, arrive at the correct answer, and capture 18 percent. Changing the container captures 59 percent and takes one line.
It is also a bigger WebP advantage than the same test found on photographs, where WebP q80 came in 31 to 39 percent below the JPEG. AI output compresses better in WebP than photographs do, which makes the case stronger here than on a stock gallery, not weaker.
Ship WebP q80 and stop thinking about it. Fifty nine percent smaller than the JPEG your pipeline currently produces, on this exact content, measured on these exact files.
If you keep a JPEG fallback, use 4:4:4 at quality 85 rather than 4:2:0 at 90. Same bytes, same measured error, and the error that remains sits in luma texture rather than on the colour edges that AI output is full of.
Do not turn subsampling off and leave quality at 90. That is the one genuinely bad option on the table: 255,652 bytes, 23 percent above the 4:2:0 file, to buy an RMSE improvement of 0.36 that WebP would have handed you for free while also removing 59 percent of the bytes.
Stop tuning JPEG. Every row in every table on this page sits between 178 KB and 256 KB. The WebP row sits at 84 KB. The entire JPEG parameter space is a 30 percent argument inside a 59 percent decision.
Open each PNG with Pillow, convert to RGB, then save into a BytesIO with format='JPEG', optimize=True, and subsampling=0, 1 or 2 for 4:4:4, 4:2:2 and 4:2:0 respectively. Read the buffer length for the byte count. For the error figure, seek the buffer back to zero, reopen it as an image, convert to RGB, and take the root mean square difference against the source bytes. The WebP row is the same loop with format='WEBP', quality=80, method=4.
Three caveats stay on the record. Eight images is a small sample and all eight came from one gallery with a broadly consistent style, so a different model or a different prompt vocabulary would move the numbers. The RMSE figure is sampled at a fixed stride rather than over every pixel, which is accurate in aggregate and can be off by a hundredth on a single file. And RMSE genuinely cannot see the difference between an error in luma texture and an error on a colour edge, which is the entire reason the 4:4:4 at 85 versus 4:2:0 at 90 comparison needs a human looking at it rather than a number.