[Openicc] Ghostscript CMS [was: PDF frustration]

[Michael Vrhel]

Hi Kai-Uwe,

Thank you for the comments.  I apologize for my late reply to you.  I had a
hard drive failure and I am slowly working my way through all that fun
stuff.  

My comments are interspersed with yours below.



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


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



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


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

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

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


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


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


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

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


 
> A nice project. Good luck and much fun with it.
> 
> kind regards
> Kai-Uwe Behrmann
> --
> developing for colour management
> www.behrmann.name + www.oyranos.org
> 



Thank you for all the great comments and questions.  It was nice to meet you
in Portland.

Kind Regards,


Michael



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