Re: Fully saturated colors - mis mapped?
Re: Fully saturated colors - mis mapped?
- Subject: Re: Fully saturated colors - mis mapped?
- From: Terry Wyse <email@hidden>
- Date: Tue, 12 Jun 2001 11:45:43 -0400
on 6/12/01 8:06 AM, Scott Kilbourne wrote:
>
Now check me on this. If I'm working in AdobeRGB (big gamut) and create a
>
color on the outer edge of the gamut (a fully saturated red, for example)
>
shouldn't that color map through a profile to the outer edge of the
>
destination gamut? IOW, If I start with AdobeRGB 255,0,0 shouldn't I end up
>
with Fuji 255,0,0? If I don't then I can't use the full gamut of the Fuji
>
when printing.
Ummm...no because AdobeRGB 255,0,0 isn't the same *appearance* as Fuji
255,0,0. Rendering intent is probably going to have some affect here ( I
assume less so since these are colors at the edge/beyond the color gamut). I
think the main thing here is that the color mapping is going to first try to
maintain the appearance of the color and THEN maintain saturation second, at
least from what I've seen. I know I've always found it confusing when
converting, say, a very saturated blue in RGB to CMYK only to find that it
didn't attempt to use 100% cyan and add in just enough MYK to get the
appearance close. No, it seems to go for appearance first then saturation.
Having said all that, this seems to be VERY dependent on the profile
creation software and their somewhat proprietary color mapping formula. I
also use ProfileMaker 3.1.5 and see a similar thing as you describe.
As a side note, I've done a couple "photographic" color managed workflows
that were primarily RGB-to-RGB conversions all the way through and had a
bunch of trouble with AdobeRGB, especially in the greens (stands to reason
maybe). At one account, we spent a goodly amount of time analyzing the color
gamut of there RGB photo printer and compared it to several RGB working
spaces. AdobeRGB seemed to be the best "fit" (not too hot, not too cold,
just right!) except we kept getting this awful blotchiness/posterization in
the greens on the monitor AND the final print. In the end we went back to
ColorMatchRGB which they had been using successfully for a while and the
problem was cured. ColorMatchRGB was quite a bit smaller than the digital
photo printers gamut but it was simply more pleasing. (For the record I was
using the Photodisc image (which is in AdobeRGB) for a lot of this work
along with some of their own scans - they all showed the same symptom). I
was a bit disappointed since I always try to make the most of the output
color gamut and tailor all the upstream processes to the output space. This
time at least it didn't seem to work. I have it on my to-do list to go back
and try re-profiling the digital photo printer using ProfileMaker's new 2.88
RGB testchart. We'll see.
Terry
_____________________________
Terence L. Wyse
PrePress Specialist
All Systems Integration, Inc.
http://www.allsystems.com
email@hidden
_____________________________