[PATCH] unstable: add HDR Mastering Meta-data Protocol

[Graeme Gill]

Pekka Paalanen wrote:
> On Wed, 27 Feb 2019 10:27:16 +0530
> "Nautiyal, Ankit K" <ankit.k.nautiyal at intel.com> wrote:
> 
>> From: Ankit Nautiyal <ankit.k.nautiyal at intel.com>
>>
>> This protcol enables a client to send the hdr meta-data:
>> MAX-CLL, MAX-FALL, Max Luminance and Min Luminance as defined by
>> SMPTE ST.2086.

Hmm. I'm wondering what the intent of this is.

If it is to feed these values through to the display
itself so that it can do dynamic HDR rendering, then
this tends to cut across color management, since
color management as it is currently formulated depends
on reproducability in color devices. If really desired,
I guess this would have to be some kind of special mode that
bypasses the usual rendering pipeline.

If the idea is that somehow the compositor is to do
dynamic HDR rendering, then I have my doubts about its
suitability and practicality, unless you are prepared to
spell out in detail the algorithm it should use for performing this.

My assumption was that the compositor would only be expected
to do well understood fallback color conversions, and that
anything that needed special functionality or that was
going to do experimental color handling (such as
dynamic HDR rendering) would do so in the client.

For the purposes of mixing SDR and HDR in the compositor
as a fallback, a much simpler set of transforms should be sufficient,
namely a brightness for converting SDR into HDR, and a tone mapping
curve or equivalent settings for compressing HDR into SDR.

> Is there a case for compositors that implement color management but not
> HDR support? Would it be unreasonable to make HDR parameters a part of
> the color management extension? Such that it would be optional for a
> client to set the HDR parameters.

I think that at this point in time it is entirely reasonable
that a compositing system have some level of HDR awareness.

> Btw. do HDR videos contain ICC profiles? Where would a client get the
> ICC profile for a video it wants to show? Do we need to require the
> compositor to expose some commonly used specific profiles?

As I understand it, no they don't. They either rely on a stated
encoding (i.e. REC2020 based), or sometimes have simple meta-data
such as primary coordinates & transfer curve specifications. A client
wanting to support such meta-data can simply create a matching ICC
profile on the fly if it wishes.

Cheers,
	Graeme Gill.