[Openicc] Introduction / Gutenprint]

[Kai-Uwe Behrmann]

Discussed where two options to forward print data. The one is to send
image data in source format (mostly RGB, but as well CIE) and the other
option a full ripped dataset ready for printing (GIMP/CinePaint).
What about sending separated data in the image resolution and ripping 
CcMmYK (for instance) after piping trough CUPS.
At least the locally selected CMM can do its work on the local host. This 
would need a transformation layer (if selected) in user space. The ripping 
options need close coupled to the selected profile and forwarded to the 
RIP.

The difference between raster and vector processing would be a higher 
administration level for postscript/pdf as it would strip out the 
advantage of vector processing (small filesizes with fine resolution). 
Maybe I am wrong here.

Sorry for reasking some questions repeatedly. But I feel a little bit 
confused about the options CUPS will provide.

Am 11.04.05, 22:21 -0400 schrieb Michael Sweet:

> Robert L Krawitz wrote:
> > Date: Mon, 11 Apr 2005 21:01:18 -0400
> > From: Michael Sweet <mike at easysw.com>
> > Cc: openicc at freedesktop.org
> > 
> > Gerhard Fuernkranz wrote:
> > > Michael Sweet schrieb:
> > > 
> > > > Basically you add cupsICCProfile attributes to your PPD file
> > > > to
> > > > specify the output profiles for various printing modes
> > > > supported
> > > > by your device. Normally the output profile selection is done
> > > > automatically using the current job options (media type,
> > > > color
> > > > model, resolution, etc.), however it is also possible to
> > > > include
> > > > the cupsICCProfile attribute in a print job to select a
> > > > specific
> > > > profile, overriding the auto selection, e.g.:
> > > > 
> > > > lp -o cupsICCProfile=CMYK.Glossy.2880dpi filename.jpg 
> > > 
> > > 
> > > What does CUPS actually do with this parameter?
> > > Or in other words, who is eventually applying the profile, at
> > > which level?
> > > (and particularly, how is it done in the case "lp -o
> > > cupsICCProfile=... filename.ps")
> > 
> > The profile is applied by the RIP (any of the *toraster filters).
> > 
> > 1) So there's a hard-coded limit of three components to the name?
> > That seems a bit limiting...
> 
> Not in practice, and we have to deal with the 40 character limit for
> option keywords in PPD files.
> 
> > 2) In CUPS 1.2, is there a 16-bit path from the RIP to the driver?
> 
> Yes, if the RIP supports it (also 32-bits per component, if supported)
> FWIW, CUPS 1.1.x also supports 16/32-bits per component in the raster
> format, however the imagetoraster and pstoraster filters do not yet
> support it.
> 
> The imagetoraster filter in CUPS 1.2 will support 16-bits per
> component.

Is this bitdepth available for arbitrary numbers of channels?
This would be indeed a good step forward.

> The pstoraster filter in ESP Ghostscript 8.15.x (x > 1) will support
> 16-bits per component, however due to limitations in the Ghostscript
> API only 15 bits of that will be significant, and on platforms that
> do not support 64-bit integers the per component resolution will be
> less, e.g. 11/11/10 for 3-components and 8/8/8/8 for for 4-components.

Ok, this is a Ghostscript issue only ?

> The cg*toraster filters in MacOS X 10.2 only support up to 8-bits per
> component, but 10.3 and higher support 16-bits.
> 
> -- 
> ______________________________________________________________________
> Michael Sweet, Easy Software Products           mike at easysw dot com
> Internet Printing and Publishing Software        http://www.easysw.com

thanks
Kai-Uwe Behrmann
                                + development for color management 
                                + imaging / panoramas
                                + email: ku.b at gmx.de
                                + http://www.behrmann.name