[Openicc] New options on the mainline

[Kai-Uwe Behrmann]

Am 21.01.08, 14:31 +1100 schrieb 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.

Would the later mean to target at the proofing device?
 
> 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.

Yes, just correct for lighness deviations and ignore the CIE*ab 
components.

> 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

You refere here to the relative versus a absolute calibration target?

> several target curves for different set-ups, and needing only
> one calibration measurement.


You have rolled out aspects I did even not consider they exist.

kind regards
Kai-Uwe Behrmann
--
developing for colour management 
www.behrmann.name + www.oyranos.org