"Mart�_Maria" <[EMAIL PROTECTED]> writes:
> Anyway, you could take a look on icc2it8 source (which I'm emailing
> you). The code is almost same as your, so search for the error
> elsewhere.
Thanks, Marti. I am in a Linux environment, so I did build from the
sources and have been looking through them. The icc2it8.c you sent
seems to be a newer version than what was included in lprof-1.09.
Comparing icc2it8.c and icctrans.c to my code, and doing a lot of
experimentation, I found a few small things:
In icc2it8.c, GenerateForward() and GenerateReverse() you do:
cmsTakeMediaWhitePoint(&WhitePoint, hProfile);
and:
cmsXYZ2xyY(&WPxyY, &WhitePoint);
But the variables WhitePoint and WPxyY are never used. The
cmsTakeMediaWhitePoint() doesn't seem to have any "side effects", so
is this just dead code?
Also, in my code, I found a slight numeric difference in results
between doing:
cmsDoTransform (lab_trans, rgb, lab, 1) ;
cmsLabEncoded2Float(&lab_float, lab) ;
and:
cmsDoTransform (xyz_trans, rgb, xyz, 1) ;
cmsXYZEncoded2Float(&xyz_float, xyz) ;
cmsXYZ2Lab (NULL, &lab_float, &xyz_float) ;
The former is similar to what you do in icctrans.c; the latter is
similar to icc2it8.c.
Finally, there should be no difference between:
cmsHPROFILE srgb_icc = cmsCreate_sRGBProfile() ;
and:
cmsHPROFILE srgb_icc
= cmsOpenProfileFromFile("sRGB Color Space
Profile.icm",
"r");
correct?
> Perhaps you are choosing the RGB values of your image arbitrarily?
> Don't do that... Lab values of targets are carefully chosen and fine
> tuned.
I worked from the following description I found in a Kodak PDF file:
... targets are based upon a similar concept that uses twelve hue
angles (rows A-L) and three lightnesses at each hue angle.
At each hue angle and lightness combination there are four chroma
or saturation levels. The first three of these at each lightness
level (columns 1-3, 5-7, and 9-11) are specifically defined in the
ANSI and ISO standards and are referred to as the common gamut
area. The values of these patches were based on film and paper
color gamut information provided by Agfa, Fuji, Kodak, and Konica.
The patches are defined such that they are able to be produced on
all the sensitized products included in the gamut comparison. The
fourth chroma (columns 4, 8, and 12), represents the maximum
chroma (colorfulness) that the specific product can produce at
that hue angle and lightness level.
Columns 13-19 contain cyan, magenta, yellow, neutral, red, green
and blue scales which are characteristic of the target dye set.
The neutral scale is defined to begin at neutral D-min and end at
neutral D-max in 12 steps with equal lightness (L*) increments.
The cyan, magenta, and yellow scales are based on the amount of
each of those dyes contained in the column 16 neutral scale. The
red, green, and blue scales are combinations of the cyan, magenta,
and yellow scales as appropriate.
Across the bottom of the target, there is a 22 step neutral scale,
bounded by a patch representing product D-min on the light end and
a patch representing product D-max on the dark end of the scale.
Steps 1 through 22 are defined as neutral, with lightness (L*)
values specified in the standards documents.
> I tell you the icc2it8 stuff because it could be a great debug tool.
> Just compare the RGB of values obtained by icc2it8 and those in your
> synthetic image. If they don't match, then the error is there.
This seems to be the secret. If I use the EmulatedRGB table of
patches from icc2it8.c, converted from sRGB to L*a*b*,
qtscannerprofiler converges to a good profile. If I use a real,
scanned IT8.2 target and its matching L*a*b* values, it also works.
> since XYZ -> Lab is done using D50 and this is not the case of sRGB,
> which has D65 as whitepoint.
Using any other set of RGB patches (including those from a real
target) converted from sRGB to L*a*b* doesn't work. Is this D50 vs.
D65 mismatch the reason why?
Or do the patch RGB and L*a*b* values have to be in a specific region
of their respective colorspaces for the LCMS profile generator to
converge? At failure, qtscannerprofiler reports:
Gamut hull: 132 inside, 0 outside, 156 on boundaries
*** WARNING: Inconsistence found, profile may be wrong. Check the
target!
Global regression: 4 terms, R2Adj = 0.562325
Extrapolation: R2Adj = 0.562325
The Kodak paper says:
In addition to the areas of the target which have specific ANSI
definitions, columns 20-21 were left undefined for each
manufacturer to include information which might be beneficial to
the end user.
(It's actually "columns 20-22".) Do you ignore these extra patches?
Even in columns 1-19 and the grayscale strip, aren't all targets
slightly different depending on the characteristics of the media on
which they're made?
I would think that the more (correctly matched RGB to L*a*b*) patches
available, the better (though more difficult) the profile generation
would be.
I hope all this theoretical discussion is interesting to other readers
of the list. I do have some practical questions about profile
generation workflow which I may post later.
=====
--
MARK
[EMAIL PROTECTED]
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Lcms-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/lcms-user
