The task of the color engine for ICC profiles, more accurately called the Color Management Module (CMM), is to convert, in one way or another, the gamut of a source device to that of a destination device.

The CMM may be included in the operating system or in the application. For example, in MacOS, ColorSync 3 offers various CMMs at operating system level; the default is AppleCMM, but others may be used: e.g. AgfaCMM, KodakCMM and HeidelbergCMM.

CMMs built into applications include Adobe Color Engine, ACE, available in recent Adobe applications (Photoshop 6, Illustrator 9, Acrobat 5) and those built into LinoColor (HeidelbergCMM), NewColor, BESTcolor, GretagMacbeth ColorPicker (LogoCMM).

In Windows 98 & 2000, the color management part of the operating system is ICM 2, which uses Heidelberg CMM. In Windows 95 and NT 4 color management is not carried out at operating system level. In this case, the applications use systems such as Kodak KCMS and Agfa FotoTune.

The task of the CMM is to convert colors from a source profile to a destination profile.

For example, if an image with an RGB profile (from the monitor) must be printed with a CMYK profile, using a choosen rendering intent, the CMM convert the RGB color coordinates to CMYK printer color coordinates. The monitor profile is used as the source (RGB to PCS) whilst the relevant table in the printer profile is used as the destination (PCS to CMYK).

If the PCS is Lab and the tables in the two profiles are those illustrated above, the color engine links them by working out the Lab absolute coordinates of the RGB colors and converting them into CMYK coordinates. See an example in Conversion between gamuts.

More precisely, and in general, the color engine is required to carry out several tasks, including the following:

• interpolation between table rows;
• proportional reduction (scaling);
• matrix transform for white point adaptation;
• modality conversion (XYZ <-> Lab);
• LUT application engine.

The profile header establishes which is the default color engine for that profile. APPL is ColorSync color engine (AppleCMM from version 3, HeidelbergCMM for version 2.0-2.61, LinoColorCMM before).

The main color engines on MacOS are:

• AppleCMM: ColorSync default;
• Adobe Color Engine (ACE): the best of all, according to Adobe; only exists in Adobe applications; gives similar results to AppleCMM and HeidelbergCMM;
• AgfaCMM: seems to have problems with simulating the white of the paper;
• KodakCMM: created for ICC Kodak profile tags, but also works with non Kodak profiles;
• HeidelbergCMM: under the name LinoColorCMM, this was the original ColorSync CMM up to version 2.6.

ICC specification supports also proprietary tags who the default CMM cannot use. In such case a proprietary CMM must also be installed in the System Folder.

QuarkXPress uses the default CMM default of ColorSync. Adobe applications let the users choose: the default ColorSync CMM, the built-in Adobe CMM or every other CMM installed in the System Folder.

As we have already seen, the profile contains all the intelligence necessary to compress the entire gamut of visible colors into the device gamut, in different ways according to the rendering intent. The color engine simply carries out the conversion of color pixel by pixel, and is unable to examine the image as a whole (dynamic gamut mapping).

In an output profile, the BtoA tables (used in destination profiles) determine the compression of the gamut (especially the BtoA0 table) which is not calculated by the CMM as one might believe. The CMM makes a pixel by pixel transformation and does not have the intelligence to compress the gamut.

Whether this is the best solution and whether it would not be better to create intelligent CMMs (dumb profiles and smart CMMs) is currently a matter for debate. Here are a few observations taken from the ColorSync mailing list:

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.

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.