[argyllcms] Re: profile: black generation

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 ...

> I noticed that although the composite view of the
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

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.

Graeme Gill.

Other related posts: