[Openicc] Ghostscript CMS [was: PDF frustration]

Ralph Giles giles at ghostscript.com
Sun Nov 30 17:24:22 PST 2008


On 29-Nov-08, at 9:39 PM, Michael Vrhel wrote:

>> The Rgb space for incoming data might be completely unuseable for
>> blending. Perhaps a blending colour space is always defined in the
>> document? I have no enough insight into PDF/PS to know that. If yes,
>> this would make a default for a blending colour space obsolete.
>
> The blending color space can be device RGB, device CMYK or CIE  
> (ICC) based.
> I am not sure I quite follow the question or issue here.  Please  
> explain a
> bit more to me.

If I understand the confusion here correctly: PDF does always specify  
the colour space in which blending occurs (as do all the other page  
description languages with transparency). However, that can be a  
generic, uncalibrated 'device' colourspace. In such cases it is  
useful to define a specific default space for blending.

In theory the components of these generic, uncalibrated 'device'  
colours are to be passed directly to the output device, but that's  
not necessarily possible when blending, proofing or converting to  
another format. So a default blending space is not obsolete, but the  
document can override it if it wants to be more specific.

>> Ghostscript will detect the available CMS options during  
>> configuration and
>> build the hooks according hooks?
>
> At this time, there will not be queries made to
> the CMS to understand it's capabilities.

As for choosing different CMS, we haven't talked about whether this  
will be runtime selectable, but the plan is to compile hooks for  
whatever systems are detected or selected at build time. Our first  
target is littlecms, but we need to at least sketch some others-- 
probably icclib and some of the platform-native systems--early on to  
confirm the API is sufficiently portable.

>> Page 6:
>> Will the gscms_create( contextptr ) and so on interfaces cover pixel
>> layout informations?
>>
>
> The pixel layout information will be communicated during
> gscms_transform_color, as this is when the information is needed.

Hmm. This means a cms would have to cache pixel-layout-specific  
compiled transforms itself, outside the gscms link cache. Are we ok  
with that? I don't know of any cms that currently does that, but it  
might become more common with gpu support.

  -r


More information about the openicc mailing list