Hi Joris,
Ok, here we go.
> 1) Is this kind of profile typical for profiles
> embedded in images?
Yes. Typical on RGB, but not the only one. As said on other spaces, profiles
are different.
> Are there any other kinds used for this purpose? I.e., when I'll
> be able to apply this type of profile, is my job decoding images
> properly done?
There are many others, CLUT-based on both v2 and v4 flavors. And each one in
8 or 16 bits. v4 profiles may have a very complex pipeline.
> 2) It is clear to me that this is the TRC/Matrix type of profile,
> but it is not clear how exactly my code should come to that conclusion.
Real world is even worse, since some profiles may contain both, CLUT based
AND matrix-shaper. On such profiles, CLUT tags takes precedence. In general,
on gray and RGB, you have to check if an AtoBxx tag is present, if so it
takes precendence. Else, the profile is matrix-shaper if it is not a named
color one. Sorry for sounding such arcane, but that is how it works.
> Should my code treat profiles as belonging to this type on the basis of
> the presence of certain tag (XxxMatrixColumn and XxxTRC tags), or should
> it also double-check the profile class is 'Display Device profile', or
> something else/additional still? As a general rule, how are the different
> (application-centered) types of profile recognized?
As said, a profile may hold xxxMatrixColumn and be not a "true" matrix
shaper. Some profiles uses matrix only on reverse direction. The profile
class may help, but in this specific usage is not such important. Any
embedded profile may be input, display, colorspace or output. I have even
seen named color profiles embedded in specific TIFFs with additional
Pantone planes.
> 3) Is my understanding correct that, as far as application of this
> profile is concerned, I can safely ignore the MediaWhitePoint tag?
The media white point should be only used in the absolute colorimetric
intent... and this introduces another variable into the equation, the
rendering intent. So, the question would be what kind of color
reproduction do you want on the output? If perceptual, the media white
point is not of your interest.
> 4) My current profile application code converts the RGB flavor in
> the file to D50-based XYZ by applying the (TRC convertion which is
> optimized away in this case and the) matrix convertion. Problem is
> though, the rest of my library thinks 'along' the D65/sRGB/Lab
> 'axis'. As a temporary measure, my code simply ignores the fact that
> the resulting XYZ is D50 based, and converts it to sRGB as if it were
> D65-based XYZ instead. Naturally, the results are *almost* fine. In
> my search for the missing link, I keep stumbling upon such magic
> formulae like 'chromatic adaptation' and 'bradford'. But both the
> maths and the theory are totally beyond me, sofar, and I'm not even
> real sure that I'm looking in the right places... I realize it may
> be a lot to ask, but could anyone provide
> (a pointer to) a clear, step by step insight in the process?
Yep, many time ago I wrote this page, maybe would be useful to you:
http://www.littlecms.com/bradford.htm
But the profile has the chromatic adaptation already embedded on the
profile. And since you have to actually apply *two* profiles, one for input
and another for output, the chromatic adaptation is already done for you
by the profile. But this only applies to certain profiles.
Regards,
Marti.
-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user
