RGB y CMYK. late binding vs. early binding


Como era de suponer, los perfiles de impresión también son determinantes a la hora de lograr una buena reproducción de color. El modelo de color CMYK también es “device-dependent”, por lo que obviar la información del dispositivo de salida hace al trabajo en este modo de color practicamente inútil.
Además, incrustar un perfil distinto al que usará nuestra imprenta conlleva el riesgo de que sea incorrectamente interpretado, así que a menos que sepamos lo que estamos haciendo (y nuestra imprenta también) el modo CMYK puede traer varios problemas.
Es tal vez por este tema que la recomendación general es trabajar con lo que se conoce como “late binding”, es decir, dejar para el final la conversión a CMYK.
La tendencia actual, acentuada por el creciente uso de sistemas DI (direct imaging) y CTP, es dejar el trabajo de separación al RIP, y que éste se encargue de la conversión a CMYK e incluso del trapping.
En ese caso se sugiere trabajar directamente en RGB, sin preocuparse en absoluto por convertir a CMYK. El hardware y software del dispositivo de salida se ocupan de convertir las imágenes según el perfil correcto, y se logra la mejor reproducción posible de nuestro original RGB en el impreso.

Sin embargo, en parte por costumbre, en parte porque esta parte del mundo está bastante atrasada en cuanto a la implementación de esas tecnologías (y en parte probablemente también por desconocimiento) se sigue trabajando con la otra opción, conocida como “early binding” donde se crea directamente el documento CMYK al principio y todo el trabajo se realiza en ese modo.
Pero esta forma de trabajar tiene desventajas a la vez que no presenta una ventaja clara que nos indique que deberíamos usarla en lugar de la otra.

La primera desventaja es la falta de flexibilidad. El ejemplo más claro es el software de Adobe, que permite trabajar con early binding pero la mayoría de los efectos y filtros disponibles no se pueden utilizar en el modo CMYK.
La explicación es simple: traducir esos filtros y funciones a CMYK sería un trabajo muy complicado y muy intensivo computacionalmente que se simplifica enormemente haciéndolo directamente en RGB.
Esta primera desventaja ya afecta directamente nuestra posibilidad de trabajo “creativo”. La decisión de trabajar con este método implica que podremos hacer menos con el software. La herramienta nos estará limitando.

Luego viene el gran tema de la gestión de color y los perfiles. Qué pasa cuando el perfil con el que se trabajó no corresponde con el perfil que utilizará nuestro impresor?
Primero, para que la imprenta sepa con qué perfil trabajamos este tiene que estar incrustado en el archivo. Si no lo está, van a tener que adivinar, y adivinar en el negocio de la imprenta no es lo más recomendable.
Si el archivo tiene el perfil incrustado, la imprenta tiene dos opciones: la correcta, que es convertir a su propio perfil o la incorrecta, que es desechar el perfil incrustado y asignarle su perfil de trabajo.
La segunda opción puede tener resultados mediocres a catastróficos, dependiendo de qué tan diferentes sea el perfil utilizado para la separación del perfil del dispositivo de impresión, pero de lo que podemos estar seguros es que no va a quedar bien.
La primera opción, la correcta, no va a tener ese problema. El sistema de gestión de color adaptará los colores de perfil de origen y destino de la forma más adecuada para lograr la apariencia correcta dentro de los parámetros posibles.
Pero estamos hablando de una nueva conversión de espacios de color. El espacio CMYK del perfil utilizado para la primera conversión RGB>CMYK era bastante más acotado que el RGB original y por lo tanto se perdió información de color. Repitiendo el proceso para llevarlo al nuevo perfil se pierde aún más información.
Y lo peor de todo: también perderemos nuestras separaciones originales, generación de negro y overprints en el proceso, porque para convertir de un perfil CMYK al otro se deberá pasar de ese modo de color “dependiente de dispositivo” a uno independiente, y volver a convertirse al dependiente correcto.

Hay que tener en cuenta que todos los errores en el ámbito de la gestión de color son acumulativos. Más errores cometemos, más lejos estaremos de lograr una buena reproducción del color, así que conviene mantener lo más controlado posible todo el proceso.

Reflexiones Finales
Lo que puedo deducir de todo esto es que el early binding (o sea, trabajar desde un principio en CMYK) sólo puede brindar algún beneficio si utilizamos el mismo perfil que utilizará la imprenta, de lo contrario habrá una pérdida adicional de información de color y nuestras separaciones no serán respetadas haciendo que sea mucho más conveniente trabajar directamente con RGB y dejar la conversión a CMYK como último paso, ya sea manualmente o dejando que el RIP se encargue.
El RGB además nos dará mayor libertad artística para aplicar filtros, efectos y transformaciones que no son posibles en el modo CMYK.
Si el software que utilizamos tiene un buen sistema de gestión de color y en nuestro hardware correctamente calibrado y perfilado podemos trabajar con un RGB corregido y hacer previsualizaciones del espacio de color tentativo de salida (utilizando soft-proofing y warning de fuera de gamut), tendremos todo lo necesario para trabajar de forma controlada y predecible, y eso se reflejará en nuestros impresos.

Cabe agregar en este punto que aunque Adobe contempla la posibilidad de trabajar con early binding, toda la información que podemos encontrar en su documentación parece indicar que recomiendan trabajar con late binding. La misma recomendación que hace Pantone en su sitio de soporte “myPantone”.

Debo confesar que en un principio al encontrarme con gente que me hablaba de todo esto en las listas de correo de los programas libres de diseño (antes de enterarme que era la misma recomendación de los grandes nombres de software de diseño) pensaba que estaban locos.
Los programas libres no tenían CMYK como los programas de Adobe y eso era todo lo que importaba. Para mi, si no lo tenían no estaban listos para el trabajo profesional. Y eso de que “el rip se encarga” sólo era en un mundo perfecto, no aquí.
Luego de investigar un poco llegué a la conclusión de que, aunque aquí sí es un poco diferente debido a la falta de tecnología y capacitación, todo eso que me decían se podía aplicar en nuestro ámbito y que todos estos principios tenían la misma validez.
Me alegra haberme encontrado con esta “limitación” en el software libre, ya que me obligó a interiorizarme en el tema y entender muchas cosas que antes daba por sentadas sin saber realmente por qué las estaba usando.
Así fue que empecé a trabajar con el “late binding”, primero por necesidad porque el software libre no me permitía otra cosa, pero ahora por elección, y con resultados muy satisfactorios.

El motivo de estos artículos es compartir esta experiencia y, si se puede, echar algo de luz sobre este tema, del que hay información pero rara vez agrupada de una forma útil para el que está empezando o migrando desde el software privativo al libre.
Creo que el verdadero profesional del diseño debería conocer esta información y las decisiones técnicas que toma deberían estar respaldadas por ese conocimiento. A lo largo de los últimos posts reproduje la información que me llevó a la conclusión de que en nuestro ámbito y con nuestros recursos pueden ser más provechosos unos seteos más conservadores y acordes a nuestra realidad que los seteos “por defecto” del software comercial que está preparado para un mercado que no es el nuestro.
Conociendo esta información estaremos en condiciones de brindar la mejor calidad posible con nuestros recursos, a la vez que estaremos preparados para resolver los problemas que se nos pueden plantear.
Una vez más repito: Profesional no es el software, es quien lo usa. Ser profesional significa estar interiorizado en todos los detalles de nuestro oficio, conocer la profesión y poder entregar un producto de calidad.
El software libre, que es el motivo de estos artículos y al que debo agradecerle porque con sus “limitaciones” me llevó a investigar sobre este tema, está perfectamente en condiciones de servirnos para nuestro trabajo “profesional”.
Herramientas como GIMP e Inkscape cuentan con gestión de color, necesaria para trabajar de forma controlada en un flujo “late binding” y contamos con herramientas que pueden ocuparse del paso final.
Entre esas herramientas se encuentran Separate+ y CMYKtool, que permiten separar un diseño RGB en CMYK, usando gestión de color y algunas opciones muy útiles de preservación de negros y grises.
Otro programa que puede utilizarse para esto es Scribus, que permite un flujo de trabajo mixto combinando los elementos en RGB que traemos de GIMP e Inkscape con elementos en CMYK y colores spot para luego enviarlos a una salida PDF lista para enviar a imprenta.

Con lo básico cubierto, es sólo cuestión de que el profesional desarrolle un buen flujo de trabajo con estas herramientas. Y llegado ese punto no hay diferencias sustanciales entre lo que se puede hacer con herramientas libres y herramientas comerciales. El buen profesional sabrá sacar de esto un resultado de calidad.

Me quedan un par de puntos por tocar, como una breve explicación de los diferentes “propósitos” de conversión de espacios de color, un par de ejemplos cotidianos del uso de sRGB vs. AdobeRGB para salida de impresión y un pequeño resumen/debate de lo que los defensores del CMYK consideran que se pierde al trabajar con un flujo de late binding. Pero queda para un próximo post, este se hizo larguísimo.

Share

Información y Enlaces

Integrese haciendo comentarios, revisando lo que otros tienen que decir o agregando enlaces desde su propio blog a nuestros Artículos


Otros Artículos

Agrege un Comentario

Tome un momento para hacer un comentario diciendonos que piensa. Se permite utilizar algunos comandos de HTML básico para dar formato al texto.

Comentarios de los Lectores

[…] – Introducción a la gestión de color – sRGB vs. AdobeRGB. Cuál utilizo? – RGB y CMYK. late binding vs. early binding – Reproducción fiable de color – RAW, Histogramas y Color de 16 bits – Paletas […]

Te felicito una vez más, Gez, por tus artículos.

Este, en concreto, creo que es sencillamente genial.

A ver si los “profesionales” del diseño empiezan a entender de una vez qué es realmente la conversión a CMYK y dejan de arguir el tan manido: “Si no tiene CMYK no sirve” cada vez que se habla del uso profesional de las herramientas de diseño libres…

Salu2 de jEsuSdA 8)

Este articulo me viene perfecto para explicar el tema, hay mucha gente que habla sin saber o repite lo que escucha y realmente no sabe sobre perfiles de color.

A todo lo ya planteado agregaría como ventaja que muchas cuestiones de retoque sobre la imagen son más sencillas y certeras en el modo RGB, por ejemplo el balance de blanco. Si tratamos de neutralizar una foto en modo CMYK es casi imposible, mientras en en modo RGB es mucho más sencillo, por ejemplo los grises deben tener valores similares de RGB… lograr un gris neutro en modo CMYK es casi imposible.
Por otro lado trabajar en RGB también optimiza los recursos del sistema ya que los archivos son más livianos debido a que guardan menos información (tienen un canal menos).

Muy buen artículo!!

Muy bueno tu blog, amigo Gez, en Venezuela no tenemos mucho ese problema porque al final de todo, en las imprentas las planchas se le mueven por milímetros, je je pero muy bueno, yo suelo usasr krita para no hacer el separate de gimp y ahí es que convierto a cmyk, hasta ahora no he recibido ninguna queja. Abro, convierto a cmyk, cierro y envio.

Siempre es un placer leerlo, amigo.
Están buenísimos todos tus artículos.

[…] en Fotocromía Como mencionaba en un post anterior, la primera decisión importante es el flujo de trabajo de color. Podemos trabajar con Early […]

Excelente artículo!! Me has aclarado mucho el tema. Gracias!!!!

Agrege aquMira lo que son las cosas.

Al igual que Guillermo Espertino, muchas de estas cosas las aprendi por las mias, investigando, probando, consultando y porque de porfiado y porque quiero traajar en forma HONESTA, PROFESIONAL y 100% LEGITIMA, uso EXCLUSIVAMENTE Software Libre bajo Linux.

En especial eso de trabajar en RGB y dejar el CMYK para el final, cuando exporto como PDF para mandar a CTP (Computer To Plate, o de computadora a chapa).

Utilizo SCRIBUS e importo desde INKSCAPE lo que no puedo hacer con SCRIBUS.
Puede ser en SVG o en PNG, a veces cuando hay efectos de sombras, brillos, y no queda otra.

En el Grupo de Facebook Diseño Gráfico Libre .UY he puesto algunos trabajos CONCRETOS y REALES.

Actualmente estoy haciendo almanaques a 4 tintas que requieren de estas tecnicas.
Ni bien los termine los subire.
Recuerden, NO SOY UN DISENADOR GRAFICO, no tengo el talento artistico, soy un DIAGRAMADOR DE IMPRENTA que entre otras muchas cosas, hace Diseno Grafico.

Gracias Daniel por compartir tu experiencia.
Creo que a esta altura está claro que se puede hacer diseño para imprenta con software libre, sólo que requiere procedimientos un poco diferentes a los que se acostumbran con el software privativo.
Lo importante que mencionás es que tu forma de trabajo es completamente legítima y además te da algo que el software no libre no te puede dar: Independencia. Nadie puede entrar a tu negocio a decirte cómo hacer las cosas ni a acusarte de ningún delito si el software que usás no lo pagaste :-)