Gerhard wrote:
It is done by the the BToA tables. The BToA1 table (relative
colorimetric)
is supposed to remap PCS values which are out-of-gamut on the device,
to in-gamut device values.
Is this really how it's done, usually? Or, does the CMM typically clip out of gamut colours?
I.e, does the profile typically *actually* contain the explicit remapping for all PCS values which
are out of the device gamut? (this is just a question - I'm not suggesting you are incorrect)
Greg,
yes, it is required by the ICC spec, that the BToA tables must be able to
map *all* possible PCS values to valid device values. And for a typical output
device, the *majority* of all possible PCS values are out of gamut and need
to be remapped, since the PCS is the complete CIELAB space.
Basically the ICC approach is based on a "dumb CMM", which stupidly
applies the tables in the profies which are involved in the transform, while the
"intelligence" is contained in the profiles (or actually in the profiler which
creates these profiles).
For speed optimization, the involved transforms are internally often combined into a single device link (-> see also "-c" option of tifficc).
For matrix/shaper, of course the CMM must do the clipping, since applying the matrix and shapers may result in negative RGB values, or RGB values exceeding 255. But I guess, this kind of clipping is usually also done in a rather simple way, like: if (R < 0) R = 0; if (R > 255) R = 255; ...
The "dumb CMM" approach also has some disadvantages. For instance, the gamut mapping in the perceptual BToA0 table of an output profiles must already assume a particular source gamut *at profile creation time*, though the source gamut is not yet known at this time. So the profiler can only attempt to guess, and try to make a reasonable compromise.
Of course, any "smart CMM" is free to ignore e.g. the perceptual BToA0 tables and to create the PCS->device mapping (incl. gamut remapping) on the fly at runtime, based on the gamut of the source and destination color spaces, or it may even use the gamut of e.g. the *image* you want to print, as source gamut, avoiding unnecessary gamut compression whenever possible. However, a smart CMM approach may be computationally very expensive and correspondingly slow.
I think, true smart CMMs are still rare. And dumb vs. smart CMM also seems to be also a philosophical issue, with followers and opponents on both sides. Maybe Marti can tell more ... ?
Except for a few extended features (like BPC, proofing, gamut warning), LCMS is basically also a "dumb CMM" engine, which just applies the tables contained in the profiles.
Regards, Gerhard
------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Lcms-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/lcms-user
