[css-color-hdr] Add mechanism to query HDR headroom

[ccameron-chromium]

The current dynamic-range media query indicates a binary value indicating if the screen is HDR (high) or SDR (standard).

The capability of an HDR screen is parameterized by its HDR headroom (how many times brighter than SDR white it can produce). This parameter is dynamic. It depends on the viewing conditions and the content on-screen.

This issue is to explore mechanisms for exposing this parameter.

[ccameron-chromium]

Probably the simplest scheme for solving this would be add a property to the Screen interface.

To avoid fingerprinting, implementations would probably want to round the value to to the nearest power-of-two, unless specific permission is granted.

[svgeesus]

https://github.com/ccameron-chromium/hdr-headroom-limit/blob/main/EXPLAINER.md

[palemieux]

Please consider the latest recommendation of the Color on the Web CG on adding output color volume information (including luminance headroom information) to the Screen interface of the CSS Object Model:

https://github.com/w3c/ColorWeb-CG/blob/hdr_canvas_r2/hdr_html_canvas_element.md#add-display-color-volume-information-to-screen-interface-of-the-css-object-model

[smfr]

If it's the case that referenceWhiteLuminance depends on viewing conditions which influence screen brightness, then WebKit objects to adding that. A web page should not be able to detect the viewing conditions in effect; it should not be able to detect when you walk outside, for instance. And I don't think there's a user prompt that could be worded in a way that users would understand that this access could be gated on.

The preferred approach is to allow authors to supply a list of assets, and have the UA pick the appropriate asset (like srcset).

[svgeesus]

The preferred approach is to allow authors to supply a list of assets, and have the UA pick the appropriate asset (like srcset).

That approach doesn't really work well in the case where there is a single asset which can adapt to a range of HDR headroom values. One example of that approach is being standardized in ISO TC 42/WG 23 on Gain Maps. A single image resource has an SDR baseline image and a gain map; from that information a variety of HDR renderings can be reconstructed, corresponding to the actual HDR headroom.

That work is being driven and implemented by Apple, and Adobe.

• https://github.com/w3c/PNG-spec/issues/366

Another example would be a web app which draws to Canvas 2D context, which computes a tone mapping curve in real time following the procedure in section 5.4.1 Mapping to display with limited brightness range of ITU Rec_BT.2390.

HDR is being widely adopted by native apps. The web also needs to adopt it, and one size definitely does not fit all viewing conditions. Presumably WebKit would not want to hold that back, especially since the Apple platforms on which it primarily runs already have that HDR headroom adaptation capability.

How can we move forward on this in a way that provides the capability in a privacy-sensitive way?

[svgeesus]

@ccameron-chromium wrote:

To avoid fingerprinting, implementations would probably want to round the value to to the nearest power-of-two, unless specific permission is granted.

So, that would give headroom values of 1 (_i.e._SDR), 2, 4 and 8 ? Or would 16 (three stops above reference white) also be useful, in a consumer web delivery context? At an SDR white of 100 nits those would correspond to peak white luminances of 200, 400, 800 and 1600 nits.

[css-meeting-bot]

The CSS Working Group just discussed [css-color-hdr] Add mechanism to query HDR headroom, and agreed to the following:

• RESOLUTION adopt the CSS Color HDR draft as a work item
• RESOLVED: CSS WG adopts the CSS Color HDR draft as a work item

The full IRC log of that discussion

<frances__> <@frances_> rossen: let's start with the first few issues [11:03] <@frances_> pierre: present background behind issues and areas to collaborate [11:03] <@frances_> rossen: I will try and help you [11:04] <@frances_> pierre: sounds great, might not solve in 10 minutes, maybe solve later [11:05] <@frances_> pierre: presentation on adding HDR imagery to html canvas for css requirements [11:05] <@frances_> pierre: highlight some work on color on web[CUT]
<chris> scribenick: frances
<dholbert> scribenick: frances__
<frances__> pierre: so far the web has standard images. effort to bring to both tv and movies, pcs, higher dynamic range images, much broader range of lumniscence, darker and brighter than png images used to
<frances__> pierre: in order to enable this, higher pixel beyond 8 bits beyond power law gamma transfer function, much effort done in the past decade
<fantasai> [pal expains SDR - standard images, whose ranges 0-100 nits, the range of luminance in a standard laptop]
<frances__> on streaming services, blue ray, and cinema, want to bring to pcs
<frances__> pal: web community group has been bringing high range images on html canvas. web gpu and so forth
<frances__> pal: straw man proposed to add HDR imagery through a series of steps
<dbaron> s/web community group/color on the web community group/
<frances__> pal: add series of 8 bit color per pixel, assist with mapping to displace that might not be high dynamic range, add api
<fantasai> [Slide: add HDR colorspaces to Canvas; add higher bit depth to Canvas etc. ; add image color volumne info to Canvas ; add display color volumn info query ; recommendations for mapping to/from HDR ]
<frances__> pal: render on displays that might not have required/narrow and render HDR images, welcome feedback
<frances__> pal: pause for questions
<frances__> rossen: suggests to keep going
<chrishtr> q+
<frances__> pal: HDR colorspaces fulfill two objectives: mapping between pixel values and emitted light
<frances__> pal: also reference viewing environment (ambient light and reference display)
<chrishtr> q-
<frances__> pal: ITU-R standard recommendation bt.2100 built on and recommends three colorspaces
<chrishtr> q+
<frances__> pal: uses hlg transfer function, uses pq transfer function, and linear light where rib corresponds to reference white (1,1,1)
<chris> q+
<frances__> pal: same color primaries and reference viewing environment, add support to the three areas
<chrishtr> q-
<frances__> pal: issue is high dynamic range image for narrow range image display
<frances__> pal: should a single algorithm be mandated or recommended?
<fantasai> i/pal: issue is/pal: Request is for CSS to add these three color spaces, as we are planning to add also to Canvas
<frances__> pal: how should a single algorithm be selected?
<frances__> pal: the cg has been considering a call for proposals
<frances__> pal: what is the capabilities of the display for minimum and maximum display luminance and of reference white?
<frances__> pal: possiblility to increase fingerprinting surfs and introduces privacy concerns
<frances__> rossen: focus the conversation
<frances__> rossen: what is the path forward?
<PaulG> q+
<Rossen_> ack chrishtr
<fantasai> i/pal: what is/pal: Also some applications might want to provide their own mapping, so would need some information from the UA
<frances__> chris: what are the colorspaces suggesting for canvas, are they all available in css ideally?
<frances__> rossen: confirms, yes would be ideal
<dbaron> I'm curious what "add a color space to CSS" means -- add it as part of mechanism for specifying colors, add the ability to use it as a working color space for compositing, other things?
<frances__> chris: on other issue, there is already an unofficial draft created. waiting for interest shown
<frances__> chris: brought down to simple high level proposed resolution, and propose to work on the draft together
<schenney> The trick is figuring out a HDR->SDR mapping that works when color information is spread across lots of elements (as opposed to a single image)
<Rossen_> ack chrishtr
<Rossen_> ack chris
<Rossen_> ack PaulG
<dbaron> https://drafts.csswg.org/css-color-hdr/
<chris> Paul, please have a look at https://drafts.csswg.org/css-color-hdr/#a11y
<frances__> paulg : has question and concern on samsung browser full canvas interface. would be excited. Is there a lag time between canvas and web implementation?
<chris> q+
<frances__> paulg: a hack with no script and can leave alot of people out on accessibility
<frances__> paulg: what coordination to do with color coordinations to accommodate for higher luminance?
<Rossen_> ack chris
<fantasai> s/a hack with no script and/if these are only available for Canvas, devs might use Canvas rather than Web in the interim, which/
<pal> q+
<frances__> chris lilley: already have accessibility considerations on the draft
<florian> q+ to ask if these 3 color spaces achieve different things, or if they are different ways to achieve the same thing
<frances__> rossen: let's answer high level bit to continue working on in csswg, and move onto other issues
<Rossen_> ack pal
<Rossen_> Zakim, close queue
<Zakim> ok, Rossen_, the speaker queue is closed
<frances__> pal: thank group for opportunity, focus on the colors
<Rossen_> ack florian
<Zakim> florian, you wanted to ask if these 3 color spaces achieve different things, or if they are different ways to achieve the same thing
<chris> Proposed Resolution: CSS WG adopts the CSS Color HDR draft as a work item
<frances__> florian: question: out of 3 color spaces, bigger range?
<frances__> chris lilley: yes, better use cases
<chrishtr> sgtm
<frances__> rossen: objections?
<fantasai> s/bigger range/are they different ways of achieving the same thing that we expect one to win, or do we need all three/
<fantasai> s/yes, better use cases/we need all three, they have different use cases/
<chris> Resolution: CSS WG adopts the CSS Color HDR draft as a work item
<frances__> RESOLUTION adopt the CSS Color HDR draft as a work item
<fantasai> RESOLVED: CSS WG adopts the CSS Color HDR draft as a work item
<frances__> rossen: archive is in the IRC
<frances__> rossen: next-issue #9511

[svgeesus]

@smfr there were some questions for you above, regarding how to expose this existing capability on the Web Platform.

[adixon-adobe]

On https://lightroom.adobe.com we'll need this to enable meaningful HDR editing, as you really need to know the amount of HDR headroom you're seeing to accurately understand the preview. For example, in the current Lightroom Desktop UI, as well as in the Adobe Camera Raw UI in Photoshop, we display a histogram of the image, along with a white line showing the peak brightness of the current monitor. It's very common to change brightness as you're editing to test different ranges, so having live updates to this during an editing session is needed,

It would be very reasonable to require the user to opt-in to this given the privacy implications.