[cairo] Adding a color management interface to GTK

[Kai-Uwe Behrmann]

Am 22.01.10, 09:38 -0000 schrieb Richard Hughes:
> 2010/1/21 Kai-Uwe Behrmann <ku.b at gmx.de>:
>> You add just an other API. But where is the new quality, the simplicity?
>> What are te advantages to virtually copy the lcms into Gtk? Please do not
>> missunderstand me, that I would ask for more features. I ask if your current
>> API is in parts already too much.
>
> That's the point. I've abstracted the color management objects so that
> we can implement with ColorSync on OSX (or using Adobe Color
> Management Module if that's installed) and the native API's on
> Windows. The whole point of having a gio-extension point is so that
> applications just work with none, one or some installed CMMs. This
> keeps the embedded users happy (as the fallback is either NOP or
> memcpy) and the artists happy as it "looks the same as in photoshop".

Agreed, abstraction is good.

>> GtkColorTransform is already hard stuff for most users. They want some fuzzy
>> CM but have so many other things to do.
>
> This is why most users won't be touching GtkColorTransform. If it's
> built directly into high level widgets like GtkImage then it becomes
> easy for the programmer to "enable" color management. If you make
> color management as hard as it is now, then most application authors
> won't bother, as we see from the small number of applications using
> things like lcms.

Ok. So I seems to missunderstood your patch as having a GtkColorTransform 
as precondition to use the new Gtk CM.

>> Gtk knows when it displays on screen on which monitor or on which printer.
>> That could be enough to not bother 80% of the CM wanting programmers about a
>> GtkColorTransform.
>
> Correct, but we have to export it in the API so applications that do
> know what they are doing, can do things like softproofing, and can
> optimize color correcting 1500 photos in a folder. You don't want to
> be loading (and then tearing down) lcms, the profile and transform
> every time you render an image.

But my question is more that a user is not forced to use that API in order 
to get a colour managed widget. My naive logic says a ICC profile passed 
to GtkImage could be made enough.

>> If you manage to pass all collected ICC profiles through the Gtk structures,
>> add resonable options, e.g. rendering intent, black point compensation and
>> so on, then Gtk could be able to display or print the whole window colour
>> managed. That had the potential of easier CM.
>
> Agreed, and this is what I've tried to do.

I try to understand the details of your approach.

>> t least there are already many thoughts gone into the question about how CM could be
>> implemented in Cairo and how a API could look like. It would not be from
>> scratch.
>
> Cairo is a great product, but at the wrong level to deal with this
> hi-level color management. To make this easy for end users, we need to
> talk about display color management in terms of GdkScreens and
> GtkWidgets.

In my understanding of your goals, Gtk will use probably a subset of a 
possible Cairo CM? Of course Cairo needs to be tould about screens and 
widgets. But once the hooks are in place to configure a Cairo backend with 
a monitor profile (probably the image backend), then its even more modular 
for Gtk to use that. Its just a guess.

>> Huch that touches the 10% of colour users. For "photo viewers, pdf readers
>> etc" the GtkColorTransform stuff can be relevant. But thats not 90% of the
>> users or area on the desktop. Most space are buttons, spacers, window
>> borders, backgrounds and so on.
>
> We're already applying vcgt ramps to the output(s), which, agreed,
> isn't color management, but is color correction. You don't want to

Fine. Does Gtk stop in case a _ICC_PROFILE is already in place and 
assume the vcgt ram is already set? (So ArgyllCMS or Oyranos could do 
this on user choice from the ~/.xinitrc file.)

> have the performance penalty of color managing every widget in every
> application as this is simply a waste of resources. Performing color
> management on a desktop (which has large, changing areas) is
> considerably more expensive than performing it on a 300x300 widget
> (which you know when has been changed).

I completely agree. So, I would assume that e.g. Gtk colour tables 
(assumedly sRGB) are internally translated to monitor Rgb. This would 
allow to flag many widget as already pre colour managed at nearly no 
computational cost.

>> One of the difficult to solve problems
>> colour managed applications are still faced with, is image content divergine
>> from the surrounding desktop. So a CM GtkImage widget would add to that
>> group just with fewer options. Of course more applications have then that
>> missed desktop CM problem.
>
> I'm not sure I understand your point.

I mean a monitor with green cast and a corrected image in a viewer might 
give the user a impression as if the image is magenta casted. This is 
due to subjective adaption to the unmanaged surrounding of the colour 
managed image on screen. It obviously changes in full screen mode. 
Such behaviour is irritating. Vcgt help quite a bit but not completely.
Think of wide gamut monitors. They will reach Gtk users at sinking price 
points in the near future.

>>> I'm also keen on pushing it into GTK core library rather than
>>> just requiring applications use something like lcms. They can, and do,
>>> frequently get this wrong and the vast majority of authors just don't
>>
>> So true. Thats why they need some help.
>
> No, software authors aren't stupid or misguided, they usually have
> time pressures, or want to add the sexy new widget into their
> application. All the time we're asking them to poke about with
> notify::pixbuf and manually tracking pixbufs or surfaces we're not
> making things easy enough.

If I look around at various application side CM implementations there is 
quite some learning curve. And admittedly its not a easy one. So taking as 
many decissions away while keeping the door open for opting out is IMO a 
good thing and helps as well for time pressure.

>> For that CM must be easy. Explicite CM in its current form is not easy.
>> (That said the lcms API had already easened life considerable for many.)
>
> Ohh, I disagree. If we can make any random program color managed by
> using a API call like
> gtk_widget_set_use_internal_color_profile(widget,TRUE) then making
> your application "color aware" is trivial.

Ah. well I would think just the way around:
gtk_widget_set_already_color_matched(widget, TRUE);

But you seems to care a lot about speed. Well I wish it could be a non 
issue for toolkits.

>> In the long run a compositing window manager might be best to colour convert
>> the whole desktop in hardware on the fly including animations ...
>
> And the performance hit of that is, well, huge. There's a reason Apple
> and Microsoft haven't put the CMM in the window manager. It's a cool
> trick, but in my opinion, not a good idea.

Time moves on. osX SL does exactly as I described. Ask someone with the 
newest Apple OS and set the monitor profile to something completely off[1] 
and switch to a normal profile for and back. Movies are completely colour 
managed. This is not vcgt only as in previous versions. (I have one of the 
slowest of the last years Apple laptops. Full HDTV is fine.)

So my guess is, MS will not wait too long with that feature.

Desktop CM, as possible with GLSL capable GPUs, might not be available 
everywhere. But interessted people will shurely enable that as it 
becomes available. If there is interesst I can do a demo at LGM[2].


kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org


[1] http://www.oyranos.org/wiki/images/c/c0/FakeBRG.icc
[2] http://create.freedesktop.org/wiki/Conference