Sharma, Shashank wrote:
Hi,
> 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.
my impression from past feedback is that EDID display characterization as a rule
is not to be relied on, at least not if any degree of accuracy is desired. Maybe
the manufacturers have got better.
But I can sympathize with the desire of not getting bogged down in
color management stuff if you are just trying to get something
vaguely reasonable displayed on HDR.
> 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.
Sure. If you just take the HDR monitors as being nominally HDR10 or similar,
then you can
do a by-the-spec conversion and get something working.
Cheers,
Graeme Gill.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
