Re: Wide Color Gamut and High Dynamic Range displays

On Wed, Jan 28, 2015 at 11:27 AM, Mark Watson <watsonm@netflix.com> wrote:
> On Wed, Jan 28, 2015 at 10:32 AM, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
>> On Wed, Jan 28, 2015 at 9:02 AM, Mark Watson <watsonm@netflix.com> wrote:
>> > All,
>> >
>> > It would be nice to be able to detect whether the display has the
>> > capability
>> > of rendering Wide Color Gamut and High Dynamic Range video.
>>
>> The wide gamut, at least, is covered by the (color) MQ
>> http://dev.w3.org/csswg/mediaqueries/#color
>
> That's the bit depth, which is important, but orthogonal to the color gamut.
> Greater bit depth means you can identify colors within the supported
> colorspace more accurately (less quantization). Wide Color Gamut refers to
> an increase in the range of possible colors, such as with BT.2020 [1].

You're right; I was incorrectly conflating those.

>> I'm unsure what High Dynamic Range is, so I dunno if there's anything
>> applicable in CSS so far.
>
> Standard video signals encode luminance within a particular range (up to 100
> candelas/m^2). High Dynamic Range refers to signals encoded with a higher
> luminance range. To be worth using you need the display itself to support
> higher brightness levels (actually most displays go higher than 100
> candelas/m^2 these days) but also for the media pipeline to support the
> higher luminance range and transmission of that to the display.
>
> In both cases, the relevant capabilities are distinct from the codec: it's
> about the interpretation of the 8 or 10 bits per pixel per component that
> are the output of the codec.

Tangent: but isn't it part of the codec? Or something like it? I mean,
if a television has wide gamut, the video needs to somehow communicate
that it's a wide-gamut or narrow-gamut video, so the TV knows how to
display it correctly.  Maybe that's communicated at another layer
entirely, I dunno.  But, like, image formats can specify their
colorspace so screens with sufficient gamut can display them
correctly; they still *send* values in 8 or 10 bits or whatever, but
might map them to a different range of actual colors.  Maybe you're
simply meaning "part of the codec" as something weaker than how I'm
interpreting it.

Anyway, I agree that you don't want to send wide-gamut stuff to
narrow-gamut screens if there's a properly-adjusted narrow-gamut
alternative you can offer (trusting the automatic correction algos
is... risky), and presumably the same applies to wide luminance.

You'd know better than me - what kind of values are appropriate for
communicating this info?

~TJ

Received on Wednesday, 28 January 2015 20:17:20 UTC