Re: Wide Color Gamut and High Dynamic Range displays

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

> On Wed, Jan 28, 2015 at 2:27 PM, Mark Watson <watsonm@netflix.com> wrote:
> > 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.
>
> Okay, cool.  Yeah, I was using the term "codec" more widely, in a
> probably incorrect way, to indicate all the metadata that's carried
> along with the video.  Color profiles aren't really part of the image
> format, and VUI isn't really part of the codec, but they both
> format/profile and codec/VUI are part of the information that's used
> to to process encoded data into display pixels.
>
> > 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.
>
> Is there a way to query the hardware stack for VUI, like you can ask
> monitors what their color profile is?
>

​The term VUI refers specifically to information attached to a (H.26x)
video stream. I'm not sure exactly what's in the "color profile" you're
referring to (would like to know).

But, yes, the hardware knows in which colorspaces it is capable of
accepting data. IIUC this basically boils down to the coordinates in the
CIE color diagram of the red, green and blue primaries with respect to
which the image data is coded.


>
> >> 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.
>
> Not quite sure what these words mean, but I don't think I have to -
> point is, some devices might not even be capable of processing certain
> types of better-quality video, and those that can will probably be
> crappy at it, so we really want a way to deliver videos using those
> better qualities only to devices that can handle them.
>

​Yes. I was also pointing out that codec discovery alone isn't sufficient
to make the determination.​


> >> 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.
>
> So what you're saying right now is that the appropriate way to talk
> about these video qualities is by name?  I was hoping for something
> more abstract and comprehensible, and hopefully arrangeable on a
> continuum, but I'd understand if that's not really possible.
>

​The quantifiable things for colorspace are the positions on the ​CIE space
of the color primaries. But, typically, a name or code point is given to
the ones actually used.

For HDR it is a transfer function, mapping from pixel code values (8, 10
bits, whatever) to luminance values (in candelas/m^2). There is some art in
the design of these functions and there is no general form that reduces the
specification to a few parameters.

So, names it is I'm afraid.

What I'm wondering is what is the appropriate way to indicate these
capabilities ? Should these be additional attributes in CSS OM View ? Or
should they be new things to be used with Media Queries ? Are there other
options ? What are the design criteria for choosing between options ?

We have an opportunity to experiment in some non-desktop settings, but I'd
like to start on the right foot, design wise.

…Mark



>
> ~TJ
>