[Openicc] color-policy / RGB to CMYK

[Jan-Peter Homann]

Hello Graeme, hello list
What I wanted to describe is a much more simple task:

Imagine SVG vectorgraphics (may be from Inksacpe) are placed in Scribus 
and should be converted to CMYK for Offsetprinting (SWOP).
If the free available SWOP-profile from Adobe is used as outputprofile 
in Scribus, all RGB-gray or RGB-black is converted to CMYK-colors with 
each channel containing some color. This happens because of the fixed 
black-generation in an CMYK ICC-profile.
If the user wants RGB-gray or RGB-black only converted to the 
black-channel of the CMYK-output, he needs a version of the SWOP-profile 
with maximum GCR.
With argyllcms, it would be possible to open an existing CMYK-profile 
and save it with a new black generation.
So the Scribus-User could open the Standard-SWOP-profile, changing the 
GCR-Setting to max and Save an new profile "SWOPgcrmax.icc"
Now, he can use this profile in Scribus for separating his SVG 
vectorgraphics.

So the functionality of changing the black generation in an 
ICC-CMYK-profile is something, which is useful for all softwares, 
targeting the graphics arts market.

A second big market is e.g. producing CMYK-PDF from docbook-manuals.
In manuals, you have often a lot of screenshots. If Screenshots should 
be printed in offset, RGB-black should stay pure CMYK-black.

This are quite normal tasks in print production. There is nothing 
special concerning performance. The user has once (!!) to recalculate 
the ICC-profile with maxGCR, which takes may be some minutes. Later he 
can use this profile like all other CMYK-profiles for RGB->CMYK conversions.

:-) Jan-Peter

Graeme Gill schrieb:
> 
>> For RGB-images/graphics with black = RGB 0/0/0 or gray R=G=B it is 
>> common to use an profile with maximum GCR for sepration.
>> This is espcialy useful for separation of screenshots or 
>> SVG-vectorgraphics.
> 
> 
> It's a workaround for the lack of the 4th "rendering intent" channel.
> It only works well if the colors are defined in idealized device spaces,
> rather than real device spaces too. It is very usefull to have such
> a profile available for such things though.
> 
>> If you are not using a profile with maxGCR black generation for this 
>> task, RGB-black and and RGB-gray is separated to all four CMYK-plates 
>> and not only to the black plate.
>>
>> So, control over black generation is very important for ALL users, 
>> which are working in RGB and need control for the conversion to CMYK.
> 
> 
> Yes, but most users are converting from RGB/CIE to CMYK, not CMYK to CMYK
> with a composed page image which mixes text, line graphics and photos. 
> They're
> more likely to have a photographic image in CMYK, but then it doesn't
> matter much if the black is regenerated (in fact it's probably a good 
> thing.)
> 
>> So an universal modul for calculating CMYK-profiles with different 
>> black generation from a given profile or standard 
>> characterization-data would be helpful for all LINUX graphics arts 
>> applications (GIMP, Scribus, Inkscape, ImageMagick....)
> 
> 
> I agree it might be good for flexibility, but I'm not convinced it's
> workable from a performance point of view at the moment. The correct
> technical approach to providing this functionality (I am theorizing),
> is to use a 4th rendering intent/black generation channel, and then
> create a non-standard B2A table with that 4th channel as an input, so that
> a device to device link with selected black generation can be computed
> as quickly as a normal ICC link (ie. all the hard work in inverting the
> A2B table is done off line.) This type of lookup is what Argyll does
> to be able to support "through black" linking.

-- 
--

homann colormanagement ------ fon/fax +49 30 611 075 18
Jan-Peter Homann ------------- mobile +49 171 54 70 358
Kastanienallee 71 ------- http://www.colormanagement.de
10435 Berlin --------- mailto:homann at colormanagement.de