[argyllcms] Re: 0.60 CMYK profile misshaped

  • From: Graeme Gill <graeme@xxxxxxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Thu, 07 Dec 2006 22:19:52 +1100

Gerhard Fürnkranz wrote:
Is non-monotonicity really a problem? Have you e.g. actually seen
> (CMYK) printers with non-monotonic colorant vs. L* responses?

Yes I have. It was a copier, and we were measuring density,
but it would have looked the same measuring L*.

> I guess
> this would be rather unusual, given the way how halftoning works (if
> one adds even more dots, then the result IMO cannot become lighter).

But anything can happen when there is electronic manipulation going on
(transfer curves, calibration systems, RGB->CMYK separations etc.),
plus some processes have strange effects, electrostatic ones being
notorious for it.

> Sure, colorant vs. C* often reverses beyond the saturation point, particularly
> for C or M, (but the section beyond saturation should not be used anyway).
Colorant vs. a* or b* may indeed be non-monotonic, except obviously for
the yellow channel, but a* or b* is rather not a calibration target
for C, M or K anyway. And I'm not sure, whether the euclidian distance
to paper white does typically reverse at the saturation point of any
colorant too, does it? (but even if it does, I guess it's usually monotonic
up to this point).

In general it's best to cope with non-monotonicity, rather than
simply fall over. The per-color curves must be non-monotonic by
decree - that's what the ICC spec says, but it means that any
non-monotonicity in the devices characteristic has to be modelled
by the 3D Lut. My inversion code is actually designed to return
all possible solutions, and a (hopefully) reasonable one is
chosen, thus dealing with non monotonicity in the 3D Lut.

Actually I'm still a bit sceptic regarding the shaper/matrix/shaper
> optimized curves. In many cases they seem to work very well, but
> I also encountered data sets, where "-ni" or "-ni -no" did result in
> better accuracy.

I think you're right to be a bit sceptical. I'm not convinced they
always do the right thing either. For the particular device in
question the do seem to be shaped in the general way one would
expect for Cyan and Magenta having a bend near the top,
and the self fit with -ni -no was max 11.0 avg err = 1.8,
compared to max 6.7 avg err = 1.5 with the (CIE94 Delta E)
curves turned on.

Or another example: I created a profile from a gamma=1 raw scan
> of an IT8 target. Now I apply gamma=2.2 to the raw scan in an image
editor and create a profile from the brightened scan image again. Ideally,
the difference between these two profiles should be handled by the
prelinearization curves only,

Interesting idea for testing the behaviour.

So I guess that the optimization possibly gets stuck in a local minimum,
either for the 1st profile, or for the 2nd one, or even for both ones.

Yes, I guess that is a possibility. The individual curve shapes don't seem
to get stuck on test cases, but I'm not so sure about the overall case.

Btw I'm wondering, do you actually optimize all oders together from the
beginning, or do you start with 1st order curves, optimize, use the result
as starting point for the next iteration, drop in the next order (additionally),
optimize again, and so on?

It's a global optimization of all the parameters - input curves, matrix and 

Graeme Gill.

Other related posts: