Gerhard Fuernkranz wrote:
And with Argyll CMS, the new sRGB profile gives me the same results for
relative colorimetric and for ICC-absolute intent:
$ icclu -ia sRGB_IEC61966-2-1_noBPC.icc
1 0 0
1.000000 0.000000 0.000000 [RGB] -> MatrixFwd -> 0.442668 0.232205
0.024054 [XYZ]
$ icclu -ir sRGB_IEC61966-2-1_noBPC.icc
1 0 0
1.000000 0.000000 0.000000 [RGB] -> MatrixFwd -> 0.442667 0.232205
0.024053 [XYZ]
According to the header, the new sRGB profile is a V 2.0.0 profile,
however, its media white point tag records D50 (not D65, but D65 adapted
to D50), and the profile also does contain a "chad" tag.
Argyll's icclib supports ICC V3.4, and this predates the chromatic
adaptation tag.
The confusion in the ICC spec. with regard to all this is something
I noted some time ago - see <http://www.argyllcms.com/icc_problems.html>
and my comments about Annex E.
The basic problem seems to be that the "new" parts of the ICC profile
were written just with print profiling in mind, while the "old"
sections (legacy from Colorsync 1 ?) seem to live in a different world.
It's fine to talk about either measuring a print sample with D50, or
transforming the raw instrument readings with a Bradford type white point
adaptation matrix to make it appear as if it was measured using a D50
illuminant, and then use a straight "wrong Von Kries" to map between
the media white and D50 for absolute/relative conversion when
you're talking about a print sample, but for a CRT, what is
the "illuminant", and what is the "media" ? Because a CRT is
self luminous, the color response can't be characterized separately
from the illuminant, they are one and the same thing. The very widely
used sRGB profile took the approach of assuming that "Absolute" meant
the native response of the device, just as "Absolute" for a print
would be the native reflectance under D50 (note that such a white
point would not necessarily be D50, the paper white can/will change
the illuminants color). To my mind, this makes perfect sense, since
it is only right that there be some way of recovering the
instrument values for a particular device, and not loose such
basic information such as what the actual, real device white point
is. Since print profiles are characterized as reflectance, and most
graphics arts instruments are set by default to measure as if
the illuminant was D50 (whether in fact the actual illuminant is D50
or not), the recovery of values measured under a non-D50 illuminant
is not terribly relevant to most color management tasks.
For pragmatic reasons (mainly to do with working properly with the sRGB
profile),
I decided it was best to use a Bradford type white point transform
for all the absolute<->relative conversions. This gives a good visual result,
works correctly with an sRGB profile, and gives only a very small error with
most print profiles that have been created with a "wrong Von Kries" transform.
All this seemed to work well in practice. Useful absolute values were
recoverable from all profiles, so that Color Appearance Models can
be properly applied, etc.
Since all that, the ICC has introduced the chromatic adaptation tag, and
gone on to make other recommendations in the V4 standard. I haven't analysed
their current suggestions in enough detail to know if they make any sense or
not.
Your experience seems to indicate that far from improving things, things
have got even more confused with the latest changes to the specifications,
as evidenced by the profiles you are working with. It is a big problem
in my book, if there is no certain way of recovering the real, absolute
color response values for a display profile.
Graeme Gill.
-------------------------------------------------------
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
