Provide MinTML/MaxTML metadata about the viewing environment

[magcius]

From what I can tell, the current minimumLuminance and maximumLuminance fields are metadata from the application to the renderer about the content, and the rendering environment applies the mapping to the display environment. As noted in #100, the standard currently has no input on how this tone and gamut mapping is applied to the display environment. On all current displays, the available theoretical range of gamut and luminance is much larger than the actual space the display itself can support.

Gamut and tone mapping is a lossy transform with no one correct answer; it's feasible for applications might want to do tone mapping themselves to make sure that their colors reproduce as accurately as possible. This is the approach recommended by the HGIG, who proposed making three metadata fields available to content: MinToneMapLuminance, MaxToneMapLuminance, and MaxFullFrameToneMapLuminance. Should we consider exposing these fields to applications that wish to provide their own tonemapping?

Historically, it's worth noting that the content-provided metadata approach was tried in SMPTE ST 2108; however it was effectively deprecated by all known platforms because the lack of standardized tonemapper across display environments made accurate color reproduction basically impossible.

[palemieux]

As noted in https://github.com/w3c/ColorWeb-CG/issues/100, the standard currently has no input on how this tone and gamut mapping is applied to the display environment.

The strawman provides recommendations on tone mapping, which is more common and complex than chromaticity mapping, at https://github.com/w3c/ColorWeb-CG/blob/8eac62f15e5b41940636beb031f6214b61e933af/hdr_html_canvas_element.md#annex-a-color-space-conversions .

There is a live (JS) demonstration of various techniques at https://www.sandflow.com/public/tone-mapping/

We could add specific recommendation on chromaticity mapping, as suggested in #100.

Should we consider exposing these fields to applications that wish to provide their own tonemapping?

The next step of the CG is in fact to extend the spec to expose to the app the following display parameters:

• maximum luminance achievable by the display
• minimum luminance achievable by the display
• luminance at which peak SDR white is current being rendered on the display

We could consider the full frame vs patch values as specified at https://www.hgig.org/doc/ForBetterHDRGaming.pdf, if this turns out to be useful.

[magcius]

The strawman has some strategies for tonemapping going from HDR -> SDR, but even HDR -> HDR can require tone mapping. If the content reports a maximum luminance of 1000 nits, but the display's maximum reported luminance is 400 nits (my current display is only DisplayHDR 400 rated), then something has to map the 400-1000 range. Doing nothing and just clamping is one option, but it is at some level "a look" with visible gamut clipping. The Notorious 6, etc.

[palemieux]

but even HDR -> HDR can require tone mapping

Yes, the method suggested in the strawman (Annex 5 of Rep. ITU-R BT.2408-5) also works for HDR -> HDR tone-mapping. This should be emphasized in the strawman.