Integrated color management with colord

Desktop Linux users used to be easily divided into two camps when it came to color management: there were the graphics geeks — who painstakingly profiled their scanners, printers, and displays and manually set up color management in each of their creative applications — and there was everyone else, who saw color management as an esoteric hobby with no practical value. The color geeks are quietly taking over, however, thanks to recent work that automates color management at the system and session level.

The root of the color management problem is that no two devices have exactly the same color reproduction characteristics: monitors and printers vary wildly in the tonal range and gamut that they can reproduce; similarly cameras and scanners vary wildly in what they can pick up. If you spend all week staring at a single display device it is easy to forget this, but anyone who has set their netbook on the desk beside a desktop LCD display recognizes immediately how different they can be. As a practical matter, when a user makes a printout and finds it too dark, or orders a piece of clothing online and is surprised at its color when it arrives, lack of color management is the problem.

But color management is essentially a solved problem that has yet to be implemented system-wide on Linux. Every display or input device can be profiled — that is, its color characteristics measured and saved in a standardized format like an ICC color profile. With profiles in hand, applications need only to perform a transformation on RGB data to map it from one profile (say, a camera's) to another (a display's). Most of the time, a mapping with a perceptual rendering intent is used, which means the final image will appear the same to the human eye on the display as it did through the camera viewfinder.

The old way

Several free software packages exist for applications to perform these transformations. By far the most popular is LittleCMS, an MIT-licensed library used by GIMP, Krita, ImageMagick, Inkscape, Scribus, and many other graphics applications. Another well-known alternative is Argyll, which is licensed under the AGPL. Argyll consists of a collection of command-line tools, however, rather than a shared library designed for use by application programs.

LittleCMS support simply gives each application the ability to perform profile-to-profile transformations. Users are still required to open the preferences dialogs in each application and specify the .icc file for each profile used in their hardware setup. As a result, "color management" came to be a feature that could be enabled or disabled on a per-application basis, since only a small percentage of users cared enough to have profiles for their displays and printers. A far better approach would be for the system to keep track of the relevant profiles (since displays, scanners, and printers tend to stay put for long periods of time), and have applications automatically retrieve them as needed — no user intervention required. That is the approach taken by both Windows and Mac OS X.

The technicolor dawn

This is where Richard Hughes's colord and Gnome Color Manager (GCM) come into play. Colord is a framework for automating the storage and retrieval of color profiles. It includes a system daemon that maintains an SQLite database to track which profiles map to which devices; it also provides a D-Bus interface for other programs to query (or in the case of GCM, add and change) profiles.

It can retrieve scanner and printer device IDs through Udev and present a simple interface with which users can select their preferred profile for each device. Multiple profiles per device are supported, to allow separate profiles for different paper stocks, ink options, flatbed and transparency adapters, and other parameters. An application can ask for the profile for a specific device using dot-separated qualifiers, such as RGB.Glossy.600dpi. If colord does not have a stored profile for the requested qualifiers, it can fall back one parameter at a time to find the best match, e.g., to RGB.Glossy.* or RGB.*.600dpi, and eventually back to RGB.*.* and the default * for a device ID.

The other half of the framework is GCM, which is a session-level process implemented as a GNOME settings daemon plug-in. GCM talks to the X.org session to retrieve the display device information through XRandR and, where possible, to set display settings such as video card gamma tables (VCGTs). The session-level process can also read ICC profile files stored in the user's home directory (as opposed to the system-wide ICC profile directories /var/share/color and /var/lib/color, which are watched by the colord daemon).

Hughes said in a recent talk that the system/session split, though it sounds confusing at first, is required for several reasons. First, the system daemon needs to talk to other system-level processes such as CUPS (for printers) and SANE (for scanners), and needs to work even when there is no active user session (consider shared printers, printers that print directly from memory cards, and GDM login screens, for example). But the session-level process also needs to be separated from privileged operations for other reasons. SELinux will not allow a system daemon to load files (in this case, ICC profiles) from a user's home directory because of security concerns, and colord would not even be able to read them if the home directory is encrypted. The separation also makes it possible for KDE, LXDE, or other environments to write their own colord-compatible session management code independent of GCM.

The application's viewpoint

The framework provided by colord and GCM is very high-level; applications must still do the color transformations using LittleCMS or another library. But by relying on colord to provide the correct profile information for a particular hardware device, there is less for the application developer to worry about.

GCM provides an interface for the user to manage his or her profiles, which alleviates the problem of manually setting the same preferences in every application. But applications do need to be updated to work with colord. At the moment, the list of colord-compatible programs is short: Hughes told Alexandre Prokoudine at Libre Graphics World that it includes CUPS, Foomatic, Simple Scan, and Compiz-CMS. The GTK+ toolkit is also compatible he said, and KDE support is on the way.

General-purpose GTK+ or KDE applications can decide to entrust colord with their entire color management workflow, but creative applications may still want to provide additional options. For example, users may want to simulate an output device with a different profile to "soft proof" before printing or rendering images. Colord can still help, because it can maintain profiles for "virtual devices" in addition to the local hardware, but of course presenting that functionality to the user requires pulling back the curtain away from the "it just works" approach favored by simple applications.

Perhaps understandably, support for colord among the already-color-aware Linux creative suite appears to be growing slowly. Krita has integration plans, but it may be a while before the other applications that already implement color management adopt colord, on the grounds that the users who already care have also already configured their software.

On the other hand, Hughes has been busy submitting patches to other projects to enable colord support. He added the colord support now found in CUPS' gstoraster filter (which converts PostScript and PDF content to raster data) and foomatic (which can directly generate printer-language files) and has reportedly been patching other tools as well. Colord debuted in 2010, and was available in GNOME 3.0, but is now a hard dependency for the imminently-due GNOME 3.2, so for the first time, application developers can count on its availability.

Where profiles come from

As a practical matter, the big lingering question for end users is where the all-important device profiles come from. After all, it makes no difference how easily the applications can retrieve the default profile for a display or printer if there is no profile available. Hughes has designed colord to support profiles from a variety of sources, and always takes the "the user is right" approach: a manually-selected profile is assumed to be better than a generic one.

The best possible profiles are those that are created with proper measuring device: a tristimulus colorimeter for displays, a high-quality target for scanners or digital cameras, or a spectrophotometer for a printer. But all of these methods involve some outlay of cash. The price of colorimeters has fallen sharply in recent years, but even the cheapest devices run close to US $100, which can sound excessive for a hardware device only used on isolated occasions. There are non-profit producers of quality IT 8.7 targets, such as Wolf Faust, but they are still not free. Spectrophotometers, which measure reflected light, remain expensive, although there are paid services to which users can mail a test printout and get a high-quality ICC profile in return. But the one-time cost of buying such a profile rises when you consider the need to have each ink and paper combination measured separately.

Still, GCM does support creating a display profile with a USB colorimeter, importing camera or scanner images of calibration targets for scanner or camera profiles, and scanning printouts to generate printer profiles. GCM uses the low-level profiling tools from Argyll for much of this process, but Hughes has also been adding native drivers for common colorimeters like the Pantone Huey.

The next rung down on the quality ladder is manufacturer-provided profiles. These vary depending on device type and quality control. An expensive film scanner might ship with an accurate profile on the accompanying CD, while an inexpensive laptop display is completely hit or miss. As Hughes explained,

Even where manufacturer-provided profiles exist, however, Linux distributions generally do not have the rights to ship them, so they are inaccessible to an "it just works" framework.

As an alternative, Hughes said, GCM can probe XRandR devices for Extended display identification data (EDID), and auto-generate a basic display profile based on it.

Here again, Hughes warned that the quality of the device in question correlates to the quality of the EDID data one should expect. Manufacturers who regularly swap in LCD panels from Korea, China, and Taiwan without indicating a difference in the model number are likely to burn in generic EDID data that covers the average characteristics of the product line.

Unfortunately, how useful the provided EDID data is can also depend on extraneous factors like the video driver. For example, the NVIDIA binary drivers only support XRandR 1.2, which in turn does not include support for sending separate VCGTs to multiple monitors. Thus regardless of the quality of the data, at least one display will be forced to use gamma tables that are only accurate for a different monitor. It is also possible to run into older monitors that do not provide EDID information at all, or to have KVM switches or splitters lose it en route to the video card.

Kai-Uwe Behrmann of the Oyranos project, a competing color management framework, recently undertook an effort to build an open, user-contributed database of device profiles. Called taxi, the system was developed in the 2011 Google Summer of Code by student Sebastian Oliva. There is a web front-end running at icc.opensuse.org, which returns both raw .icc files and JSON-formatted metadata about the source device. It is an interesting approach, though one with its own set of problems. Display characteristics change over time, for example, as the backlight ages, and there is no way to verify the conditions under which another person's profile was created.

In the final analysis there is no automated substitute for a good profile created with quality test materials; a fallback profile will always be better than nothing, but unpredictable. Perhaps the best thing the community at large can do if it wishes to spread good, non-generic profiling is to make sure that the distributions and desktop environments pack a colorimeter and IT 8.7 target into the "booth box" when heading to community Linux shows. It certainly would not hurt.

The future

The colord daemon and GCM session manager provide the framework on which future applications can build end-to-end, "it just works" color management for the Linux desktop environment. That future is a big step up from the recent past, where each color-aware application needed to pester the user individually for a collection of profile settings, but it is still not color nirvana. For that one needs to look ahead to full-screen color management.

Hughes outlined the situation in his interview at Libre Graphics World. A full-screen color managed system would need a color-aware compositing manager, but would also allow applications to mark specific regions of the screen to "opt out" from the transformation — UI widgets are assumed to have sRGB pixels, for example, but a photograph would have a camera profile instead. But by pushing the transformation into the compositor, it becomes possible to offload the calculations to the GPU, potentially speeding up workflow dramatically.

The compiz-cms plug-in is an attempt to do this, although an incomplete one: because the applications are not able to mark specific regions with different transformation needs, the plug-in assumes all images are sRGB. For Compiz users, however, it is an intriguing glimpse at the possibilities.

Behrmann has developed a draft specification for communicating color regions, formerly called net-color but recently renamed X Color Management (currently in the draft stage for version 0.3). Hughes has concerns about the specification for use with colord, including its network transparency and its ease of implementation for application developers, but so far there is not a competing proposal. As he told Libre Graphics World, however, he is hoping to put together a plan for GNOME 3.4 that will incorporate colord support into Mutter, the GNOME compositing manager, but it is likely to involve changes to GTK+ and other parts of the stack as well.

Color-management is not something that can be completely automated, but desktop Linux is on track toward the next best thing, that the choice of sane defaults is automated. Colord effectively moves color-awareness out of the application space and down to the session level. For most people, on modern video hardware, an automatically-detected display profile will provide a "good enough" color balanced experience. The list of applications taking advantage of it is short, but growing, but the color geeks need not frown — as was the case before, those who are interested in hand-tweaking their color matching can still dig into the details and customize the experience.