[Openicc] Colormanagement in Gutenprint

[Hal V Engel]

On Wednesday 20 April 2005 05:39 am, Kai-Uwe Behrmann wrote:
> Am 20.04.05, 11:42 +0200 schrieb Jan-Peter Homann:
>
> Jan-Peter,
> thanks for wading though all the details with us.
>

I agree.


> > 1. Integration of littleCMS into Gutenprint
> > --------------------------------------------
> > - The input of Gutenprint is always a  RGB or CMYK Rasterimage with 8 or
> > 16 Bit color depth.

I think that Jan-Peter (please correct me if I am wrong) it talking about what 
the native color space of the Gutenprint driver is for any given device.  In 
other words all of the device specific profiles for a given class or model of 
printer will be of one basic type.  The device may have any number of 
profiles for different media and driver settings but these will all be (RGB 
or CMYK or grayscale) and (8 bit or 16 bit).  The point is to simplify both 
the complexity of the low level device drivers and in particular for users to 
also simplify the process of generating custom profiles.  This does not in 
any way affect what source profiles may be used.
 
>
> Why this limit? The specified input document colour space should allways
> be honored.


I think that Jan-Peter (please correct me if I am wrong) it talking about the 
native color space of the Gutenprint driver is for any given device.  He is 
not talking about the document.image profile(s).  In other words all of the 
device specific profiles for a given class or model of printer will be of one 
basic type.  The device may have any number of profiles for different media 
and driver settings but these will all be (RGB or CMYK or grayscale) and (8 
bit or 16 bit).  The point is to simplify both the complexity of the low 
level device drivers and in particular for users to also simplify the process 
of generating custom profiles.  Again Jan-Peter if I am wrong please correct 
me.

snip

> > Making a good linearization, as basis for good ICC-transformtions needs
> > to steps:
> > 2a. individual linearization of the pure CMYK channels
> > 2b. Inklimiting for a maximum amount of color (GCR)
>
> Does you imaging a on the fly inklimiting profile?

Being able to setup custom linearizations and ink limiting is needed to get 
every last little bit of gamut out of any give printer/media combination.  
But will in all likely hood only be used by a very small number of 
users/organizations.  But it should still be available to those with the 
expertise and resources to implement this level of control.

> > The user should be first able to print a testchart for making 2a.
> > "individual linearization". If this is done, he prints a testchart using
> > the individual linearization curves for step 2b.   "Inklimit/GCR"
> > In the last step he prints the testchart for profiling with active GCR
> > and active individual inklinearization.
>
> This is a multi step preparation. Alternatively she/he can use the inbuild
> Gutenprint linearisations. They are allready of good quality for a lot of
> standard printers.

For many users/orginizations this is how they will operate.  But they should 
not be limited to this.  Also how good the built in linearizations are 
depends on a number of factors that are beyond the control of the Gutenprint 
developers.  For example I may use paper types and/or inks that could benefit 
from custom linearization curves.  I simply can not expect the Gutenprint 
developers to provide for this kind of special case. 

snip 


> Would'nt it suffice to have one linearisation file? The GCR can be
> specified as an option. Maybe you meant it otherwise. Please let
> us know.

I think linearization and ink limits vary with each media and resolution 
combination.  This could depend on the characteristics of the printer.  Again 
it should be possible to users to do both.

snip 

> My suggestion is to include all these setting in one profile. It is, from
> a technical point of view, no problem to embedd all setting in one mother
> profile. Later the settings can be extracted without any installation
> hassles. Simply copy a profile into a standard profile path and select it
> in the gui. No locical printer is needed.
> Of course a logical printer can be installed if one needs it. For instance
> to have a colour managed queue. Which does by default a relevant settings.
>
> For Gutenprint this means; there is logic needed to tell the colour system
> about colour options to include into the profile - the final options used
> during calibration. These options can result in a text snippet describing
> all settings in a configuration format of choice.
>
> Gutenprintgui needs further to read the same data format in (text, xml
> ...) . All colour relevant settings change to the colour options settings
> extracted from the profile and become frozen (grayed out or unavailable).
>
> Later Gutenprint gets the same data again and uses them as options.
>
> The described procedure is easy implementable for the two print plug-ins.
>
> For a general workflow there are two decissions to make. Is it possible
> with the PPD approach to set up all Gutenprint settings? Integrate
> Gutenprint PPDs into these workflow - generate a PPD from one profile or
> leave the options unsplit and dont embedd into a profile. The PPD file can
> contains all sorts of geometric options (papertray selection, positioning,
> margins ...). The complex colour options are specified together with the
> destination profile.
>

Where and how the logical printer configuration is physically stored and 
represented are probably not important at this point.  I think we need to get 
a handle on how this will used and how users will interact with it.  Once we 
have a design at that level we can dive into the implemention details.  

You are probably right that the ppd could be used.  But from my point of view 
at this stag we should be talking about high level requirements and not 
implementation details.  I know most of us are programmers and we like to 
dive into the implementation details.  I tend to do this myself and I have to 
keep reminding myself that we are not at that point yet.   So far I have had 
limited success however.

snip

> Thats completely avoidable. If a system is able to make a difference
> between sRGB and AdobeRGB there is no need to express it with special
> printing queues "logical printer". It will cause irritation to have one
> the one side a colour managed printing system and on the other side the
> applications are not able to specify the source or document
> profile/profiles .
>
> The simple rule to tread everything which is not specified as sRGB is the
> most common acepted.

I agree totally.  I may be wrong, so please correct me if I am, but I think 
Jan-Peter was trying to come up with a work around for the fact that in CUPS 
version 1.2 there is no way to pass the document profile to Gutenprint.   The 
logical printer should not be specific to the document profile.  But I think 
the concept of using logical printers to encapsulate at set of printer 
parameters for color management is valid and would result in a system that 
was much more accessable to users and easier to manage. 

Hal