[Openicc] Ghostscript CMS [was: PDF frustration]

[Kai-Uwe Behrmann]

Am 30.11.08, 17:24 -0800 schrieb Ralph Giles:
> 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.

Thanks for explicitely clearing the document description capabilities 
point.

>>> 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.

Yes, a interessting question, whether a GPU context should remain 
persistent or can be rebuild easily enough.

kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org