[Printing-architecture] [Gimp-print-devel] [Openicc] Looking ahead to 5.3

[Hal V. Engel]

On Monday 20 October 2008 17:26:49 Robert Krawitz wrote:
>    From: "Hal V. Engel" <hvengel at astound.net>
>    Date: Mon, 20 Oct 2008 14:03:25 -0700
>
>    On Monday 20 October 2008 09:37:40 Michael R Sweet wrote:
>    > If we
>    > also want to profile the individual color channels and modify the
>    > RGB-to-DeviceN and CMYK-to-DeviceN mappings, I recommend having a
>    > printer command (using the same interface we add for status
>    > monitoring and head alignment) that prints the linearization target(s)
>    > instead, with enough parameters to satisfy Robert. :)
>
>    This would be ideal but would require some work by the driver suppliers.
>
> Right -- and that's what we (Gutenprint) need requirements for.

I wish I had more expertise in this specific area so that I could provide 
those requirements at some level of detail.  I think for the most part that 
the GutenPrint Epson drivers are now well positioned for this but I don't know 
that for sure.  I know that Graeme Gill started working on a set of utilities 
to create linearization corrections but I think he got side tracked with other 
work.  Graeme at one time worked for a RIP vendor and he is the open source 
subject matter expert in this area. 

>
> Actually, for printing linearization targets you really don't want any
> of the fancy options.  The elaborate options are more for unmanaged
> environments or for people who have funky inks or papers.  You'd use
> Raw or Density color correction mode, either with CMYK or DeviceN
> input (which is also confusingly enough called Raw, but in a different
> context).
>
> We currently have a test pattern generator that can do a lot of this
> stuff, but it could also be done through the CUPS interface.
>
>    > I'd then also suggest that we add support for user profiles and/or
>    > drivers, such that a user could "install" XML files that would be
>    > "merged" with the standard/base files included with Gutenprint to
>    > determine which drivers, media types, ink sets, etc. are available.
>
>    Clearly something like this is needed both to support the
>    calibration and profiling process and to expose this in the UI and
>    to allow admins to control printer setup for users.
>
> We do have STP_DATA_PATH.  It won't really let you merge data in quite
> this way; you'd have to copy the file from the system path into the
> user path.  Then there's the matter of getting the PPD files in sync
> with this (you might add new media types to the customized data file),
> and getting an arbitrary file through CUPS somehow.
>
>    > All that would be necessary after that would be an application
>    > that prints the targets, measures then, generates the profiles,
>
>    We already have much of this for the ICC profile part but we
>    currently do not have anything for handing the
>    calibration/linearization part.
>
> This seems to be one of the sticky areas.

Agreed but there is lots of other work to be done to get the printing work 
flow to use ICC profiles.  Since this should be the highest priority CM 
related printing project I think that we should not be too concerned about 
calibration/linearization issues until that is in place.

>
>    > and
>    > installs them so they can be used by Gutenprint.  (Yes, I am aware
>    > that this is probably the most difficult part of the
>    > implementation...)
>
>    Yes It is probably the most involved part of this and I think it
>    will be some time before we can tackle the
>    calibration/linearization part of this.  I think the focus should
>    be on making the printing work flow and UI function correctly with
>    RGB and CMYK ICC profiles since we already have software to handle
>    the creation of these profiles and to implement
>    calibration/linearization and device-N support after basic ICC
>    profile support is in place.  I think it should be possible to have
>    this all working correctly with ICC profiles, at least with
>    development versions of the various software systems involved, with
>    in the next 6 to 12 months.
>
> That sounds like you're taking a longer-term view about Gutenprint and
> aren't looking for any short-term changes.  Is that correct?

From a color management perspective that is correct.  I think the current 
focus should be on getting the rest of the printing work flow so that it uses 
ICC profiles in the *toraster filters (at least with PDF input files).  This 
would make basic CM ubiquitous and driver independent.   That would still 
leave lots of related work for those that support the drivers.  For example, 
as ICC profile support was being added to the printing work flow printer 
vendors and driver authors would need to think about things like what default 
ICC profiles would ship with the drivers and issues related to this with PPD 
files, for example incorrect paths for cupsICCProfile settings, would need to 
be fixed.   

On the other hand there is no reason that work on instrument driven 
calibration/linearization couldn't be going on in parallel since these are not 
dependent on each other and in the end we do want both capabilities.  But I 
think this is a lower priority. 

Calibration/linearization would involve work at the driver/GutenPrint level 
but it sounds to me like the work that was done on the Epson drivers to make 
things data driven rather than hard coded has positioned those drivers to make 
that work possible although there may be more things that need to be done.  
It also sounds like this same work needs to be done with other GutenPrint 
drivers like the Canon driver.  Perhaps getting all of the drivers into the 
same state should be the current focus of GutenPrint with respect to color 
management.  

From my point of view I want to avoid trying to take steps that are so big 
that it causes significant resistance (IE. I don't want to overwhelm the teams 
working on the printing related stuff) and I would like to see this broken 
down into a series of smaller easier to accomplish steps that each build on 
the previous steps. 

Hal