[RFC wayland-protocols] Color management protocol

[Carsten Haitzler (The Rasterman)]

On Mon, 19 Dec 2016 17:01:50 +1100 Graeme Gill <graeme2 at argyllcms.com> said:

....

at this point i'm going to summarize this. this might be more helpful than
continuing point by point rebuttals as i sense that there's something missing
in this conversation:

summary of what i think should be the case (or roughly):

1. if colorspace/profile with buffer from client matches screen compositor
SHOULD do nothing with the pixels unless it has to (eg has to blend them with
content below or otherwise do effects etc. designated by its layout policy).
2. if null colorspace then compositors generally agree to ALSO not touch pixels
and transform them unless it has to blend them etc. like #1, but irrespective
of the output
3. if colorspace/profile does NOT match the display then compositor can either
a) transform colors to get them correct on another display or b) leave them
along and just leave things as they are and perhaps let the user know that the
colors for that window/surface may be wrong on that display, or limit the
screens that display that buffer based on context.

how to clients select a colorspace? compositor sends available colorspaces to
client (maybe send per surface actually?). client picks one and renders content
given that colorspace/profile and presents that to the compositor for display.
compositor may update colorspaces that are available at any time.

colorspaces/profiles should be nominal colorspace with a whole bunch of numbers
detailing adjustments/mappings to do exact color correction for that
colorspace. if i have 2 sRGB monitors i may get 2 sRGB colorspaces each with
different transform constants/gamma lut tables etc.



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