Hi Gerhard.
I was aware of that problem, which turns to be one of these things that makes ICC
color management seem so complex. Sigh.
The response is: this error is due to particular Lab encoding used by ICC. Really. Oh,
of course there are ways to get rid of it,
but none is cheap or easy to implement.
Lab encoding in ICC v2, is ..*ahem*, well, a bit tricky. Let's take L* for
example. L*, that goes from 0...100, is encoded as
0x0000 to 0xFF00.
Unless the profile is using any sort of matrix or prelinearization in LUT, there is no
number of gridpoints that maps L=100 exactly
on a node.
So, if you are using 17 nodes (as -c0 does), node 17 would be on 65535, node 16 would
be on 61439.0625 and so one. Unfortunately
L=100 falls between node 16 and node 17, exactly on 65280 (0xFF00). So, the CMM must
use interpolation when using this profile to
locate white point. And then... rounding errors makes small deviations from 0.
Unfortunately, this means to drop some ink for pure
white. Same for a*/b*, but worst.
Solutions, well, one would be to fill the diagonal of matrix in the LUT with
0xFF00/0xFFFF, this would solve the L* issue but not
the a*/b* one. Another solution would be to use 16 and 31 points and then use an
offset of 8 in the prelinearization table (this one
is really tricky). But both implies a lot of understanding by icclink on the Lab
centering problem which currently hasn't. I cannot
figure out (yet!) how to solve this problem in a general way, so if anyone has *the*
clever idea that would fix it, please tell me!
Regards,
Marti.
----- Original Message -----
From: "Gerhard Fuernkranz" <[EMAIL PROTECTED]>
To: "LCMS mailing list" <[EMAIL PROTECTED]>
Sent: Sunday, August 01, 2004 10:13 PM
Subject: [Lcms-user] icclink accuracy problem
Hi Marti,
I'm having an accuracy problem with icclink.
I'm starting with a RGB -> CMYK device link, which accurately maps
R=G=B=65535 to CMYK=0,0,0,0.
$ icctrans -w -l CHP410-1200-link-i4-kx.icm
little cms ColorSpace conversion calculator - v1.7
Enter values, 'q' to quit
R (0..65535)? 65535
G (0..65535)? 65535
B (0..65535)? 65535
C=0.00 M=0.00 Y=0.00 K=0.00
Now I generate an output profile from this device link:
$ icclink -x -t0 -c2 -o out.icm \
"*Lab" sRGB.icm CHP410-1200-link-i4-kx.icm
When I check the resulting profile, then it does not map L*a*b* =
100,0,0 to CMYK=0,0,0,0, but to 4.86,1.70,4.87,0.30.
$ icctrans -o out.icm -i "*Lab" -w
little cms ColorSpace conversion calculator - v1.7
Enter values, 'q' to quit
L*? 100
a*? 0
b*? 0
C=4.86 M=1.70 Y=4.87 K=0.30
Basically I had expected that iclink would place a grid point at L*a*b*
= 100,0,0 such that at least white gets mapped very accurately, does it?
Though this inaccuracy is not extreme (approx. 1.5dE), this is a problem
for me, since the consequence is, that the printer prints a very light
shade over the complete page instead of keeping a blank page unprinted,
as one would expect.
Thanks,
Gerhard
-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Lcms-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/lcms-user
-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Lcms-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/lcms-user
