[argyllcms] Re: request colprof black generation

  • From: Graeme Gill <graeme@xxxxxxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Mon, 18 Jan 2010 16:24:57 +1100

Martin Weberg wrote:
Ok. I'll run an example using 1.1.0.

colprof -kp 0 .1 1 .98 .5 -l300 -L98 FOGRA39L

icclu -ir -fb FOGRA39L.icm
From -kp stpo=.1 I expect 90 0 0 [Lab] -> K~0-1% and get:
90 0 0
90.000000 0.000000 0.000000 [Lab] -> Lut -> 0.102880 0.074649 0.080666
0.034677 [CMYK]
K=3.47%, too much.
Trying 98 0 0 [Lab]:
98 0 0
98.000000 0.000000 0.000000 [Lab] -> Lut -> 0.020894 0.015157 0.016418
0.005429 [CMYK]
K=0.54%, transition already started.

Hi Martin,
    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.

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.

98.000000 0.000000 0.000000 [Lab] -> Lut -> 0.023747 0.016865 0.018471 0.001763 
[CMYK]

100.000000 0.000000 0.000000 [Lab] -> Lut -> 0.000018 0.000013 0.000014 
0.000001 [CMYK]

A workaround might be to move the start transition up a bit more (say 0.15),
and reduce the curve shape slightly to compensate.

Having -kp enpo=1 and enle=.98 (shape=.5) I expect a continuous
concave curve up to K~98% where it ends. Instead the curve bends just
before ending. To me, this bend before the end is not consistent with
-kp enpo=1.

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.

"Wide" is definitely what most people want "out-of-the-box" I guess.

I'd imagine so, and it tends to reduce errors at the dark boundary surface
because it matches what's needed for maximum gamut.

[I've uploaded the source changes to 
http://www.argyllcms.com/Argyll_dev_src.zip,
 although only xicc/xlut.c and xicc/xicc.h have changed, for those compiling 
from
 source.]

Graeme Gill.

Other related posts: