[Openicc] Ghostscript CMS [was: PDF frustration]

[Kai-Uwe Behrmann]

Hello Michael,

comments inside.

Am 29.11.08, 21:39 -0800 schrieb Michael Vrhel:
>> -----Original Message-----
>> From: Kai-Uwe Behrmann [mailto:ku.b at gmx.de]
>> Sent: Thursday, November 20, 2008 2:46 PM
>> To: Michael Vrhel
>> Cc: 'Ralph Giles'; OpenICC Liste
>> Subject: [Openicc] Re: Ghostscript CMS [was: PDF frustration]
>>
>> Hello Michael,
>>
>> The overall recipe looks good to me. Just some annotations about the
>> quantities in he hope things get more clearer to us all. As well I will
>> ask for my own understanding, as my usual terminology differs or
>> things are implied and mentioning explictely is helpful.
>>
>>
>> Page 5:
>> The gsicc_get_link function takes a rendering intent argument to
>> lookup the device link in the cache. I'd say at least Black Point
>> Compensation (bpc) should be included and will hopefull at some point
>> visible in PDF's.
>
> The idea of the rendering intent is just to communicate to the CMS what is
> requested for those colors in the document.  In PDF, you can set a rendering
> intent.  The CMS will need to decide what it wants to do with that
> information.  It may decide for perceptual intent for example that it will
> do black point compensation.

Bpc works only with relative colorimetric. As I recently looked over the 
default CM settings, I remembered that many developers voted for five 
rendering intents here some time ago:
http://lists.freedesktop.org/archives/openicc/2007q4/000963.html

I do not know if and how this, or bpc as a separate option, could make its 
way into PDF.

This could obsolete bpc as a separate option. Well, we do not know what 
else might appear as new options, which was the starting point for my 
comment.

>> The number of colour spaces taken by this function seems fixed. I am not
>> shure if this is a good idea. This can not good handle proofing, for
>> instance if someone wants a the print output to appear like some different
>> kind of printer. What about effect profiles? The look a user likes
>> to see should not be embedded into device profiles. Without a certain
>> look, most time some contrast and saturation increase, many users are
>> disappointed.
>
> You bring up an excellent comment with respect to proofing and effects.  My
> inclination is not to get the proofing profile tangled up in Ghostscript.
> If someone really wants to use one, then the proofing application should
> really make that adjustment after ghostscript has created the result for the
> destination profile.  That said, I am open to hear arguments to the
> contrary.

You suggests(?)
input CSP -> Ghostscript internal CSP -> output CSP -> effect -> output CSP

If so, I would state that this is a case of a double conversion. Most 
programmers target at as few as possible colour conversions to avoid error 
introduction. So be that my argument ;)

>> Setting the default profiles by colour space seem difficult. There are
>> at least two different groups of profiles needed:
>> * for incoming untagged data
>> * blending colour space
>> * interpolation colour space
>> 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.

The native device colour spaces may not behave symetrical along the gray 
axis. So gray should remain gray after applying a function to all channels 
equaly. Typical editing spaces like sRGB, eciRGB or AdobeRGB have 
therefore their TRC tags in sync. (For Cmyk the aabove assumption does 
often not apply.)
Many device specific profiles shift away from gray for the above outlined 
test. This would make a unfortune case for blending.
So in summary, having a processing/blending space independent from the 
native device space my often be very useful.

I hope, I could clear a bit the editing(/working/blending) colour space
term.

>> As a side note:
>> Devicelink link caching might be better handled externally. The
>> possibility to register a handler could help with that.
>> ... oh, I see on the bottom of page 5 it is already mentioned.
>>
>> Ghostscript will detect the available CMS options during configuration and
>> build the hooks according hooks?
>
> There will need to be an interface created between the CMS and ghostscript.
> If the CMS does not support certain things like object level (i.e. text,
> grahic or image specific) rendering, then the interface will handle those
> differences by not passing that information on to the CMS.  Ghostscript will
> always provide it though.  At this time, there will not be queries made to
> the CMS to understand it's capabilities.

Ok.

>> Is gsicc_profile_t DeviceProfile /* The actual profile for the device */
>> the output space or the devices native colour space? So a tiff device
>> could obtain Swop and a proofer its native Inkjet/Media/Ghostscript
>> profile?
>
> That is the color space for which the output device colors are to be
> produced.  So yes, you could have a tiff device with a SWOP profile and the
> SWOP ICC profile should get embedded into the TIFF file.  For the proofer
> you would use the proofer's native profile.

good

>> Will gsicc_load_default_input_profile( NumChannels ) work like a default?
>>
>
> Yes.  This will occur if no other profile has been assigned for the default
> device spaces.
>
>
>> 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.

So you will alwas have to check for that and add a small cost. It is more 
usual to have a fixed colour conversion context after initialisation and 
setup. So the conversion keeps at the lowest possible time. Whether it is 
of much importance for your design I do not know.

>>
>> Page 8:
>> gsicc_load_default_device_profile( NumChannels ) will make sense only for
>> 4 cases (Named[0], Gray[1], Rgb[2], Cmyk[3]) ?
>>
>
> Yes.  This is a problem that I am trying to figure out how best to handle.
> In the document I stated that if the device has no profile and NumChannels
> is greater than 4 than we really should use gsicc_set_device_profile with a
> profile that has the proper number of channels.
> gsicc_load_default_device_profile was more for a lazy case where we will
> always have something we can use.

Deploying the ICC colour space signature? E.g. 'Rgb ' 'Cmyk' ...
They are defined in icc34.h and similiar headers. Not so nice as a 
enumeration, but otherwise ok.

>> The actual device profile would be great find embedded in the output
>> stream (PNG, JPEG, Tiff, PDF, SVG ...). A option to flatten complex colour
>> documents into one colour space would be a great option. But this step
>> needs more CMS options, like the special ones for Cmyk to Cmyk transforms.
>> This would affect e.g. the gscms_get_link() API from page 9.
>
> I am not entirely clear what you mean here, but I would like to understand.
> Can you please explain this to me a bit more?

The first sentence you answered about for embedding a profile in a Tiff 
device. Related to the vector document types is the other text as they can 
contain multiple CSP's.
The document flattening is meant as a feature to homogenise colour spaces 
inside a document. This could be helpful in reducing ambiguities. As there 
might happen Cmyk to Cmyk conversions, the CMS should know in which 
fashion to do this. The homogenise option is possibly not a CMS but 
more a Ghostscript one. The cmyk_to_cmyk option might be specified as 
well outside of Ghostscript in a CMM, e.g. as a default setting.

>> Page 9:
>> Would point 4 mean that Ghostscript caches a thierd party link and hand
>> it over to a custom CMS for applying to data?
>>
>
> The CMS creates the link and hands some information about it (e.g. a handle)
> to ghostscript.  Ghostscript will retain that handle and use it as need by
> asking the CMS to use it on transforming color data.  When it is done, it
> will let the CMS know that it can be destroyed.
>
>
>> How will no transform be handled? A explicit means would be great. I am
>> not shure where the PDF specs allow for that. Shurely they do, just I
>> dont know which PDF-X to choose.
>
> This is a good question.  Originally, I was thinking that would be achieved
> by having the source and destination profiles the same.  In that case, the
> mapping should be detected as being identity and not occur.  Now, I am not
> sure I like that as well as simply having a way to override color
> management.

We have seen ambiguities in regards of the dest==src approach. Therfore 
I'd like to strengthen a explicite option as a important request. It will 
make live easier for deploying Ghostscript ;-)

>> Next to that some OpenICC people would be glad to know about the means to
>> explicitely embedd a output profile and have a means to get it applied as
>> device profile in a strict and on request in a lazy manner. The first
>> would help for colour critical work, the later for retargetting in case a
>> queue is not available and a document should be reouted to a different
>> device with a different device profile.
>
> Interesting.  I had not thought about this lazy manner case.  For me it was
> always going to be strict.  Again this goes back somewhat to my feelings
> about proofing.  This should really be handled on the application side.  If
> someone wants to have the capability to map to multiple devices, then they
> should pick a destination color space for their document that has a gamut
> encompassing all the possible devices.  Then, at the time that the decision
> is made to go to a particular device, the colors are appropriately mapped.
>
>
>
>>
>> Page 10:
>> "A comment on the hash codes" - I am in doubt that a fixed number of
>> options will be flexible enough as I mentioned above. Possibly it is good
>> to merge the options into a common part of the context pointer:
>> struct gscms_context_t {
>>    ...
>>    gscms_options_t * options;
>>    void* cmm_context;
>>    ... };
>>
>
> That is a good point.  I will do that.  Thanks.
>
>
>
>> I probably did not yet get the point of the gsicc_xxx versus the gscms_xxx
>> API's.
>> Especially page 10 with gsicc_get_link() for obtaining non ICC links is
>> confusing to me as the name suggests ICC complyance. Possibly I do oversee
>> something as no types are assigned to the function arguments.
>> The one is the internal ICC alike implementation and the other a public
>> API? How does they interact as the arguments differ?
>> ... ok page 20 gives more hints.
>>
>
> Sorry for the confusion on that.  The gscms_xxx functions are basically the
> functions that interface to the external CMS.  These must be rewritten when
> a new CMS is introduced.  The gsicc_xxx functions are ghostcript specific
> with regards to handling ICC profiles.

Thanks.

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


>> Am 31.10.08, 10:56 -0800 schrieb Michael Vrhel:
>>> Quite some time ago, I promised to share a document on my plan to update
>>> Ghostscript's color management.  Sorry it has taken so long to get this
>> to
>>
>>> http://www.ghostscript.com/~mvrhel/Ghostscript_Proposed_ICCFlow.pdf
>