Gerhard Yes, there is no reasonable number of gridpoints that would make exact match. However, a prelinearization of 258 entries, would map 0xFF00 on entry 257. This is almost what we need, unfortunately, the rest of entries should be scaled by (255*257/256) and this is not exact.
An intermediate solution would be to use 257 entries. This does not map 0xFF00 exactly on a node, but so close that the dE induced is negligible. AND the rest of curve is exact: 0x0000 0x0101 0x0202 0x0303 0x0404 .. 0xFEFE 0xFFFF 0xFFFF. Note two 0xFFFF at the very end. Value 0xFF00 would be mapped on entry 255.00389, which is *very* close to entry 255. Oh, well, this is going too arcane. Just to prove that would work, I've put an early snapshot of my development sources here: http://www.littlecms.com/lcms_1.14_snapshot_aug_4_2004.zip It includes this Lab prelinearization, and some other fixes. Obviously, this is NOT aimed to be used in production code and I would recommend to avoid it if you want stability. Otherwise it would be fine for experimentation and so. Regards, Marti. ----- Original Message ----- From: "Gerhard Fuernkranz" <[EMAIL PROTECTED]> To: "Marti Maria" <[EMAIL PROTECTED]> Cc: "LCMS mailing list" <[EMAIL PROTECTED]> Sent: Monday, August 02, 2004 9:44 PM Subject: Re: [Lcms-user] icclink accuracy problem Hi Marti, I've also investigated the code in the meantime, and I noticed, that you are using a 48-point grid for "-c2" with three input dimensions. Changing this to an odd number surely does not solve the general problem you explained below, but apparently it did reduce the error for "white" *significanly*. Is my understanding correct, that for an even number of grid points, there are no grid points on the L* axis at all? Best Regards, Gerhard Marti Maria schrieb: >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 > > > > ------------------------------------------------------- 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
