Re: MS Color Control Applet
Re: MS Color Control Applet
- Subject: Re: MS Color Control Applet
- From: Graeme Gill <email@hidden>
- Date: Tue, 11 Jul 2006 11:52:37 +1000
Chris Murphy wrote:
I'm unable to say who is doing what, but most of the v2 display
profiles being built have a number of issues going against them. Three
are:
1. There is only one intent provided, thus vendors produce a blended
perceptual/relcol intent in the single required intent (perceptual)
that is required in this profile class.
Not true. If it's a matrix-shaper, then there is only two intents (relative
and absolute colorimetric), but any LUT based display profile has the
usual machinery for all 4 intents, just like any normal print profile.
You can't really make a "blended perceptual/relcol" using
matrix/shaper, it is simply colorimetric.
2. there is an ambiguity as to the adaptation of the end user because
it's not defined, therefore different vendors make different
assumptions as to the adaptation of the user. If they assume the end
user is not fully adapted, which is almost always false, then the
resulting pre-adapted profile is in effect causing chromatic adaptation
to occur more than once (i.e. in the end-user himself).
This sounds a lot like an explanation about the effect of
certain vendors problems, rather than the causes. To
convince me there was actually a problem, you need
to translate this into specifics. What combination
of display characteristic, white point setting and
matrix/LUT setup lead to the problem you say justified
the radical change in V4 display profiles ?
I can't understand any vendor pursuing the common
case (ie., Relative colorimetric, Perceptual or
Saturation rendering) assuming that the user is
not fully adapted to the media - this is pretty
fundamental to those three intents !
3. Neither 1 nor 2 are reversible by a CMS, to get back at original
measurement data.
Problem 1 doesn't exist.
I still haven't seen a case that problem 2 exists.
ICC V4 itself causes problems in getting back the original measurement data
There is a continuum from no adaptation to full adaptation for the end
user. This is not defined in v2, so vendors make an assumption for less
than full adaptation, and then they bake in compensation for the
remaining non-adaptation into the resulting profile. It's hardwired at
that point *and* it isn't reversible.
This simply isn't true. If the absolute information is retained,
then it's easy to tell whether the devices white point has been
fully adapted to PCS D50 via the colorimetric table. Relative
colorimetic with full adaptation can then be re-created. It's
the lack of the ability to recover the absolute information that
causes problems, and the ICC V4 display changes do exactly that,
they break absolute colorimetric for display profiles,
so that you can't (using the ICC Absolute Colorimetric
machinery) recover the display absolute response.
The ICC v4 view is that the profile should assume full adaptation to
the actual display white, so that no further chromatic adaptation
occurs by either the CMS or the display profile vendor. While I'm
unaware of any CMM's that allow a user selection to engage partial
chromatic adaptation, it's at least feasible in an ICC v4 context where
it not possible in a v2 context.
I'm not aware that "assumption of partial adaptation" is an issue
with V2 display profiles. If it is, then it's an issue with
all ICC profiles, not just display profiles.
There were things that could be improved about the application of
ICC V2 to Display profiles, and ambiguities that could be resolved,
but the V4 changes have simply solved the wrong non-problem,
and stuffed things up IMHO.
In an ICC v4 world, they are chromatically adapted to D50 so that
by default there isn't going to be double chromatic adaptation.
You will have to explain this. I haven't come across any problem
with "double chromatic adaptation".
Well it used to be routine until Adobe took care of this in either the
PSCS or PSCS2 time frame (I forget which), and started to ignore the
wtpt tag in display profiles, even v2 display profiles, and thus assume
the end user has fully chromatically adapted to the display white.
Before then, paper white simulation when using a D65 display white was
way too yellow.
I haven't seen this with the (rather old) version of Photoshop I have
access to. The behaviour has been reasonable, and consistent with
other CMMs with all the display profiles I've stumbled across.
Absolute and Relative do the things you would expect, just like
printer profiles.
Have you got an example of a V2 Display profile that
has this "double chromatic adaptation" problem you describe ?
Can you send it to me ?
I don't see how you can claim that functionality hasn't been lost.
With V2 it was possible using Absolute Colorimetric to get the absolute
display white (ie. D65). Under V4 you will get D50. The 'chad' tag
does contain the information needed to reverse this, but there
is no official intent that makes use of it.
The functionality you're talking about didn't work particularly well in
my experience. The way it works now in the CS2 apps, with the
assumption of an end user fully adapted to display white does work
quite well.
If the machinery didn't work particularly well, then it's a problem
for print profiles too. From my perspective, the machinery
worked perfectly well, once the problems with the use of
"Wrong Von Kries" for absolute conversion are worked around.
Now there's a problem that V4 should have solved!
Now there is the possibility of developers writing a CMM that allows
for a partially adapted end user. This is possible in v4, and was not
in v2.
I simply can't agree. It is quite possible to deal with partial
adaptation in V2, as long as absolute colorimetric can be
recovered. Doing this in V4 is actually harder, because it's
been made harder in V4 to recover absolute colorimetric for
displays.
It really isn't soft proofing if you're looking at a screen and you're
looking at a hard proof in a viewing box, is it?
Um, yes it is. Customers were keen about doing this.
They're really mutually exclusive events.
Not at all. Difficult under many circumstances, but quite
a common request. The Color Management machinery
certainly shouldn't stand in the way of attempting such matches.
There are two completely different light
sources being viewed at the same time, and the level of partial
adaptation between those two light sources isn't something the CMS can
know.
Yes it can, and the whole point is to make it so that the
user doesn't have to be partially adapted, but can be fully
adapted to the one white point, because the aim is to
make the white points of the two media (print and display)
match in an absolute sense, if they are displaying the
same proof.
gmb ProfileMaker 5.05b, produced a v2 and v4 profile from the same
measurement data. I get the same apparent white simulation using either
profile in PSCS2. So I'm not sure what you're seeing different between
them, especially since the wtpt tag has been ignored for a while now in
v2 display profiles by Adobe applications.
Sorry, I don't have ProfileMaker 5.05b, nor examples of it's V2 and V4
profiles to examine. It would be interesting to do so.
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