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

HDR support #10

Open
da2x opened this issue Jan 17, 2021 · 10 comments
Open

HDR support #10

da2x opened this issue Jan 17, 2021 · 10 comments

Comments

@da2x
Copy link

da2x commented Jan 17, 2021

Hi, any chance you could add support for 10 and 12-bit color depth, please? Either switching automatically based on the source image or using a command argument.

I’ve experimented with it in link-u/cavif, and the files are only 1–2 % bigger and still way smaller than the 8-bit JPEG/WebP equivalent.

@kornelski
Copy link
Owner

Yeah, that's doable.

@gitoss
Copy link

gitoss commented Apr 4, 2021

Yeah, that's doable.

+1 for this request, 10bit shows better performance even for 8bit sources

Libavif does 10bit, but releases or binaries around don't include rav1e (yet) :-\

@Ralith
Copy link

Ralith commented Nov 3, 2021

HDR metadata support would go nicely with this!

@kornelski
Copy link
Owner

I don't understand how HDR metadata support would help generating correct HDR files.

This crate supports JPEG and PNG as input, and AFAIK neither of these are good for HDR. I can put HDR metadata, but how do you get HDR pixels in?

@Ralith
Copy link

Ralith commented Nov 20, 2021

My interest is for using the ravif library to encode HDR data I generate myself; I don't know if it's relevant to transcoding from LDR using the command line tool, though it might be convenient for testing. Perhaps there's some esoteric form of JPEG that encodes the same metadata that would be nice to preserve?

@Ralith
Copy link

Ralith commented Dec 12, 2021

Is that something you consider in-scope, @kornelski?

@kornelski
Copy link
Owner

kornelski commented Dec 12, 2021

Use-case for programmatically-generated data makes sense. ravif could definitely support it, even if the CLI tool can't.

I haven't had time to play enough with HDR images to know how to best handle them. In my experience—for SDR—the separation between pixel data and color profiles that alter the meaning of the data is inelegant and has lead to a lot of broken software. Is is possible to make a better API for HDR data?

@Ralith
Copy link

Ralith commented Dec 12, 2021

HDR metadata is standardized and absolutely necessary, because it informs the ultimate display device of how to most effectively tonemap, avoiding unnecessary quality loss in common cases. I'm all in favor of designing an API to make it as difficult as possible to have missing/incorrect metadata, but it's not obvious to me what that would look like. Maybe require HDR metadata always be supplied if a HDR color space is used, for starters?

@kornelski
Copy link
Owner

10-bit encoding of sRGB has been released.

Encoding of HDR is still an open issue. What formats would you supply HDR images in? OpenEXR?

@Ralith
Copy link

Ralith commented Jan 27, 2023

That's again a non-issue for library users, which can just pass in raw uncompressed HDR10 bitmaps. Raw half-float bitmaps might also be useful.

@kornelski kornelski changed the title 10-bit and 12-bit support HDR support Oct 17, 2024
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

4 participants