From Chromix newsletter 26:
===========================================================================
This Month's Feature Article: Vista's new Color Management System: WCS
by CHROMiX President Steve Upton
Recently Microsoft released their delayed and highly anticipated
upgrade to Windows: Vista.
There is no shortage of articles analyzing Vista, its requirements,
its new features, and many of the changes that will take place for
the user and software developer. What I have not seen, however, is an
article addressing Vista's color management system (CMS)
capabilities. So here we go.
Windows Vista includes a significant upgrade to operating
system-level color management. The Windows Color System (WCS)
represents an departure from the ICC-based architecture that most
CMSs have used for the past 10 years or so. As I often do with many
of my articles, let's take a few steps back to put it all in
perspective.
Windows 2000 and XP include Microsoft's CMS called Image Color
Management (ICM). The Color Management Module (CMM - I hope this is
the last of these acronyms) was originally written by Heidelberg and
has not seen much of upgrades or bug fixes over the years. As a
result of this low priority on Microsoft's list, ICM has had enough
bugs and short comings few people rarely use it for color
conversions. Though you can select ICM for conversions in Photoshop
and other applications, few users do. Many print drivers and RIPs on
Windows use CMMs licensed from Kodak and other companies. It's fair
to say that those of us in the professional realm had given ICM up
for dead.
Windows ICM, Apple's CMM in the Mac OS, Adobe's CMM "ACE" in their
publishing applications, Kodak's CMS and most other major color
processing systems have used the architecture and profile format
described by the ICC. In this architecture (at least thus far) the
basic components have been 'smart' profiles and a 'dumb' CMM. This is
an over simplification but it captures the basic building blocks.
In the early to mid 1990's computing power was only a fraction of
what it is today. Calculating color transformations took time - 5 to
20 minutes or so - and it wasn't realistic to calculate these tables
real-time in production workflows. At the same time, the bleeding
edge of color research lay in mapping gamuts and transforming color
as smoothly and realistically as possible. By placing the color
mapping function into the ICC profile, the CMM was left to perform
the much simpler - and faster - job of converting image colors using
simple interpolations of the profile's tables. The hard work, both in
design and computation, is performed off-line when the profile is
originally calculated from color measurement and reference data.
Profiling software manufacturers can refine and revise their color
conversion technology to bring us better and better profiles without
us having to upgrade our publishing applications. Competition between
profiling vendors would also drive improvement in color technology
over time. All in all, a wise method to get us through the first 10
years of advancement.
But over time, shortcomings in the architecture came to light. One of
its primary strengths turns out to be a weakness as well. Recall that
ICC device profiles perform half the required color conversion. In a
normal workflow, when an image is converted between two color spaces
(say Adobe RGB and SWOP CMYK), two profiles are put to work and they
hand off the image color in the Lab color space. By selecting Lab
(and sometimes its cousin XYZ) as the profile connection space the
ICC gave us the brilliant system where a profile only needs to know
about converting between its device and Lab. Users can select
profiles on the fly and the CMS knits them together to perform the
conversion. Profiles can be combined in different ways to convert
from device space or to device space. Profiles can be used for
matching between devices or simulating one device on another. The
problem is that the very calculations that map color between one
device and another are performed when we don't know what the 'other'
device will be. In other words, when I choose the perceptual
rendering intent, the tables in my source profile and in my
destination profile will both try to map color from the, typically,
larger source gamut to the smaller destination gamut. As I mentioned
before, this stuff is the real rocket science behind color management
and yet neither profile can be aware of the size and shape of the
other's gamut. This can result in sub-optimal hand-off between
profiles and inaccuracies or unnecessary desaturation in color
conversions.
Another example of this is black point compensation. BPC is an Adobe
work-around to this same gamut-blindness. With BPC, the Adobe CMM
evaluates the lightness range of each device gamut and scales between
them. BPC is performed in the CMM, has been only available in the
Adobe CMM, and was outside the ICC spec.
For this and other reasons, advanced users have been calling for a
change in the architecture to allow for moving some of the smarts
from the profile into the CMM. The ICC is evaluating several options
to change the way profiles interact as well.
Windows WCS, as you might have been able to anticipate, is based on
an updated architecture where the profiles are simplified and the CMM
enhanced. ICM, the ICC-based engine is still playing along for the
times when users supply ICC profiles for their conversions. The new
features and interplay between WCS and ICM are a bit involved so
let's step through it:
- WCS profiles are NOT compatible with ICC profiles. They are
XML-based text files that are much simpler and do not contain gamut
mapping calculations at all. Think of them as slightly processed
measurement files.
- There are three different kinds of WCS profiles: device model,
gamut mapping method, and appearance model. The device model profiles
contain the color measurement information from the actual graphics
device. The gamut mapping method profile selects which gamut mapping
technique the user desires. WCS is based on CIECAM02 appearance
modelling. The appearance model profile contains the parameters for
CIECAM02 transforms. This is where you might specify the color
temperature of the lighting used to view your print or the color and
intensity of its surround.
- WCS and ICM work hand-in-hand in Vista. If all the profiles
supplied in a color transformation are ICC-format, then ICM is call
upon to do the processing. If one or more of the profiles is
WCS-format, then WCS takes over and performs the conversions.
- If WCS is performing the conversions, any ICC profiles in the
workflow are converted to WCS format prior to processing the image
color data. Any gamut mapping in the ICC profile is ignored and WCS
treats it as a virtual device, reconstructing the device measurements
from the A2Bn tags in the ICC profile.
- Microsoft has upgraded ICM to version 3, fixed its bugs and updated
it to use ICC version 4 profiles, bringing it up to date and
hopefully removing any processing problems we've seen in the past.
This is great news as it shows that Vista will be able to play with
all the ICC profiles in the world and fit into existing color
workflows. ICM is still based on the original Heidelberg code.
- Because WCS calculates the color transformation on the fly, gamut
mapping should be more efficient and accurate. WCS has the
information for each device's gamut and can presumably make better
judgements and choices when dealing with out of gamut colors. This
also means that black point compensation is automatically handled at
this stage. (more on BPC below)
- WCS can also perform calculations using floating point math and
allows device models to describe where to map diffuse whites and
specular highlights. This and other enhancements allow for a number
of new things to occur such as avoiding possible round-off errors on
16 bit devices, support for high dynamic-range devices (like the new
digital projectors in movie theaters) and also extended gamuts.
- WCS can also be set to preserve the black channel through a
workflow. Something for which ICC users require device link profiles
at this time.
- By separating the device information from the gamut mapping and
viewing data, users may be able to address specific color problems in
the most appropriate area. Gamut mapping issues could be addressed
separately from device measurements and viewing issues. In ICC
profiles today, all the functions are combined during profile
construction into one table.
- WCS can convert WCS profiles to ICC profiles. After conversion, the
original WCS device profile is embedded into the ICC profile as the
'MS00' tag. In this manner WCS profiles can be embedded into image
files as ICC profiles.
- WCS is only available with Windows Vista and Microsoft has stated
it will not be made available to Windows XP.
- WCS was developed in conjunction with Canon.
- Microsoft has documented the daylights out of WCS so very little of
it is based on 'magic sauce'. Also, many of the algorithm components
are extensible or replaceable so developers can write their own
plug-ins and alter device models (how the system expects devices to
behave, inks to mix, paper to absorb), gamut mapping and so forth.
- Microsoft has created a useful demo image that contains an ICC
profile that has a WCS profile embedded within it. The image and
profiles are constructed in such a way that a Ducati motorcycle
appears to be blue, green or red if the profile is entirely ignored,
the ICC component is used, or the WCS component is used,
respectively. It's worth a look:
< http://blogs.msdn.com/color_blog/archive/2006/09/29/Profile-utilization-test-image-and-profile.aspx>;
... to be continued in next message