In pratica le situazioni che si possono presentare sono diverse e il motore di colore deve riuscire a cavarsela in ogni caso.

Per esempio se il profilo di destinazione contiene una tabella deve essere in grado di manipolarla (LUT application engine) e di interpolare tra i suoi valori.

Invece, se un profilo contiene una matrice, il motore deve essere in grado di eseguire i rispettivi calcoli matriciali (trasformazioni di matrice).

In ogni caso deve poter ricavare i valori della conversione colorimetrica assoluta a partire da quella relativa (data sottoforma di matrice o di tabella), cioè di operare lo scalamento.

Ancora, se i PCS dei due profili sono diversi (uno Lab, l'altro XYZ) il motore deve essere in grado di convertire i valori da uno spazio all'altro (conversione di modalità).

Se il PCS è Lab e i due profili sono quelli indicati qui sopra, il motore di colore li collega e dai valori RGB ricava le coordinate assolute Lab, che a loro volta converte in coordinate CMYK.

La seconda tabella, da Lab a CMYK nell'esempio, specifica in quale colore CMYK trasformare un colore Lab dato. Non tutti i colori Lab potranno essere resi esattamente con un colore CMYK: ci saranno dei colori che rientrano nel gamut della stampante ed altri che non vi rientrano. In tal caso il profilo potrà allora specificare diverse tabelle, una per ogni intento di rendering.

Le specifiche ICC ammettono che in un profilo, oltre alle informazioni standard ("pubbliche") siano comprese informazioni proprietarie che solo il rispettivo CMM proprietario è in grado di interpretare. Questi CMM proprietari, oltre a leggere le informazioni pubbliche di tutti i profili, sono anche in grado di leggere le informazioni private dei propri profili, naturalmente con l'intento di arrivare ad un risultato migliore.

Per esempio i CMM di Kodak e Agfa, oltre a leggere le informazioni pubbliche di tutti i profili ICC, sono in grado di leggere anche le informazioni private dei profili ICC rispettivamente Kodak e Agfa, appunto. Gli altri CMM non sono in grado di interpretare queste informazioni private, e leggono solo quelle pubbliche.

Le società introducono queste tecnologie proprietarie per differenziare e migliorare i loro prodotti, ma c'è un dibattito tra coloro che sono favorevoli a questa possibilità e che appoggiano l'uso di CMM proprietari, ed altri che sono contrari sostenendo che ciò va contro la filosofia "aperta" della gestione del colore secondo le specifiche ICC.

Per ragioni diverse, motori diversi possono dare luogo a risultati diversi sugli stessi profili e intenti di rendering.

Si possono osservare queste differenze per esempio con il comando di Photoshop 6 Converti a profilo, oppure con una utilità come quelle indicate nella pagina precedente.

Ci sono due ragioni di tipo generale. Una prima ragione consiste nel fatto che il CMM è un programma, e in quanto tale è stato scritto da qualche programmatore. Programmatori diversi scrivono programmi diversi, anche se gli obiettivi sono gli stessi. Una seconda ragione sta nel fatto che il CMM può deliberatamente utilizzare tag proprietari all'interno del profilo, come è stato detto nella pagina precedente.

Some CMMs perform a very elaborate "K-channel" operation in order to preseve K-levels when doing CMYK-CMYK matching. In effect, they are processing the data in the profiles and building another profile which contains new kinds of tables.

Ci sono poi ragioni più specifiche e tecniche.

Una prima ragione riguarda l'uso delle tabelle. Ogni tabella ha un certo numero di righe, ma il CMM può usare più righe (per aumentare la precisione) o meno righe (per risparmiare memoria). Interviene quindi un procedimento di interpolazione, che può essere più o meno accurato.

In altre parole alcuni CMM conservano il numero di bit delle tabelle (8 bit in origine, 8 nel PCS, 8 in destinazione). Altri, come il motore di Adobe incorporato in Photoshop usano internamente un numero maggiore di bit (qualunque numero in origine, un numero più ampio intermedio, qualunque numero in uscita).

Una seconda ragione riguarda l'ordine delle operazioni. Per esempio se un numero deve essere ricercato in una tabella e il risultato deve essere cercato in una seconda tabella, il CMM può decidere di combinare preventivamente le due tabelle in una sola. La precisione matematica con cui queste operazioni sono effettuate può influenzare il risultato. Infatti le coordinate XYZ sono in genere numeri con virgola compresi tra 0.0 e 3.0. I CMM possono rappresentare questi numeri con virgola con più o meno bit, quindi con più o meno precisione, e di solito, maggior precisione significa minore velocità.

Quindi tra i vari CMM (Kodak, Heidelberg, Agfa, Imation, ...) ci sono inconsistenze (variazioni significative e incontrollabili) e differenze volute, che li caratterizzano e costituiscono la loro ragione d'essere.

The ICC has long been concerned with how this issue gets expressed and how it affects color management. It is the intent of the ICC to ensure that the differentiation between CMMs be allowed to exist (in order to ensure a healthy competition and active investment in new technology on the part of the companies involved) but that it not degrade the experience of those depending on color management to work reliably. Inconsistency is bad if it means significant and uncontrollable variations.

The ICC has begun work on a "reference implementation" of a CMM, which will, once it is completed, provide a benchmark for performance and accuracy. I don't know what the status of this reference CMM is, perhaps others on the list list can chime in here. (Eric Broadbent)

There is no good way to test the intended result of the profiles to within a few percent accuracy. And with some profiles, you CANNOT get a "correct" result due to the way the tables are built (ie: if white has to be interpolated, it's almost certain to be wrong....). (Chris Cox)

We need a more robust ICC-Standard and tools for proofing CMMs and profiles against this standard.
The only solution I see, are a reference CMM and reference-profiles by the ICC itself.
Profiles and Profiling applications would be tested with the reference CMM
A CMM would be tested with the reference.profiles.
The testcriteria for the CMMs should be:
Lab 100/0/0 should always result to CMYK 0/0/0/0 and RGB 255/255/255 with the reference-profiles and perc/relCol/Sat Intents CMYK 0,01/0/0/0 or RGB 254,99/255/255 would fail the test.
Same results are necessary for every RGB- or CMYK-profiles with the reference CMM (Jan-Peter Homann)

ColorSync has one problem scaling 16 bit/channel LAB data -- so most third party CMMs will have problems when called from Photoshop. Apple is working to fix this. (Chris Cox)

White should stay white, and is does not. What is happen internaly? Another thing is, the method in the CMM of using the nearby-values in the grid for color-calculation. (Jan-Peter Homann)