[argyllcms] Re: ArgyllCMS V1.1.0 RC1 is now available
- From: Gerhard Fuernkranz <nospam456@xxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Mon, 09 Nov 2009 02:44:18 +0100
Alastair M. Robinson wrote:
> Hi :)
> Nikolay Pokhilchenko wrote:
>> I completely agree with Alastair.
>> Graeme, I suggest to include the inverted calibration curves into
>> profiling process and compute wither ink limit reached or not with
>> backward conversion of linearization. By such way the limits can be
>> truly physical and real amount of inks can be accounted.
> I think Graeme said once before that he already had hooks in place in
> preparation for handling that.
If I understand the code in function icxLimit() in xicc/xlut.c correctly
then version 1.1 already does honor the calibration curves (if there are
any present in the 'targ' tag of the profile) when calculating the TAC.
But in order to end up with the desired results, I suppose that the
color space being calibrated must be the printer's/driver's raw "linear
ink amount space" (i.e. a color space with a linear relation between
colorant values and the laid down ink amounts).
> However, when working with inkjets there's an additional gamma
> adjustment required - outside the regular calibration path.
Why necessarily an _additional_ adjustment? Why not directly calibrate
the printer's/driver's raw "linear ink amount space"? The calibration is
basically supposed to do any necessary gamma adjustment anyway (and if
this happens not work yet (e.g. in case of quite large dot gain), then
I'm sure Graeme will fix it).
> Normally it's buried inside the printer driver, but with enough
> control over the driver (which we have with Gutenprint) it doesn't
> have to be.
That's what I mean above. And for closed-source drivers the actual ink
amounts for given colorant tuples are possibly unknown anyway and cannot
be easily determined.
> Ideally this additional gamma adjustment would be brought into the
> calibration path, because of the implications it has for ink limiting.
> But failing that, taking it into account alongside the calibration
> curves when computing patches' coverage would help.
E.g. in case of multicolor printers driven via CMYK I could imagine that
the driver may no longer be able to provide a linear relationship (with
fixed coefficients) between the given CMYK tuples and the total amount
of the differently colored inks laid down on the paper. Then possibly
even a 4D LUT may be necessary to describe the ink amount as a function
of the given CMYK tuples. Sure, multicolor printers should possibly
rather be driven by multicolor profiles, but colprof is currently
limited to CMYK (or RGB).
Regards,
Gerhard
Other related posts:
