[RFC wayland-protocols] Color management protocol

[Carsten Haitzler (The Rasterman)]

On Wed, 14 Dec 2016 18:49:14 +1100 Graeme Gill <graeme2 at argyllcms.com> said:

> Carsten Haitzler (The Rasterman) wrote:
> > On Mon, 12 Dec 2016 17:57:08 +1100 Graeme Gill <graeme2 at argyllcms.com> said:
> 
> >> 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.
> 
> Please read my earlier posts. No (sane) compositor can implement CMM
> capabilities to a color critical applications requirements,
> so color management without any participation of a compositor
> is a core requirement.

oh course it can. client provides 30bit (10bit per rgb) buffers for example and
compositor can remap. from the provided colorspace for that buffer to the real
display colorspace.

> > 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).
> 
> Relying on an artificial side effect (the so called "null color transform")
> to implement the ability to directly control what is displayed, is a poor
> approach, as I've explained at length previously.

but that is EXACTLY what you have detailed to rely on for color managed
applications. for core color management you say that the client knows the
colorspace/profile/mappings of the monitor and renders appropriately and
expects its pixel values to be presented 1:1 without remapping on the screen
because it knows the 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".
> 
> No compositor should be involved for core support. The application
> should be able to render appropriately to each portion of the span.

then no need for any extension. :) compositor HAs to be involved to at least
tell you the colorspace of the monitor... as the screen is its resource.

> > 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:
> 
> That only works if the client doesn't care about color management very much -
> i.e. it's not a color critical application. I'd hope that the intended use of
> Wayland is wider in scope than that.

how does it NOT work? let me give a really simple version of this.

you have a YUV buffer. some screens can display yuv, some cannot. you want to
know which screens support yuv and know where your surface is mapped to which
screens so you can render some of your buffer (some regions) in yuv and some
in rgb (i'm assuming packed YUVxYUVxYUVx and RGBxRGBxRGBx layout here for
example)... you wish to move all color correct rendering, clipping that correct
(yuv vs rgb) rendering client-side and have the compositor just not care.

this leads to the artifacts i was mentioning. just this one will be a LOT more
obvious.

> > compositor has a mirroring mode where it can mirror a window across multiple
> > screens.
> 
> Sure, and in that case the user has a choice about which screen is
> properly color managed. Nothing new there - the same currently
> applies on X11, OS X, MSWin. Anyone doing color critical work
> will not run in such modes, or will just use the color managed screen.

the point of wayland is to be "every frame is perfect". this breaks that.

> > some screens can or cannot do color management.
> 
> Nothing to do with screens - core color management is up to
> the application, and all it needs is to know the display profile.

i mean they are able to display wider gammut of color beyond the limited sRGB
range that is common.

> > 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?
> 
> Yep, same as any other sort of re-rendering event (i.e. exactly what happens
> with current systems - nothing new here.)

and this leads to imperfect frames.

> > 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.
> 
> If you don't care so much about color, yes. i.e. this is
> what I call "Enhanced" color management, rather than core.
> It doesn't have to be as flexible or as accurate, but it has
> the benefit of being easy to use for applications that don't care
> as much, or currently aren't color managed at all.

how not? a colorspace/profile can be a full transform with r/g/b points in
space... not just a simple enum with only fixed values (well thats how i'm
imagining it). in this case the api's tell the client the available colorspaces
and chooses the best. it would have NO CHOICE in your core mangement anyway.
it'd be stuck with that colorspace and have to render accordingly which is the
exact same thing you are proposing for core. profide a list of 1 colorspace -
the monitor native one. application renders accordingly. if colorspace of
rendered buffer == colorspace of target screen, compositor doesn't touch pixel
values. if the buffer is sRGB (or well current wayland rgb buffers) it might
rmap srgb to this output colorspace OR it might just do nothing and also leave
it alone, thus doing exactly what you propose for core color management.

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