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

Feature request: Quality-optimized subsampling #168

Open
tdaede opened this issue Feb 15, 2022 · 2 comments
Open

Feature request: Quality-optimized subsampling #168

tdaede opened this issue Feb 15, 2022 · 2 comments

Comments

@tdaede
Copy link

tdaede commented Feb 15, 2022

There are methods for producing 4:2:0 subsampled video that aim to provide more optimal results once displayed (both subjectively, and via cross-coefficient PSNR and CIEDE2000 metrics):

https://norkin.org/pdf/SPIE_2016_HDR_conversion_metrics.pdf

Despite the HDR title, the methods are also useful for SDR content. The paper provides 3 methods, of which the "Closed Form 1" method is probably most suitable for a SIMD implementation.

Also, these algorithms currently only perturb the luma coefficient. This helps make the problem tractable but there are likely better algorithms that could potentially generate better chroma values as well.

HDRTools also has an open source implementation that can be checked against (HDRTools is more a reference implementation rather than a practical library like zimg).

@tdaede
Copy link
Author

tdaede commented Apr 7, 2022

Yes, this is specifically for encoding only (or slightly more generally, when downsampling chroma).

The method in the paper converts RGB->YUV and does the downsample in one step. This doesn't map well to any of the existing zimg filter types. A YUV->YUV filter type can also be derived fairly efficiently as long as the colorspace is known, and the input is non constant luminance. I don't know if that would be worth implementing over simply forcing a conversion to RGB with an existing colorspace filter, though.

@Artoria2e5
Copy link

The webp people has a different, iterative thing that touches not just luma. It's available as a a libyuvsharp your program can link to, but it's only intended for static images given the speed.

mozilla/mozjpeg#193 is related

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

No branches or pull requests

3 participants
@tdaede @Artoria2e5 and others