[Openicc] New options on the mainline

[Kai-Uwe Behrmann]

Am 20.01.08, 11:28 -0800 schrieb Hal V. Engel:

> On Sunday 20 January 2008 10:58:15 Robert Krawitz wrote:
> >    Date: Sun, 20 Jan 2008 19:30:00 +0100 (CET)
> >    From: Kai-Uwe Behrmann <ku.b at gmx.de>
> >
> >    About exporting the current calibrations: from the previous post
> >    I'd guess most parts are already somehow available through a
> >    interface. How much work would it be to make a small tool to export
> >    the Uncorrected curves to something readable? I could help on
> >    transforming say integer or double arrays to the above mentioned DL
> >    profiles inside such a tool. With the tool, I'd guess, the
> >    Uncorrected mode is not that much desired to keep stable across
> >    releases. Uncorrected still remains as a good starting calibration.
> >    The created DL profiles would not at all know about device
> >    states. So this part remains open. I would later connect this as
> >    well, i.e. make the DL knowing about the Gutenprint options.
> >
> > Right now there's no straightforward way to extract those curves --
> > they're not generated until very late in the initialization process,
> > and the GCR curves are computed in a different module from the other

GCR involves already Rgb to Cmyk conversion. I thought more of 
linearisations, i.e. one curve per colour channel.

> > color curves.  But it would be worthwhile to figure out how to do
> > this.

In which file is the struct described?

> > The format I would dump them out in would be either the Gutenprint XML
> > curve format, or as a dump of the internal lookup table structure
> > (probably just the curves), which itself would contain a collection of
> > curves.  But I'm open to other suggestions.

Internal lookup table structures (curves) are probably more convenient. So 
I'd not need to reparse xml.
 
> Robert,
> 
> When I looked at trying to linearize my printer a few weeks back what I wanted 
> was to start with the existing curves and to be able to apply a correction to 
> that curve.  The problem of course was the UI does not make that curve 
> available and there was no way to get this without resorting to making API 
> calls to the GutenPrint driver and even then it was not clear from the API 
> docs that these calls are really what I wanted.

We will see those task several times. As they are not Gutenprint specific, 
it would make sense to handle them in a separate project. At the moment it 
is unclear who takes over this task.

> 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.  Once 
> there was such an API exposing it in a UI so that users could hand enter a 
> set of correction values would be a good starting place.  For example the 
> QuadTone RIP Eye-One-ReadMe document shows a set of examples based on taking 
> a set of measurements of a 21 step gray ramp (this is a B&W RIP) and then 
> loading this into an application called QTR-Linearize-Data that analysis 
> those measurements and gives a result something like:
> 
> LINEARIZE="96.55 92.14 86.45 81.02 75.65 70.55 64.85 59.60 54.62 50.06 45.73 
> 41.99 37.63 33.91 30.95 27.75 25.01 21.80 19.84 18.43 16.95"
> 
> The user then takes this data and drops it into the QuadTone UI and tells it 
> to use these measurements to correct the printers output.  The data above is 
> nothing more than the L* values from the measurements.  We already have the 
> tools to make similar sets of measurements and to create similar data sets.  
> Of course the real issue is what would the GutenPrint API do with these 
> measurements to make the linearization corrections?   

My impression is to keeping such stuff outside of Gutenprint makes 
completely sense. The curves can easily described in ICC profiles. It 
would be up to early colour binding applications or the print system to 
select and chain the according profiles (calibration + final profile). We 
could certainly assist in creating or teach in using the appropriate 
tools.

> Anyway I thought that I would through this out there to see if this sort of 
> thing was possible.  I suspect that long term what it does should be based on 
> some standard that tries to establish an ideal set of curves for each 
> channel.  This might be based on something like G7.

Would it make sense to you to support the provided G7 targets?

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