Re: Rendering Intents
Re: Rendering Intents
- Subject: Re: Rendering Intents
- From: Graeme Gill <email@hidden>
- Date: Mon, 02 Sep 2002 12:12:11 +1000
bruce fraser wrote:
>
It's not really an ICC profile limitation, it's a corollary of the
>
"smart profile/dumb CMM" architecture of ICC color management.
It seems to also be patterned after the way Postscript handles
color, as it to, doesn't seem to have any expectation that "real"
gamut mapping will be performed.
>
The upside to the architecture is that we can obtain very similar results
>
from different CMMs, and hence we have interoperability and an open
>
standard.
Sorry, I don't follow this line or reasoning. Given that both the
A2B and B2A tables may change the gamut, and given
that in general you will be mixing and matching source and
destination profiles from different CMMs, there seems a very
large scope indeed for poor results. Consider the situation
in which CMM A takes the line of using the A2B table to
expand or compress to its standard gamut (which happens to
be, say, the SWOP colorspace) and sets up its B2A table to
assume that it is being fed from one of its own profiles,
mixed with CMM B, which assumes that the A2B table doesn't
change the gamut, and that it has to compress from a gamut
that exceeds a "super" RGB monitor.
>
To do that, I think you'd need a smarter CMM, and simpler profiles. A
>
profile only has knowledge of itself and the PCS. The gamut mappings
>
we build into profiles are based on an assumed source gamut (usually
>
undocumented). The packages that allowed you to choose a specific
>
source gamut on which to base perceptual rendering seem to have
>
fallen from favor -- none of the current major players let you do so.
Since they are striving for simplicity and speed (from a user and an implementers
point of view), this is hardly surprising. To be fair to the ICC profile format,
there is enough information to do proper gamut mapping, it's just not as
easy as it should be, since the gamut boundary format supported by the
ICC format isn't very useful, nor seem very reliable. Some vital information
for printer profiles, such as the TAC isn't supported in ICC profiles.
Computing two gamut boundaries, and a gamut mapping is going to be a lot
slower than throwing a grid through the A2B and B2A tables too.
[My CMS for instance, supports both the simple linking step as
all others do, as well as two "intelligent" linking mode, that
work just from the colorimetric tables. This allows things like
using the source image gamut to create the optimized gamut
mapping, as well as a lot more choices as to intent, and overall
higher accuracy.]
>
The ICC spec also lets you implement perceptual gamut mapping in the
>
source profile. But the same problem applies: unless you know both
>
the source and destination gamuts, an optimal perceptual mapping
>
isn't possible -- you just have to make a middle-of-the-road
>
assumption.
While this seems perfectly satisfactory for many casual users of
color, I think the point has been reached where the advanced users
see this as a limitation.
>
To get a color management system that produced adaptive perceptual
>
mapping, wouldn't the intelligence to do so have to be in the CMM?
>
Profiles are just data...
Yes.
>
It would be fascinating to see someone build such a system to see if
>
it actually produced better results. Meanwhile, I use Relative
>
Colorimetric with Black Point Compensation about 90% of the time.
If you have any way of using the resulting ICC device link profile,
I'd be happy to link a couple of your profiles using my CMS, and send
you the results, so you can make a judgement.
Graeme Gill.
_______________________________________________
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.