Este post está enfocado especialmente para texture artists, aunque no viene mal para todos aquellos que trabajen con referencias fotográficas en un pipeline de efectos visuales. Como texture artist trabajando en VFX lo más normal es que desde hace años no trabajes con Photoshop. Aparte de las limitaciones de no poder pintar en 3D, de no poder trabajar con UDIMs y de lo engorroso y lento que es gestionar toda la información que vas generando día a día, el mayor problema de Photoshop es la gestión de color (LUTs, ACES, OIIO, etc) y del rango dinámico. Por eso y por la estandarización de software de texturizado como Mari (que no tiene las limitaciones mencionadas), Photoshop ha pasado a ser una herramienta obsoleta para los que nos dedicamos a pintar texturas en proyectos de efectos visuales.

Aún así, sigo utilizando Photoshop para una sola tarea, eliminar sombras y reflejos de mis referencias utilizando la herramienta Shadows&Highlights. Sólo para eso.
Generalmente, en los VFX facilities solemos disponer de cross polarized references, carentes de información no deseable como sombras y reflejos, pero no en el 100% de los casos, y cuando te topas con referencias que han sido fotografiadas utilizando técnicas más comunes, no queda otras que intentar eliminar esta información no deseada como buenamente puedas. La herramienta Shadows&Highlights es muy buena para este propósito.

Pero comentaba, uno de los mayores defectos de Photoshop es como trata el rango dinámico. Trabajar con imágenes .exr de 16 o 32 bits es simplemente infernal. Muchas de las operaciones disponibles en Photoshop están desactivadas o requieren que hagas un merge del layer stack. Esto significa, en muchas ocasiones perder rango dinámico, tener que convertir imágenes de 32 bits a 16 bits, incluso a 8 bits. Es decir, descartado, lo ultimo que quiero es perder rango dinámico en mis referencias, que generalmente serán fotografías RAW compuestas de al menos 3 exposiciones, es decir, imágenes HDRI con alto rango dinámico.

Otro de los grandes defectos de Photoshop es la gestión de color. Si en el proyecto en el que estoy trabajando utiliza un determinado LUT (para resumir, un color grading bestial que simula por ejemplo, una determinada emulsión de película) y altera la apariencia visual de mis referencias, necesito visualizar mis imágenes bajo las mismas circunstancias en Photosop. Imposible debido a la carencia de gestión de color en Photoshop.
Afortunadamente en la última versión de Photoshop (CS6 y CC) han incorporado una capa de ajuste llamada Color Lookup que permite cargar algunos formatos comunes de archivos LUT. Esto entre otras cosas me permite poder utilizar Photoshop de vez en cuando si lo necesitase para alguna tarea extraordinaria de texturizado, como por ejemplo, la mencionada herramienta Shadows&Highlights. Veamos como.

Si trabajamos en un espacio de color sRGB

  • En Nuke tengo mis referencias en formato .exr 16 bits linear.
  • Para poder abrirlas en Photoshop sin ningún tipo de limitación, necesitamos guardarlas en formato .tif 16 bits linear.
  • Si las abrimos en Photoshop, se verán de forma incorrecta. Para visualizarlas correctamente basta con añadir un gamma correction 2.2 (solución cercana al espacio de color sRGB).
  • Tras hacer los cambios oportunos en las referencias, desactivar el gamma correction y volver a guardar la imagen como .tif 16 bits.
  • Leer en Nuke como linear.

 

  • Para seguir trabajando en el pipeline VFX, es decir, para importar en Mari o para llevársela a Maya para render, conviene convertir en .exr linear.

Si trabajamos en un espacio de color LUT

  • Visualizar las imágenes en Nuke 16 bits .exr linear a través del LUT.
  • Escribirlas como 16 bits .tif linear para poder abrirlas en Photoshop sin limitaciones.
  • En Photoshop abrir las imágenes y utilizar un Color Lookup con el LUT. Guardar la imagen como 16 bits .tif con el Color Lookup desactivado.
  • Leer en Nuke como linear.
  • Para seguir en el pipeline de VFX de nuevo conviene escribirla como 16 bits .exr linear.
  • Si las importamos en Mari con el LUT activado deberían de verse exactamente igual.
  • Del mismo modo debería de ocurrir a la hora de renderizar en Maya y Arnold (o cualquier otro software).

A estas alturas no vamos a explicar nada relacionado con Linear Workflow, Gamma Correction, Color Spaces, etc. Seguramente ya todos llevamos años trabajando así y de lo contrario, existen muchos recursos en internet con información al respecto. En este mismo blog podéis encontrar información relacionada con este tópico en esta entrada del blog, o en esta o quizás en esta. También si buscáis el término Linear Workflow en la sección tutoriales.

El caso es que Autodesk Maya 2016 viene con una serie de novedades, entre ellas la gestión de color, lo que hace que por ejemplo, el Gamma Correction en Arnold Render se vea ligeramente alterado con respecto a versiones anteriores de Maya. Parece que esto está causando algunas confusiones entre algunos usuarios de Arnold, así que vamos a explicar de forma sencilla como configurar Maya 2016 y Arnold para trabajar de forma correcta. Nótese que esta no es la única forma de configurar LWF correctamente, pero es la que más me gusta a mi.

En las preferencias de Maya tenemos que activar el Color Managment. Lo ideal es renderizar siempre de forma linear y que el view transformation sea siempre sRGB (o LUT en el caso de estar utilizando uno). El input color space vamos a dejarlo como sRGB aunque después será Arnold el encargado de dictaminar el color space de nuestras texturas.

Como prueba para chequear que todo funciona correctamente, vamos a utilizar dos texturas de Macbeth Chart. La primera es una textura linear en formato .exr y la segunda una textura sRGB en formato .jpg Estos son generalmente los dos tipos de inputs que vamos a encontrar en una producción, linear y sRGB.
Si leemos ambas como linear, que es lo que ocurre a la hora de renderizar (hay que linearizar las texturas siempre) comprobaremos que la textura sRGB no se ve de forma correcta. Bien, lo mismo debería ocurrir en Maya y Arnold.

En las opciones de render de Arnold, en el apartado Gamma Correction, tenemos que poner todos los parámetros a 1.0
Esto quiere decir que Arnold espera que todos los inputs estén linearizados. Como ya dije anteriormente, hay que linearizar las texturas siempre.

El Macbeth Chart de arriba es el que tiene aplicado la textura linear .exr y el Macbeth Chart de abajo tiene aplicada la textura sRGB .jpg
La esfera diffuse tiene aplicado un color neutral grey 50%

Cuando lanzamos un render, ya que Arnold espera que todos los inputs estén linearizados, el Macbeth Chart de abajo y la esfera gris se van a ver de forma incorrectaLa solución es linearizarlos antes del render.

Existen dos formas de linearizar los inputs. La primera pasa por colocar invert gamma correction en todas las texturas que no estén linearizadas. Es decir, cualquier textura en espacio de color sRGB sea cual sea su formato. En este ejemplo solo tendremos que corregir la textura del Macbeth Chart de abajo.

Si renderizamos de nuevo, los dos Macbeth Charts deberían de verse de forma correcta.

La esfera diffuse sigue sin verse correctamente. Esto ocurre porque Maya está tratando al color plano 50% grey como si estuviese en el espacio de renderizado (linear). Así que tenemos que decirle que lo trate como si estuviese en el espacio de visionado (sRGB).

Ahora si renderizamos de nuevo, todo se verá de forma correcta.

Antes comentaba que existen dos formas de linearizar las texturas. La primera es la que hemos visto, la segunda, es la recomendada, ya que obviamos gamma correction nodes y ahorramos tiempo de computación al render.
Consiste en convertir las texturas al formato .tx que por otro lado me imagino que ya estás acostumbrado a convertir tus texturas a este formato ya que las texturas han de ser convertidas a MIP-mapped textures sobre todo, para ahorrarte infinidad de tiempo en el renderizado.

En el caso de texturas en espacio de color sRGB no olvides utilizar la opción "--colorconvert sRGB to linear"

Si ahora eliminamos todos los nodos gamma correction y sustituimos las texturas por su equivalente .tx obtendremos el resultado esperado.

No está de más mencionar que en la última versión de Arnold, SolidAngle proporciona su propio Frame Buffer. Puedes encontrarlo en el menú Arnold -> Experimental -> MtoA RenderView

Donde entre otras opciones, puedes cargar directamente un LUT.

Huelga decir que nuestros renders siempre van a ser lineares, así que se verán correctamente en Nuke. Basta con leerlos como linear y visionarlos como sRGB (o LUT) al igual que en Maya.

Cualquier duda, pásate por el foro o deja un comentario en el blog.

Render utilizando Ptex.

¿Qué ocurre si estás trabajando con Ptex pero necesitas hacer algún tipo de detalle de desplazamiento en Zbrush? ¿Cómo se puede renderizar eso?

Como seguramente sepas, en este momento Zbrush no soporta Ptex. Como ya comentaba en el post anterior, no soy un gran fan de Ptex, pero eso va a cambiar en el futuro, probablemente. La mayor ventaja (para mi) de utilizar Ptex, es como comentaba, la posibilidad de no tener que realizar UV mapping. Pero entonces, si Zbrush no soporta Ptex, y no tengo tiempo/ganas de realizar UV mapping, ¿cómo puedo esculpir en Zbrush y exportar mis mapas de desplazamiento para ser renderizados en Ptex?

Render sin displacemet.

  • En la imagen de abajo, tengo un scan 3D el cual he procesado en Meshlab para reducir la cantidad de poligonos a un numero aceptable para poder trabajar en otros software.
  • El siguiente paso, es importar el modelo en Zbrush. 500.000 polígonos son suficientes para poder trabajar de forma fluida y mantener los detalles que me interesan en este particular modelo.
  • Voy a utilizar Zbrush para generar una retopología rápida, automática. Puedes por supuesto utilizar Maya o Modo para generara un modelo consistente de quads, listo para producción. Para el propósito de esta demo, una retopología automática es suficiente.
  • Utilizando la herramienta Zremesher podemos crear una topología más que digna para este propósito en diez segundos.
  • El siguiente paso consiste en exportar tanto el modelo original de alta resolución, como el modelo de baja resolución. Puedes utilizar el formato .obj
  • Vamos a importar los dos en Mudbox para extraer el mapa de desplazamiento utilizando Ptex. Mudbox si soporta Ptex.
  • Una vez importados los dos modelos, mantén los dos visibles.
  • Exporta los displacement maps de forma normal.
  • Lo más importante de las opciones que has de tocar está señalado en la imagen de abajo.
  • Y ya está, todo debería de renderizarse correctamente.

Allá por el 2009 Walt Disney Animation Studios presentó Ptex, y sobre el papel, parecía la mejor solución posible para cualquier pipeline complejo de VFX (y también de feature animation). Muchos de los problemas comunes del texturizado, podrían esfumarse con este nuevo sistema de texturizado por caras. Lo cierto es que más de seis años después, nadie utiliza Ptex.

Bueno, tampoco pretendo ser tan contundente, mejor debería de decir que no conozco a nadie que utilice Ptex, salvo claro, Walt Disney Animation Studios (sus propios creadores por otra parte) y seguro algún estudio o boutique más, probablemente.
He trabajado en, con o para, Dr.D-Animal Logic, MPC, Dneg, Framestore, ILM, Digital Domain, Rythm&Hues y varios middle size y boutiques de VFX alrededor del mundo, y aún no he tenido la oportunidad de trabajar utilizando Ptex.

Y me da rabia. Ptex es una gran solución, estaría encantado de incorporarlo en mi sistema de trabajo diario, pero la realidad es la que es, UDIM sigue siendo el sistema de trabajo estandard cuando hablamos de pipelines de texturizado.

¿Cuáles creo que son los beneficios de utilizar Ptex?

  • El primero y más importante, eliminamos el proceso de UV Mapping. Genial! A priori puede parecer poca cosa, pero realizar el UV Mapping de un asset complejo, y además, hacerlo bien, es una tarea muy complicada, y precisa de un modelador con mucha experiencia y conocimientos específicos. Además, con cada iteración de modelado las UVs pueden verse alteradas, teniendo que modificar las UVs existentes.
  • No hay seams ni overlappings. Con Ptex también eliminamos varios de los problemas más engorrosos del UV Mapping, como por ejemplo seams y overlappings, que pueden causar resultados muy inesperados en el look de nuestros assets, especialmente cuando utilizamos displacement maps (es decir, siempre).
  • No necesitas gestionar ficheros. Bueno en realidad si, pero solo es un fichero por canal. Mientra que cuando trabajamos con UDIMs necesitamos cientos, que digo cientos, miles de ficheros de texturas para assets complejos. Con Ptex nos bastaría con un solo archivo (bastante pesado por cierto) para cada canal de textura.
  • Puedes almacenar todo tipo de datos en los ficheros Ptex. 8 bits, 16  bits, 32 bits, vector displacements, integer o float.
  • Se aprovecha toda la resolución posible, no hay espacios UV vacíos como ocurre con UDIM y tradicional UV Mapping.
  • Se puede variar fácilmente la resolución de las texturas. Cada parte del asset puede tener una resolución diferente en función de las necesidades del plano. De hecho, cada cara del modelo puede tener una resolución diferente.
  • Walt Disney Animation Studios dice que Ptex es más rápido que UDIMs mipmapped. Puedes encontrar varias tablas en internet con los resultados de sus tests.

¿Cuáles creo que son los puntos flacos de Ptex?

  • No user friendly. La mayoría de texture artist les gusta pintar tanto en 3D como en 2D. Con Ptex no puedes pintar en 2D.
  • Limitación de software. No todos los motores de render soportan Ptex. Cierto es que la mayoría si, pero no todos, y entre los que no soportan Ptex, el mejor render del momento.
  • Comunicación inexistente entre software. Ptex es un archivo de texto. Obviamente no se puede abrir en Photoshop (si es que queda algún texture artist utilizando Photoshop) ni en Nuke. Y ese si es un problema grave. Y aquí otro problema grave, tampoco Zbruh soporta Ptex. Si, ya se que Mudbox soporta Ptex, pero si eres texture artist y utilizas Mudbox, seguramente también utlizas Photoshop, así que es bastante probable que estés en un ambiente más bien amateur, no en un VFX facility.
  • UDIM está muy arraigado en todos los VFX facilities del mundo desde hace mas de una década, y funciona muy bien si el UV Mapping es bueno. A los artistas no les gustan los cambios, y menos cuando no se aprecian con la vista. Ptex a priori, solo es buena solución para los artistas porque no necesitaríamos emplear nuestro tiempo en realizar UV Mapping. No vemos mas allá de eso. (por desgracia).
  • Si no hay suficiente geometría (tessellation) es difícil conseguir buena resolución de texturas.
  • Poca información y ejemplos horribles. Apenas existe documentación sobre Ptex y los ejemplos visuales (repito, a los artistas se les convence por los ojos -o la cartera-) son patéticos. En la web oficial de Ptex hay un dinosaurio de juguete, una tetera y un cubo. Y las referencias constantes que Walt Disney hace sobre ejemplos de producción se reducen a la película Bolt. Muy bonita, pero si quieres vender un sistema de texturizado a VFX facilities necesitas mostrar ejemplos más ambiciosos desde el punto de vista de assets development.

Algunos usos alternativos/inteligentes que le he dado a Ptex

  • Para limpiar 3D scans, Lidars o Photogrammetry en Zbrush, hacer retopologías automáticas (para objetos que no necesitan rigging) exportar todo a Mudbox y extraer displacement maps utilizando Ptex sin perder ni un minuto en hacer UV Mapping para assets irrelevantes.
  • Empezar la tarea de texturizado en Mari cuando el modelo ha sido finalizado pero las UVs aún no están listas. Después, cuando el modelador haya terminado el UV Mapping, transferir lo pintado en Ptex a las UVs y continuar desde ahí.

¿Entonce Xuan, a ti te gusta Ptex?

Si, me gusta. Pero si me dan las UVs hechas (que es el caso) no veo razones de peso para dejar UDIMs en favor de Ptex.
Supongo que si tuviese que hacer un extreme close up, me forzaría a utilizar Ptex. Supongo que si me mostrasen un montón de ejemplos visuales realizados por importantes texture artists, me forzaría a utilizarlo. Supongo que si pudiese leer un montón de información interesante (de cara a artistas) sobre Ptex me forzaría a utilizarlo. Supongo que si...

Por el momento, utilizaré Ptex única y exclusivamente para proyectos personales y tests donde yo mismo tenga que realizar tareas de UV Mapping que no me apetezca (o no tenga tiempo) realizar.


Reflexiones de aeropuerto :)

Posted
AuthorXuan Prada

Este video es una pequeña demo que grabé hace tiempo explicando como utilizar el gizmo de Nuke "mmColorTarget" creado por Marco Meyer.

En el video explico primero como instalarlo en Mac, que no es cosa fácil. De hecho, si encuentras otra forma de hacerlo, agradecería que la compartieras.
Después, explico los usos que yo le doy en relación con referencias de texturas, background plates e Image Based Lightning.

El video originalmente fue creado para xuanprada.com así que está en inglés, aunque supongo no tendrás mayores problemas en seguirlo.

Conocer los aspectos técnicos detrás del color en efectos visuales es algo realmente complejo. La ciencia del color aplicada a la creación de imágenes sinteticas, es un tópico denso, complicado de entender (y explicar) y sin duda, yo no estoy capacitado para hacerlo de una forma correcta y precisa. Si realmente estás interesado en como funciona el color y como debemos utilizarlo en un pipeline complejo de VFX, te recomiendo que le eches un vistazo al paper publicado por VES, donde recoge en profundidad todos los tópicos que necesitas estudiar en relacion al color en el mundo audiovisual.

Lo que si voy a intentar explicarte de la forma más amena posible son los conceptos básicos y necesarios que considero cualquier VFX artist ha de comprender para poder desenvolverse con soltura en un pipeline de efectos visuales en cualquier estudio de VFX.

El color en efectos visuales parece ser un tema tabú, que mucha gente parece no comprender, otros ni siquiera están al corriente de como gestionamos el color en nuestros proyectos, y algunos, ni siquiera se interesan por el asunto. Tiempo atrás, algunos dejaron de trabajar en 8 bits y empezaron a trabajar de forma lineal. De esto hace años, y mucha gente hablaba de Linear Workflow, aunque la mayoría, se quedaron en como corregir los mapas de texturas para que su input fuese lineal y como renderizar imágenes flotantes de forma lineal sin hacer un bake de gamma.

Sin duda, es un paso, pero la mayoría de artistas siguen sin comprender los diferentes sistemas de color utilizados en VFX, incluso aquellos artistas trabajando en grandes VFX facilities. Muchos escuchamos términos como ACES o LUT, y realmente no sabemos que significan, o por qué debemos utilizarlos. Simplemente somos conscientes de que las imágenes mostradas en nuestro monitor de trabajo son diferentes cuando utilizamos un LUT u otro.

Por otro lado, profesionales trabajando en boutiques de VFX o estudiantes, nunca se han enfrentado a este tipo de terminología relacionada con el color, y cuando llegan a un estudio más grande, o simplemente han de colaborar en un proyecto global con varias boutiques, o realizan outsourcing para grandes estudios, etc. se topan directamente con algunos conceptos relacionados con el color que desconocen completamente.

Intentemos desde este blog arrojar un poco de información relacionada con este tema tan importante y necesario, siempre desde el punto de vista de quien escribe, un artista de efectos visuales, con las carencias que uno pueda tener en un campo tan complejo como la ciencia del color.

Asunciones generales

Como VFX artists vamos a tener que lidiar con diferentes tipos de material relacionados con color. Por simplificar el proceso digamos que tendremos que preocuparnos por recoger el material que viene de un set de rodaje, después tendremos que pensar en como almacenar ese material para poder utilizarlo a lo largo del pipeline de producción cinematográfica, después lo más importante será como poder visualizarlo correctamente, como trabajarlo en un entorno de VFX y finalmente, como distribuirlo para que pueda ser utilizado de forma correcta en las fases posteriores a la realización de los efectos visuales. 

En set de rodaje, lo más importante relacionado con color son las fuentes lumínicas artificiales y las cámaras. Temperatura de color y tintado son las propiedades más importantes de las que debemos estar al tanto. Siempre necesitaremos Macbeth Charts y otros color samples para poder trabajar el color grading de forma correcta. La resolución y profundidad de color del material rodado también cobra importancia cuando trabajamos con color. LED, tungsteno, Kinoflo, etc. cada fuente lumínica tiene propiedades diferentes que tenemos que conocer para poder trabajar con los diferentes recursos de forma correcta, eficaz y sobre todo, consistentemente.

  • Todos los estudios de VFX son diferentes.

Todos los estudios de VFX para los que he trabajado y con los que he trabajado, abordan la gestión de color de forma diferente, lo que me hace pensar que nadie trabaja de la misma forma. Es lógico, cada estudio (especialmente los grandes) utilizan un montón de herramientas propias que requieren ser tratadas de forma extraordinaria.

Como bien sabéis, no hay un solo proyecto que se realice de forma íntegra en un solo estudio de VFX, así que siempre toca lidiar con pipelines de color de otros estudios, ya que se comparten assets y otros materiales entre varios facilities.

  • 8 bits

En el pasado solíamos trabajar en sistemas de color de 8 bits. Sin entrar en mucho detalle, digamos que solíamos bakear un gamma en la imagen de salida, esto permitía que las imágenes producidas se pudiesen representar bien en los dispositivos utilizados, tv, cine, monitor, etc. Podemos referirnos a este sistema de trabajo como sRGB pipeline.

No creo que quede un solo estudio sobre la faz de la tierra trabajando en 8 bits. Todos ya trabajamos de forma linear. Supongo que tu también.

  • Physical Based Workflow

Hoy en día, prácticamente todos los estudios tienden a trabajar en un physical based workflow, donde todo el material se interpreta de forma linear. Footage, texturas, luces, shaders, renders, composición, etc. todo es o se convierte a linear para que los cálculos sean correctos. Nos referimos también a este sistema de trabajo como High Dynamic Range Pipeline o simplemente Linear Pipeline.

Cuando trabajamos en un Physical Based Workflow entendemos que utilizamos Plausible Lighting, Physical Based Shading y Physical Based Lighting and Rendering.

  • Luts

Luts o Look Up Table, son por resumirlo mucho, archivos digitales que simulan la emulsión de una película fotográfica existente o inventada. Es decir, cuando aplicamos un LUT a un footage o a un render, éste va a cambiar en función del LUT aplicado. Los LUTs cambian en función del show y generalmente son elegidos por el cinematógrafo antes de rodar el proyecto. La productora se encargara de proporcionar el LUT utilizado a los diferentes departamentos que figuran en la producción cinematográfica, como VFX, editing, o DI.

En efectos visuales es extremadamente importante trabajar siempre con el LUT del show aplicado, ya que el resultado tras aplicar el LUT en ocasiones es extremadamente diferente. Es por esto que por ejemplo aplicaciones como Photoshop han quedado prácticamente desterradas de los pipelines de VFX, ya que no tienen soporte para LUTs y otros sistemas de color de los que hablaremos más adelante.

  • Gamut

El gamut es el rango de color disponible en una imagen. Este rango de color puede variar de forma considerable en función del espacio de color utilizado. A continuación hablaremos de diferentes espacios de color.

Múltiple información, múltiples software

Independientemente de cual sea nuestro pipeline de VFX vamos a necesitar utilizar una cantidad de software ingente y tendremos que utilizar y generar todo tipo de información visual.

Partiremos seguramente de scans o footage de alta resolución (4k o 6k) en diferentes formatos y espacios de color, pero siempre con un rango dinámico muy alto. Muchas veces estos scans no son puramente digitales, aún se ruedan muchísimas películas en film, así que los scans puede que sean negativos escaneados.

También tendremos que trabajar con footage en 8 bits, con imágenes, HDR, con imágenes LDR, con texturas de todo tipo, etc.

Cuando hablamos de software, utilizaremos software comercial como Maya, Nuke, Mari, Arnold, Vray, RenderMan, Clarisse, Katana, Houdini, etc. Cada uno de estos paquetes son perfectamente capaces de gestionar color para VFX de diferentes formas. Además de todos los mencionados anteriormente, la mayoría de estudios de efectos visuales utilizan software propietario para cubrir sus necesidades más especificas.

En resumen, hay un montón de variables relacionadas con el color en nuestro pipeline, y si no las conocemos y si no somos consistentes a la hora de trabajar con color, seremos incapaces de realizar nuestra labor como VFX artists.

Output

Los efectos visuales no son el final del proceso cinematográfico, como muchos pueden pensar. Tras terminar los VFX de cualquier película, el material generado por el estudio al igual que el resto del footage rodado, pasan a la sala de DI (Digital Intermediate) donde el color va a sufrir importantes modificaciones artísticas en base a las opiniones subjetivas del director, el cinematógrafo y el colorista.

Si el material proporcionado por el estudio de VFX no tiene la suficiente calidad e información de color, cuando este sea manipulado en la sala de DI, empezaran a aparecer todo tipo de artefactos, banding, etc. así que tenemos que asegurarnos de que el material que generemos como VFX artists cumpla con los requisitos necesarios.

Ciencia del color

La energía de la luz puede medirse con la siguiente gráfica de longitud de onda o wavelength cuyas unidades son nm.
El espectro visible que el ojo humano es capaz de apreciar oscila entre 380nm y 780nm.

El sistema de vision humano es tricromático y ha sido mapeado al sistema de color CIE 1931 para que podamos medir colores físicos puros (wavelenght) en señales electromagnéticas correspondientes al espectro visible humano.

En las imágenes más abajo, tenemos representado el espectro en su totalidad. El triángulo mas grande corresponde al espectro visible humano, prueba de que no somos capaces en entender visualmente toda la información existente en la naturaleza.
El triángulo mediano, corresponde al gamut representado en el espacio de color REC 709 o también llamado HDTV

En las dos imágenes de abajo, podemos ver a la izquierda el gamut en el espacio de color sRGB y a la derecha, en el espacio de color CIE RGB. Lo que esto pone de manifiesto es que en función del espacio de color que utilicemos, vamos a ser capaces de revelar de forma directa más o menos información, con los pros y contras que ello conlleva.

RGB es un sistema de codificación de color que utiliza colores primarios (rojo, verde y azul) para crear un gamut específico. Recuerda que el gamut es el rango de colores, y que como hemos visto, varía en función del espacio de color utilizado. Este look basado en coloes primarios está obligadamente ligado al dispositivo donde se muestran las imágenes, nunca se ven de forma linear, siempre necesitan de un espacio de color pasa ser representados de forma correcta.

Display (sRGB) vs Scene (Linear)

Los espacios de color diseñados en relación con el dispositivo donde se van a representar imágenes, son llamados Display Referred, y varían como decimos, en función del dispositivo. Monitor, iPad, proyector, etc.

  • En cuanto a colorimetría se refiere, se define en función de lo mostrado en pantalla.
  • El rango dinámico es el que se ve en pantalla, no hay más.
  • sRGB se utiliza como espacio de color en dispositivos RGB (gamma 2.2).
  • Requiere de linearización (gamma inversa).

Los espacios de color diseñados para dispositivos de entrada son llamados Scene Referred.

  • Los valores no son definidos en base a imagen en pantalla si no en base a unidades globales del mundo real.
  • Se trabaja de forma linear.
  • No hay valores máximos, por eso imágenes HDRI tienen valores extremadamente altos.
  • Nos referimos a sus valores mediante stops, no mediante valores numéricos de pixels. No hablamos de contraste en términos de 1000:1 si no en términos de rango dinámico. A fin de cuentas, este es el lenguaje cinematográfico y cuando un cinematógrafo dice "aumenta 1 stop" se refiere a que dobles la iluminación de la escena.
  • Para poder visualizar correctamente Scene Referred material, necesitamos aplicar un tone mapping a las imágenes, ya que si no, se verían demasiado oscuras. La mayoría de monitores no son capaces de visualizar imágenes lineares, por eso tenemos que aplicar tone mapping para poder visualizar imágenes HDR en monitores LDR.
  • Un mínimo de 16 bits es necesario para trabajar con este tipo de imágenes.

Log

En ocasiones puede que nos encontremos con ficheros Log de 10 bits. En su día fueron el sistema estándar a través de Cineon y DPX aunque han sido prácticamente sustituidos por Floating Point .EXR
Generalmente cuando vemos este tipo de imágenes en un monitor RGB aparecerán completamente lavadas, es necesario visualizarlas con una codificación apropiada.

ACES y OPENCOLOR IO

Academy Color Encoding Space es un "nuevo" sistema de gestión de color que muchos estudios de VFX ya utilizan, guarda toda la información en Open EXR.
El espacio de color es High Dynamic Range o Scene Referred Linear Space, lo que quiere decir que el gris medio sera de 0.18 y no de 0.5

En la imagen de abajo se puede ver que el gamut o rango de color, es tan grande como el propio espectro visible.

aces.png

OPENCOLOR IO es otro pipeline de color open-source adoptado por varios estudios de VFX cuyas mayores ventajas son la unificación de transformaciones y visionados de color entre múltiples plataformas y aplicaciones, lo que asegura una mayor estandarización.

¿Y en mi casa qué?

En tu casa has de trabajar siempre de forma linear. Si no partes de material linear tendrás que convertirlo.
Las operaciones en el motor de render siempre ocurren de forma linear, y tanto los inputs como los outputs han de ser lineares.

Si por ejemplo estás pintando texturas en Mari, hazlo en 16 bits (o 32 si es necesario) y expórtalas en formato .EXR
Si por el contrario, partes de fotografías descargadas de internet, estas serán de 8 bits .jpg por ejemplo. Así que deberás de linearizarlas antes de poder renderizarlas. Basta con añadir una función gamma 2.2 inversa. El siguiente gráfico muestra a la perfección como han de ser los inputs y los outputs.

Siempre vas a renderizar de forma linear y para poder visualizar tus renders de forma correcta simplemente has de utilizar el espacio de color apropiado para tu dispositivo. Generalmente sRGB.
En el caso de utilizar un LUT concreto, simplemente selecciónalo en Maya, en Nuke, en Mari o en el software que utilices. Lee la docuemntación de tu motor de render favorito para entender como interpreta la gestión de color.

Nueva gestión de color en Maya 2016

Cada software es único y la gestión del color se hace diferente dependiendo del producto y la versión. Vamos a ilustrar como funciona en Maya 2016, por aquello de ser el software standard en la industria y además, incorporar un nuevo sistema de gestión de color en esta nueva versión 2016.

  • En las preferencias, asegúrate de tener activado Enable Color Managment.
  • En el apartado Color Transformation, has de tener como Rendering Space linear sRGB, también podrías utilizar otros espacio de color si fuese necesario, como ACES, REC, CIE, etc. Seguramente en tu casa sólo vayas a utilizar linear sRGB.
  • En la opción View Transform, utilizarás sRGB ya que vas a visionar tus imágenes en un monitor LDR. Podrías utilizar RAW en el caso de utilizar un monitor HDR o LOG por ejemplo. Pero generalmente en casa, no vas a utilizarlos.
  • Existe la opción utilizar un pipeline OCIO y una ruta para seleccionar el archivo proporcionado para la producción.
  • También existe la opción de indicar el espacio de color por defecto de tus imágenes. Puedes seleccionar sRGB o Linear. Por supuesto depende de tu pipeline de texturizado, generalmente en un VFX facility será Linear.
  • En el apartado Output, existe la opción de hacer un bake de gamma al render final. Nunca vamos a utilizar esto.
  • Un poco más abajo existe la opción de utilizar un fichero LUT, cuando sea necesario este será el lugar de colocarlo.
  • El último setting que podemos necesitar es el llamado Show Color Managed Pots, para corregir por ejemplo, color swatches en los shaders.
  • En este ejemplo, tengo dos MacBeth Charts completamente idénticas, la de la izquierda es una imagen de 8 bits en espacio de color sRGB .jpg. La imagen de la derecha es una imagen linear float point 16 bits .exr. Como puedes comprobar se visualiza de forma incorrecta en el visor de imágenes de OSX, porque éste no tiene forma de transformar el espacio de representación, como haría por ejemplo Nuke.
  • Si queremos aplicar estas dos texturas en un pipeline de color linear, la imagen de la derecha funcionaría perfectamente, la imagen de la izquierda necesita ser linearizada.
  • Para ello puedes añadir un inverse gamma de 2.2 (0.455) o cambiar el color space en el attribute editor a sRGB. En el caso de utilizar una imagen linear .exr deberíamos utilizar la opción RAW. Si utilizamos un pipeline linear, no necesitaríamos cambiar el color space de las imágenes lineares, ya que por defecto, hemos indicado en las opciones de Maya que estamos trabajando de forma linear.

Espero que haya quedado un poco más claro como gestionamos en color en proyectos de efectos visuales.