Come si è visto in precedenza, nel profilo è contenuta tutta l'intelligenza necessaria a comprimere l'intero gamut dei colori visibili nel gamut della periferica, secondo le diverse modalità indicate dai diversi intenti di rendering. Il motore di colore esegue solo la conversione del colore pixel per pixel, senza avere la capacità di esaminare l'immagine nel suo complesso (mappatura dinamica del gamut).

E' in corso un dibattito se questa sia la soluzione migliore, o se non sia il caso di creare CMM intelligenti (dumb profiles and smart CMM). Ecco alcune battute tratte dalla mailing list di ColorSync.

Chris Murphy: Profiles can only be made so smart. They are just text files. They contain no code and no algorithms so the "smart" profile model really doesn't exist either. What we have now are mostly stupid CMMs (with one exception) and mostly stupid ICC profiles. The smarts are in the profiling packages.

Steve Bay: it amazes me that a standards body could define a system where the gamut compression decisions must be made at a time in the workflow when there is absolutely no way to know how much compression is required, if any. This seems like a very fundamental flaw. The increased use of very large spaces for scanning seems like it makes a fixed, pre-determined gamut compression even less viable.

Henrik Holmegaard: If the smart CMM approach wins out, then users will vote with their feet, shifting the definition of device independence from CIE color models to a workflow definition that says you have device independence when you're using the same CMM.

Bruce Lindbloom: My personal opinion is that this is a fundamental flaw in the ICC architecture. Gamut mapping can only be performed adaptively at the time the profile is *used*, not when it is *created*. This leaves the job to the CMM, not the profiling software.