Thanks, Graeme for digging into this. It will make CMYK-profiling easier reducing guesswork and iterations. 2010/1/18 Graeme Gill <graeme@xxxxxxxxxxxxx>: > I think this is more of a bug than expected behavior. The > curve smoothing filter isn't being forced to transition to the > start level at white, and the filter may be overly broad. > Without the smoothing filter you will get an unwelcome > transition as the black suddenly to kick in though. Yes, alright. > After much hacking to do the filtering another way, as well > as reducing the width of the filter, I get the following: > > 90.000000 0.000000 0.000000 [Lab] -> Lut -> 0.113345 0.082260 0.088403 > 0.019597 [CMYK] > > but this is right at the transition point, so with smoothing it is > expected that it not be zero. K=1.96% much better. However, in my liking, smoothing would start at the transition point not before. > 98.000000 0.000000 0.000000 [Lab] -> Lut -> 0.023747 0.016865 0.018471 > 0.001763 [CMYK] Ok, less "smoothing width". > A workaround might be to move the start transition up a bit more (say 0.15), > and reduce the curve shape slightly to compensate. Yes. > That seems to be a function of the -L98. Try -L96 for instance, > and it flattens out (I would guess this is due to the fwd cLUT cell > based interpolation of the ink limit values introducing an > inaccuracy, or some other unknown bug). It's nothing to do with the > target black curve shape though. Yes, I tried -L95 and enle=.95 before and the curve was ok and thought the issue I had was gone. Then I tried 98... Even if -kp was perfect I think the features I suggested would become nice alternatives. Inputting a function or sequence, like -kf resp. -ks, K generation would almost be in the hands of the user (depending on node frequency in -ks). Still, there would have to be some limitations I guess. Resulting K should not override output neutrality. Martin Weberg