[Openicc] Introduction / Gutenprint

[Gerhard Fuernkranz]

Robert L Krawitz schrieb:

>Part of the rub is what the "final DeviceCMYK" values are. They're
>always going to be interpreted somehow by the driver, since inkjets
>aren't continuous-tone devices and all that.
>
Correct, and their colorimetric meaning depends on the particular driver 
settings, the used consumables (paper, inks, ...).

>It sounds like what you're really suggesting here is that the driver
>provide good linearized output, and ICC profiles or whatnot be applied
>in Ghostscript.  That's fine, but if Ghostscript is delivering 8-bit
>data to the driver, it means that a fair bit of information is getting
>lost because the profile won't be a 1-1 mapping.  If Ghostscript
>outputs 16-bit data that issue goes away.
>
Actually I'm not really suggesting anything, because I don't know a 
satisfactory solution.

On the one hand, I'm not fully satisfied with the quality of 
ghostscript't color rendering, and on the other hand, with ghostscript 
as is, I see no way to do it externally in the driver (like Gutenprint 
does for halftoning), without breaking PS L3 support for CIE-based color 
spaces in PS documents (I'd hope, my understanding were wrong).

I'm no sure, if gs output to the driver is really limited to 8bpp (is 
it?), but 8bpp is indeed a design limitation for the RenderTable in 
color rendering dictionaries. There may exists other RIPs which use an 
ICC profile instead of the CRD, but ghostscript as is, seems to honor 
strictly the PLRM regarding this issue, and requires a _CRD_ for color 
rendering (not an ICC profile).

If the device color space is well linearized, I'm not sure, if the 8-bit 
RenderTable is really an inacceptable limitation, since only the 3D grid 
points are quantized to 8-bit, but the interpolation between the grid 
points can of course be done with arbitrary precision, which should 
still permit smooth color gradients (if it is implemented carefully).

(So far the theory - how accurate the evaluation, interpolation, 
caching, etc. of color transformations seems to be implemented in gs, is 
a different issue)

>To summarize what I think I'm hearing:
>
>1) Linearization should be performed in the driver.
>
IMO also the generation of Cyan/LightCyan, Magenta/LightMagenta 
separations, since often simply CMYK profiles are used for CcMmYK 
printers, in this case the driver should accept CMYK input for a CcMmYK 
printer. If additionally e.g. orange and green colorants come into the 
play, a multicolor profile is likely unavoidable to utilize the full 
color gamut optimally. But of course, for CcMmYK, a multicolor profile 
could be used as well.

Btw, does the IJS interface currently support drivers with a DeviceN 
(i.e. multicolor) ProcessColorModel?

Regards,
Gerhard