Re: Wide Color Gamut and High Dynamic Range displays

On Wed, Jan 28, 2015 at 5:45 PM, Mark Watson <watsonm@netflix.com> wrote:

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

I found a place that describes the VUI entry: line 105 in
http://git.videolan.org/?p=x264.git;a=blob;f=doc/vui.txt
I believe it is the color profile of the video stream (transfer + matrix
coefficients)


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

Why so? It looks like if you have the VUI info, you have all the
information to construct a profile.


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

I'm still unsure what you're trying to do. Are you trying to pick a video
based on the connected display or change CSS attributes?