Re: [csswg-drafts] [css-color-hdr] Absolute luminance of PQ (#10460)

We are drifting to the domain of window systems. A browser presents its contents through a window system, so it cannot escape the window system effects. I would even include the physical brightness and contrast knobs of a monitor or a TV here, since they are essentially indistinguishable from the window system, from the browser's point of view.

I consider a display that refuses to adjust contrast and brightness when presented a PQ signal to be broken. Broken hardware is often worked around in software.

@DanMan If you happen to be a content producer working in your studio, do you not calibrate your equipment as well as your environment? As part of that calibration, if you were using a window system that allows to work around broken displays, would you not also switch off that workaround or take it into account?

What about a home producer who cannot afford or cannot verify a studio-like environment? I would imagine they do the calibration by eye-balling some test images and adjusting their system, including the dynamic range mapping. Would that not lead to better production results for PQ material than trying to mimic the supposed "too dark" look?

----

Let's consider the alternative, and assume that PQ signal really is displayed nit-for-nit.

Let's say are you are a content producer. Your customers complain to you, that the PQ material you provided is too dark, and the only reason for that is that they consume that material in a dim home environment, or even in an office environment. What do you do?

If you modify the material to be brighter, then people in studio environments will complain that it is too bright. People in the office environment might still deem it too dark.

Do you tell those people to make their environment dark enough? "You're holding it wrong." Depending on your audience, would you not lose them?

----

Dynamic range re-rendering is not easy, even though we might sound like it's a ready solution for mismatching viewing conditions. I just think that doing something is better than nothing when that mismatch itself cannot be corrected, and we will find better ways of doing it over time.

What all the above means for the CSS HDR spec, I'm not sure. If wanted, I think the CSS HDR spec *can* choose to hold on to the promise of PQ signal encoding absolute luminance, and leave all this debate to window system and monitor and TV manufacturers as long as the spec makes no promises on their behalf.

SMPTE ST 2084:2014 says in Introduction (non-normative):

> The EOTF does not impart a preferred rendering appearance for any particular viewing environment. Image
> modifications needed for viewer contrast, colorfulness, highlight details, and visible detail in shadows at any
> particular output level must be chosen as part of the mastering process.

but then it also says:

> The reference EOTF and its inverse represent an efficient encoding system for high luminance range data.
> Though an idealized display device could follow this EOTF exactly, in real world displays the EOTF can be
> thought of as a nominal target. Actual displays can vary from the absolute curve due to output limitations and
> effects of non-ideal viewing environments.

This seems contradictory to me. The latter paragraph seems to allow image re-rendering to the viewing conditions at hand.

Unless, where is "the mastering process"? A PQ signal going from a computer to a monitor makes sense, if the mastering process is in the computer (or TV receiver or video player) rather than before them (in the broadcast or video production).

Would anyone happen to have a link to HDR10 specs? I have never found anything better than what we noted in https://gitlab.freedesktop.org/pq/color-and-hdr/-/blob/main/doc/hdr10.md#hdr10-media-profile . What's the HDR10 definition of the reference viewing environment?

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


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

Received on Monday, 16 September 2024 11:25:17 UTC