On Jun 13, 2005, at 10:14 PM, Russ Wyatt wrote:
Hi all color geniuses,
I am hoping some of you can answer some questions that have been baffling me for some time in regards to rending intents when converting RGB files to CMYK.
Q1: Why is it when i convert an RGB image to U.S Sheetfed Coated V2 in Photoshop CS using either Perceptual,Relative, Saturation or Absolute and all with and without Black Point Compensation the black point is always C95 M85 Y85 K85 / Total Ink=350%, but when I convert RGB images to custom made CMYK profiles the black point always changes?
I'm not sure what developers call it. I call it a bug. It's something I've been complaining about for years. One of my first conniptions on this list, way back when, was in regards to this very problem. I don't understand what's so difficult about having a consistent total ink limit in all of the rendering intents.
Now, it *is* possible to set an ink limit (which is a limit, that is it should not be higher than that value), but the higher the GCR is, the lower total ink will be, and vice versa. I don't know of a single user interface (something in my brain is saying Fuji ColourKit ProfileMaker or the editor may be an exception) that shows this intuitively. For a given data set, I feel like the UI needs to give me feedback on what amount of black generation is necessary for a particular ink limit, or what ink limit is implied for a particular black generation.
The biggest problem I see here is with ProfileMaker newsprint. Total ink has been busted by 9%, while the K ink limit is about 1/2 of what it ought to be. Clearly your black ink limit is set to 94-95% and that is honored in the perceptual intent. I find it impossible to believe there is the same density achieved at 53%. This is a bug, plain and simple. (Not that you usually want a 95% ink limit for printing on newsprint anyway but it is what you asked for).
The basICColor profile is also misbehaving by not achieving the specified density in one of its rendering intents. There is a 33% different in K ink limit between Perceptual and RelCol. Not acceptable.
You might try repeating some of these tests without black point compensation. I had problems similar to this where bpc does not affect perceptual rendering all that much (if at all), but it affects the CMYK values for black considerably with Monaco Profiles in a similar way. This is due to the profile being built in "incorrectly" (i.e. in a way that prevents black point compensation from working correctly). That problem was fixed in Profiler 4.7.2.
Since ProfileMaker 5.01, it's much more well behaved than 4.1.5 in this respect, but there still are differences in total ink limit among the rendering intents. If you want to send me the profilemaker chromalin and newsprint data I can run it through 5.03 and have a basis of comparison on this issue.
Q2: Are all icc profiles that are created with ProfileMaker and basICColor generated with Perceptual Rending in-built in every profile created? Hence why the black point and total ink densities match when converting RGB to CMYK using Perceptual/BLK Point Comp.
I don't know. Theoretically, ink limit is just a suggestion. It's an amount not to be busted. It's not an amount to be matched. However, insofar as ink limit is taken as a rule for perceptual (and usually also saturation), but is a casual suggestion for colorimetric - it's absurd. For a particular black ink limit, total ink limit, and GCR amount & width, and colorimetric data set, there is a set of CMYK values that will get you the darkest black. That's the black point and it's the same regardless of rendering intent.
Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
-------------------------------------------------------------
Co-author "Real World Color Management, 2nd Edition"
Published by PeachPit Press (ISBN 0-321-26722-2)