Hello,
It's very difficult to contribute to this discussion, but here is my
delta contribution.
I agree with the following proposal with comment bellow.
On 19/12/2016 09:27, Carsten Haitzler (The Rasterman) wrote:
On Mon, 19 Dec 2016 17:01:50 +1100 Graeme Gill <grae...@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.
First this proposal do not cover the calibration and profiling
procedure. This is about 'non-calibration clients' to use already used
vocabulary, and I agree with the proposition to treat this topic
independently of the calibration and profiling procedure.
The color space must be defined: color space define the link between the
pixel value and the corresponding physical light property
(Intensity/Luminescence, the mix of wavelength, ...?)[1]
To that proposal, I would add that the compositor should advertise the
preferred color space. The definition of 'preferred' color space is
implementation-defined (compositor-defined)[2]. For example a compositor
may set the preferred color space to the color space that have the most
accurate result, or the color space the most 'hardware' efficient
(null-transform), or simply the user preferred color space[3]. He may
not match any monitor color space.
We should also agree that surface that do not include color space
specification should be null-transformed or maybe sRGB or something else
(this is an open choice).
[1] I guess most color spaces are not defined as absolute light
intensity but with relative intensity between a given black point and
white point.
[2] I choose compositor-defined, because in case of multi-monitor it
would be difficult to give a definition.
[3] I choose only one preferred color space instead of per monitor,
because per-monitor color space, imply that client must known the
monitor he belong.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
