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.
> - 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.
> - 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.
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.)
> - 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 ?)
> - 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).
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 ?
regards,
Graeme Gill
(Author of ArgyllCMS <http://www.argyllcms.com/>)
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
