SCALE 8x: Color management for everyone
We're bad at marketingWe can admit it, marketing is not our strong suit. Our strength is writing the kind of articles that developers, administrators, and free-software supporters depend on to know what is going on in the Linux world. Please subscribe today to help us keep doing that, and so we don’t have to get good at marketing.
On Sunday at SCALE 8x, Inkscape developer Jon Cruz presented a talk entitled "Why Color Management matters to Open Source and to You," putting the need for color management into real-world terms for the average Linux user, outlining current development work on the subject at the application and toolkit levels, and giving example color-managed workflows for print and web production. Color management is sometimes unfairly characterized as a topic of interest only to print shops and video editors, but as Cruz explained at the top of his talk, anyone who shares digital content wants it to look correct, and everyone who uses more than one device knows how tricky that can be.
"If you have eyes and a display, you need color management"
Color management, broadly speaking, is the automatic transformation of image colors so as to provide a uniformly accurate representation across devices. This includes output-only devices such as televisions and printers, as well as CRT and LCD displays on which editing as well as final output is viewed. The first problem is that every device is capable of generating a different spectrum of colors — different hues, different ranges of white-to-black values, and different degrees of saturation. Collectively, the color capabilities of the device are its gamut, which can be represented by a three-dimensional volume in one of several mathematical color models (or "color spaces").
The second problem is that digital files store the color of each pixel as a numeric triple that may or may not represent coordinates in some specified color space. If the color space to which the file referenced is known, mapping each triple from its stored value into the gamut of the output device is a simple transformation, and the user can visually examine the full range of pixel data. Without that transformation, multiple colors outside the display device's gamut get mapped to the boundaries, causing artifacts and loss of detail, and the entire image can get mapped too dark or too light, misrepresenting the scene.
Although it is clear that graphics professionals need color managed displays and printers, Cruz said, the explosion of user-generated digital content in recent years makes it a problem for everyone.
Home users want to be able to edit video and share it online, knowing that what appears appropriately bright on-screen will not look washed-out or too dark on DVD or YouTube. They also want to drop off family photos at the corner drugstore kiosk and not be disappointed by a red or green cast to the skin-tones. Photo kiosks may be inexpensive per-print, he said, but online vendors like Apple and Google's Picasa are increasingly offering more elaborate services, such as hardbound books, with correspondingly higher prices. Consumers might shrug off paying a few cents for a bad-looking 4x6 print, but getting burned on an expensive book is considerably more aggravating.
Just as importantly, Cruz added, business users need to care about the professionalism of their presentations, both for aesthetic reasons, and because a mis-colored partner logo could accidentally sour the opinion of the executive at the table who recently spent months determining the "perfect shade of puce
" to represent the company image. Finally, he said, anyone who sells products online should know that the number one reason for returned consumer purchases is mismatched colors — if the product shots on the web site make the red shirts look orange, the seller is financially at risk for the cost of returns.
In addition to these use cases, Cruz explained that users need color management support in their desktop applications to cope with the variety of different display devices they use over the course of a day. Multiple computers are commonplace, from desktops to laptops to netbooks to hand-held devices, and each have different display characteristics. Laptop screens have noticeably smaller gamuts than desktop LCDs, which are in turn smaller than CRTs, and different also from the displays of consumer HDTVs. Mobile devices, based on different graphics hardware, may not even support full 8-bit-per-channel color. Presenting a consistent display across these platforms cannot be left to chance.
Status report
Fortunately for Linux users, Cruz continued, color management support in Linux is in good shape, although more still needs to be done. Most creative graphics applications support color management already, thanks in large part to the collaborative efforts of the Create project at Freedesktop.org. These include Gimp, Krita, Inkscape, Scribus, Digikam, F-Spot, and Rawstudio, as well as several image viewing utilities.
Enabling users to acquire good ICC profiles (tables measuring the device's attributes against points in a known color space, thus allowing for interpolation of color data) or to build their own is one of the key areas of current color work. Projects like Argyll and Oyranos handle tasks such as precisely measuring monitor color output through hardware colorimeters, creating profiles for printers, scanners, and cameras through color targets, and linking profiles for advanced usage.
A simpler solution aimed at the home user is GNOME Color Manager (GCM); unlike the previous two examples GCM does not attempt to be a complete ICC profile management tool, but focuses on easily enabling users to correctly assign a profile to their monitor. Default profiles are usually available from the manufacturer, either through the web or on the "driver" CDs in the box, and for normal usage they are an excellent first step. Developers from these and several related projects collaborate on common goals in the OpenICC project.
Developers interested in adding color management to their applications should start with LittleCMS, Cruz advised, noting that he personally added Inkscape's color management support in less than one week's time with LittleCMS. LittleCMS is a library that handles the mathematical transformations between color spaces automatically, quickly, and with very little overhead.
Currently, however, one drawback of the Linux color management scene is that most color-aware applications work in isolation from one another, requiring the user to choose display, output, and working ICC profiles in each program — whether through LittleCMS or with in-house routines. Ongoing work to bring color management to a wider range of programs includes adding support to the Cairo vector graphics rendering library, attaching display profiles to X displays, and building color management into GTK+ itself. The latter, in particular, would enable "dumb" applications to automatically be rendered in color-corrected form on the monitor, while still allowing "smart" applications to manage their own color. This is important because graphics and video editing applications need to be able to switch between different profiles for tasks like soft-proofing (simulating a printer's output on-screen by rendering with a different ICC profile) or testing for out-of-gamut color.
To the work!
Finally, Cruz showed several example workflows for print and web graphics, first illustrating potential problem points when working in a non-color-managed environment, then explaining how using a color-aware setup would trap and eliminate the problem.
For web graphics, the example scenario was a simple photo color-correction. Over-correcting the color balance on an improperly-managed monitor easily leads to site visitors seeing a wildly distorted image. In addition, Windows and Macs use different system gamuts, which leads to photos looking either too bright on Macs or too dark on Windows. With a managed workflow, users should target the sRGB color space, previewing the results with Windows, Mac OS X 10.4 and Mac OS X 10.5 profiles (due to changes introduced by Apple in 10.5), as well as mobile devices under different conditions. Because most web site audiences do not have color-corrected displays, he said, not everything is under the designer's control — but if the end user's monitor is broken and the artwork is broken, the problems multiply.
For print graphics, the workflow is more complicated, starting with the fact that — despite the popularity of the term — there is no single, standard "CMYK" color space. All process-color spaces are device-dependent, including common four-ink CMYK printers, CcMmYK photo printers, Hexachrome, and others; there is not even an analogous color space to the "Web safe" sRGB standard. Process color's small gamut makes it very easy to produce poor output when not using color management to edit and proof.
Fortunately, Inkscape and other SVG-capable editing tools can take advantage of the fact that SVG allows different color profiles to be attached to different objects in a drawing. A CMYK profile for the target printer can be used for most of the drawing, with a separate spot-color profile attached to specific objects that need careful attention, and corrective profiles for embedded RGB elements like raster graphics. A test run is always the best idea, Cruz said, but having proofing profiles available on the system saves both money and time.
Conclusion
Color management on Linux has come a long way in the last four years. The application support in the basic graphics suite is good, and for professionals tools like Argyll and Oyranos open the door to complete solutions; as Cruz observed in his talk, the colorimeter hardware that used to cost thousands of dollars and lack support on free operating systems is now cheap and well-supported.
Still, the average desktop Linux distribution does not install in a color-managed state, which is unfortunate. Proper support for transforming pixels from one color space to another is straightforward math that, much like window translucency, smooth widget animation, and audio mixing, should happen without requiring the user to stop and think about it. It is promising that headway is being made on that front as well, with GCM and GTK+; perhaps in a few release cycles Linux will have full color management out-of-the-box.
Index entries for this article | |
---|---|
GuestArticles | Willis, Nathan |
Conference | Southern California Linux Expo/2010 |
SCALE 8x: Color management for everyone
Posted Mar 2, 2010 0:46 UTC (Tue)
by mattdm (subscriber, #18)
[Link]
Posted Mar 2, 2010 0:46 UTC (Tue) by mattdm (subscriber, #18) [Link]
It is promising that headway is being made on that front as well, with GCM and GTK+; perhaps in a few release cycles Linux will have full color management out-of-the-box.
See http://fedoraproject.org/wiki/Features/ColorManagement targeted for the upcoming Fedora 13. I'm not holding my breath for RHEL6, but hopefully this will make it in there too.
SCALE 8x: Color management for everyone
Posted Mar 2, 2010 2:25 UTC (Tue)
by nlucas (guest, #33793)
[Link] (2 responses)
Posted Mar 2, 2010 2:25 UTC (Tue) by nlucas (guest, #33793) [Link] (2 responses)
nothing. Is this something only GTK+ devs are working on?
SCALE 8x: Color management for everyone
Posted Mar 2, 2010 7:38 UTC (Tue)
by halla (subscriber, #14185)
[Link] (1 responses)
Posted Mar 2, 2010 7:38 UTC (Tue) by halla (subscriber, #14185) [Link] (1 responses)
There is a color management settings module for KDE already, but it depends on Oyranos, which isn't packaged by any distributions that I know, probably because of its dependency on the Elektra configuration system. So the kcm isn't in kde by default yet.
Krita is a Qt-based (well... KDE) that has used lcms (and therefore icc profiles) for color management since version 1.5 which was released in 2006. KDE-based Digikam has support for color management as well, I think also since 2006. Qt-based Scribus ditto.
SCALE 8x: Color management for everyone
Posted Mar 2, 2010 15:03 UTC (Tue)
by azouhr (guest, #40022)
[Link]
On software.opensuse.org, you can find Oyranos packages for
Posted Mar 2, 2010 15:03 UTC (Tue) by azouhr (guest, #40022) [Link]
- openSUSE 11.0, 11.1 and Factory
- Mandriva 2007
- Fedora 10
SCALE 8x: Color management for everyone
Posted Mar 2, 2010 6:39 UTC (Tue)
by cuboci (subscriber, #9641)
[Link] (2 responses)
Posted Mar 2, 2010 6:39 UTC (Tue) by cuboci (subscriber, #9641) [Link] (2 responses)
display? Last time I checked it was able to use my Spyder2 Express device to measure my
laptop's display.
SCALE 8x: Color management for everyone
Posted Mar 2, 2010 9:34 UTC (Tue)
by lolando (guest, #7139)
[Link] (1 responses)
Posted Mar 2, 2010 9:34 UTC (Tue) by lolando (guest, #7139) [Link] (1 responses)
SCALE 8x: Color management for everyone
Posted Mar 2, 2010 12:22 UTC (Tue)
by hughsient (guest, #52199)
[Link]
Posted Mar 2, 2010 12:22 UTC (Tue) by hughsient (guest, #52199) [Link]
SCALE 8x: Color management for everyone
Posted Mar 4, 2010 4:40 UTC (Thu)
by joedrew (guest, #828)
[Link]
For Firefox's colour management, we initially used LCMS, but found that our needs and desires increasingly didn't align well with the LCMS developers' needs and desires, so one of my co-workers, Jeff Muizelaar, took parts of LCMS and made a similar project he called QCMS.Posted Mar 4, 2010 4:40 UTC (Thu) by joedrew (guest, #828) [Link]
As of Firefox 3.5 (and continuing in Firefox 3.6), we colour-correct tagged images by default; users who want to change that default (so that we treat untagged images as if they're in the sRGB colour space) can do so easily; check out the MDC article on ICC color correction in Firefox.
Thank you
Posted Mar 4, 2010 6:20 UTC (Thu)
by ncm (guest, #165)
[Link]
Posted Mar 4, 2010 6:20 UTC (Thu) by ncm (guest, #165) [Link]
SCALE 8x: Color management for everyone
Posted Mar 4, 2010 13:51 UTC (Thu)
by ssam (guest, #46587)
[Link] (9 responses)
Posted Mar 4, 2010 13:51 UTC (Thu) by ssam (guest, #46587) [Link] (9 responses)
i have an image file where each pixel is given by a red, blue and green component, and a standard that says what a give combination or r, g and b should look like (sRGB). so if my pixel is 'lwn orange' #FFCE9C, it could be well defined what this should look like.
now my image viewer tells the X server to paint the pixel #FFCE9C, X passes this value the graphic driver, and the graphics driver figures out what signal need to be sent down my dvi/vga cable to show the colour.
if its the application doing the translation, then what happens if i take a screen shot? also what happens if the application window is spread across 2 monitors?
SCALE 8x: Color management for everyone
Posted Mar 4, 2010 14:28 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (5 responses)
Posted Mar 4, 2010 14:28 UTC (Thu) by farnz (subscriber, #17727) [Link] (5 responses)
sRGB isn't the only standard RGB colourspace. Just off the top of my head, I can think of sRGB, Adobe RGB, BT.709 RGB, CIE 1931 RGB and I'm sure there are more out there. I can very easily find images in three of those colourspaces (my digital camera can produce two of them, I can get a third by grabbing a frame from BBC HD and converting from YUV to RGB).
Plus, many images aren't in an RGB colourspace to begin with; if the image is CMYK (common if it's being prepared for print), or some variation on YCbCr (common if it's from TV). The application needs to tell the graphics driver about all of this information if you're to get a precise match; what's more, not all colour values are in 8-bits per channel RGB; if I had 16-bit per channel CMYK, I'd like the graphics driver to know that I want a slightly darker red than the RGB tuple suggests, so that it knows which way to round error.
This becomes more important on 30-bit displays (where an RGB tuple is three ten-bit values, not three 8-bit values), as the conversion formulae are not precise, and it would be nice to use the extra accuracy to improve colour reproduction.
SCALE 8x: Color management for everyone
Posted Mar 4, 2010 15:02 UTC (Thu)
by ssam (guest, #46587)
[Link] (2 responses)
Posted Mar 4, 2010 15:02 UTC (Thu) by ssam (guest, #46587) [Link] (2 responses)
SCALE 8x: Color management for everyone
Posted Mar 5, 2010 23:39 UTC (Fri)
by roelofs (guest, #2599)
[Link]
ok. so the application would just need to pass some colour space metadata along with the pixels.
Posted Mar 5, 2010 23:39 UTC (Fri) by roelofs (guest, #2599) [Link]
No--any application that does its own alpha-blending, for example, needs to convert the image(s) and background from their native color space(s) to linear (gamma = 1.0), do the compositing, and (usually) convert back. Other transformations (lighting/shading calculations and whatnot in 3D, IIRC) also require linear gamma for correctness. And it's hard to imagine a driver complex enough to support multi-source display app like a browser ("this block of pixels is linear, this block uses this custom ICC profile, that block is SGI/gamma-1.7, and everything else is sRGB"). Conceivably it's doable, but I'm not sure a driver is the best place for it.
Greg
SCALE 8x: Color management for everyone
Posted Mar 8, 2010 3:50 UTC (Mon)
by psyquark (subscriber, #58373)
[Link]
Posted Mar 8, 2010 3:50 UTC (Mon) by psyquark (subscriber, #58373) [Link]
All color triplets have a color space, either explicit or implicit. On a stand alone uncalibrated machine the implicit colorspace is the colorspace of the display. The problems start when sharing files with other computers, each of which has its own implicit colorspaces. Known colorspace to known colorspace mapping is doable but unknown colorspace to any colorspace is not feasible. To fix that the sRGB colorspace was created. It was defined to be a decent approximation of the standard displays of the time. The web standard became "If you don't know the space and care about color, treat it as sRGB."
The naive solution is to have the client handle all color management and output pixel values in the display's colorspace. This can be useful in cases when a specific or controlled rendering intent is needed to accommodate special needs. The problem is that client side management does not handle multiple outputs well. In fact, it is not possible for a client to handle simultaneous display on multiple outputs such as from software mirror to a projector or a visual pager application showing a preview on a second display.
The best solution is to have the Compositor handle the final colorspace conversion. It knows exactly where each pixel is going to be displayed because it will be putting that pixel there. There has been some work towards this (but not mentioned in any slides or the writeup) from a Google Summer of Code in 2008. It was called "Color Management Near X" and I believe the "net-color" standard. The solution was not to send colorspace with each pixel, but rather to set window properties defining the icc profile for the window or regions of the window. I should note that specifying client's colorspace to be the same as one of the outputs results in a null transform. That gives the application the same power as before, but allows the Compositor to give sane colors on other displays. Sadly I can't find much information on it with google.
As it stands "color managed applications" can display correctly on my wide-gamut LCD or my normal gamut LCD but not both. The colors will be flat wrong when they appear on the "other" output.
YUV and YCbCr irrelevant
Posted Mar 4, 2010 23:07 UTC (Thu)
by spitzak (guest, #4593)
[Link] (1 responses)
Posted Mar 4, 2010 23:07 UTC (Thu) by spitzak (guest, #4593) [Link] (1 responses)
Claiming these are color spaces is equivalent to claiming that jpeg is a color space, rather than a compression algorithm.
YUV and YCbCr irrelevant
Posted Mar 5, 2010 10:02 UTC (Fri)
by farnz (subscriber, #17727)
[Link]
Posted Mar 5, 2010 10:02 UTC (Fri) by farnz (subscriber, #17727) [Link]
Depends on how you define a colour space; on the one hand, they are just a reversible transform from a known RGB colour space. On the other hand, practical YUV colour spaces, while sharing primaries with practical RGB colour spaces, tend to have different gamuts.
Additionally, they only correspond perfectly under the assumption of infinite precision; in colour management situations, it's of interest to the output driver to know that when I ask for 8-bit BT601 RGB (236, 250, 255), it actually came from YUV (230, 140, 120), and thus if display RGB (237, 251, 255) corresponds to BT601 RGB (237, 251, 255) while display RGB (236, 250, 255) corresponds to BT601 RGB (235, 249, 255), the former is a closer approximation to the desired colour than the latter.
YUV colour spaces differ from JPEG in a very important manner; JPEG is lossy by design, whereas YUV isn't lossy until you subsample. Any loss between an RGB and YUV colour space occurs due to loss of precision
SCALE 8x: Color management for everyone
Posted Mar 4, 2010 17:00 UTC (Thu)
by rgmoore (✭ supporter ✭, #75)
[Link] (2 responses)
Posted Mar 4, 2010 17:00 UTC (Thu) by rgmoore (✭ supporter ✭, #75) [Link] (2 responses)
i have never understood why applications need to care about colour management, surely it could all be done by the graphics driver.
That works for most applications that are only interested in displaying graphics; they send the color information (possibly with an ICC profile) to the graphics server and don't worry about anything else. But it's obviously not enough for a program that's supposed to be editing the graphics information itself, e.g. GIMP, Inkscape, etc. Those programs need to understand the color information to be able to edit it properly.
A good example of this kind of problem is one that I saw recently about problems with image scaling; most image processing applications do it wrong. The problem is that their color information has a gamma of 2.2, meaning that displayed intensity is supposed to be value**2.2. The correct way to apply scaling is to convert the color information to a linear value, apply the scaling, and then convert back. Instead, most image processing applications use the values with gamma applied, which results in the scaled images being too dark. A properly color aware application wouldn't make that mistake.
Image scaling problem
Posted Mar 4, 2010 23:04 UTC (Thu)
by spitzak (guest, #4593)
[Link] (1 responses)
Posted Mar 4, 2010 23:04 UTC (Thu) by spitzak (guest, #4593) [Link] (1 responses)
If as the original poster said, everybody could assume the image is sRGB, then the scaling algorithim could be designed to correctly scale sRGB. This is much easier than something that can scale "anything".
Also from everything I have learned about color management, there appears to be a need for a "blending space" that is controllable and that scaling and mixing is always done linearly in this blending space. If this blending space is sRGB then the scaling is in fact required to do the "wrong" result. You need to change the "blending space" to some linear color space for blending to be correct.
Image scaling problem
Posted Mar 5, 2010 2:02 UTC (Fri)
by rgmoore (✭ supporter ✭, #75)
[Link]
Posted Mar 5, 2010 2:02 UTC (Fri) by rgmoore (✭ supporter ✭, #75) [Link]
If as the original poster said, everybody could assume the image is sRGB, then the scaling algorithim could be designed to correctly scale sRGB. This is much easier than something that can scale "anything".A) I'm not sure that it would be any easier to do everything on the raw sRGB data. It's not just image scaling but all aspects of image processing that are easier to do on linear data. It's likely to be easier to write one algorithm to convert sRGB to linear and one to convert it back than to include an implicit implicit conversion in every image processing algorithm. And if you care about correctness- which you obviously do if you're bothering to worry about the gamma applied data- it's going to be much easier to prove that you're doing everything correctly by working on explicitly gamma corrected data than to count on having the correction in every routine.
B) The "everything is sRGB" assumption is untrue. Real world programs have to deal with all kinds of color spaces. Once you have to deal with more than two color spaces (sRGB and linear), the need for real color management will be much more obvious.
Terminology
Posted Mar 14, 2010 21:38 UTC (Sun)
by Ross (guest, #4065)
[Link]
Posted Mar 14, 2010 21:38 UTC (Sun) by Ross (guest, #4065) [Link]
However, I think the article sometimes uses term gamut to refer to the entire set of characteristics of a device colorspace, but it should only refer to the range of colors which can be displayed. To be specific, the meaning of the numeric coordinates of colorspaces can be different even when they have the same gamut, and because of things like the gamma response curve the coordinates don't necessarily even have a linear relationship.
Also, both the gamma and the amount of quantization of the colorspace coordinates are affected by the video card and drivers as much as by the display device. For example 15 or 16 bit depth modes will result in only 5 or 6 bits of accuracy per channel no matter how nice the display. Hopefully these limitations are taken into account in the profiles somehow.