Skip to content

Comment on Impressive JPEG Recompression

Comments

I once worked somewhere where we had a need to store and transmit lots of camera created jpegs in as efficient a manner as possible.

When working on this problem, I noticed that all digital cameras create jpeg with 422 sampling. This might be a religious topic for some, but I cannot see any visual difference between 4:2:2 and 4:2:0, even with high magnification or on physical prints as large as 30 inch height. Simply sub-sampling to 4:2:0 along with subtle tweaks to quantization tables and with little effort we'd bring a typical jpeg from 1-2MB down to 300-400KB.

We even did a series of experiments with people who look at photo prints all day and they could not reliably pick the 'recompressed' images.

The only reason I think people really hold on to 422 or even 444 is that when subsampling you can get nasty amplified errors if you are using two tools that sampling with different algorithms or from different siting (i.e. imaging if one tool picked odd lines and one picked even). Although the spec specifies siting, I think there are still people who do it wrong, not to mention there is still leeway for interpretation on how pixels are averaged for siting that is not on a pixel boundary.

Bottom line is that if you know exactly what you are going to do with the photo in the future you can compress a lot and quite easily with little risk. If you have a lot of unknown processing in the future, things can get dicey.

For those wondering about the differences between 4:2:2 and 4:2:0, check out http://en.wikipedia.org/wiki/Chroma_subsampling#4:2:0

4:4:4 sampling is necessary to preserve color distinction in screenshots (otherwise your icons and text may change color), but since very few photographs will have single-pixel color variation, 4:2:0 is usually sufficient. Don't get me started on 4:1:1, though... I'm glad to be rid of the chromatic curse that was miniDV.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.