Difference between revisions of "Color management"
Jump to navigation
Jump to search
m (despam) |
|||
| (26 intermediate revisions by 10 users not shown) | |||
| Line 1: | Line 1: | ||
=== Inkscape's Color User Interface === | === Inkscape's Color User Interface === | ||
* CurrentColorWidget | * [[CurrentColorWidget]] | ||
* ColourPicker | * [[ColourPicker]] | ||
* ColorPalette | * [[ColorPalette]] | ||
=== What is "Color"? === | === What is "Color"? === | ||
[ http:// | |||
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 [http://en2.wikipedia.org/wiki/Color_space color spaces] comes into play. | |||
A color space determines how a tuple of data values (e.g., an RGB triplet) maps to a well-defined color (and vice-versa). In software, this is commonly achieved through the use of an [http://en.wikipedia.org/wiki/Color_profile ICC profile]. In ICC profiles, well-defined colors are defined in either the [http://en.wikipedia.org/wiki/Lab_color_space La*b* color space] or the [http://en.wikipedia.org/wiki/CIE_1931_color_space CIEXYZ color space]. These are known as profile connector spaces. | |||
To illustrate how this works, consider the case where you need an sRGB graphic displayed on your profiled LCD monitor. The sRGB profile is used to convert the RGB tuple in the document into a La*b* tuple. Your monitor's profile is then used to convert the La*b* tuple to the RGB tuple that will be delivered to your monitor. | |||
This same technique for displaying a graphic is used if your graphic is defined in the Adobe RGB 1998 color space, a CMYK colorspace defined by a print industry standard profile (e.g. FOGRA or SWOP), or a custom profile tailored to a particular printer and output medium. | |||
A common color space for the Internet is [http://www.w3.org/Graphics/Color/sRGB.html sRGB]. Adobe and HP created this color space to model the behavior of a typical computer monitor so that in the absence of any color management, the raw RGB values piped to your display hardware will appear more-or-less as the designer intended. For this reason, SVG defaults to sRGB. Likewise, CSS supports only sRGB. As a working space for artwork not targeted exclusively at web browsers, sRGB is a poor choice due to its limited gamut. | |||
And then there are [http://www.ps.missouri.edu/PS2/support/TutorialFolder/ColorTutorial/ColorTutorial2.html spot colors]. Many designers (and thus users of vector art packages) often specify spot colors that are precise matches from a book, such as [http://en.wikipedia.org/wiki/Pantone 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 | |||
*RGB and CMYK colorspaces defined by ICC profiles | |||
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. PostScript handles this readily with the /DeviceN color space, whereas output to PNG would involve masking occluded artwork. A more sophisticated approach would need to address [http://en.wikipedia.org/wiki/Spreading_and_choking trapping] and [http://en.wikipedia.org/wiki/Overprinting overprinting]. | |||
=== 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. | |||
Note: adding some information on [[Adding color-profile element]] | |||
=== 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. | |||
:<i>What changes do you have in mind? Below are the changes I'm aware of, but these aren't particularly radical. --pjrm</i> | |||
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)" | |||
==== 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 <tt>@color-profile</tt> 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 <tt>@color-profile</tt> at-rules). (The reason for storing a pointer rather than just storing the name is to allow for duplicate names in the list.) | |||
=== Links === | |||
*[http://www.w3.org/TR/SVGPrint/#devcolor SVG Print mentions color issues], including expected color support in SVG 1.2 | |||
* Sk1's code: https://github.com/sk1project/sk1-wx | |||
[[Category:Developer Discussion]] | |||
Latest revision as of 02:35, 9 January 2018
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 color spaces comes into play.
A color space determines how a tuple of data values (e.g., an RGB triplet) maps to a well-defined color (and vice-versa). In software, this is commonly achieved through the use of an ICC profile. In ICC profiles, well-defined colors are defined in either the La*b* color space or the CIEXYZ color space. These are known as profile connector spaces.
To illustrate how this works, consider the case where you need an sRGB graphic displayed on your profiled LCD monitor. The sRGB profile is used to convert the RGB tuple in the document into a La*b* tuple. Your monitor's profile is then used to convert the La*b* tuple to the RGB tuple that will be delivered to your monitor.
This same technique for displaying a graphic is used if your graphic is defined in the Adobe RGB 1998 color space, a CMYK colorspace defined by a print industry standard profile (e.g. FOGRA or SWOP), or a custom profile tailored to a particular printer and output medium.
A common color space for the Internet is sRGB. Adobe and HP created this color space to model the behavior of a typical computer monitor so that in the absence of any color management, the raw RGB values piped to your display hardware will appear more-or-less as the designer intended. For this reason, SVG defaults to sRGB. Likewise, CSS supports only sRGB. As a working space for artwork not targeted exclusively at web browsers, sRGB is a poor choice due to its limited gamut.
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
- RGB and CMYK colorspaces defined by ICC profiles
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. PostScript handles this readily with the /DeviceN color space, whereas output to PNG would involve masking occluded artwork. A more sophisticated approach would need to address trapping and overprinting.
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.
Note: adding some information on Adding color-profile element
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
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)"
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
- Sk1's code: https://github.com/sk1project/sk1-wx