Re: MS Color Control Applet
Re: MS Color Control Applet
- Subject: Re: MS Color Control Applet
- From: Chris Murphy <email@hidden>
- Date: Mon, 10 Jul 2006 11:22:17 -0600
On Jul 4, 2006, at 9:56 PM, Graeme Gill wrote:
Chris Murphy wrote:
On Jul 1, 2006, at 12:53 AM, Graeme Gill wrote:
It's more complicated that that. All (useful) V2 profiles adapt
the monitor white point
to be D50 already. What's changed in V4 is that now even
absolute colorimetic intent
in display profiles have to adapt the display white point to
D50, because the ICC
have (wrongly IMHO) declared that an emissive devices white is
to be regarded
as the illuminant, rather than the devices media white point.
The idea is to prevent chromatic adaptation from occurring twice.
I'm unaware of any such problem with V2 profiles.
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.
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).
3. Neither 1 nor 2 are reversible by a CMS, to get back at original
measurement data.
> When
the human has fully chromatically adapted to display white, and
the assumption on the part of the display profile is that the
human has not fully chromatically adapted, the profile building
does some chromatic adaptation when they should do none and leave
any chromatic adaptation to the CMS.
Would you care to explain this in some more detail ? While a CMS could
do anything, I'm not aware of any that make the assumption that the
viewer isn't fully chromatically adapted to the white point of the
display
for Relative Colorimetric (ie. the PCS) Intent.
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.
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.
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 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.
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.
> further chromatic adaptation for that white point is unnecessary
when making
> that assumption.
The point is not "Further chromatic adaptation", it is undoing the
adaptation the CMM has assumed, to be able to do real absolute intent.
A proofing situation is one in which you can't assume the user is
100% adapted to the display, since that's not the only thing they
are looking it.
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? They're
really mutually exclusive events. 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.
What we know works, best practices, is that you don't soft proof and
hard proof at the exact same time in the same field of view. Thus far
anything else, all bets are off.
Looking at the V4 mechanisms, and reports recently from people using
V4 applications, I think my understanding is correct, and in
my last discussions with Marti Maria we both agreed this was the case.
If you can point to something specific in the specification that
I've missed, I'd be grateful.
If you aren't seeing this effect, perhaps the profiles or
application you
are using isn't ICC V4 compliant ?
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.
Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
---------------------------------------------------------
Co-author "Real World Color Management, 2nd Ed"
Published by PeachPit Press (ISBN 0-321-26722-2)
_______________________________________________
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