A solution for gamma-adjustment support in Wayland

[Mattias Andrée]

On Tue, 27 Dec 2016 16:25:20 +1100
Graeme Gill <graeme2 at argyllcms.com> wrote:

> Hi,
> 
> Daniel Stone wrote:
> > 'The size and depth' and 'the CLUT' are no longer
> > applicable. Colour management units, incorporating two
> > LUTs and a matrix (coarsely, degamma-transform-regamma)
> > are becoming rather common now. These units can be
> > present per-plane as well as per-output/pipe. Sometimes
> > you have to make tradeoffs.  
> 
> Just because some hardware is a lot more capable, is no
> reason to ignore supporting currently expected
> functionality.
> 
> Simple per channel hardware lookup tables have been
> supported by graphics card software for a very long time
> (Our X terminals in the late 80's certainly had them), so
> this level of support can be assumed as almost universal,
> and there are well understood reasons for using such
> hardware to set the state of the display for color
> management purposes at least (which I have articulated
> elsewhere). Usage of further HW capabilities (matrices
> etc.) are much less clear - no application interested in
> fully utilizing a displays best possible gamut has any
> use for them (since they can only reduce the gamut),

Ideally I think the display server should support sRGB,
CIE XYZ, and the monitors' native RGB for input. sRGB is
useful for programs such as image viewers and video players.
Native RGB is useful for utilising the full gamut, and
CIE XYZ is useful because almost all colour models can be
converted to CIE XYZ in one step, it is device independent
and can represent any visible colour. But of only supporting
one colour space I think the monitors' native RGB should be
used and that it is up to the application to find out one
which monitor each part of the application's windows are
visible and which colour space each monitor uses.

But supporting matrices is useful for filters such as
simulating defective colour vision and changing colours
to make it easier for people with defective colour vision
to distinguish them.

> and
> there is much more flexibility in dealing with non color
> managed applications in the applications and/or
> compositor, so that they can co-exist with full color
> aware applications.
> 
> > The point is that I'm extremely wary of copying X11 by
> > way of encoding this into an API; it's a truly dizzying
> > space to even enumerate, let alone abstract.  
> 
> I'm not sure what you are thinking of here - the existing
> per channel VideoLUT API's are universally simple, and
> the only temptation in making changes to this might be in
> the direction of better coordinating competing use of
> this shared resource.
> 
> I agree that expanding such API's to encompass more
> advanced HW capabilities is something of a project, and
> might not even be a good direction to proceed if other
> alternatives are a more enticing use of time and effort
> (installable shaders in the rendering pipeline ??)
> 
> Regards,
> 
> Graeme Gill.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20161227/bd1cb744/attachment.sig>