1. Colour Management in X/GNOME

We need unified colour management in GNOME, so that applications can correct images for display. Otherwise photos look dull and washed out, and designers print their work to find the colours are wrong.

1.1. Current Status

The first release of the ICC Profiles In X specification is now available. (the latest spec)

GIMP 2.4 and Krita (a KDE drawing app) use this specification and there are patches for Eye of Gnome, while Scribus is considering adding support (bug report)

1.2. GdkPixbuf stuff

gdk-pixbuf should either provide the profile embedded in an image in a generic way, or transform images to a standard colour space when they are loaded (say sRGB). I'm torn over this at the moment, if someone has a monitor with a wide gamut or is printing the images from the pixbuf, if the image was transformed to sRGB it could have lost data.

Currently, GdkPixbuf loads image data plainly; it does not apply any gamma correction or do other transformations. The resulting RGB data in memory is "as is".

gnomebug:304253 is about reading the gamma information from a PNG file and correcting the RGB data appropriately. Also, BMP version 4 has extra fields in the header that give curve data for each channel.

The data stored in GdkPixbuf or by Cairo is considered to be sRGB. (Note that for an ARGB image, the alpha channel is however linear.) Currently, compositing in GdkPixbuf or Cairo is not gamma-corrected but this is considered to be something that we'll want to improve in the future when we can do it with reasonable efficiency.

The reason for using sRGB rather than a gamma=1.0 format is partly matching existing practice and working OK when fed without correction to a monitor, but it is also because sRGB is simply a better format for representing image data: since sRGB approximately matches the response of the human eye, to get equivalent quality to 8-bit sRGB requires 10 or more bits for gamma=1.0. (gamma=1.0 images have two many levels near white and too few near black.)

One obvious downside to using sRGB for images is that sRGB with RGB in the range [0,1] doesn't have a very big gamut (hence formats like Adobe RGB). So, eventually, we may want to support additional image formats for Cairo: for example some of the floating point formats that are becoming common now. There is no problem with the specification of colors for functions like cairo_set_source_rgb() because we take floating point arguments so we can use RGB values out of the [0,1] range to get colors not representable in sRGB.

1.3. Other Implementations

Apple uses the ColorSync APIs for this, see the overview or the API reference.

1.4. Current ideas

I (HubertFiguiere) would like to throw up a few ideas here:

• screen calibration, we should make that a freedesktop standard. Ross Burton has written xicc, and that implementation should be hidden thru APIs to set and get the current screen ICC profile. The cross-dekstop is required to allow GNOME apps working from within KDE and vice versa, this is an important point.

• APIs. We should be able to create a GdkPixbuf with in and output ICC profiles. The input ICC profile could be exctracted from the input image file. Also creating uncalibrated GdkPixbuf should be left, as the default.

• GNOME-print should be able to is the printer ICC profile. Gimp-print too.

• We should have a capplet to setup the screen profile, and various options. Possibly turn the current "Screen Resolution" capplet into a general screen prefs (RossBurton)

• ICC profiles collection: GNOME should come with as much ICC profiles as it can. Basic profiles can be found in the Scarse Profile Library. This might be a long process as we would have to collect them from manufacturers and check that we are allowed to use them, which is not settled yet given their current "cooperation". (note that lcms doesn't ship with the Adobe RGB profile due to trademark issues) How about being able to import them from the install CDs? (BastienNocera) Good idea, maybe the UI should be able to search CDs for .icc files. (HubertFiguiere) I thought about that, but it should plan B and this does not solve the issue if they put the profile inside the installer binary, which is likely to be the case most of the time. For example my Canon camera does not come with the ICC profiles verbatim on the CD. One has to install them.

1.4.1. ICC profiles

Just because a CMS without profile is useless, we should list available sources:

• Adobe has a set of ICC profiles that can be redistributed in a Free Software incompatible way. See download page. We should get legal council to see if that can be included in GNOME and/or request Adobe permission, but definitely, it is worth it. Note1: Search for "ICC Profile" on adobe.com, if above url is not working. Note2: See Adobe ICC Profile Bundling Eula for bundling which show that the redistribution is not possible in a Free Software compatible way.

• Scanner profiles from KWLee

• Oyranos also ship with several profiles including on that is compatible with !AdobeRGB.

1.4.2. UI

• The screen capplet should allow setting the ICC profile. The best would be to be able to set it up automatically as we can detect which monitor is connected.
• We should have a widget to show ICC profiles, and allow visually comparing them. Here is how it looks like on MacOS X:

  • 

1.5. Links

• OpenICC

• LittleCMS

• Ralph Levien's gcmm

• Apple tutorials will give some UI ideas.