HDR support in Wayland/Weston

[Sharma, Shashank]

Hello Graeme,

Thanks for your inputs and comment, please find mine inline.

Regards
Shashank
On 1/11/2019 12:55 PM, Graeme Gill wrote:
> Sharma, Shashank wrote:
>
> Hi,
>
> While I'm sure you could hard code various color space assumptions into
> such an implementation (and perhaps this is a pretty reasonable way
> of doing a proof of concept), it's not a good long term solution,
> and could end up being something of a millstone. What's missing
> is any serous Color Management in Wayland. It's a bigger project
> to fix that, but HDR would then be able to slot into a much more usable
> framework.
I agree, honestly, HDR might be the biggest consumer of color 
management. We can very well use this stack to drive color management 
design. But the only worry is, when to target too big and too generic, 
the actual purpose gets diluted and we get stuck into long chain of mail 
communication. So probably the most important thing for us, as a team, 
would be to break this implementation into small measurable steps which 
slowly targets respective areas of Weston development, keeping the end 
goal alive.
>> - HDR content/buffers are composed in REC2020 colorspace, with bit depth 10/12/16 BPC.
>> Some of the popular formats are P010,P012,P016.
> While REC2020 based HDR colorspaces are very popular, they aren't the only ones out there.
Agree. My sole purpose of proposing this design was to talk to people, 
and come up with a small, scalable target use case, which we can slowly 
expand and shape into a bigger, more generic framework, over the period 
of time and maturity. So the target was to start with one of the broadly 
used cases, and try to expand this range, into all possible 
formats/cases without regressing into existing framework.
>> - Normal SRGB buffers are composed in SRGB color space following REC709 specifications.
> As far as I'm aware (I haven't been closely monitoring this mailing
> list since the last rather long and unsatisfactory discussion about color
> management), Wayland works in display dependent colorspace, since there
> is no facility for it to know how to convert from anything else to the
> display space (i.e. no knowledge of display profiles so it doesn't
> know what sRGB is). In all other computer graphic display systems, it's
> up to the client to be informed about each display colorspace is, and
> to do color conversion to the display space either itself, or by using
> operating system libraries. The operating system provides the display
> profile information to allow this. As far as I was informed, Wayland
> is architected in such a way that this is not possible, since clients
> have no knowledge of which display the pixels they send will end up on.
Yes, this is very accurate. We are planning to add a protocol extension, 
which will allow a client to pass the buffers colorspace information to 
the compositor. And compositor already has HW's color capabilities (drm 
properties per plane and CRTC), and monitor color capabilities (EDID). 
So if compositor gets all of this, with some good policies, it might be 
able to take call on colorspace accurately.

Also, only from HDR implementation point-of-view, we need not to really 
know, that which REC709 implementation is this buffer actually. We just 
need to know if this is a BT2020 buffer or not, so that we an scale 
up/down the color gamut, for a proper blending scenario. So again, 
strictly for HDR playback scenario, a non-2020 buffer can be considered 
as 709 buffer, and its almost safe.

But if we want to provide a proper and accurate color management 
solution, we definitely need to know more about the buffer's 
color-space, than if its 2020 or not.
> Also note that while the use of an intermediate compositing space is
> essential when combining different colorspace sources together, it's
> not desirable in other situations where maximum fidelity and
> gamut are desired i.e. Photography. (The double conversions are a
> possible accuracy loss, and it makes it very difficult to
> achieve good gamut mapping from large gamut sources.)
Very valid point, and that's why I was incline towards using the display 
HW's capabilities, because modern day HWs are investing well on the 
color pipeline to handle cases like HDR. I guess once we have a mature 
basic stack working, we can think of adding something like a uses's 
preference, which could be another entry in our blending decision making 
inputs.
>> - For accurate blending in display engines, we need to make sure following:
>>      - All the buffers are in same colorspace (Rec 709 or Rec 2020)
>>      - All the buffers are liner (gamma/EOTF removed)
>>      - All the buffers are tone mapped in same zone (HDR or SDR)
> Is that something that Wayland should really know about though ?
> i.e. shouldn't that be an application issue, where Wayland provides
> the necessary mechanisms to achieve correct composition ?
> (Or in fact is that what you are suggesting ?)
Not really, I was in favor of compositor should own this, as, compositor 
is the only element which could have access to a system-wide graphics 
view. So I was suggesting to let compositor be responsible for the 
accurate blending part.
>>      - Now, in order to re-apply the HDR curve, compositor will apply CRTC level gamma, so
>> that the output buffer is non-linear again.
> Note that in most Color Managed systems, the CRTC per channel lookup curves are used for
> the purposes of display calibration, although Wayland doesn't currently support
> Color Management tools at all (unlike X11 or other operating systems, it provides no
> access to the CRTC by client software).
Correct, in fact, we would be using these same CRTC channels to apply 
the EOTFs. If we go through the REC2020/2023 spec carefully, we realize 
that EOTF/OETF curves are nothing but gamma/degamma correction curves 
for HDR monitors while they are displaying a much wider gamut, like 
BT2020 or DCI-P3. I had written one drm-compositor based implementation 
of sample color management using these CRTC/Plane color properties being 
exposed by DRM, for accurate blending, but now I want to go through and 
understand Niels's color management solution first.
> Perhaps it's worth re-visiting some of the ideas about how to add Color Management
> to Wayland, to see how HDR could fit into it ?
Agree, again,  this presents a case for Niels's color management 
solution, and I am trying to see if HDR makes a fit use case for that.
> regards,
> 	Graeme Gill
> 	(Author of ArgyllCMS <http://www.argyllcms.com/>)
Thanks for all the comments and inputs.
- Shashank
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel