[Openicc] Re: Ghostscript CMS [was: PDF frustration]

[Kai-Uwe Behrmann]

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

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.


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?

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?

Will gsicc_load_default_input_profile( NumChannels ) work like a default?


Page 6:
Will the gscms_create( contextptr ) and so on interfaces cover pixel 
layout informations?


Page 8:
gsicc_load_default_device_profile( NumChannels ) will make sense only for 
4 cases (Named[0], Gray[1], Rgb[2], Cmyk[3]) ?


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.

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?


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


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


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.


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




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