Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automatic chroma subsampling level #183

Open
kornelski opened this issue Jul 25, 2015 · 6 comments
Open

Automatic chroma subsampling level #183

kornelski opened this issue Jul 25, 2015 · 6 comments

Comments

@kornelski
Copy link
Member

Chroma subsampling gives nice file size savings, but there are cases where it goes horribly wrong, e.g. thin red lines.

It would be great if mozjpeg had heuristics to detect when subsampling is appropriate, taking into account contrast in chroma channels (especially the the one responsible for red color).

@kornelski
Copy link
Member Author

Does anybody know if there was any research done in this area?

I'm wondering whether it's enough to have a threshold based on mean square error with half-resolution image, or does it need to be smarter.

And how much and when luma can mask errors in chroma?

http://infoscience.epfl.ch/record/33957/files/33957-SüsstrunkW04.pdf — has measure of "colorfulness" lost due to subsampling

@jrmsmith
Copy link

Have you checked tis paper: PSNR-based optimization of JPEG baseline compression on color images?

On the plus side the paper is 10 years old and I haven't found the patent related to this paper.

@danielgtaylor
Copy link

I had to expose a chroma subsampling command line parameter recently and honestly it's kind of a pain to deal with. I'd love to see this be automatic. 👍

@kornelski
Copy link
Member Author

@jrmsmith That paper assumes distortion of subsampled image is just MSE of RGB channels, so it evaluates MSE(1x1 compression) vs MSE(2x2 compression) + MSE(scaling).

I think it could be improved by looking at MSE of Cb and Cr, with high weight on Cr (maybe even as high as R and B weights used for grayscale conversion)

The paper has a very interesting case: their algorithm chose to use subsampling on Goldhill

It's interesting, because in that case subsampling does make the red lines in the image look bad! But extra bits help textures on buildings look much better, so it's really hard to say what should be the correct subsampling.

s
t

@brunogm0
Copy link

brunogm0 commented May 10, 2017

Quality of RGB - YUV - RGB conversion

Nice test of subsampling patterns, but the sensitvity of a few test images could help this feature.

@magicgoose
Copy link

magicgoose commented May 2, 2018

I had the idea that one can test the perceptual similarity between the source and the subsampled image (round-trip to subsampled YUV and back), using small overlapped windows (for example, 64x64 blocks with 50% overlap in both dimensions) and taking the worst score.
Then, if the worst score is worse than some threshold, subsampling is not applied.

It's interesting, because in that case subsampling does make the red lines in the image look bad! But extra bits help textures on buildings look much better, so it's really hard to say what should be the correct subsampling.

It should somehow depend on the chosen quality level. At some point, the loss of subsampling becomes bigger than the gain from extra bits.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants