Graeme Gill schrieb:
Yes it appears that the only way to provide
V4 compatibility and backward compatibility is to create a
new pseudo-intent (something like "icICCAbsoluteColorimetric"),
as well as the backward compatible "icAbsoluteColorimetric",
or "icRealAbsoluteColorimetric".
Yes, in the meantime I also think, that a CMM should probably offer
three colorimetric intents:
- media relative ("relative colorimetric")
- illuminant relative ("ICC-absolute"?)
- "real absolute", i.e. unchanged reproduction of XYZ
This whole change is a real puzzle.
After taking a look at the old and the new specs, I'm getting more and
more the impression that V4 hasn't really introduced a significant
change, but only extensions. Couldn't it be that the *intended*
semantics have not realy changed, but that they have been misinterpreted
previously by CMM and profile makers, simply because the early specs
weren't clear enough?
I'm coming more and more to the conclusion that probably even for V2
profiles
- the terms "absolute colorimetric" or "ICC-absolute"
were always intended to mean an *illuminant relative*
transformation
- the media white point was always intended to record
the media color, adapted from the device illuminant
to D50 (and not the "real absolute" XYZ of the WP)
- the transformation from measurements to PCS values
was always intended to be a 2-step procedure:
1) CAT from device illuminant to D50 PCS illuminant
2) media relative encoding, using wrong von Kries
- profiles prior to profile version 2.4 did not offer
any opportunity to compute the "real absolute" XYZ
values (as measured) from the device values in general.
(This is only possible after the "chad" tag has been
introduced.)
but the old specs likely did not communicate the intention of the ICC
clearly enough.
The ICC white paper referred by Marti
http://www.color.org/ICC_white_paper_6_v2_and_v4_display_profile_diffrerences.pdf
basically only mentions the ambiguities arising because the V2 spec does
not specify the adaptation state of the observer for self-luminous
devices. But it does not say for instance, that the encoding/meaning of
the mediaWhitePointTag or the meaning of ICC-absolute intent would have
changed from V2 to V4. Wouldn't it be noteworthy to mention it in this
white paper, if their intended meaning had really changed?
Applied to the sRGB profile IMO this would imply:
Since the 1998 sRGB profile records D65 in the "wtpt" tag, it obviously
assumes an "illuminant" of D50. This is strange (why should the observer
of the sRGB monitor be adapted to D50 instead of D65?), but it is not
prohibited according to the old specs, since they did not tell how do
deal with illuminant/media color for self-luminous devices.
Since the asumed illuminant is already D50, the chromatic adaptation
from the device illuminant to the D50 PCS illuminant in step (1) becomes
a no-op, and the conversion of the measurements to PCS involves only the
media-relative encoding in step (2). IMO, here the 1998 sRGB profile
violates the spec, by using a Bradford transformation for the
media-relative encoding, instead of using a wrong von Kries
transformation. For step (1), any arbitrary linear CAT method is
allowed, but for step (2), a wrong von Kries transform is IMO required
by the ICC spec.
Though a V2 profile w/o "chad" tag does does not allow to compute the
"real absolute" XYZ values from device values in general, it
nevertheless works with this particular profile, using ICC-absolute
intent (even with "illuminant relative" meaning), because a D50
illuminant was assumed for the device.
The new 2004 sRGB profile on the other hand now assumes illuminant =
monitor white = adapted observer whitepoint = D65, and media color =
perfect diffusor, and thus also records mediaWhitePointTag=D50 in the
profile (as it is now defined in the V4 spec).
Since the illuminant is now D65 (i.e. != D50), the CAT in step (1) is
not a no-op, and the profile maker can use any desired linear CAT method
(e.g. Bradford, CAT02, ...) for this step, without violating the spec.
On the other hand, now the media-relative encoding now becomes a no-op.
Since a "chad" tag is present, it is also possible to recover the CAT
which was performed in step (1), and to compute the "real absolute" XYZ
values from device values.
Regards,
Gerhard
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user
