[Openicc] New options on the mainline

[Graeme Gill]

Hal V. Engel wrote:

 > I think that what is really needed is an API that allows for applying a
 > correction curve to the existing base curves.  I believe that this is how
 > most RIPs operate but I really don't have any experience with them.

It depends how much the calibration is an add-on, or whether it is
fundamental to the pipeline. If one were starting with a blank sheet,
then really there should only be one curve needed for each channel.
More interesting questions are things like how the target response
should be established. What response attribute, and should it
be relative or absolute ? The former is good for "pretty pictures",
and getting the maximum gamut for a given printer. The latter allows
for matching different instances of printers, and is better things like
proofing, but the trade off is reducing the target to be the common
denominator gamut.

My current favourite idea for linearizing each channel would
be to measure the L*a*b* for a step wedge test chart, and then
linearize with respect to the distance along the response locus.
This evens out the delta E change for a change in the channel input.
Such an approach may be a little hard to compute, and makes it
hard to clip non-monotonicity, so a slight compromise
would be to fit a straight line to the response points (least
squares), and then measure the delta E projected onto that
line.

As for file formats, I personally prefer the CGATS text format,
although it is a little inflexible for some purposes, but it
is widely accepted in the color community, and is easily parsed
into standard databases and spreadsheets. There is an XML
version of CGATS I understand, although I don't particularly
like XML since it seems to be the worst of both worlds:
text based therefore bulky and slow to parse, but
sufficiently complex in most cases that it's not easily
human readable!

One simply links the target response curve with the inverse of
the measured response curve to arrive at a device to device
per channel transform that is the calibration curve. Often
it's better to store the device response as the "calibration" and
compute the actual transform on the fly. This permits having
several target curves for different set-ups, and needing only
one calibration measurement.

Graeme Gill.