Color management

From Inkscape Wiki
Jump to navigation Jump to search

Inkscape's Color User Interface

What is "Color"?

That is a very good question. In Inkscape, color is basically RGB value triplets. But in order to get precise, and to enable the same color to be seen on different computers, the general idea of colorspaces comes into play.

A common colorspace for the internet is sRGB. SVG defaults to sRGB.

Then there is CMYK. Of course, this is not a single colorspace, but needs to be specified per output device, inks, media, viewing conditions, etc.

And then there are spot colors. Many designers (and thus users of vector art packages) often specify spot colors that are precise matches from a book, such as Pantone named colors. The main thing about these is that they are supposed to be fixed single colors of a known appearance.

So, off hand it seems that it would be good if Inkscape would support:

  • sRGB color
  • spot color

  • colorspace definition

There are two different problems: firstly, displaying a composite image composed of several spot colours. This is easy - just represent the spot colours with their rgb approximations. The only work is at the interface and colour lookup phase - implementing schemes or palettes solves this straight off. The second problem is generating postscript or png with the colours separated correctly. This is hard.

Color Management

For Inkscape to be accepted in the print world, there must be good reliable support for both RGBA and CMYK color spaces. At the moment, the easiest way to get Inkscape SVG into CMYK color spaces is via import into Scribus or using Acrobat Distiller on Win32. Export to eps and conversion using perl script pscol from is also possible.

Scribus and The Gimp both use littlecms for a color mangement module for doing "soft previews" of RGBA color into a CMYK (print) space. At some point, adding color management support should be discussed.

There is a list just starting on on this topic. Details to be announced soon.

Adding support for littlecms means we match color output across devices (like Apple's inkscape) like scanner > digital camera > app > monitor > print, and also, both The Gimp and Scribus use littlecms.

LittleCMS also has its own VERY ACCURATE COLOR CONVERSION ROUTINES!!! I know we were discussing this awhile back when the new color palette was being built.

Note: adding some information on Adding color-profile element


We can store the CYMK and RGB approximations side-by-side in the CSS, using SVG's ICC color support and a selected CYMK ICC profile.

For example:

fill: #ff0000 icc-color(blah, 0.0, 1.0, 1.0, 0.0);

Where "blah" would be bound to some CYMK color profile. (SVG specifies "sRGB" to be bound to standard sRGB profile, but there is seemingly no "standard" CYMK profile. So we may need to be able to use a device-specific one.)

Of course our CSS infrastructure alone would need some radical changes before it would deal well with this well.

What changes do you have in mind? Below are the changes I'm aware of, but these aren't particularly radical. --pjrm

Other examples with more parts:

fill="uri(#pat) #f0f icc-color(myprofile, .1, .3)"
fill="steelblue icc-color(cmyk, 0.8, 0.1745, 0.098, 0.2)"
fill="uri(#machine) steelblue icc-color(cmyk, 0.8, 0.1745, 0.098, 0.2)"

SVG 1.2 had proposed additional icc-named-color and device-color:

fill="steelblue icc-named-color(named, greyblue) device-color(spot-inks, blue7030)"


See for what SPIPaint will eventually need to support; and see for the DOM interface (and for its base interface SVGColor): the DOM interface might be good to copy from.

A minimal change would be adding to SPIPaint a pointer to an ICC color struct, which might have the same field names as interface SVGICCColor (in

Profile Database

Fill/stroke paints that mention an icc color reference a color-profile by name. We thus need a mapping from name to color profile. This mapping is to be populated by handlers for the