[Openicc] ALL YOU NEED IS A PROFILE, THE MYTH. (WAS CC Profiles In X Specification and dispwin)

[Graeme Gill]

Robert Krawitz wrote:

> Yes, but we need to handle these cases.  The simple channel splitting
> model for light channels has some limitations; I suspect, for example,
> that the hue and saturation doesn't perfectly match. 

In general they don't. That's why you have to use a crossover
to move from one ink to the next. The crossover smooths the saturation
and hue change to the point where the (coarser) profile can account
for it.

 > Then there's the
> whole issue of ink limiting. 

The print processing part only needs to cope with the per channel
limits. Combination limits are best handled by the profile.

 > You also missed the drop size issue.

It should just be part of forming the channel response. A particular
channel response will be composed of the dot schedule chosen, the screening,
the light ink crossover, the per channel ink limit and the linearisation curve.
A particular printer, paper and "quality" setting will involve determining all of these.

 > For black ink, sometimes the light inks
 > have a significant hue and the darkest black is neutral.

You'll have to explain in more detail what the issue is. As long as
the black channel response doesn't change abruptly, then it doesn't
matter that it's not quite neutral - the profile will account for it.

> The way we do CMYKRB (it extends to additional inks) is to convert to
> HSL, and pick the right combination of color inks from the hue (we
> don't use the auxiliary inks in gray/black generation).  It's not all
> that scientific; it kindasorta works, but I'd like to do better.

I've had less experience in this particular area, but the profile
approach to this is to encapsulate the separation step in a device link,
and then form the contents of the link off line using whatever
means you would like to apply. The print pipeline can then remain fixed.
My experience was that the hue angle separation approach sort of works, but
doesn't necessarily produce the optimal result. It's a hard problem to solve
optimally for reasons I won't go into here, but it needn't impact the
print pipeline.

Graeme Gill.