[RFC wayland-protocols] Color management protocol

Tue Dec 13 03:12:03 UTC 2016

On Mon, 12 Dec 2016 17:57:08 +1100 Graeme Gill <graeme2 at argyllcms.com> said:

> Niels Ole Salscheider wrote:
> > Am Donnerstag, 8. Dezember 2016, 13:33:20 CET schrieb Graeme Gill:
> 
> Hi,
> 
> >> I'm not quite sure what you mean. Generally an application will have
> >> specific reasons for wanting to do it's own color management - for
> >> instance, perhaps it is previewing a CMYKOGlclm file, and wants to
> >> treat out of gamut mapping and black point mapping in a particular way,
> >> etc. I don't think the Wayland compositor is going to be expected to handle
> >> CMYKOGlclm etc. input rasters, never mind all the requirements of
> >> specialist application color management!
> > 
> > This is of course something that the client application has to do. It would 
> > query the main output for its surface, do the conversions to that color
> > space and then attach the output color space to the surface.
> 
> Right. So a protocol for querying the profile of each output for its surface
> is a base requirement.

i totally disagree. the compositor should simply provide available colorspaces
(and generally only provide those that hardware can do). what screen they apply
to is unimportant.

if the colorspace is native to that display or possible, the compositor will do
NO CONVERSION of your pixel data and display directly (and instead convert sRGB
data into that colorspace). if your surface spans 2 screens the compositor may
convert some to the colorspace of a monitor if it does not support that
colorspace. choose the colorspace (as a client) that matches your data best.
compositor will do a "best effort".

this way client doesnt need to know about outputs, which outputs it spans etc.
and compositor will pick up the pieces. let me give some more complex examples:

compositor has a mirroring mode where it can mirror a window across multiple
screens. some screens can or cannot do color management. what do you do now?
compositor may display your window in a pager that is duplicated across
multiple screens and thus the content of that window should be rendered
correctly. what happens when the colorspace changes on the fly (you recalbrate
the screen or output driving hardware). you expect applications to directly
control this and have to respond to this and redraw content all the time?

this can be far simpler:

1. list of supported colorspaces (bonus points if flags say if its able to be
native or is emulated).
2. colorspace attached to buffer by client.

that's it.

> > The compositor now must not touch the parts of the surface on the main
> > output (where the color spaces match). But it could still try to convert
> > from the color space of the main output to that of a secondary screen if
> > the surface covers two screens with different color profiles.
> 
> Not as a base requirement. The application needs to be able to
> do it's own color management, which means color managing for
> every output the surface goes to. So the base requirement
> has no rendering requirement for a composer - it's just
> about signalling the required information to the client application.
> 
> > But then again most people that work with professional applications would
> > not make them cover multiple screens, I guess.
> 
> People using color managed applications expect color management to work as
> best it can across multiple screens.
> 
> > Therefore I'm not opposed to adding 
> > a flag that indicates that the application wants to disable color
> > corrections completely for that surface, independent of the output.
> 
> This is only something that becomes a question at the next
> level, where there is an expectation that the composer
> has some degree of color management capability.
> 
> >> Which is not to say that compositor color management doesn't have its
> >> place - it is ideal for applications that just want to use "RGB", and
> >> not deal with specific display behavior.
> > 
> > Very simple applications would just keep the attached sRGB color space and 
> > maybe place images on subsurfaces with the embedded color space from the
> > image attached.
> 
> That works only in the case that the composer supports the image colorspaces.
> This may well be the case for some applications (i.e. web browsers), but
> I imagine it may not be desirable to insist that all composers supporting
> a color management capability, support a full range of colorspaces (N - color
> in general).
> 
> > Applications that care a bit more about color correction (but do not have 
> > professional needs) could convert all their colors to the blending color
> > space of the compositor. I'd expect this blending color space to be linear
> > if the compositor cares about good colors.
> 
> It's not clear to me that any application that is interested in good
> color would trust it to blending operations.
> 
> I'd also imagine that there is a class of applications wishing to get the
> compositor to deal with gross display differences (Wide gamut vs.
> sRGB-like for instance) but is not interested enough in exactly what's going
> on color wise to be aware of the distinctions between linear light space
> compositing and other approaches.
> 
> Cheers,
> 
> Graeme Gill.
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com