[Openicc] New options on the mainline

[edmund ronald]

On Jan 21, 2008 4:31 AM, Graeme Gill <graeme at argyllcms.com> wrote:

> 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.
I'm not quite sure why one shouldn't just work with densities here,
leaving the colorimetric issues for the profile engine ? Define a set
of target densities for the steps, measure the device with ink
limitation already applied,  and see how the desired values can be
achieved by inverting the measured density curves, display the
measurements and the suggested corrections to the user and allow him
to edit if desired ? At this point we're really working in ink-space
more than in color space. Sorry if this approach is very primitive,
but I think this is what existing RIP engines do. The profile is then
applied to the linearised device and deals with the color, and
implicitly corrects for the notorious hue deviations that occur with
changing ink densities.  And, although I may be wrong, if the device
drifts or one changes the device sample, bringing the device back into
conformance with the desired density curves allows the profile to
function correctly - the profile becomes a transferable resource, so
one can use proprietary software for creating the profile itself. The
latter is useful because some of the proprietary profiling engines do
embody considerable domain knowledge.

Edmund
>
> 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.
>
>
>
>
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc
>