Re: MS Color Control Applet
Re: MS Color Control Applet
- Subject: Re: MS Color Control Applet
- From: Graeme Gill <email@hidden>
- Date: Wed, 12 Jul 2006 18:23:10 +1000
(Sorry if this ends up being posted twice. My first reply seems to have
vanished down the bit bucket...)
Chris Murphy wrote:
> On Jul 10, 2006, at 7:52 PM, Graeme Gill wrote
>> You can't really make a "blended perceptual/relcol" using
>> matrix/shaper, it is simply colorimetric.
>
> Of course you can. You can do anything you want to do with the
> perceptual intent because it isn't defined at all in v2. Nothing in the
> spec or the guts of the profile prevents a vendor from populating a
> matrix profile with fudged values.
ICC Spec ICC.1:2001-04 (That's V2.4), page 19, table 20,
Display TRC/Matrix has intent "colorimetric", not perceptual,
so yes, the spec. prevents vendors from populating a
matrix profile with fudged values.
The other point was that a matrix profile isn't really suited
to incorporate gamut mapping (it's an incredible hack
if the other gamut is something like a print gamut, because
a matrix doesn't have the flexibility to make the RGB
gamut conform to an arbitrary other gamut).
> Any time the display white point is not D50, and the profile claims the
> media white point is also not D50, and the rendering intent to the
> display profile is AbsCol, and any time a CMM then decides to
> compensate for a non-D50 display *and also* assumes the end user is not
> fully adapted to a non-D50 display white, you then get *excessively*
> yellow soft proofs.
What you're describing sounds like a broken application if it
is (for some unknown reason) assuming anything about user
adaptation. If a user requests absolute colorimetric rendering,
then that's what the CMM should do, nothing else. A profile
for a display that has a non D50 white point, and accurately
marks that in the media white point tag, is being perfectly
reasonable. See the sRGB profile for an instance.
If the user asks for absolute rendering, then a (correctly working
application) will reproduce an absolute rendering. If you
send it D50, then it produces D50, and against the users adaptation
to the presumably D65'ish white point of the monitor,
it will look yellow. It's supposed to. If you measure the color
though, it should be as close to D50 as it can get, just like you
asked for when specifying absolute rendering.
> I have two profiles for an identically calibrated display. One is v2,
> one is v4. The wtpt tag for the v2 profile uses XYZ values for the
> actual white point, which is not D50. The wtpt tag for the v4 profile
> uses XYZ values for D50.
Right. They are both conforming to their respective specifications.
> I take a CMYK TIFF filled with white space. I take a modified "Match to
> chosen profiles" AppleScript, modified to use AbsCol rendering. The
> source profile is set to SWOP v2, the destination profile is set to the
> ICC v2 profile and the image is converted. I do it again with a
> separate copy of the image using ICC v4 profile as the destination.
>
> So I now have two RGB TIFF images. One the result of ICC v2 profile as
> destination, and the other the result of the ICC v4 profile as
> destination. The RGB values of the v2 profile are 255, 255, 216. The
> RGB values of the v2 profile are 219, 219, 212. These are *completely*
> different colors. One is decidedly very yellow as well as bright and
> the other is more gray than it is yellow. And that is the visual
> experience that best simulates a true publication grade stock on a
> display. The yellow simulation is simply wrong. It looks obviously wrong.
There are a few problems with what you describe:
1) You are using absolute colorimetic and expecting this to
operate like a "soft proofing" switch. It isn't. It's
simply instructs the CMM to give as close as possible to
non-media white point relative (ie. instrument readings)
reproduction. That's a necessary step in being able
to do soft proofing, but mightn't be sufficient in itself.
One important reason is gamut clipping. You are taking
the SWOP gamut, and mapping it absolutely to the
display gamut. You will almost certainly clip the
swop white, giving you a strange white point. You
have to scale the swop down to fit within the
display gamut (brightness scaling, so as to
retain the absolute color reproduction).
A CMM or application that just implements the ICC
intents, doesn't have a switch to do this.
I'm not too sure many people are aware of this problem.
2) ICC "absolute" is not CIE "absolute", ie. it doesn't
give you absolute brightness level rendering.
The usual workaround to both the problems is to
calibrate the display to make it's white point match
that of the target (ie. SWOP). This avoids the gamut
clipping problem, and explicitly takes care of the
brightness matching problem. It has the disadvantage
though, of being rather inflexible if you want to
softproof other media (non-SWOP).
I doubt that the V4 case is much better though. By
accident it may be a better visual match, but since
it's not a real absolute reproduction (unless
Photoshop is pulling some tricks to work around
the loss of absolute rendering information that
has occurred in recording the display white point
as D50 when in fact it isn't), it's seems unlikely to
be a better colorimetric match, which was what was asked
for.
Now, whether a colorimetric reproduction of the SWOP is a visual
match, is a different question (very much the realm of the
paper by Fairchild referred to previously), but is irrelevant
to the operation of absolute colorimetric rendering. Having
absolute rendering being able to operate correctly is the first
step in being able to make adjustments that can move to
a closer visual match. V4 makes that more difficult.
> Now if I perform this experiment in Photoshop of any version I have
> easily available to me, Photoshop 7 and higher, there is no difference
> between the two profiles. I get a paper white simulation that is more
> gray than yellow, as it should be.
If that is the case, then Photoshop is doing a lot of
work in the background, and their "Absolute colorimetric"
isn't the ICC Absolute Colorimetric (a bit like "black point
correction").
>>> 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.
>
> This conversation is simply a waste of time if you're not going to
> qualify your statements. I have several bits of information in there
> and your suggesting none of it is true. You think there is only full
> and zero adaptation? Or that the level of adaptation is defined in the
> v2 spec? Or you're denying that some vendors bake varying levels of
> assumed adaptation into their profiles?
My reply was a little more than "This simply isn't true.",
it was a paragraph of explanation, but OK, lets go through it
one point at a time:
>>> There is a continuum from no adaptation to full adaptation for the
>>> end user.
Certainly. It's not something ever tackled in the ICC spec. though,
because it's still research, not established principle yet
>>> This is not defined in v2, so vendors make an assumption
>>> for less than full adaptation,
In writing and maintaining an ICC compatible CMM over the last
9 years, I've never seen such a thing, nor seen any references to
such a thing. Any sane display profile I've come across has
assumed the 100% adaptation that the PCS implies. They mark the
display white point in the white point tag, apply the chromatic
adaptation in the matrix needed to adapt the display white
to PCS D50, and that's it. See sRGB. There no room there that I can
see for partial chromatic adaptation in there.
I think I've stumbled across a couple of un-sane profiles,
that have a real white point non-D50 to D50 white point adaptation
in their matrix, and then mark their white point as D50, or
don't transform their white point to D50 at all, and although this
can be blamed partially on the ambiguities in the v2 profile,
their creators weren't thinking clearly either.
I thing it's a while since such profiles were circulating.
>>> 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.
I can't see how this would be done, and I can't see any examples
of this being done. Please point to a widely accepted
display profile where this is the case. I can point
to many that don't.
>> , 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.
>
> Then why is it Adobe has been disregarding wtpt tags for almost a
> decade?
Well I'm not entirely sure what Adobe do and don't do, because I'm not
privy to their source code, and I don't see the relevance to
the ICC spec. if they choose not to present to the user
any choice of Intent for RGB profiles. I'd be pretty surprised
if they don't use the wtpt tag though, since this this
part of the ICC spec., and needed for Absolute Colorimetric,
which is selectable (and seems to work as one would
expect) for CMYK profiles, at least on PhotoShop 5.5.
> You're proposing that Adobe has broken absolute colorimetric
> for display profiles in all of their applications this whole time that
> people have been effectively doing soft proofing, including with
> displays that do not have D50 white points.
It depends a little on the style of softproofing, but again,
the ICC spec. is not written from what Adobe do, it is the
other way around.
> The problem is with the CMS honoring the wtpt tag in an absolute
> colorimetric conversion in a manner inconsistent with the state of
> adaptation of the end user, in effect over compensating for a non-D50
> white point. This is why I get different results with the same display
> profile depending on whether I use an Adobe application and its CMS,
> versus some other CMS like the Apple CMM + an AppleScript.
"Absolute Colorimetric" is not the same as soft proofing. It
is meant to have a specific set of functionality that is
needed as a foundation for applications to be able
to offer end user features, such as soft proofing. The changes
to the V4 spec. have made this difficult by removing the
distinction between relative colorimetic and absolute
colorimetric for display profiles.
You are probably right that using absolute colorimetric
in itself doesn't give you good softproofing results,
but the solution isn't to break a foundation element
on which ICC profiles and systems that rely on them
are based. The right solution is to keep a strong
technical foundation, and for the applications to implement
the necessary corrections, such as avoiding gamut
clipping, adjusting brightness levels, allowing for
different levels of adaptation for displays vs. prints.
The fact Photoshop and other CMS don't operate the same
when absolute colorimetric is selected is a black mark
against the success of the ICC spec. V4 changes were meant
to reduce such differing interpretations, not increase them.
> That you see consistency between other CMMs and your version of
> Photoshop (which is what version exactly?) indicates you indeed have an
> old version and you're completely unaware of today's state of technology.
Gee, I try to keep up.
> Now ideally we'd be able to choose the level of adaptation of the end
> user, so that we could better compensate for partial end-user
> adaptation which we currently cannot in existing UI.
But I thought you said that some Display creators
were already doing this, hence the need to make the V4 changes :-)
>> 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.
>
> The data in the profile is reversible to AbsCol.
Are you talking about ICC V4 AbsCol, or real non-media
white point relative data ?
To recover the latter is not something ICC Absolute
Colorimetric does, since it undoes the shift from
the white point tag to D50, and for V4 Display profiles
the white point tag has to be D50.
Yes, a CMM can implement a non-ICC "Real Absolute"
intent that uses the 'chad' tag to recover real
non-media white point relative readings from V4
profiles, but how will they represent that to
applications ? How will they represent that
to users ? Will they simply substitute "Real Absolute"
for "ICC Absolute", creating lots of confusion ?
> That was not a
> guarantee in v2 profiles because the data was munged for reasons
> previously described. Just because you have a wtpt tag doesn't mean you
> can simple adapt and get back measurement data. The data was altered in
> ways that aren't described in the profile.
If what you say was the case, the display profile creators
weren't following the spec. The spec. is quite clear
on what intents the matrix or Luts are meant to represent,
and how to transform from absolute to relative colorimetric
and back - the equations are specified.
I haven't come across any widely used display profiles
that have such "munging". If it's a common enough problem
that Absolute Colorimetric display profile rendering had
to be broken in V4, please point these profiles out.
> It's a fantasy at this point.
Some of us like challenges. We need good support to
do this though, like a device profiling format that
stores the non-media relative device data in
a form that's easy to get at, and can be relied upon.
> If you have two different light sources,
> the human visual system cannot simultaneously adapt to both of them.
We don't usually look at light sources. It hurts. We instinctively
look away from light sources.
> And a viewing booth is a completely different light source than a
> display even if the white points match. There's more to this than just
> white point matching.
The idea isn't to match light source white points. The idea
is that the media whites should match, irrespective of the
media being reflective or emissive. You don't look
at the light source, you look at the print. You might
see the light source reflected from objects other than
the print, but that's a viewing conditions issue.
> Soft proofing by definition does not involve a hard proof.
I take it as meaning at least one image from an electronic
display.
> Hard proofing by definition does not involve a soft proof.
I take it as meaning at least one image is a print.
> When you combine both of these events together, best practices, for a
> number of years now, has dictated that you don't view one in the field
> of view of the other.
Agreed that it's not easy to set up such a viewing situation, but
that doesn't mean it's impossible. How else do you verify the soft
proof ?
>> 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.
> Yes the CMS can know the level of partial adaptation? How? What UI
> element does this? What CMM supports it?
Please read the above again. There is no partial adaptation involved,
just controlling what the user sees from the two media.
> If you have two completely different light sources in field of view, a
> human is not fully adapted to either one of them!
You don't look at light sources, you look at their light after
it has been reflected off something, and the whole point about
a proofing setup is to control this situation.
> They behave the same in Adobe applications. They behave differently in
> other applications.
Adobe is doing some curious things then.
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