Hi Marti,
thanks, it works great!
Your modified prelinearization, combined with an odd number of CLUT points, now gives very accurate results for white. My CMYK values for white are now
0.001275, 0.003570, 0.015045, 0.000000 (for a 0..255 CMYK range). This is far below one halftone-level, so a white page now comes out unprinted :-)
However, with an even number of CLUT points, the accuracy for white is still unsatisfactory, thus the following should be changed as well:
int
_cmsReasonableGridpointsByColorspace(
icColorSpaceSignature Colorspace, DWORD dwFlags)
{
int nChannels = _cmsChannelsOf(Colorspace);
// HighResPrecalc is maximum resolution
if (dwFlags & cmsFLAGS_HIGHRESPRECALC) {
if (nChannels > 4)
return 7; // 7 for Hifi
if (nChannels == 4) // 23 for CMYK
return 23;
new: return 49; // 49 for RGB and others
old: return 48; // 48 for RGB and others
}
Best Regards,
Gerhard
Marti Maria schrieb:
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.
