El motor de color ICC

La misión del motor de color para los perfiles ICC, más correctamente llamado "Módulo de Gestión del Color" (Colour Management Module: CMM), es convertir de algún modo el gamut del dispositivo de origen al de destino.

El CMM puede estar incluido en el sistema operativo o en un programa concreto. Por ejemplo, en el sistema MacOS, ColorSync 3 ofrece varios CMM que funcionan a nivel de sistema operativo. El que actua por omisión es Apple CMM, pero se pueden usar otro como por ejemplo AgfaCMM, KodakCMM o HeidelbergCMM.

Entre los CMMs incluidos en los programas se encuentran Adobe Colour Engine (ACE, disponible en las aplicaciones más recientes de Adobe como Photoshop 6, Illustrator 9 y Acrobat 5), y los incluidos en LinoColor (HeidelbbergCMM), NewColor, BESTcolor y GretagMacbeth ColorPicker (LogoCMM).

En Microsoft Windows 98 y 2000, la parte del sistema operativo dedicada a la gestión del color es ICM 2, que usa HeidelbergCMM. En Windows 95 y Windows NT, no hay gestión del color al nivel den sistema operativo. En estos casos, las distintas aplicaciones usan sistemas como Kodak KCMS y Agfa FotoTune.

Cómo funciona un CMM ICC

La tarea del CMM es convertir los colores desde un perfil de origen a un perfil de destino.

Por ejemplo, si una imagen con un perfil RGB (desde el monitor) debe imprimirse con un perfil CMYK utilizando un propósito de conversión definido, el CMM convierte las coordenadas de color RGB a las coordenadas de color CMYK del dispositivo de impresión. El perfil del monitor se usa como origen (RGB a PCS) mientras que la tabla relevante en el perfil de la impresora se usa como destino (PCS a CMYK).

Una conversión RGB a CMYK

R	G	B	L	a	b		L	a	b	C	M	Y	K
En las tablas, los puntos suspensivos indican que se ha omitido (por abreviar) la sucesión de valores descendentes.
255	255	255	100	0	0		100	0	0	0	0	0	0
255	255	223	99	-3	11		99	-3	11	0	0	12.5	0
…							…
0	0	31	2	12	-30		2	12	-30	100	100	87.3	0
0	0	0	1	0	0		1	0	0	100	100	100	0

Si el PCS es Lab y las tablas en los dos perfiles son las que se ilustran arriba, el motor de color las enlaza sacando las coordenadas absolutas Lab de los colores RGB y convirtiéndolas a las coordenadas CMYK. Véase el ejemplo en conversión entre gamuts.

Más precisamente (y en general) el motor de color debe realizar varias raeas entre las que están:

• Interpolar entre las filas de las tablas.
• Reducir proporcionalmente (scaling).
• Transformación de las matrices para adaptar el punto blanco.
• Conversión de modalidades (XYZ <-> lab).
• Servir de motor para LUT.

Los principales CMMs

La cabecera del perfil establece cuál es el motor de color por omisión para ese perfil. APPL es el motor de color de ColorSync (AppleCMM para la versión 3, HeidelbergCMM para las versiones 2.0-2.61, y LinoColorCMM para las anteriores).

Los principales motores de color en MacOS son:

• AppleCMM: El CMM por omisión de ColorSync.
• Adobe Color Engine (ACE): El mejor de todos, según Adobe. Sólo existe en los programas de Adobe. Sus resultados son similares a AppleCMM y HeidelbergCMM.
• AgfaCMM: Parece tener ciertos problemas para simular el blanco del papel.
• KodakCMM: aunque se creó para las marcas (tags) ICC de perfiles de Kodak, funciona también con perfiles que no son de Kodak.
• HeidelbergCMM: Najo el nombre de LinoColorCMM, fue el CMM original de COlorSync hasta su versión 2.6.

Las especificaciones del ICC admiten también marcas (tags) privativas que el CMM por omisión no puede usar. En ese caso, debe haberse instaladoen la carpeta del sistema un CMM que haga uso de esas marcas privativas.

Quark XPress usa el motor de color por omisión de ColorSync. Los programas de Adobe dejan al usuario decidir entre ColorSyncCMM, el CMM incorporado de Adobe o cualquier otro CMM instalado en la carpeta del sistema.

Perfiles inteligentes y motores estúpidos

Como ya hemos visto, el perfil tiene la inteligencia necesaria para comprimir todo el gamut de colores visibles en el gamut del dispositivo de muchos modos dependiendo del propósito de conversión. El motor de color simplemente realiza la conversión de color píxel por píxel y es incapaz de examinar la imagen en su conjunto (distribución dinámica del gamut o dynamic gamut mapping).

En un perfil de salida, las tablas BtoA (usadas en los perfiles de destino) determinan la compresión del gamut (especialmente la tabla BtoA0), un cálculo que no realiza el CMM, como se podría creer. El CMM hace una transformación píxel a píxel y carece de la inteligencia necesaria para comprimir el gamut.

Si esta es o no la mejor solución y si habría sido mejor crear CMMs inteligentes (es decir, perfiles estúpidos y motores inteligentes) es actualmente un tema en cuestión. Éstas son algunas observaciones realizadas en la lista de correos de ColorSync:

Steve Bay: "Me sorprende que un organismo regulador pudiera definir un sistema donde las decisiones sobre la compresión del gamut deben hacerse en un momento del proceso de trabajo eb el que no hay modo alguno de saber cuánta compresión hace falta, si es que hace falta alguna. Esto parece un principio fundamental. El uso creciente de espacios muy amplios para el escaneo parece hacer de la compresión fija y predeterminada del gamu algo aun menos viable".

Henrik Holmegaard: "Si termina por ganar la postura de un CMM inteligente, los usuarios votarán con sus pies, cambiando la definición de independencia del dispositivo desde los modelos de color del CIE hacia una definición de los sistemas de trabajo (workflows) que diga que se tiene independencia del dispositivo cuando se está usando el mismo CMM".

Chris Murphy: "Los perfiles sólo se pueden hacer así de inteligentes. Sólo son ficheros de texto. No contienen ni código ni algoritmos, por lo que el modelo de perfil inteligente realmente no existe. Lo que ahora tenemos es una mayoría de CMMs estúpidos (con una excepción) y una mayoría de perfiles ICC estúpidos. Los rasgos de inteligencia están en los programas de realización de perfiles".