HDR / wide color hints

[eeeps]

They might be nice! Especially if the files that take advantage of the extra display capabilities are significantly larger (>8 bits-per-channel) than 8-bit SDR/sRGB versions, and can't simply be mapped to less-capable output displays client-side without some cost.

What could such hints contain? I see two options:

1. Lower-entropy versions of the hints would take their values from the relevant media queries.
2. Higher entropy versions of the hints would take their values from the HDR Canvas Proposal, although this would require three significant pieces to land, first:
   1. The HDR Canvas Proposal would need to be spec'd, achieve consensus, and implemented.
   2. A permissions gate for accessing detailed display information from this API would have to be implemented as Permissions-Policy HTTP headers (right now, the proposal only mentions user prompts).
   3. Client Hints Infrastructure would need to be updated, so that there were a new class of hints for which Permissions-Policies were checked/required even for same-origin requests.

All of that is making me lean towards the lower-entropy values, but more research on use cases is required.

[yoavweiss]

The lower entropy hints seem useful. The higher entropy hints seem like they'd need a bit more justification. What are the use cases for those that the low entropy hints don't satisfy?

[eeeps]

Image expert @jonsneyers says,

For delivery, probably for Display P3 and AdobeRGB, 8-bit is still OK (though you can get some banding even with sRGB in 8-bit, especially if YCbCr is used). For SDR Rec2020, 10 bits are needed. For HDR with PQ or HLG transfer curves, 10 bit is a minimum, and for Rec2100 (wide gamut HDR) displays tend to take 10 bit but 12 bit might be more comfortable.

My interpretation of this is that lower-entropy hints are fine. Mapping between specific color spaces can happen at the client; servers only need a general idea of the gamut+contrast that the output device is capable of in order to know how many bits to spend per channel (8, 10, or 12) in order to prevent banding.

So I guess this is now a proposal for two new hints whose potential values are a closed set of sf-tokens, identical to the potential values of the corresponding media queries:

Sec-CH-Dynamic-Range: high | standard

&

Sec-CH-Color-Gamut: srgb | p3 | rec2020.

The use case being that servers can transcode between gamuts/transfer curves and modulate the bit depth of a wide-gamut and/or HDR image for delivery based on the hints, like so:

Sec-CH-Dynamic-Range	Sec-CH-Color-Gamut	required bit depth
standard	srgb	8 bits
standard	p3	8 or 10 bits depending on content
standard	rec2020	10 bits
high	srgb	10 bits
high	p3	10 or 12 bits, depending on content
high	rec2020	12 bits

So if I'm delivering a wide-gamut, HDR source to a standard+srgb display, I can convert to sRGB + an SDR transfer curve and encode at 8 bits-per-channel, saving ~a third of the filesize vs a 12 bit-per-channel HDR/wide-gamut version (that would be converted to the output space on the client side, ~equivalently).

[svgeesus]

What are the use cases for those that the low entropy hints don't satisfy?

Knowing things like the max full-screen luminance allows accurate tone-mapping so that content on the Web looks as good as native content on the same platform. A simple SDR-or-HDR media query gives no such information, resulting in sub-standard generic mapping that fails to take advantage of the actual capabilities of the display (dull content, or harsh clipped highlights, or the 'battle of winterfell effect" where you can't see a thing)

[eeeps]

@svgeesus makes sense, though I worry about fingerprinting. (Also I'm curious to see some "generic mapping" failures; I'll try to hunt some down but feel free to share!).

Before we expose max full-screen luminance via Client Hints, it should really be available somewhere else first (via JS or CSS). Is https://github.com/w3c/ColorWeb-CG/blob/master/hdr_html_canvas_element.md still the thing to track for that?

[eeeps]

Answering my own question... based on the recent Intent to Prototype, it looks like that is the current proposal. And just making sure I understand the proposal correctly, the specific thing that would be useful to expose as a Client Hint would be highDynamicRangeHeadroom?

[svgeesus]

Yes, that is the actively maintained place to track

[svgeesus]

he specific thing that would be useful to expose as a Client Hint would be highDynamicRangeHeadroom?

Exactly