Klaus Karcher wrote:
Now I have a question regarding black generation (Singular Value Decomposition):
Converting one of my favorite gamut mapping test images (the hull of a RGB Cube) to CMYK,
I've actually just written a program to generate such test images, so that I could play with the resolution and pixel depth, as well as generate non-surface versions of the chart. It will be in the next release ...
result looks smoothly and coherently, viewing each canal separately shows a undulating surface.
I've noticed that, but assumed it was to do with the limited resolution of the CLUT grid. Your example makes the effect more obvious though.
I've made a web page to illustrate this: see http://digitalproof.info/argyll/k-test/
The only way to avoid the problem seems to set black generation to zero or max -- increasing the quality parameter only reduces the wavelength of the oscillation and using profile's new "-r" parameter or varying the "smth" variable in gammap.c seems to have almost no influence on the issue.
This is consistent with it being related to the limited resolution of the CLUT grid (although I'm not sure which grid, the forward, the gamut mapping, or the reverse one. It might even be a "beat" between the two of the grids. It would take a little work changing each grid resolution independently to pin this down)
A handwaving explanation might run along the lines that it is inherent in the limited precision dictated by interpolated grids in the forward and/or reverse tables. (I seem to remember noticing that this effect was less when you went further into the gamut, but I can't confirm that at the moment.)
Now whether it is actually as good as possible, is harder to answer. My guess is that it is not optimal, in that the "bumpiness" could in theory be minimised in some fashion by a different black locus between each "ridge". The question is what is really the cause of it. Is it something to do with how the black locus value is computed (as a proportion of the min or max possible K values ?), or is it something to do with the linear assumption within each cell not tracking the actuall visual result ? Notice that bumpiness is only revealed easily when you examine the K separate from the CMY, the CMYK combination is quite close to the target color. I think it would take a detailed analysis of what's going on along a particular locus down the the surface to point to an answer to this. I suspect it is desirable to reduce this artefact, because it will then make the separation more robust, in the face of device behaviour change, or profile inacuracy.
Therefore I think the root of the problem must be somewhere in the svd code. Do you have any hints on how it can be amended?
The SVD code doesn't do anything very complicated in principle. It returns the closest mathematical solution possible given the interpolated table representation of the forward device characteristic, so I would be looking first at what numbers it is being fed with, to see if there is an explanation there.