Re: null match
Re: null match
- Subject: Re: null match
- From: Chris Murphy <email@hidden>
- Date: Mon, 15 Jul 2002 19:05:53 -0600
Graeme Gill <email@hidden> writes:
>
I've got no problem with, a CMM behaving in this way, I was just hoping
>
to uncover the reasoning behind it, and to discover whether the
>
issue I raised had been thought through. I seem to have failed to
>
provoke any sort of in-depth discussion :-(
You have failed to provide a compelling case for why this behavior is a
good thing. There are any number of reasons why it would be a bad thing.
Imagine having a whole bunch of images that are properly separated and
tagged, and you want to batch process them to ensure they are normalized
into a particular color space. Since this is a great task for automation,
and embedded profiles are used, it's acceptable to drop the whole lot of
files onto a hot folder for processing. The automation software then uses
the embedded profile as source and a preselected destination profile, and
converts all images EXCEPT those that are already in the desired
destination space. To reconvert them is unnecessary. It increasing
processing time, when it's not necessary, it hoses any subtle CMYK color
correction or tweaks done on the file, it recombined the black channel
and causes a new black channel to be created. This could vary from minor
to very bad news if those images had black only drop shadows in them.
If you have reason to believe a set of images don't have the proper ink
limit, then a suitable device link should be used to process those
images; or manually open them and fix them; or convert them to RGB or LAB
and then reseparate.
Chris Murphy
Color Remedies (tm)
Boulder, CO
303-415-9932
_______________________________________________
colorsync-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/colorsync-users
Do not post admin requests to the list. They will be ignored.