Color Management, Open Source, and Inkscape


Table of Contents

Color Management Basics
ICC Profiles
Tools
Argyll Color Management System
Oyranos
LPROF
XICC
Multi-monitor
Color Management in Scribus
Color Management in GIMP 2.4
Color management in Inkscape 0.46
Feature Overview
Inkscape CMS for Web Graphics
Inkscape CMS for Print Graphics
Inkscape CMS for Mobile Devices
Integration of Color Management Across Applications

The primary goal of color management is quite simple: to obtain a good visual match across various devices. A video should appear the same whether it is shown on a computer LCD monitor, a CRT monitor, a projector, a plasma TV, or if a frame is printed out and held up for comparison.

Traditionally the perception is that color management has been reserved for professionals and esoteric experts. Photographers, graphic designers and those working in film and television often have a good understanding and experience with color management. However home users, businessmen and others who could benefit from at least basic color management have remained either ignorant of the concept itself, or have shied away due to seeing it as too complex or not relevant.

A businessman working on a proposal for a large deal may send materials off to be professionally printed, and it may be critical that the colors come out as desired, especially with items such as corporate identity, logos and such. Home users taking photographs with digital cameras now have very capable hardware available, but will not like prints where greens shift, or blues turn to purple. And even consumers browsing the web for purchases need to have color managed better than it often is; the number one reason for returns of online sales is color.

The main vendors of consumer operating systems, Apple and Microsoft, have understood the benefits of color management and have been incorporating it at the system level for some time now. Apple has focused on support for graphics professions from early on in the history Mac OS and have a very robust and mature solution in ColorSync. Microsoft also has a well developed solution in Windows Image Color Management. However, Linux has fallen far short in this arena. There are still some debates on where different aspects of color management belong in a Linux system, including some question of which parts if any belong in X11 and which should ride on top of it. Complicating this is the flexible nature of X11 itself, including among its core premises the fact that a computer running an application may not be the one running the display for that application.

The good news is that in the last few years the landscape of color management in Open Source has made some significant progress, and is definitely picking up momentum. A lot of this is due to the nature of computers, electronics and graphics. Cameras and scanners with better fidelity have become affordable consumer items. More commerce is being conducted online. And constantly growing numbers of people are engaging in more computer related activities. Another factor has been the collaboration of various Open Source projects that had not occurred in the past. The now annual Libre Graphics Meetings (LGM) started as a simple get-together of members of a single project, but in planning it they quickly saw the benefit of inviting more groups. One of the benefits of that first meeting was a chance for different project members to start talking, and especially for them to hear about LittleCMS from Marti Maria. Also people from different projects collaborating on OpenICC were able to get together and also spread the word on OpenICC itself.

Developers had been aware of the need for better color management for some time, but coming together presented the chance to see how close first steps might be, and how benefits could begin without too much extra effort. For example, not too many weeks after that first LGM work was completed in Inkscape to add base ICC profile loading and application of profiles to embedded images (which happened to allow it to pass another of the SVG test suite cases). By fall of 2007 additional color management support was integrated into Inkscape. More importantly GIMP 2.4 was released with a good base of initial CMS support. Work had been done independently in the two, but from the same seed and with cross-project windup for things like xicc.

The current workflow focus is on incorporating ICC profiles. Those are the standard descriptions of the aspects of a given input or output device, With proper ICC profiles, color can be captured correctly, passed onto editing software correctly, and output correctly. Additionally ICC profiles can be used to preview output while still working on graphics. If an end user has a profile for his monitor, one for his camera, one for his printer *and* software that uses them, then he will get exactly what he sees consistently showing up everywhere as he needs. Knowing that ICC profiles are the centerpiece is the main step.

First are tools for creating, applying and maintaining ICC profiles. These include Argyll CMS, LProf, xicc and others.

http://www.argyllcms.com/

Argyll is an open source, ICC compatible color management system. It mainly consists of a set of command-line tools, and supports several spectrometer and colorimeter devices used to measure and create ICC profiles.

Support instruments are listed at http://www.argyllcms.com/doc/instruments.html.

http://www.oyranos.org/

Oyranos is another CMS system targeting Linux and was created by Kai-Uwe Behrmann. It was drawn from his experience and work on CinePaint.

http://lprof.sourceforge.net/

LPROF is an open source ICC profiler with a GUI and can be used to create ICC v2 compliant profiles for cameras, scanners, and monitors.

http://burtonini.com/blog/computers/xicc

XICC is a simple specification for attaching monitor-specific profiles as X11 atoms. XICC aware applications can use this to dynamically fetch appropriate ICC profiles even under multi-monitor and multi-computer situations. Ross Burton has also made available a command-line implementation as xicc.

Applications supporting XICC include the GIMP, Eye of GNOME, Krita, UFRaw and Inkscape.

Multi-monitor setups present a special problem for color management. Not only is it possible to have different types of displays connected, including LCD monitors, CRT monitors, projectors, HDTV televisions, etc., but the ways these are connected and run can differ. Multiple displays may be connected via a single card, or with multiple display cards. Some vendors provide their own support for multiple displays (such as NVIDIA's TwinView), but the more common standards are Xinerama and XRandR.

Xinerama is the older solution, and is moving out of vogue. However it is still important to some systems, such as X11 applications running on top of OS X. With OS X 1.04, dynamic multi-monitor support is supported well, including shifting of device resolution being passed through X11 up to GTK+. There was a major shift with OSX 10.5 where Apple moved from Xfree86 to X.org. Apple also continues to move forward in the X11 support on OSX 1.05. And, of course, native OS X applications can gain direct use and benefit of ColorSync.

XRandR support has sped up of late, with the last few versions of Ubuntu working on improving implementation and reliability. Recent work of members in OpenICC has also been focusing on how to deal with XRandR setups among others.

Once the lower level has been addressed, there are different steps applications can take to detect and adjust to multi-monitor setups. One of the simplest is xicc. Despite its simplicity, though, it is surprisingly helpful. It basically spells out a simple mechanism to use X11 atoms to attach ICC profiles to an individual monitor. Given the availability of those, an application can adjust its rendering to correct for the monitor a given window is displayed on. Or a more advanced application could even use different profiles to adjust different portions of a window.

Scribus has had color management for some time now, and has a very print-oriented workflow. It has been targeting professional printing capabilities, and creates nice PDF output.

One main block in an Inkscape-Scribus workflow has been in its importing of SVG graphics. In the fall of 2007 Inkscape 0.46 finally put out a common tool artists can use to create SVG files with true CMYK. Developers working on Scribus were winding up their next release, but have looked in to enhancing the SVG import. The Scribus developers are currently targeting version 1.3.6 to include this enhanced support.

They list "Color management with Scribus, an Introduction" http://docs.scribus.net/index.php?page=cms and links to general information at "Color Management" http://www.scribus.net/?q=links/color

Color management was introduced in GIMP 2.4 in the fall of 2007. It was a base implementation with all required functionality for artists to be up and running with a color managed workflow. http://www.gimp.org/release-notes/gimp-2.4-cm.html

GIMP allows for an RGB and a CMYK working profile, along with a display profile and a "Print simulation" (aka soft-proofing) profile. When working with raster image data, however, care must be taken with different files and different working profiles.

The first step in color management for Inkscape has actually been in from the beginning as an effect of the SVG specification itself. SVG defines that the working colorspace for data and interpolation is the sRGB colorspace. So for any standard SVG file, the colors specified are done so in such a way that the *desired* value is explicit.

Inkscape 0.44 added support for linking to ICC profiles via the <color-profile> element. However the only use for those profiles at that time was to assign them to a given image for the image to be corrected. With version 0.46 the ICC support was expanded to cover display adjustment, soft-proofing and color selection.

It is important to enable a color managed workflow across as many applications as possible. In early 2005 color management was mainly just supported in Scribus and CinePaint. Since that time, GIMP, Krita, Inkscape and others have released versions with CMS support.

The work on connecting these is moving forward, including one of the Google Summer of Code projects done for OpenICC. Until things are more automated, however, end users will need to get their displays calibrated, adjustments loaded and all aware applications loading the proper display profiles.

And finally the best thing to get solutions working well across applications is for people to start using color management in their workflow and to give feedback to developers on different projects. It is very hard for developers to address interoperability issues unless end users notify them of the problems. The more that people can use color managed workflows and spread the news, the better it will get.