Re: Microsoft's color-management claims
Re: Microsoft's color-management claims
- Subject: Re: Microsoft's color-management claims
- From: Graeme Gill <email@hidden>
- Date: Wed, 21 Sep 2005 23:41:30 +1000
Marco Ugolini wrote:
Head-scratcher #1:
ICC and WCS XML architectures are both profile-based. It is probably clearer
to describe ICC profiles as pre-processed monolithic collections of device,
viewing condition and gamut mapping data, where the WCS XML profiles are
unprocessed modular profiles with separate profiles for the objective
intra-device measurement data, the objective intra-viewing condition
measurement data and the subjective inter-device/viewing condition gamut
mapping data. In one sense, both ICC and WCS XML profiles contain the same
basic information. ICC profiles combine them all together typically after some
processing by the profile creation software to massage the objective
measurement data into the format structure. WCS XML profiles keeps the
information separate and unprocessed until invoked by the workflow
transformation process.
If the measurement data have to be processed at some point, what difference
does it actually make to process them earlier or later? (I'm not being
polemical here: I am really asking for an answer. And what measurement data
are we talking about here? Colorimetric or spectral? And who is supposed to
provide the spectrophotometer to take the measurements? Does WCS come with
one?)
[This is my take on how it works, based on how I tend to use ICC profiles,
which I am guessing is rather close to the WCS approach. I don't have
any particular inside knowledge of WCS.]
WCS profiles are like just using the Absolute Colorimetric A2B table of
an ICC profile. It's a complete model of the device behaviour, not
just instrument readings (ie. the instrument readings have been
interpolated.) Unlike an ICC profile, it isn't meant to be in a given,
standardized PCS (which includes a standardized viewing condition), but
is meant to be the raw CIE readings for the device plus the actual viewing
conditions of the device (which are also stored with the WCS profile.)
A WCS profile doesn't contain the equivalent of B2A tables, which
are highly processed (in that they are working in PCS, and entail
pre-packaged gamut mapping and profile inversions).
One of the major flaws of the ICC profile is that it presupposes
that the gamut mapping transform is known at profile creation time.
Given that the source gamut in any device to device transform is
not known at profile creation time, this is an incorrect assumption.
ICC V4 attempts to work around this flaw, by recommending that
the (perceptual) A2B transform convert the device color into a
standard viewing condition and gamut. Unfortunately no gamut
is yet standardized, and how well this idea will work remains
to be seen. I have some concerns that the two gamut mappings
(possibly generated by different profiling packages) will
when combined, do some strange things to the color mapping
(distortions, errors, banding etc.).
The alternate approach (which ArgyllCMS and WCS embody), is
to compute the gamut mapping at linking time, when the source
and destination gamuts are known. Things like viewing condition
transforms are easily dealt with at the same time, as is making
a richer set of intents available. Additional features such
as content dependent gamut mapping (where the source gamut is taken
not just from the source color space, but from the gamut actually
used within the source color space) can also be contemplated.
Using a "smart" CMM also allows maintenance of the black channel
in CMYK to CMYK conversions. Since there is only a single gamut
mapping step, possible distortions due to multiple gamut mappings
are avoided.
The main penalty, is that linking speed is slower, or there may
be a price with regard to quality to pay, if you want linking to be fast.
At one point or another, some decisions still have to be made about
chromatic adaptation, interpolation and all the other factors which end up
making the profile usable. So saying that software packages other than
Microsoft's WCS "do the processing beforehand, but we wait until the
workflow requests it" (or something to that effect) may SOUND impressive,
but is it REALLY?
As explained above, the forward profile is created by other packages, and
WCS deals with gamut mapping etc. at link time (with the option of
using plug in modules for alternate algorithms for this.)
Where are the numbers and tests that prove the superiority
of WCS over the current solutions?
Well, naturally that isn't possible with WCS until there is at least
a Beta release. Presumably the developers think they are on the right
track. Of course, you could get some idea about the potential of
the whole approach right now, by using the ArgyllCMS linker in "smart"
mode to generate properly tailored device links, and compare the result
to the "dumb" linking mode.
Head-scratcher #2:
3) In what way is the drift of equipment addressed? Will MS encourage a
move to self-calibrating equipment, or is the user still supposed to keep
measuring his equipment and ensuring its color stability?
This solution will enable 3rd parties to better address the problem of drift
by supporting plug-in device models as well as device model profiles that
are objective measurement data which can easily be compared against newer
measurements to compute differences and recomputed the plug-in device
parameters. While we did not solve all color management problems with this
version, but this work lays the foundation for a long term commitment to
solving color management problems.
What they're saying is that WCS device models (ie. profiles) are in a more
flexible format than ICC profiles, which would allow 3rd party developers
to develop cleverer models, that allow easier tuning (ie. calibration) of a
model to be accomplished, or allow some degree of modelling for the effects of
changing DPI, paper type etc., without the need to re-profile.
I've seen this type of thing in some work on 3D calibration in a paper at
the CIC12, last year. WCS doesn't in itself solve the problem of calibration.
You still need an instrument, and need to take readings, or have
such information pre-packaged for you by someone who has done this work.
Their plug-in device models may make this process easier. Of course, it
might also make profile inter-operability worse, and it is not all that
hard to apply such ideas to the more rigid (perhaps better defined ?)
format of an ICC profile.
In a white paper
(<http://download.microsoft.com/download/5/d/6/5d6eaf2b-7ddf-476b-93dc-7cf00
72878e6/WCS.doc>), Microsoft emphasizes how their Windows Color System (WCS)
is "transparent" and represents a step away from the necessity for color
experts to obtain color-managed results ("Troubleshooting color problems is
complicated and obscure for even the most knowledgeable expert users" --
"Color used to be the domain of experts" -- and so on, statements clearly
aimed at insinuating the impression that WCS is liberating us from the
tyranny of expert knowledge, though never quite explicitly saying so --
which allows deniability later, a trick common in political circles).
"Color management for the masses," if you will. Great. Apart from the fact
that the white paper offers no concrete workflow examples to illustrate how
such "transparency" is supposed to unfold, now this reply quoted above says
that things like device drift require user intervention. How many
"non-expert" users, or even moderately knowledgeable users, will be able to
do this on their own? Gather "objective measurement data which can easily be
compared against newer measurements to compute differences and recomputed
the plug-in device parameters"? How many will look at this and say" "Screw
it! I quit!"?
My interpretation of the above "spin" is this: Much of the color transformations
that occur in an ICC workflow, are embedded in the B2A tables. Current tools
aren't that smart at dealing with viewing condition issues, and ICC profiles
are inherently handicapped in trying to create gamut mappings without
knowing the source gamut. Currently, the way these problems are worked around,
is for a color expert to massage the ICC profile. By implementing a system
that removes some of these inherent problems, and also including more
modern approaches (such as viewing condition adjustment), some of the
need for color experts may disappear.
Nothing in the WCS approach inherently tackles drift etc. WCS as presented
might only improve on this area if it included bundled tools that would
let users more readily compensate for such effects (such as a build in monitor
calibration tool that they talk of).
Again, Microsoft may really have a doomsday machine up their sleeves here,
just like the Soviet ambassador in Dr. Strangelove. But so far it's truly
hard to figure out behind the fog of their opaque explanations what truly
innovative offerings they have for all of us, and if they perform as well as
they claim compared to our present way of working.
I don't see what they are doing as all that revolutionary. It might
have the benefit though, of getting ICC based systems to shift along
in the direction of "smart" CMMs, and then nudge the ICC profile format
itself along in a direction that would better support this approach.
One area where they are opening things up a bit, is allowing for higher
dynamic range images. The ICC approach is fastened heavily to the
idea of a print, which can't have a white that is brighter than
the white point. This doesn't reflect the reality of the real world,
which can contain specular values. Digital capture devices (and CGI)
are capable of grabbing this, but ICC color handing can't really
cope.
Graeme Gill.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Colorsync-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden