[Openicc] color-policy vs. color-infrastructure
Graeme Gill
graeme at argyllcms.com
Tue Mar 1 02:00:26 EST 2005
Jan-Peter Homann wrote:
> Even the creative people, which are working mostly in RGB needing often
> CMYK-profiles with different black generation.
I'm not convinced. I haven't had much experience with printing presses,
and maybe they are more forgiving of different black levels, but
for inkjets I know that black generation has to be chosen very
carefully, along with total ink limit, light ink separation etc.,
as all of this has a great effect on print consistency (sensitivity
of the color to process variations), the appearance of the image
(black "dots"), neutral robustness in different lighting conditions,
sensitivity to banding, etc. etc. Most users won't want to deal with
all this.
> For RGB-images/photos with mainly neutral colors, it is common to use an
> profile with heavy GCR for separation to CMYK.
I'm not so sure about that. Many photo separations seem to use a moderate
or even light GCR to give the black more density, and the image more
contrast, particularly when the device in question is a printing press.
> 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.
> For this, argyllcms is delivering the necessary functionality.
But performance would probably be an issue. Even with a good
cache system backing it up (so that a particular conversion only
has to be computed once), is it acceptable for a user to
hit the "print" or "Flatten" button, and have the hour glass
cursor pop up for 30 minutes or so while the inverse lookup
is computed ?
> can you explain, if argyllcms offers following possibilities:
> - convert a CGATS style textfile (describing only a testchart, no
> Lab-values) to an image, where every CGATS text entry is represented by
> only one pixel ?
No, but I have some rather old code lying around that created a TIFF file
that contained a 33^3 RGB values or 17^4 CMYK values, and then the
reverse, which converted such a TIFF file into (effectively) a
device link profile. The overall processing is pretty trivial.
Of course in this day and age it should all operate at 16 bit
per component as an option too.
[This was originally part of an experiment aimed at capturing
Photoshops color conversions in a device profile like form.]
Graeme Gill.
More information about the openicc
mailing list