Abstract
Open Source has traditionally been seen as lacking in full support of the needs of artists and graphic professionals. The most cited problem is a lack of color management systems (CMS) in Open Source applications such as GIMP and Inkscape. However, the landscape has changed greatly over the past year with major advancements on several fronts. The reality for Open Source graphic applications and their users is now significantly improved.
This talk will present an overview of color management in Open Source applications including GIMP, Scribus and Inkscape, and on various operating systems including Linux, OS X and MS Windows. Any user of graphic applications from professionals though hobbyists and beginners can benefit from color management and color managed applications.
After covering basics and tools to support color management, the new features in Inkscape related to color management will be explored, including how different users might leverage them for different needs and how color management for SVG differs from usual color management.
Table of Contents
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.
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.
Oyranos is another CMS system targeting Linux and was created by Kai-Uwe Behrmann. It was drawn from his experience and work on CinePaint.
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.
Display adjustment is leveraging an ICC profile (or profiles) for the monitor to get the displayed color as close to the desired value as possible. Since colors in SVG start as sRGB colors, there is no immediate need for a working colorspace to be set. Specifying a display profile allows for a proper conversion from sRGB to the RGB values the target display needs in order to emit the proper color. The rendering intent can be explicitly set, however "perceptual" is usually a good working value.
Additionally Inkscape can be set to attempt to retrieve the profile from the display itself. On Linux, UNIX and OS X this is accomplished via xicc. Support for fetching dynamically from Microsoft Windows is not supported in Inkscape 0.46, but the code to extend dynamic support to Windows and native OS X is available. When Inkscape is set to fetch profiles from the display it will adjust windows as they are moved across displays, and also as profiles are set, cleared and changed on displays.
Soft-proofing attempts to simulate the look once graphics end up on the final display medium. Profiles for print output generally are created to list the effects of the inks that will be used, the specific paper type printed on, and the details of the printing process itself. Given a decent target profile and a reasonable display profile, a user then gets a good way to judge how his work will be viewed. Also different profiles may be switched between to preview the same artwork as it will appear on different targets.
Inkscape 0.46 also allows out of gamut colors to be marked. This takes regions whose resulting color falls outside of the capabilities of the target (as defined by the ICC profile) and changes them to a replacement "warning" color. The color starts as a neutral gray, but can be changed in the preferences. Often an artist may need to change this depending on the content of the project currently being worked on.
The remaining settings of rendering intent, black point compensation and black preservation are standard CMS settings and are consistent with other applications.
With Inkscape 0.46 a new color selector is available when an SVG file being edited has at least one embedded profile. Unlike the prior HSL or CMYK pickers which merely presented in a different color type but stored in RGB, the CMS selector preserves all values seen. So a color with an ICC profile that is CMYK will actually be stored with four values (C, M, Y, and K) and not be converted back to sRGB triplets.
This color selection works for most known colorspaces, including RGB, CMYK, CMY, YCC, Lab, etc. Also Inkscape's standard gradient color sliders are present and functional. However the work is still fairly generic and needs to be integrated better with other visuals (such as the color wheel) for selecting colors.
There are still a range of people viewing websites who do not have their systems "properly" calibrated. The classic darker/lighter Mac vs. PC problems persist.
The main workflow for web graphics is to target sRGB, since that is what the W3C has declared the default for the web. Colors can be specified using normal SVG values, with no need for in-document ICC profiles. Then by leveraging different proofing profiles, one can get a feel for how the different people viewing the artwork may see it.
Print output is probably the most common workflow in need of color management. The first step is for the artist to link in the appropriate target profile via a <color-profile> element. Then colors can be selected using any linked profiles. Note that the workflow is different than some bitmap editors, since SVG explicitly links colors to included profile references, and a single SVG document can have colors from several ICC profiles at once.
A proofing profile can be set to preview output, and out of gamut warning can be used to find problems before anything is sent to print.
Creating artwork targeting mobile devices actually is another good candidate for the use of CMS. Values can be specified normally for SVG, using the implicit sRGB colorspace. Then display on different end devices can be simulated with proofing ICC profiles. If one is ambitious, profiles can even be created for a single target device under different conditions including sunlight, indoors, backlight on, backlight off, etc.
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.