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 output curves. Graeme Gill.