Re: [Gimp-developer] [Gegl-developer] Don't make an architectural mistake based on a groundless premise

[Øyvind Kolås <pippin gimp org>]

On Sun, Oct 12, 2014 at 3:01 PM, Simone Karin Lehmann <simone lisanet de> wrote:
> > Cairo is just one part of our eco-system which is following the
> > guidelines of how to integrate with color management even if you do it
> > badly; assume sRGB.
>
> so that means, that specifying a monitor profile in GIMP’s preferences other than sRGB will result in 
> displaying wrong colors. Or am I wrong?
>
> I didn’t know that.
>
> On systems with builtin desktop CM, like OS X, wouldn’t it be better to disable the choice of a monitor 
> profile in GIMP at all, as long as cairo assumes sRGB?

This depends on how good GIMPs integration with the desktop CM is/will
be, whether it is possible to opt the canvas and some other bits of
the UI out of the sRGB assumption of the CM and pass uncorrected data
through to the front buffer of the GPU for display. The reason for
wanting to opt out only sub-rectangles rather than full windows, is to
ensure that colors of buttons and other ui bits is the same in all
applications. Without doing this one easily introduces color casts and
more.

For instance Gnome Color Manager does; or at least used to, do this
global correction of the front buffer towards being sRGB by altering
the vCGT - gamma lookup tables in the GPU itself - with a little bit
higher precision than 8bit. When fullscreen color management is done
like that, for all pixels of the display - we do not even have a
chance to opt out. When it is done with shaders and the possibility of
masks for opting regions out, which are features that kwin/compiz have
implementations of, the situation is different. GIMP needs to be able
to adapt to various of these circumstances. Including the situation
where nothing else on the system is doing color managment and the
values GIMP provide for output gets passed through without anything
else tweaking them.

/Øyvind