Re: Specifying an API to query the display color volume

> However, I'm confused by claims that PQ monitors would display the
> input signal nit-for-nit up to capability and lack end user
> adjustments. That would mean any adaptation to the actual viewing
> environment would need to happen at the video signal source. My monitor
> indeed disables brightness and contrast adjustments in PQ HDR mode.


Yea this. I have been confused by Dolby’s decision making here. It is as if to assume that there is a single environment that all PQ displays shall be in… Sure that works for commercial cinema—but only because of the evolution of film technology and the practical limits on film-projector brightness, which demanded a blackout viewing condition.

Well… that ain’t today…

😳😎



Andrew Somers
Senior Color Science Researcher 
Redacted for public list

> On Sep 12, 2023, at 6:01 AM, Pekka Paalanen <pekka.paalanen@collabora.com> wrote:
> 
> On Tue, 12 Sep 2023 03:21:36 +0000
> Lars Borg <borg@adobe.com <mailto:borg@adobe.com>> wrote:
> 
>> How about this:
>> Start with standardized values, from maybe 40 to 10,000.
>> (Such as 48, 80, 100, 160, 203, 235, 300, 500, 600, 720, 1000)
>> If some standard values are close together, fake example 200 and 203, drop one.
>> Fill in large gaps (> 40%? increment) with intermediate values
>> 
>> These values would be max luminance for small patches.
>> Some displays can return this value over HDMI, but the value must be
>> mapped to the limited set to prevent fingerprinting.
> 
> Hi,
> 
> are you perhaps referring to EDID CTA-861-H: HDR Static Metadata Data Block?
> 
> I'd just like to point out that this block in question defines
> "desired" luminance levels. I don't think it is any kind of promise of
> emitted luminance levels.
> 
> My HP Pavilion 27" quantum dot monitor was advertised with 400 cd/m²
> luminance, but the EDID says desired max luminance is 600 cd/m², for
> example, and with desired max frame-average luminance of 350 cd/m².
> 
> In other words, it does not look like these numbers would be usable to
> correlate with actual viewing environments, assuming you had
> information about the actual viewing environment.
> 
> Then again, that's just one example that could as well be explained by
> EDID being incorrect, as EDID generally is notorious for.
> 
>> 
>> No ambient info, as:
>> 
>>  *   this would require a measurement device.
>>  *   Standardized mastering display color volume does not include it
> 
> SMPTE ST 2086 mastering display information does not include it, but
> BT.2100 does give guidelines about it in "Reference viewing environment
> for critical viewing of HDR programme material". I guess assuming that
> is the best guess.
> 
> The PQ system uses a display-referred signal, so one could say the
> signal needs to be displayed as encoded literally. But displays have
> different capabilities, not to mention different viewing environments.
> The PQ system can use ST 2086 metadata to describe the display it was
> mastered for, and BT.2100 recommends a viewing environment, so these
> should define the intended appearance which could be mapped to the
> display at hand in the actual viewing environment.
> 
> However, I'm confused by claims that PQ monitors would display the
> input signal nit-for-nit up to capability and lack end user
> adjustments. That would mean any adaptation to the actual viewing
> environment would need to happen at the video signal source. My monitor
> indeed disables brightness and contrast adjustments in PQ HDR mode.
> 
> 
> Thanks,
> pq