[Openicc] profile-configuration, application, CUPS, Ghostscript, Gutenprint

[Hal V Engel]

On Tuesday 19 April 2005 05:35 am, Michael Sweet wrote:
> Jan-Peter Homann wrote:
snip 
> > b) Also GhostScript has no possibility to deliver to profile for the
> > document-colorspace to Gutenprint.
> >
>  > ...
>
> This is correct, however IMHO Gutenprint doesn't need to know this
> information.  It will get one of 4 colorspaces (W, RGB, K, or CMYK)
> and can assume that W and RGB are sRGB, and K and CMYK are linear
> CMYK which can be profiled with the transform happening in the app
> or RIP.

I am not sure why Gutenprint would need to make any assumptions about the 
color space of the raster image it is being handed.  Shouldn't Gutenprint be 
getting the raster image in a printer model specific or custom device 
specific color space rather than a generic color space like sRGB?  If 
Gutenprint gets the document in the sRGB color space (the same is true for 
any non-model/device specific color space such as linear CMYK) then it must 
apply another color space transformation from sRGB to the device color space.  

Besides sRGB is really a generic monitor profile and it does not have a wide 
enough gamut to handle the full range of colors that are possible with, at 
least some, current printers.  I have compared the gamut maps of my printer's 
custom profiles to sRGB and I would lose some of my yellow and blue gamut if 
sRGB was used in the processing chain.   Other printers have wider gamut than 
mine because I am using archival inks. Therefore for many the decrease in 
gamut would be even greater than in my case.  I also think that we should 
expect that printers will have even wider gamuts in the future.  So the use 
of sRGB in this processing flow is inappropriate for a number of reasons.

The only place that the sRGB color space has any role in the printing work 
flow, if it is not the embedded color space, is when CUPS gets a document or 
image with no embedded color space(s).  In that case it should assume that 
the document or image is sRGB if it is an RGB document.  Simply because this 
is the best guess that it can make. 

In the simplest case, which is a raster image such as a photograph, CUPS will 
be passed the image file from the app along with possibly some CM related 
arguments.  CUPS (or the filter as the case may be) will pull the embedded 
profile from the image and using other arguments passed by the app will use 
the correct printer profile and rendering intent to transform the image to 
the correct printer color space and pass the resulting printer specific 
raster image to Gutenprint.  

application          CUPS/GhostPrint
gimp-print   =>  and filters            => Gutenprint => printer
plug-in for           embedded CS to
example              printer CS

In the case of PDL type documents we really have the same basic processing 
flow if we think of the RIP as the application. Since the RIP could produce a 
raster image that is in a single intermediate standardized color space that 
will be passed into the filter that handles the final color space conversion 
to the printer color space.  Or perhaps the RIP handles this all in one pass 
by going directly to the printers color space.   Since I don't work with 
these types of documents I will leave this to others.  In any case what gets 
handed to Gutenprint (or any lower level printer driver) is a raster image 
that is in the correct device specific color space. 

                                Ghostprint        CUPS
DPL =>  CUPS  => RIP flattens => flattened CS  => Gutenprint => printer
app                          image CS           to printer CS        
                                                                         
OR


                                Ghostprint      
DPL =>  CUPS  => RIP flattens => CUPS  => Gutenprint => printer
app                          doc CS to 
                                printer CS



Hal