[Openicc] New options on the mainline

Hal V. Engel hvengel at astound.net
Sun Jan 20 13:19:02 PST 2008


On Sunday 20 January 2008 12:24:33 Kai-Uwe Behrmann wrote:
> Am 20.01.08, 11:28 -0800 schrieb Hal V. Engel:
snip
> >
> > 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.

I was mostly trying to layout some "user" expectations in this specific area.  
That is a user would expect to be able to generate and print some type of 
linearization target that was correctly laid out for his/her 
spectrophotometer.  Then, either from the linearization software or 
externally, measure it and that this data would (after being entered into the 
linearization app if it were measured externally) result in the appropriate 
corrections being made to the ink curves.

At first this could be very basic and could even be a set of command line apps 
to do a series of steps to get the job done.  For example, ArgllCMS could be 
used to generate and then measure the linearization targets.  The resulting 
CGATS measurement file could be used as input into the linearization app 
which would feed the resulting curves back into GutenPrint.  Once this was 
working we could start building a GUI around this and eventually end up with 
a nice fairly easy to use system.

I do agree that this could be totally external to GutenPrint or it could also 
be part of GutenPrint or some combination of these.  From a user point of 
view where the separation takes place is not very important as long as things 
work.  But you are right that having this be external to GutenPrint would 
allow it to work with other drivers if those drivers exposed the needed 
interfaces.

I also think these tool need to support the work that goes on when the 
GutenPrint team developes the initial set of ink curves.

>
> > 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?

I am not sure what you are asking.   But it would be possible to use LProf's 
SourceForge facilities such as CVS/SVN to support something like this.  It 
might even make sense to have this interface be an extension of LProf since 
it already has things like a UI for selecting and configuring meters and 
longer term LProf will have facilities for generating and reading printer 
targets.  Currently we are focused on display calibration and profiling work.  
But I don't think we can take this on unless there are new volunteers who can 
take on the added work load and I think that we would need someone to take on 
the lead role for this effort as well.

Hal


More information about the openicc mailing list