[css-color-hdr] How should multiple layered elements with different `dynamic-range-limit` values behave?

[weinig]

I am trying to wrap my head around how dynamic-range-limit is intended to work (an introduction to the property, not just an introduction to the concepts, would be helpful I think), and I am trying to work out what the intended behavior of multiple elements, all occupying the same space, one on top of another, with different dynamic-range-limit values should be?

If the goal of the property is to rein in overzealous dynamic ranges, choosing the lowest might make sense, but that would contradict the example given:

body { dynamic-range-limit: standard; }
div.photogrid img { dynamic-range-limit: constrained-high } 

which indicates that the highest should be used? Or maybe it is indicating that z-order is important?

(Ultimately, this will need to be mapped to some platform concept, so if there Windows/macOS/etc APIs you are expecting these to be built on / are taking inspiration from, I would be interested to read up on them).

[svgeesus]

(an introduction to the property, not just an introduction to the concepts, would be helpful I think)

Agreed, but pending an improvement in the specthere is an explainer which may help?

[weinig]

That sheds light on the inspiration (looks like UIImage and NSImage from apple's platform have quite similar APIs), but unfortunately I can't find any information on how those work. e.g. are they just hints? if you have two UIImages overlapping each other with different preferredImageDynamicRange values, which one takes precedence?

I think the spec needs to clarify what exactly dynamic-range-limit does and what effects it has.

I can't even really tell if the implication of having dynamic-range-limit: high be the default means that a CSS color value like color(srgb 10 10 10) should now be super bright.

[annevk]

cc @ccameron-chromium

[ccameron-chromium]

When HDR content is composited, it can be thought of* as being all put into a single buffer. This single buffer has the maximum available headroom, which is the headroom of the screen.

• On macOS, this is NSScreen's maximumExtendedDynamicRangeColorComponentValue
• On Android, this is Display.getHdrSdrRatio
• On Windows this is the ratio of DISPLAYCONFIG_SDR_WHITE_LEVEL::SDRWhiteLevel to DXGI_OUTPUT_DESC::MaxLuminance

Let's call the headroom of the screen H.

Each piece of HDR content is tone mapped into this single buffer independently.

• This is a very important concept. Each image, each video, etc, is treated separately.
• Any content that has a maximum pixel value** greater than H is tone mapped so that its maximum value is H.

The dynamic-range-limit allows each individual element, on its own, to say "use something other than H for the tone mapping step".

• If you say standard, the value is 1.
• If you say constrained-high, it's up to the user agent. Chromium uses min(2, H).
• If you say high, then you use H (which is the default behavior today).

So, to the question:

If you have two UIImages overlapping each other with different preferredImageDynamicRange values, which one takes precedence?

Neither. Each image is tone mapped separately. That's what happens already. Consider the following example (assuming dynamic-range-limit doesn't exist):

• I have Image A with maximum pixel value** 8
• I have image B with maximum pixel value** 5
• My display has headroom H=6

In this case, Image A has a tone mapping performed that maps its maximum (8) to 6, while Image B has a totally different tone mapping (in particular, it has no tone mapping applied, because 5<6).

Now assume that Image A has high and Image B has standard. As before, Image A will be tone mapped so that it has a maximum value of 6, while Image B will now be tone mapped so that it has a maximum value of 1.

Once the images have been tone mapped, they're just regular pixel values (that can be overlapping, covering each other, blending, etc).

I can't even really tell if the implication of having dynamic-range-limit: high be the default means that a CSS color value like color(srgb 10 10 10) should now be super bright.

For the moment, I'm only applying this to HDR images, videos, and canvases. For colors, Chromium has unrelated bugs. With respect to how to express this, my opinion on this is as follows: "colors should be like HDR image pixels". HDR image pixels must specify something to the effect of "I am (0.5, 0.9, 0.7) when there is headroom 1 and (6, 9, 8) when there is headroom 10, and what you see will be interpolated between those two based on the display's headroom".

[*] Hardware overlays, etc, will make it so that content will not always end up in a single buffer, but that's a separate detail.
[**] Pixel value in linear space

[weinig]

Thank you @ccameron-chromium, super helpful.

So, for (non-image/video) color values then, do you imagine we will need new css syntax to express these different values at different headrooms?

[ccameron-chromium]

So, for (non-image/video) color values then, do you imagine we will need new css syntax to express these different values at different headrooms?

I think that's the direction to go. It allows colors to "opt in" to being HDR ("is this color HDR?" is a question with messy borders), and it also allows for the design of an HDR site without having to know the display's exact headroom (which I understand to be a very important constraint).

[weinig]

Makes sense.

I think having this processing model spelled out in the spec would be a huge improvement.

I'd also be interested to understand how (if at all) this plays into gamut mapping.

Also, what is the benefit in having constrained-high be user agent defined?

[ccameron-chromium]

I'd also be interested to understand how (if at all) this plays into gamut mapping.

My sense is that gamut mapping should be done to the user's gamut at the effective headroom. So if you have P3 primaries, and the effective headroom is 4, then gamut mapping is done to [0,4]^3 in P3 linear space.

Also, what is the benefit in having constrained-high be user agent defined?

We wanted to allow some flexibility in the implementations to account for "other stuff" (e.g, ambient brightness, etc) in that.

[weinig]

@svgeesus I am happy to close this, unless you want to keep it open to track to adding more information about the processing model to the spec. Just let me know.

[svgeesus]

unless you want to keep it open to track to adding more information about the processing model to the spec

I would prefer to keep it open, so that we can add more to the spec rather than just having it documented in this issue :)

[css-meeting-bot]

The CSS Working Group just discussed [css-color-hdr] How should multiple layered elements with different `dynamic-range-limit` values behave?, and agreed to the following:

• RESOLVED: modify spec text as discussed, to try and flesh out if there are blocking compositor issues in implementations; possibly add an appendix of test cases and blocking issues with platform limitations

The full IRC log of that discussion

<jcraig> weinig: for multiple layered elements, need more added to clarifying the model underlying what this property actually does
<jcraig> uses tone map example
<jcraig> s/map example/map compositing example to explain compositor controlling whether this is additional headroom/
<jcraig> ChrisL: we have a brief section on compositing... would be good to get better text
<jcraig> weinig: understanding what implementors would like to apply here would be useful
<jcraig> and the constraints of existing compositors
<jcraig> Said: the dynamic range limit is cascading, correct?
<jcraig> weinig: inherited but overridden by an explicit defining on higher specificity
<jcraig> simon: yes, agreed at F2F that these are not multipliers
<jcraig> ChrisL: should be documented, possibly in an appendix...
<jcraig> easy to write something that looks great from a color theory perspective but may not be implementable
<jcraig> PROPOSAL: modify spec text as discussed, to try and flesh out if there are blocking compositor issues in implementations; possibly add an appendix of test cases and blocking issues
<jcraig> weinig: WPT is lacking here because the color space can be modified
<jcraig> ChrisL: and WPT is limited to sRGB
<jcraig> s/PROPOSAL: modify spec text as discussed, to try and flesh out if there are blocking compositor issues in implementations; possibly add an appendix of test cases and blocking issues/PROPOSAL: modify spec text as discussed, to try and flesh out if there are blocking compositor issues in implementations; possibly add an appendix of test cases and blocking issues with platform limitations/
<jcraig> RESOLVED: modify spec text as discussed, to try and flesh out if there are blocking compositor issues in implementations; possibly add an appendix of test cases and blocking issues with platform limitations
<jcraig> weinig: I will take that issue