Getting colors right from the camera to the web,
through Apple Aperture

A very delicate matter when publishing photos on the web (or anywhere actually) is color management. What looks good on one monitor usually looks different (read: “bad”) on another one, or on paper. My goal is to publish pictures taken with a Canon EOS 40D camera in web galleries (ZenPhoto, Gallery, Flickr, etc.) or flash based galleries (such as SimpleViewer). I use Apple Aperture to manage and edit my pictures on a MacBook. Here is what I have learned and decided to use.

What is color management…

… and, more importantly, why should I care? Getting up to speed on the subject requires quite a bit of reading and I will not go into much details here. The interested reader should peruse some of these resources:

• Color Management Overview from Apple, but very general in its purpose.
• The Critically Important Color and Gamma Calibration Article from Inside Photoshop CS by Gary D. Bouton. The text is focused on Photoshop, obviously, and not very well written, but some of the less technical passages are enlightening.
• Color Management in Mac OS X Tiger from Apple. Even more targeted on Apple’s ColorSync than the previous one but still general enough to be a worth reading for non-Apple users.
• Aperture: Color and gamma settings for print and web for the application of those concepts in Apple Aperture.

The simplest explanation I have found is in Color Management in Mac OS X Tiger:

An RGB value of R10, G100, B10 does not define how that color should appear; it is just the ratio of the three RGB components. By specifying a scale for these RGB values within the range of human vision, R10, G100, B10 can replicate how this green should appear. This scale is called a color space. […] R10, G100, B10 in two different color spaces such as sRGB and Adobe RGB (1998) will not produce the same color, even though they share the same ratio of RGB numbers.

So a color space (also called color profile) is the scale on which numeric values contained in the image (i.e. the data) are interpreted.

Time for an example. The image of a color gradient is created in a color managed application and the color space it is created in (Adobe RGB) is embedded into the file. This profile is then used to translate colors into other color spaces. Translating means that the RGB data is changed so that the colors appear the same while expressed on different scales. Consider a simpler unidimensional example: a grey scale with 10 steps, from black to white. The second grey is expressed as “Grey=2”. Now translate this particular dark grey shade in a scale with 100 steps. To keep the same appearance, the gray shade must be expressed as “Grey=20” and not “Grey=2” anymore. This is what happens for the three R, G, and B values and sure enough, once the values are translated and interpreted each in their own color space, the color gradients are nearly identical as the following montage of screen captures shows

They are only nearly identical because the translation is made within the limits of the destination color spaces: some color spaces are capable of representing more color than others and Adobe RGB is a particularly capable space to start from.

Now the same files are viewed in an application that is not capable of color management. In this case, the raw RGB data of all files is interpreted as if it was in a single default color space. In the unidimensional example above, this would mean interpreting the raw data “Grey=2” and “Grey=20” on the same scale, from 1 to 100. Of course the result in this case is that the colors appear different

This is the most common problem when posting pictures on the web.

In a perfect world, every program would support color profiles and the profile I choose embed in picture would not really matter, as long as it can represent a wide enough array of colors. Indeed the application displaying the image would translate the colors from the original profile to the display profile and the appearance would stay unchanged, as in the first gradient example above. Unfortunately, we don’t live in a perfect world, do we.

The problem

At the operating system level, Mac OS and Windows Vista support embedded color profiles but Windows XP and Linux do not.

In Mac OS X, the Color Management Module called ColorSync translates the color data of all images from their embedded profile to the profile of your monitor (e.g. “Color LCD” by default on a MacBook). Notice that the RGB values of the green square below are not identical when expressed in the two color spaces, but that its appearance stays the same.

But an image expressed in the Abode RGB color space, for example, will appear differently in the Picture and Fax Viewer of Windows XP and on a Mac. In Windows, the Red, Green, and Blue data information is interpreted as-is, in a default color space corresponding to the characteristics of the average PC monitor (sRGB IEC61966-2.1 — top square), instead of being properly translated to this color space from the Adobe RGB space (bottom square). Because of the differences between the color spaces, the same color mix appears less saturated.

When the OS does not support color management, third party libraries can provide this functionality for some applications. This is the case of Adobe Photoshop which uses proprietary libraries from Adobe, or of recent versions of The Gimp and Inkscape which use LittleCMS.

The interest of this post lies in web browsers (see, we’re getting there), which are, in fact, the applications where the situation is the most complicated.

The most modern browsers such as Safari, Firefox starting with version 3.0, and development versions of Camino support color profiles. Note that the feature is disabled by default in Gecko based browsers however.

Older browsers, such as Internet Explorer, previous version of Gecko based browsers (Firefox < v3.0, Shiira, etc.), or Opera cannot read color profiles and render pictures using a default space.

Finally, when images are displayed inside Flash content, the Flash plugin rather than the browser deals with the image, and also ignores color profiles. In other words, even in a browser capable of color management, images inside Flash content are still not color managed.

In the real world, this means that, if I edit a file in the Abode RGB color space and then post it directly on Flickr, all users not using Safari (or Firefox 3.0/Camino devel with the color-management option enabled) will not view it as I intended it to be. And many photographers already noticed actually. If I export this image in a SimpleViewer gallery, things are even worse and no browser will actually show the image correctly. In both cases, the image will not be as saturated as it should be.

So what should I do now? The advice online is somewhat disparate and contradictory (not without reasons actually, as we will see further down). So I started…

A quest for the perfect color management workflow

The start of the workflow is simple: I should just use the color space with the widest gamut (i.e. the color space which is capable of expressing the most colors). I shoot RAW and at this stage there is no color profile involved. If I shot JPEGs I would use Adobe RGB rather than sRGB on my camera. For the image editing step Aperture actually takes care of this for me because “Aperture will always work in a wide gamut” (the fact that RAW images are shown as having the Adobe RGB profile makes me think that this is the wide gamut profile in question). In Photoshop or Gimp or Krita I would use Adobe RGB as my working color space.

Then for the purpose of getting images to display correctly in systems/browsers which are not color managed I should “simply” express their data on the color scale those systems/browsers use by default. Now, the real issue is to find this default.

To do so, I translated the same image to the spaces Adobe RGB 1998, Color LCD Calibrated (my monitor profile in case you were wondering), and sRGB IEC61966-2.1 (and some more but they turned out to be irrelevant). I displayed it in several applications and browsers on Mac, Windows and Linux machines and made screen captures. As a side note, using VMware or Parallels to run other systems is not an option here because the colors displayed by Windows inside VMware on a MacBook are not the same that the ones on a regular PC. I then gathered all the screenshots on my Mac and converted them all to the same color space (Color LCD Calibrated, the one of my display) so that their raw data is comparable on the same scale. Eventually I compared this data visually and numerically in ImageJ, by doing image subtractions. My reference was the image displayed by Apple Preview which I know is color managed correctly. Here is an overview of the visual results (click to enlarge).

The numerical results, using image subtraction, confirmed what was apparent visually: browsers on Mac OS X use the current display profile as default in non color-managed situations (Camino, Firefox, Flash in Safari etc.), while browsers on Windows (and Linux) use sRGB IEC61966-2.1 as the default. This means that it is actually impossible to have the same image look good in, say, IE and Camino. In addition, it makes the situation of non color-managed applications (including Flash content) on the Mac inextricable because the color profile of the display is likely to change between the LCD of a MacBook and a Cinema display. In the end, the wisest thing to do is probably to let the majority rule and export images using the sRGB IEC61966-2.1 profile. This is what is recommended most often on the web so this long article has not brought much to the table, but at least it details the arguments behind this choice and explains why it does not work (and cannot work) in Camino or Firefox-Mac.

There is one more thing though. As I said earlier, when editing the image, the working color space does not really matter as long as it has a wide enough gamut. The conservative approach is therefore to use a very wide gamut profile such as Adobe 1998 and acknowledge the fact that some minor color details will not make it through when you convert your image to sRGB IEC61966-2.1 for the web. However, the way the display itself is set up does matter. Imagine editing an image with display brightness at its lowest level: it would probably push you toward adding much contrast, too much contrast when you get back to a sane display setting. So, to ensure that your images have the correct contrast and saturation when viewed on the web, you should also set your display to whatever looks like the average display out there. And this means setting the white point to D6500 (instead of D5000) and the gamma to 2.2 (instead of 1.8), as advised by Apple itself.

Bottom line

Overall, a sane color management workflow, from image capture to the web, through Aperture on a Mac would be:

1. shoot RAW or set your camera profile to Adobe RGB
2. calibrate your display (Apple’s visual calibration is probably enough for the web)
3. set your display’s gamma to 2.2 and white point to D6500 (at the end of the calibration steps)
4. edit your images in Aperture or keep Adobe RGB as your image editor’s working color space
5. at export time, convert your images to the sRGB IEC61966-2.1 color space
6. post them on the web
   • in PHP/HTML based galleries and view them in any browser on Windows or Linux, in Safari, or in a Gecko based browser with the color management option set to true. They will appear sightly too light to Mac users who kept the default 1.8 gamma.
   • in Flash based galleries and view them correctly on Windows and Linux only.

This is saddens me because I much preferred SimpleViewer galleries over the other options but hopefully Adobe will do the right thing and add color management to Flash. In the meantime I will probably use the barest version of ZenPhoto.