Why it doesn't work the way most people think it does, and how to make it work the way it should work.
If you're a photographer then colours are important, and you'll want to see the same colours coming from your monitor as you saw when you shot the picture. You also want to be sure that anyone else viewing your images sees what you intend them to see.
That's ok, you think, because we have "Colour Management" to sort all that out for us. You just buy a Spyder or similar device, run the software which comes with it, and it's all good, right? Wrong... if you're a Windows user at least, that's not enough. In fact you may well see less accurate colours in a calibrated system than in an uncalibrated one, unless you're very careful.
In fact Windows is not colour managed in the way most people think it is. I've researched this across the internet and misunderstanding vastly overshadows correct data. Some of the errors come from apparently reputable sources, so it's not necessarily obvious which is which. This is my attempt to set explain what actually happens, based on a few simple experiments anyone can repeat.
2 Windows Colour Management
2.1 How It Works
Windows (Vista or 7) will let you store the name of a colour profile along with your display, and it'll let you run some software to calibrate your graphics card (a Look Up Table/LUT loader), but it doesn't automatically transcode the data sent to the display according to that profile. Instead, Windows expects the applications to request that the transcoding be done. Which many of them don't do. For example the built-in Windows Explorer just ignores the monitor profile, so your desktop wallpaper is not colour managed, something which is easily verified.
The Windows Color System (WCS) was first introduced in Vista and appears unchanged for Windows 7. MSDN provides more implementation details on WCS 1.0. Here's a relevant extract:
On a fundamental level, almost any application should be able to adjust colour automatically so that its output looks the same on different monitors and printers. WCS 1.0 provides a set of functions to deliver this kind of colour management that is transparent to a user and requires little overhead in the application.
The clue is "in the application". The application must explicitly ask Windows to colour manage output; it doesn't happen by default. The Application Programming Interface (API) reflects this, providing the application engineer with the hooks to enable colour management.
Let me spell that out:
- Monitor calibration systems produce two things: (a) settings for your graphics card's Look Up Table; and (b) a profile for the monitor.
- The calibration system's loader will write (a) into the graphics card. This changes the way the display looks in a manner similar to tweaking the brightness/ contrast/ colour temperature.
- The calibration system will assign the monitor profile (b) to the monitor via Windows Vista or 7.
- Windows will then "tell" applications what the monitor profile is on request.
- Applications must explicitly "ask" Windows to transform colours to achieve correct output.
That's it. Windows does not simply "Colour Manage" everything it draws on your screen. It does not use the monitor profile itself, it only tells applications what it is and lets them decide if they're going to make use of it.
what about embedded profiles?
Most people think that colour management is important for (say) browsers because it means that the browser reads and uses any profile embedded in an image.
Whilst that may be a very civilized thing for a browser to do, it's not relevant to most of us as most people don't embed profiles into images for web display. Indeed, it's not possible for all image formats.
In any case, Colour Management such as that described here is necessary for the browser to render images accurately irrespective of if they've a profile embedded in them or not.
Don't believe me? Try this:
- Create one or more wildly incorrect monitor profiles. Assign them one by one to your monitor using Windows. Nothing happens... Windows will helpfully remember what the profile you set is, but it does not apply it to the stuff it's displaying (your wallpaper, for example). Windows Explorer ignores the profile. Dealing with Colour Management in Windows is the responsibility of the applications.
- Now try running a Colour-Managed application such as Photoshop, Firefox3 (with CM enabled - not a default option), or Windows Photo Gallery (Vista)/ Windows Photo Viewer (Win 7). These applications are colour managed, so they read the colour profile from Windows and use it to transcode their output. The difference you see between an image viewed through these applications and Windows Explorer is the monitor profile being applied, and as you're using a wildly incorrect one it should be blindingly obvious. If you can see no difference between colour managed and not colour managed applications, probably something is not set up correctly.
- Switch back to your correct monitor profile and repeat the comparison between managed and unmanaged applications. If you can no longer see a difference, most likely your monitor is very close to sRGB and your profile applies little colour adjustment, so it's hard to see it. This isn't a problem, but it's worth bearing in mind that it's easier to confirm that your colour management is working if the difference is large when it's not working.
2.2 Images with Embedded Profiles
In addition to the profile assigned to your monitor (or printer), there may also be a profile assigned to any image you're viewing. To see the correct colours the combination of application and operating system must read the bits of the image, and transform them with both the embedded profile and then the monitor profile.
In the case where there is no embedded profile, which is true for almost all web images, the W3C specifies in "A Standard Default Colour Space for the Internet - sRGB" how the image should be interpreted:
Since the image has no ICC profile, it is assumed to be in the sRGB color space.
In Windows the responsibility for making this assumption lies with the application.
2.3 When calibration can make things worse
Users without a calibrated, colour managed system will generally adjust their monitors to "something which looks about right", and will not assign a monitor profile. By definition this looks "about right", and unless you compare two such systems the user may not notice that the colours are a little off. As there's no monitor profile in use (any adjustments being done using the graphics card LUT), it makes no difference if an application is colour managed or not.
Unfortunately if you invest in some calibration equipment and calibrate your monitor (or run the calibration tools in Windows 7) things generally get worse for unmanaged applications. That's because, as above, a calibrated monitor relies on both the LUT settings and the monitor profile for correct output. Any output from an application which ignores the monitor profile is therefore definitely incorrect. In the totally unmanaged case the user can change the LUT settings until the image "looks right"; you can't do this if you're using a calibration tool, hence the calibrated system typically will achieve less fidelity than the uncalibrated one for unmanaged applications.
Each Windows application separately handles Colour Management using Windows functions provided for the purpose. This responsibility includes dealing with both the monitor profile, and also any embedded profiles embedded in images. The Windows Color System (WCS) provides the "hooks" to do this, but the application controls their use.
So Windows can be colour managed, but it has to be set up correctly and each program used must explicitly support colour management on Windows. It's obvious if you think about it: if Windows just took care of all this then there would be no differences in colour management support amongst various applications running on it.
3 Colour Management in Windows Browsers
As above, any application (for example a browser) could be fully colour managed on the Windows platform simply by calling the appropriate WCS functions. Any limitations in specific applications are caused by the way that application has been built.
Here are a few simple test images intended to demonstrate the colour management differences between various common Windows 7 browsers. Fortunately it's relatively easy to see colour differences with the eye, which of course is why we're so bothered about getting it right.
3.1 Browser Tests
The following charts all look identical on a fully colour managed system. The originals are in sRGB. The only other gamut used here is Adobe RGB (1998) which is wider than sRGB, with conversion from sRGB to Adobe RGB using "perceptual" rendering intent. On a calibrated system the images should look "correct"; that is, they should look the same on different but similarly calibrated systems assuming those systems' gamuts include sRGB.
Below are four identical charts plus a html representation of the same colours. What you see on a Windows system depends on the colour management capabilities of whatever you're reading this page with. I find it easiest to pick a specific colour which is obviously different across Colour Managed/ Unmanaged, then use that as an "indicator" when reviewing web page colours. So here, I would start with Firefox with Colour Management on, and look for visual differences between the Flash (unmanaged) and images/HTML (managed). With my desktop system the green colour shows the most difference, so I use that to check the other browsers.
tagged Adobe RGB
sRGB Flash movie
All tests were performed on a calibrated Windows 7 system using an ICCv2 monitor profile. The image tagged with "Adobe RGB (1998)" is tagged with an ICCv2 profile from PS/CS.
Browser Test Results
Colour Management Enabled for all images
|The first three charts look identical and match the colours in the HTML swatches. The Flash movie does not match.
||The first two images look identical because FF3 follows sRGB and assumes the untagged image is sRGB. The third image was converted with "perceptual" rendering intent so it looks the same despite the different colour gamut, and FF3.5 is honouring the embedded profile and converting through the monitor profile.
The Flash movie is not explicitly Colour Managed, so that's not using the monitor profile and hence looks wrong.
The HTML swatches are correct as Firefox correctly assumes untagged html such as this is sRGB and renders it as such via the monitor profile.
|IE6, IE7, Chrome 0.*, Firefox 3 with Colour Management Disabled, Opera 9.51
||Nothing's rendered correctly. The browser does not use the monitor profile; doesn't read or use embedded profiles; doesn't render html correctly; and the Flash SWF I'm using here is not colour managed.
||The tagged Adobe RGB (1998) image looks different from the others because the image is in Adobe RGB (1998), which has slightly different colour values from the default sRGB. Totally unmanaged browsers ignore the embedded profile and just throw unmodified RGB values at the screen.
|Safari 3, 4/PC
||The untagged and Flash are identically wrong as neither is rendered with the monitor profile. The two tagged images are identical as both are correctly rendered. The HTML is incorrectly rendered.
||Safari ignores the sRGB standard, which means that if you're using a calibrated system with a none-trivial monitor profile, almost all of the web will be incorrectly coloured.
|IE8 (32 or 64 bit), Opera 10, Chrome 3
||The untagged and tagged sRGB images are wrong. The tagged Adobe RGB is rendered correctly. The HTML is incorrectly rendered. The Flash is not colour managed.
||This approach means that these browsers render the small percentage of tagged none-sRGB images correctly, whilst failing to render the vast majority of untagged images correctly. That's another direct contradiction of the standard (which has Microsoft's name on it, twice). With these browsers you can only get accurate image colours by using embedded profiles other than sRGB, which won't be recognized by 99% of your viewers!
3.2 Firefox 3
Firefox 3.0 was a game-winning colour managed browser on Windows. You had to explicitly enable colour management, but it worked as you'd expect. Note however that 100% of the internet reviews I found when this was released completely missed the point. Which is not that the browser reads embedded profiles, which almost no-one uses, but that it reads and uses the monitor profile, which everyone with a calibrated system needs it to do. In other words the colours output by FF3 will match those of PS/CS for any website you happen to look at. Simple, effective, correct.
Firefox 3.5 uses a new internal colour management system called "qcms", which breaks colour management in a rather subtle way. On a colour managed system, images with embedded ICC v2 profiles will render correctly, but those with embedded ICC v4 profiles will not. So that's a step in the wrong direction, and we no longer have a completely colour managed browser in Firefox. You can confirm this yourself at the ICC's test page.
Note however that this is only an issue if you embed an ICCv4 profile which is not a simple superset of an ICCv2 profile into a web page. Everything else works as expected. The defect is inside Firefox and does not affect Windows support for any ICCv4 monitor profile you may be using (thanks to EJ for assistance in confirming that this is true).
If you, or someone else, should embed such a profile into an image, then Firefox users with or without colour management will incorrect colours.
Version 3.5 also introduced a second, default Colour Management setting for Firefox, which is to colour manage only if the source image has a profile tag. Configred this way Firefox behaves in the same way as Safari, bizzarely using your monitor profile only for images containing a profile tag.
3.3 Browser Plug-Ins
Plug-ins render their own content and also have the responsibility for colour managing it. In this sense they are independent of any browser they are running in.
Flash 9 was not colour managed, so even running inside a colour managed browser it would render incorrectly.
Flash 10 fixes this. Adobe's documentation is excellent, explaining to the Flash programmer how to explicitly request output to be colour managed, and giving an interactive example of it in use.
Note however that Flash authors must explicitly use the colour management API: it does not "come for free" simply by using Flash 10 as a player or development environment. Hence any legacy Flash is still going to colours incorrectly for anyone with a none-trivial monitor profile. My Flash sample doesn't explicitly use these APIs, so it's "unmanaged" in any browser.
One advantage of using Flash is that if your movie is colour managed, it will be so in any Windows browser, irrespective of the colour management capabilities of that browser.
Silverlight 1.0 - 3.0
I could find no mention of sRGB or colour management in the Silverlight documentation, and none of the example code is colour managed.There is one forlorn feature request for colour management to be added post 3.0. At this time, Flash is the only way to go for photography related applications for this reason alone.
Photoshop has been colour managed since, what was it, version 5? It's useful to compare the correctly rendered output from Photoshop with the web browsers, as most people are confident now with Colour Management in Photoshop. There are a couple of subtleties which I think it's worth noting however.
The way PS/CS displays Windows screen grabs (Alt-Print Screen) from various applications is slightly counter-intuitive. You may expect that a straight screen grab of a correctly colour-managed Firefox screen pasted into Photoshop would show the correct colours. After all they're both colour managed applications. It's not so: the pasted image is displayed with incorrect colours (this is true even if you have "ask when pasting" set in your colour management policies).
It appears that the Windows "clipboard" (or the snipping tool) isn't smart enough to take into account both the copied image's bits and the colour space they were in. In the case of Windows Explorer (unmanaged) at least, it just takes the image bits and ignores the monitor profile. So if you're pasting from there into Photoshop, you need to tell Photoshop what the source colour profile was. Paste the image in, then immediately "assign" your monitor profile to it and the colours will match. I normally then immediately convert to my working colour space to keep things simple.
The PS/CS help files are unclear on precisely what their soft proofing features do. Here's what they appear to do on my systems based on my tests.
- According to the documentation, the preset proof target "Monitor RGB" uses the monitor ICC as the proof target, and won't use colour management. From my tests it actually bypasses the monitor profile and also ignores the source image's colour space. It is therefore not colour managed, it just throws the bits from the image file at the screen.
- The "Windows RGB" preset in my tests ignores the document's colour space but uses the monitor profile for output. This is useful, as it shows the image as others will see it.
Windows colour management is still a little complicated, and application support remains patchy. Much third-party documentation is misleading or incorrect, but as demonstrated here a few simple experiments can help work out what's actually happening.
All this is changing quickly, and in the last year considerable progress has been made. Flash 10 is colour managed if programmed correctly, and when Firefox is correctly configured it is colour managed, assuming you do not embed ICCv4 profiles in your images. Together those two are enough for many users. Other browsers remain mostly broken in this respect for the time being.
Based on the above, there are a couple of obvious strategies for maximizing the number of people who can see your image colours correctly. I have tested neither of these!
- Convert everything to sRGB (which is probably within the gamut of most monitors), and then tag with an sRGB profile identified as anything other than sRGB. The images would look reasonable to the average user because they're sRGB. The embedded sRGB profile would make them work with all the latest browsers except for the IE8 group. Deliberately mis-naming the profile should make it work correctly in the IE8 group.
- Use a Flash 10 developed plug-in which explictly supports colour management. Assuming this is correctly coded, the images will simply match Photoshop every time.
Apendix 1: Why not do it all in the Look Up Table?
If your graphics card's Look Up Table (LUT) was as flexible as the ICC profile, then you could in principle simply use the LUT to do all the required colour mapping for monitor output. So why split the operation into two, having translation in the LUT and also within the Operating System (OS)?
The LUT seems like an unnecessary complication, as you could do all mapping within the OS. However that assumes that the gamut of the output device (the display) is broad enough to contain at least sRGB gamut output. I suspect then that the LUT adjustments are course (low bit count) adjustments intended to bring the output device within the required gamut, then the OS handles colour transforms into that gamut.
You could argue that the LUT could handle the ICC mapping too. The problem with that would be that the card would have to map from any arbitiary colour space (eg that tagged to any image) to that of the monitor, which is perhaps better done in the OS.
It would be necessary to look a little closer at the ICC profile and the LUT data format to understand precisely what's done in each or to be sure of why.
Appendix 2: Other Links
I've learned to trust little other than primary sources on the internet. Here are some useful references I'd recommend in addition to those included above.