Elle Stone wrote:
> How should the following two quotes from the V2 version of the ICC
> specifications that is linked to on the color.org specifications page
> (http://color.org/icc_specs2.xalter) be interpreted?
Hi,
this is an old chestnut. I'm not sure how many more
times I'm prepared to repeat all the ins and outs.
> A.3.1.1 MediaWhitePoint Tag
> The mediaWhitePointTag contains CIE 1931 XYZ colorimetry of the white
> point of the actual medium. If the viewer completely adapts to the white
> point of the medium (as is often the case with monitors) this tag should
> be set to Xi, Yi, Zi (the PCS white point). If chromatic adaptation is
> being applied to the PCS val-ues, the adaptation should be applied to
> the mediaWhitePointTag values as well.
This section is present only in the V2.4 specifications. By definition it can't
change anything that has come before, which means that the vast bulk of ICC V2
CMM
implementations and profiles precede it, and cannot be expected to conform to
it,
even if it was regarded as being canonical, which is doubtful, given that is in
an annex rather than the spec. proper, and goes against a great deal of
previous practice, utility, and basic logic.
There is some irony in such a fundamental point being ambiguous in ICCV2,
given that ICC was derived from the Apple ColorSync format, which (I gather)
was originally a display only format. To a degree this may be explained by
the appearance that the print profile (cLUT) support seems to have been
mostly added in, rather than fully integrated into the spec., so
perhaps the explanation is that the print profiles added the idea of
absolute colorimetry and a media white point, and the assumption was
that display profiles would continue to work in the same undocumented
way that they had done in ColorSync. Those of us not privy to the
"way things have always been done in ColorSync", instead had to interpret
the ICC spec. as written, and deal with various ambiguities, as well
as industry "best practice" in regard to chromatic adaptation.
One of the odd things about the ICC format is that it uses a
"wrong Von Kries" chromatic adaption matrix for the media white
to PCS adapted white transformation. I've yet to hear any convincing
technical justification for this, and it is a key problem in dealing
with display profiles withing the ICC framework.
The white point shift for a print profile is typically very small,
so the visual error between "wrong" and "right" Von Kries
is typically insignificant (although less so for tinted media), while
the error for D65 to D50 cannot be so easily overlooked. So it is no
surprise that those faced with the task of creating useful ICCV2
display profiles adapted the ICC specifications as best they could. There
are two basic approaches, one being to hide the chromatic adaption
completely, and claim that the display profile has a D50 white point.
This results in an ICC profile in which there is no means of
recovering the underlying device behavior, or using it for soft proofing
in a pure ICC workflow. The other is to put the actual display white point
into the media white point tag, just like a print profile, and use an
appropriate chromatic adaptation transform to adapt to PCS D50.
This results in an ICC profile in which the the underlying device behavior
can be recovered, and it can also be used for soft proofing in a pure
ICC workflow. The problem with this approach is that the chromatic
transform matrix used is different to the one specified by the ICC spec.
None the less, the the latter approach is the one that the sRGB and AdobeRGB
profiles take. Given the prominence of both of these profiles, as well
as the well documented means used to create the sRGB profile, as
well as the strong technical reasoning behind using this approach,
it is a tragedy in my opinion that the ICC didn't resolve this problem
by simply adding a new (optional) tag to specify the chromatic adaptation
matrix to be used for media white to/from PCS D50 in place of the
default "Wrong Von Kries".
Instead for ICCV4 they added an additional chromatic adaptation matrix
tag (the chad tag) for the purposes of documenting any illuminant white
point transformation, and specify that display profiles are to lie about
their media white point. This means that, using a standard CMM with the
usual 4 intent selections, you can't recover the instrument readings or
use the display profile for soft proofing.
This whole approach flies in the face of logic. For print media
the illuminant is independent of the media itself, so it's quite
logical to specify that the media be evaluated and measured
under a given illuminant spectrum such as D50, and if this
is not possible, to allow for a separate chromatic transformation
(the chad tag) between the actual illuminant used and the standard
illuminant. The remaining chromatic transform is then a (usually a
small one) from the actual media under D50 to PCS D50.
A display on the other hand has an "illuminant" that is physically
inseparable from the "media". So it is nonsense to apply a chromatic
adaption from it's media white to D50 as if it were a change
in illumination, since a change of illumination is physically impossible.
> My understanding of V2 ICC profiles is that there are two ways to
> specify a V2 ICC profile's source white point:
> 1. You can either put the source white point in the media white point
> tag (for example D65 for sRGB).
> 2. Or you can put the ICC D50 illuminant values in the media white point
> tag and include a chad tag that gives the chromatic adaptation matrix
> from the source white point to the ICC D50 illuminant.
The chad tag was a latter addition, so there are V2 display profiles
that do 2. without containing a chad tag.
> An alternative interpretation of the quote from Annex A is that for at
> least some ICC profiles, perhaps including the D65 sRGB profile, the
> media white point tag should *always* read D50 even for V2 sRGB profiles.
The reality is that this annex section was added extremely late in
the piece, and doesn't at all represent the reality of ICCV2 display
profiles - witness sRGB and AdobeRGB.
> Does the quote from Annex A:
>
> 1. Apply specifically to sRGB, because sRGB is (sometimes) used as a
> monitor profile? And if the quote does apply to sRGB, does this mean
> that V2 sRGB profiles that have the sRGB D65 XYZ values in the media
> white point tag actually violate the (or perhaps some particular version
> of the) V2 ICC specifications?
It can't possibly apply to the Microsoft/HP sRGB profile, because it was
issued well after the profile was created and widely distributed.
> 2. Apply to *any* ICC profile that has 'mntr' in the header, which would
> include AdobeRGB1998 and ProPhotoRGB?
See above. You can't magically make all existing profiles and CMM conform
to a retrospective change in the existing practice.
> 3. Apply only to the particular device ICC profile that is being used as
> the display device profile in a particular color-managed workflow?
See above.
> 4. Some other case?
My advice would be to apply it in no situation for ICC V2 profiles, unless
you are prepared to somehow guess or can determine that an ICC V2 profile
uses the V4 scheme of things. The presence of a chad tag and a D50 media
white point may be a reasonable guess, but this isn't guaranteed, because
there was a long period of confusion even after the introduction of the
chad tag to V2, so there may well be profiles out there in which the chad tag
represents the transformation from the display white point to PCS D50,
rather than from display white point to "D50 illuminant".
> In whatever cases where the quote from Annex A might apply, is it
> suggestive (can be done, but not mandated) or normative (must be done or
> else the profile violates the V2 ICC specifications)?
See above. I would ignore it as merely an attempt to re-write history.
The approach I've taken in Argyll and icclib is a more pragmatic one, that
recognizes the reality of the wide spread sRGB and AdobeRGB profiles,
industry best practice in regard to chromatic transformations, and
the importance of the ICC profile being a representation of the basic,
measurable device behavior. I'm simply using a proper chromatic
adaptation transform instead of the "Wrong Von Kries". This means
that it properly complements the one used in sRGB and AdobeRGB, so
that soft proofing and recovery of the measurement values is possible
using absolute colorimetric, while having minimal impact on interoperability
of print profiles, because most media has a very small white point shift,
while vastly improving the chromatic transform appearance for display profiles
and tinted media by the application of a better chromatic white point
transformation.
This approach sacrifices a small measure of interoperability
between CMM's in an area that was already fraught with incompatibility, for
much better utility and compatibility with widely used profiles, as well
as better visual performance.
ICC v4 poses a number of problems in conforming to the "wrong Von Kries"
media white point transform, as well as the "display profiles shall be
chromatically transformed to D50" specification, even if it is less
ambiguous than V2.
An approach that I've considered is:
1) Make the CMM "absolute colorimetric" intent undo the chad tag effect
for display profiles.
2) For any profile that has a media white != D50:
* Transform the profile data from relative to absolute using "Wrong Von
Kries"
as per the ICC spec.
* Create a new relative colorimetric etc. intent data by forward transforming
the absolute data using a proper chromatic transformation.
The latter is fraught with issues about aligning any other auxiliary data with
the change in relative/perceptual/saturation values, so it is also tempting
to simply use the same approach as V2, and use a proper chromatic adaption
transform rather than "Wrong Von Kries".
Graeme Gill.
------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience. Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user
