Re: Camera profiling with ICC et al
Re: Camera profiling with ICC et al
- Subject: Re: Camera profiling with ICC et al
- From: Graeme Gill <email@hidden>
- Date: Tue, 16 Sep 2008 12:16:39 +1000
email@hidden wrote:
Here is the reference in 6.2.1:
"In transforms for the media-relative and ICC-absolute colorimetric intents,
the PCS values may represent a colour rendering of the actual original
captured for input profiles. "
This is actually a reference from the v4 spec which was intended to clarify
then-current v2 practice and better define proper profile behavior.
Hi Eric,
No, sorry, I don't find this an acceptable reference. To call it a
"clarification" is (to my mind) simply mischievous of the ICC, since
the V2 spec. was clear and unambiguous (see my previous email) about
the basis of the colorimetric information, and the intent
of matrix based profiles. This all too similar to the
change made to the L*a*b* PCS encoding between V2 and V4. It's
simply poor practice to try to make a retrospective change to
an established standard under the guise of it being a "clarification",
and worse than this, it make for a poor standard.
The ICC profile standard has been criticized quite a bit for being
fuzzy about what perceptual and saturation intent tables contain,
but at least there was the bedrock of the colorimetric table
(putting aside the display white point handling fiasco of course!).
To now take that ground out from under the standard with the the
possibility of colorimetric being a rendering of the device
behavior is simply awful I think. And while the passage you
quote is specific in allowing this for input devices, when
I pointed out that the V2 sRGB profiles being offered in
the ICC web site include some rendering transforms in their
colorimetric model, which is contradictory to the V2 spec,
Jack Holm implied that the above V4 "clarification" was also
applicable to display profiles, so that flare as seen
by the viewer could be taken into account! The V2 spec. is
explicit that the colorimetric information be flareless.
The result of now allowing rendering changes to the colorimetric
model is that (since such rendering is vendor and situation specific),
the profiles cannot be independently verified, nor accurately re-purposed.
I can readily sympathize with the camp (WCS) that ditched the ICC profile
format, and started again with a firmer, instrument measurement base.
produce scene-referred colorimetry. And you are absolutely right, this attribute
of the ICC spec is poor. We wanted the CRI to be sacrosanct, but practice
proved otherwise. In the absense of the image state tag, in the general case, we
really don't know what's in the CRI, and whatever you assume, there is a good
chance you will be wrong. So now we have the image state tag to clue apps and
cmms whats really in the CRI.
It seems to me then, that (once again) the ICC have proceeded in an
unfortunate direction. If keeping CRI a solid, verifiable set of
numbers was important, and if the practice is out of alignment,
then it should be brought into alignment (the ICC format is a standard
driven one, not a canonical implementation driven one. To give precedence
to some implementations over others by changing the spec. to suite
what they happen to implement is simply unfair, and bad practice IMHO).
If there are very good reasons why practice was out of alignment with
the spec., then it seems that the problem is that there is a missing a
"slot" to place such a rendered colorimetric model, and the correct
solution is to create a slot, and label it appropriately, not
attempt to retrospectively change the standard and re-purpose
the colorimetric intent.
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