Color management

Inkscape's Color User Interface

• CurrentColorWidget
• ColourPicker
• ColorPalette

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 http://dionysos.mpch-mainz.mpg.de/~joeckel/pscol/ 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 freedesktop.org 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.

Implementation

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

SPIPaint

See http://www.w3.org/TR/SVG11/painting.html#SpecifyingPaint for what SPIPaint will eventually need to support; and see http://www.w3.org/TR/SVG11/painting.html#InterfaceSVGPaint for the DOM interface (and http://www.w3.org/TR/SVG11/idl.html 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 http://www.w3.org/TR/SVG11/idl.html).

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 <color-profile> element and the @color-profile CSS at-rule. However, note that these handlers also need to cope with the user changing or deleting that element/stylesheet; and that there can be multiple purported definitions for a given name (in which case the last one wins). I think we want a doubly-linked list of definitions, and then we re-create the mapping (hashtable or whatever) in full when the list changes. (We don't expect the list to contain many entries, so it's cheap to rescan the whole list.) The <color-profile> element object should then include a pointer into that list, and I suppose that stylesheet objects should include multiple pointers into the list (given that stylesheets can contain arbitrarily many @color-profile at-rules). (The reason for storing a pointer rather than just storing the name is to allow for duplicate names in the list.)

Links

• SVG Print mentions color issues, including expected color support in SVG 1.2