You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
The text was updated successfully, but these errors were encountered:
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).
The text was updated successfully, but these errors were encountered: