Re: [csswg-drafts] [css-color-hdr] How should multiple layered elements with different `dynamic-range-limit` values behave? (#11307)

@svgeesus, yep, I am working on a PR to add a set of definitions that `dynamic-range-limit` can be implemented on top of. This is very much a draft:

```
## Webpage HDR Rendering Pipeline ##

The following describes a simplified description of the rendering/display pipeline to be used by web browsers displaying SDR and HDR content.

The system is comprised of the following components:

- The `output device`.

    - Has a `color space` value.
        (e.g. `NSScreen.colorSpace` in Apple's ecosystem.)
    - Has a `current headroom` value. This value is equal to 1.0 when only SDR content can be shown and is greater than 1.0 when HDR content can be shown.
        (e.g. `NSScreen.maximumExtendedDynamicRangeColorComponentValue` in Apple's ecosystem.)

    ACTIONS:
        - Can be sent a message requesting `additional headroom`.
            (e.g. setting `wantsExtendedDynamicRangeContent` on one of your CALayers in Apple's ecosystem.)

    A `webpage` can 

- The `webpage`.

    - Has a `backing store` with a `color space` equal to that of the `output device`.

    ACTIONS:
        - Can be sent a message when `current headroom` has changed.
            (e.g. listening for `NSApplicationDidChangeScreenParametersNotification` in Apple's ecosystem.)

- The `content`.

    - Examples include:
        SDR images
        HDR images
        SDR video
        HDR video
        SDR canvas
        HDR canvas
        SDR color values [color(srgb 0.4 0 1.0)]
        HDR color values [color(srgb 3 5 2)]

    - Has a `backing store` with a `color space` (potentially different from the `webpage` and `output device`)
    - Has a `dynamic-range-limit` value that places limits on how much of the `current headroom` can be used during `gamut / tone mapping`.
    - Has an optional `metadata` that can augment how `gamut / tone mapping` should behave.

    ACTIONS:
        - Can be drawn to the `webpage` `backing store` by:
             1. Converting each pixel in its `backing store` to match the `color space` of the `webpage`
             2. If necessary (see pipeline descriptions below), applying `gamut / tone mapping` to each converted pixel using the values of `current headroom`, `dynamic-range-limit` and the optional `metadata`.
             3. Compositing (using operations defined elsewhere) the final pixels into the `webpage` `backing store`.


### Pre-HDR webpage pipeline ###

In the pre-HDR webpage pipeline (that is, the world where `output devices` might have supported HDR, but `webpages` did not), the following was expected to take place:

    For an `output device` with a `current headroom` value equal to 1.0:
        - When drawing SDR `content` to the `webpage`, no `gamut / tone mapping` is applied.
        - When drawing HDR `content` to the `webpage`, `gamut / tone mapping` is applied, bringing all pixel values to be less than or equal to 1.0 (i.e. `current headroom`) in each channel.

    For an `output device` with a `current headroom` value greater than 1.0:
        - When drawing SDR `content` to the `webpage`, no `gamut / tone mapping` is applied.
        - When drawing HDR `content` to the `webpage`, `gamut / tone mapping` is applied with an OVERRIDDEN `current headroom` set to 1.0, bringing all pixel values to be less than or equal to (i.e. the OVERRIDDEN `current headroom`) in each channel.

        Examples
            - ADD EXAMPLE FOR HDR IMAGE HERE
            - For a hypothetical `output device` using `srgb` as its `color space`, a color like `color(srgb 3 5 2)`, would be mapped to a color channel value less than or equal to 1.0. If the mapping was a pure clip, this would be `color(srgb 1 1 1)`.


### HDR webpage pipeline ###

In the HDR `webpage` pipeline, the following is now expected to take place:
    For an `output device` with a `current headroom` value equal to 1.0:
        - When drawing SDR `content` to the `webpage`, no `gamut / tone mapping`. (No change from pre-HDR pipeline!)
        - When drawing HDR `content` to the `webpage`, `gamut / tone mapping` is applied, bringing all pixel values to be less than or equal to 1.0 (i.e. `current headroom`) in each channel. (No change from pre-HDR pipeline!)

            NOTE: In parallel to this, the `webpage` should message the `output device` requesting `additional headroom`. If the `output device` can accommodate the request, it will update `current headroom` to be greater than 1.0 and message the `webpage` informing it the `current headroom` has changed, at which point the branch below will be followed.

    For an `output device` with a `current headroom` value greater than 1.0:
        - When drawing SDR `content` to the `webpage`, no `gamut / tone mapping`. (No change from pre-HDR pipeline).
        - When drawing HDR `content` to the `webpage`, `gamut / tone mapping` is applied, bringing all pixel values to be less than or equal to `current headroom` in each channel. 

            NOTE: The only change between the two pipelines is that in the HDR world, HDR content uses `current headroom` as its upper bound for `gamut / tone mapping`, instead of the OVERRIDDEN value of 1.0.

NOTE: Due to `gamut / tone mapping` taking `current headroom` as one of its inputs, `webpages` will need to potentially repaint whenever `current headroom` changes. 



#### Optimization Warnings (non-normative) ####

The pipeline described above is a simplification of the real world, where browsers often use multiple buffers with different backing store configurations, `layers`, and have the operating system composite and color match on their behalf allowing for certain optimizations (such as hardware color correction). These optimizations should remain usable, but implementors must be careful to ensure that all content drawn into one of these `layers` require the same corrections to applied by the system.

For example, for a hypothetical `output device` with a `current headroom` value of 2.0, a `webpage` that wants to draw a solid SDR background with a single HDR image on top of it, could use one `layer` for the background, and one `layer` for the contents of the image, and have the operating system perform the `gamut / tone mapping` itself. However, if image has say, a solid SDR border around it, the `webpage` can't draw the SDR border into the `layer` used by the image, as the operating system would also apply the `gamut / tone mapping` to it. 

(This all assumes `layers` have `gamut / tone mapping` applied by the system for all its pixels. If future systems allow per-pixel metadata, this warning no longer applies.)
```

-- 
GitHub Notification of comment by weinig
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11307#issuecomment-2718858571 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 12 March 2025 19:10:28 UTC