Re: Wide Color Gamut and High Dynamic Range displays

On Wed, Jan 28, 2015 at 12:16 PM, Tab Atkins Jr. <jackalmage@gmail.com>
wrote:

> 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.
>

​I think so, yes. For example, in H.265 the "codec" is generally considered
to be the part that takes in compressed video data and outputs three planes
of pixels with 8 to 10 bits of data per pixel per plane.

There is then "Visual Usability Information" (VUI) transmitted along with
the compressed video signal which indicates how to interpret that output:
color gamut, transfer function etc.

As a result, when querying codec capabilities (Profile, Level etc.) you
tend to only get information about the capabilities of the first part, not
the capability of the output device​ to interpret the raw output according
to the SEI.

It's not dissimilar from resolution in some respect: your device may
support the necessary codec capabilities for 4K resolution but may not at
that time be connected to a 4K-capable display.


>
> 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.
>

​Yes, the mapping of High Dynamic Range content to Standard Dynamic Range
is a creative process that is not easy to do well automatically.

Also, there are existing devices which support codec capabilities (in the
narrow sense described above - which is also the sense in which codec
capability discovery works) suitable for HDR but which cannot interpret the
output as HDR, even to map down to an SDR display.


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

​For color gamut, for video, the practically relevant choice is between
BT.2020 and BT.709 (Content is created in other colorspaces, but generally
mapped to one of these for delivery).

However, for all I know there may be a whole different world of color
spaces for graphics ​which the CSS group should consider.

For HDR, the relevant information is the transfer function. H.265 lists
quite a number of transfer functions for standard dynamic range, though I
believe all the ones in current use can be classified as BT.709. For High
Dynamic Range, presently on the table is SMPTE-2084, though in some
contexts others are being discussed.

…Mark



>
> ~TJ
>