[argyllcms] Re: ArgyllCMS V1.1.0 RC1 is now available

  • From: Graeme Gill <graeme@xxxxxxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Mon, 09 Nov 2009 18:23:15 +1100

Gerhard Fuernkranz wrote:

This applies indeed to the other, gamma-adjusted space presented by the
driver to the user. It certainly suffers from the problem that summing
the colorant values won't sum up the actual ink amounts (but there is a
non-linear relationship). I understand that this is the obvious reason
why you wanted to calibrate the _raw_ space of the halftoning engine
instead.

V1.1.0 colprof takes care of that if the .ti3 ends up with calibration
tables embedded into it, which will be the case if printtarg is supplied
with the calibration using either the -K or -I options. Similarly
collink will take the calibration into account when computing
total ink limits if the profiles it is given have the calibration
embedded in the .ti3 embeded in them by colprof.

dot gain (or extremely high "gamma")), a wedge with linear steps in
device space is likely no longer optimal (but a non-linearly spaced
wedge may be more suitable).

It would certainly be easy enough to add a fudge factor that applies
to the wedge steps to do this type of thing, but I don't think it
substitutes for correct setting of the usable range, which is
something more closely tied to print mode.

But back to the TAC calculation: While for a printer with CMYK inks only
the raw space of the halftoning engine may indeed have the desired
properties (i.e. laid down ink amount proportional to the colorant value
sent to the driver), I'm wondering whether this still applies when light
inks come into the play and the driver needs to separate e.g. the cyan
channel into dark cyan and light cyan. Is the sum of the dark and light
cyan ink amounts still proportional to the cyan colorant value sent to
the driver then? If not, we have lost again...

Currently doing light ink separation is out of the scope of
Argyll, so I haven't created a format to represent the separation,
hence it's not possible to feed that into the ink sum calculations,
but conceptually it would be done in a similar way to the above.

Graeme Gill.

Other related posts: