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

Discussion HDR and white level scaling #919

Open
benstevens48 opened this issue May 19, 2023 · 0 comments
Open

Discussion HDR and white level scaling #919

benstevens48 opened this issue May 19, 2023 · 0 comments

Comments

@benstevens48
Copy link

I just wanted to post a few comments on HDR and white level scaling somewhere where the DirectX team might see it.

I have been thinking quite hard about how the white level should be scaled when converting between HDR color spaces. In particular, I have been thinking about how to do this in a way that is compatible with ICC profiles (using the DtoB tags which allow floating-point unclipped mappings). The only think that makes sense to me, and that is also backwards compatible with SDR, is that a value Y = 1 in the profile connection space represents SDR white (or diffuse white). It follows that for linear spaces such as scRGB, a value of (1,1,1) should represent SDR white. In addition to this, it doesn't make sense to assign absolute luminance to pixel values until the very end of the processing pipeline (using the display properties). Indeed, for standards like HLG, the absolute luminance is meant to depend on the peak luminance of the display.

Following these observations, it doesn't make sense for an ST.2084-gamma profile to scale by a factor of 125, as is now the built-in behavior. Rather, it makes sense to scale so that the SDR white as specified by this standard (something like 0.58 of the input scale or 203 nits if the max value is 10000 nits) maps to 1, which means scaling by 10000/203 (approx 50). If you were making a color profile for it, this would be the most sensible option in my opinion, so the built-in space should do the same. I appreciate it's probably too late to change the behavior now, but maybe introduce an option or something?

Then, right at the end of the processing pipeline, having converted to scRGB (without any scaling except as specified above), one should get the display metadata and scale as appropriate for the display. This will probably be (display SDR white level)/80 (due to the fact that (1,1,1) is treated as being 80 nits at this point, which I guess can't be changed now).

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

1 participant