[RFC wayland-protocols] Color management protocol

[Carsten Haitzler (The Rasterman)]

On Tue, 13 Dec 2016 17:46:25 +1100 Graeme Gill <graeme2 at argyllcms.com> said:

> Carsten Haitzler (The Rasterman) wrote:
> 
> > wouldn't it be best not to explicitly ask for an output colorspace and just
> > provide the colorspace of your buffer and let the compositor decide? e.g. if
> > your window is on top, or it's the largest one, or it's focused,then the
> > compositor MAY switch the colorspace of that monitor to match your surface's
> > buffer colorspace, and if it goes into the background or whatever, switch
> > back? it can (and likely should) emulato other colorspaced then.
> 
> That doesn't seem like color management. Ultimately you arrive
> at the native display space, so if things are to look as intended,
> something (application or compositor) should transform from
> a non-native spaces into the native space.
> 
> At a practical level, if it is expected that the compositor
> deals with transparency (which I assume it does), then I'd
> suggest something simple - compositing in output device space
> (Isn't that what current Wayland compositors are doing ?),

a display may not have a single native colorspace. it may be able to switch.
embedded devices can do this as the display panel may have extra control lines
for switching to a different display gammut/profile. it may be done at the gfx
card output level too... so it can change on the fly.

yes. compositors right now work in display colorspace. they do no conversions.
eventually they SHOULD to display correctly. to do so they need a color profile
for the display.

it may be that a window spans 8 different screens all with different profiles.
then what? currently the image looks a bit different on each display. with a
proper color correcting compositor it can make them all look the same. if you
want apps to be able to provide "raw in screen colorspace pixels" this is going
to be horrible especially as windows span multilpe screens. if i mmove the
window around the client has drawn different parts of its buffer with different
colorspaces/profiles in mind and then has to keep redrawing to adjust as it
moves. you'll be ablew to see "trails" of incorrect coloring around the
boundaries of the screens untl the client catches up.

the compositor SHOULD do any color correction needed at this point. if you want
PROPER color correction the compositor at a MINIMUM needs to be able to report
the color profile of a screen even if it does no correcting. yes you may have
multiple screens. i really dislike the above scenario of incorrect pixel tails
because this goes against the whole philosophy of "every frame is perfect". you
cannot do this given your proposal. it can only be done if the compositor
handles the color correction and the clients just provide the colorspace being
used for their pixel data.

> or as a refinement, compositing in a per-channel light
> linearised space, that is reversible at the bit level.
> 
> Bottom line is that a color critical application won't
> use compositor transparency for anything it cares about.

i'm totally ignoring the case of having alpha. yes. blending in gamma space is
"wrong". but it's fast. :)

> > e.g. if buffer is adobe rgb, then switch display to work in adobe rgb but
> > re-render everything else that is sRGB into adobe argb space... there might
> > be a slight "flicker" so to speak as maybe some banding appears in some
> > gradients of SRGB windows or colors are ever so slightly off, but the
> > compositor is optimizing for the surface it thinks it most important.
> 
> Sounds cumbersome. It's certainly not how existing systems work.
> 
> > i really don't like the
> > idea of applications explicitly controlling screen colorspace.
> 
> I'm not sure what you mean by that. Traditionally applications render
> to the display colorspace. Changing the display setup (i.e. switching
> display colorspace emulation) is a user action, complicated only by the
> need to make the corresponding change to the display profile, and re-rendering
> anything that depends on the display profile.

being able to  modify what the screen colorspace is in any way is what i
dislike. only the compositor should affect this based on it's own decisions.

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