Blog

Desde que comprendí administración de color, me dí cuenta de una mala praxis acerca de cómo trabajaba archivos con codificación logarítmica, como Log-C, S-Log y otras. Y también la mala interpretación que hacía al leer archivos Raw.
En general suponía erróneamente que la codificación Log había que deshacerla manualmente, por lo que el punto de partida del trabajo de color era ese material “lavado” “chato” “sin contraste y saturación”.
No suponía además que ese material poseía colores primarios que no necesariamente eran los primarios RGB de mi monitor HD, sino otros muy diferentes, los cuales definen el gamut nativo de cámara.
El error recurrente y muy propagado en ámbitos profesionales, e incluso canales de youtube que enseñan este proceder incorrecto, es el de realizar una corrección “manual” sobre los valores Log, utilizando una curva o ajustando gamma y otros valores de corrección directamente sobre el material. De esta manera se pierde el gamut nativo y además se interpreta de manera incorrecta la exposición original.
Al utilizar espacios de trabajo Display Referred, como proyectos o timelines Rec.709, existe la opción de realizar la transformación del material con funciones matemáticas como en Resolve el OpenFX “Color Space Transform”, desde el cual puede definir como entrada el color nativo y codificación del material, para así convertirse al espacio del timeline.
En Scratch es un poco diferente, pues la aplicación puede cambiar de espacio de trabajo por evento de edición, de manera que en un mismo timeline pueden coexistir diferentes espacios de trabajo como ACES, o bien P3, 2020, 709, etc. Los settings de Scratch se realizan desde el menú Media/Data Format.
Los que trabajamos con Mistika o Baselight puede que tengamos más clara la administración color, pues es mucho más explícita que en otras plataformas.
Al implementar ACES como administrador de color, simplemente seleccionando como IDT la codificación de cámara y gamut, se convierte el material hacia ACES, el cual vuelve a convertirse hacia 709.
En el caso de archivos Raw esta identificación no suele ser necesaria gracias a los metadatos del Raw.
A veces a primera vista la conversión puede parecer sobreexpuesta, y esto se corrige o bien desde el valor ISO del Raw, o bien para archivos Log desde la corrección de color modificando Offset. De esta manera se vuelca el alto rango dinámico de manera adecuada hacia el rango dinámico del display que estemos utilizando, aprovechando así la diferencia entre estos rangos, lo cual da lugar a la “latitud” que es ese margen de diferencia corregible entre el rango de la captación original y el rango de visualización, siendo este segundo un rango menor.
Los archivos Raw, al leerse en proyectos Display Referred por ejemplo un timeline 709, permiten reinterpretar el media desde el propio decodificador, el cual posibilita la transformación a 709. Este sería entonces la manera “justa” de iniciar el grading en el caso de elegir este pipeline de color basado en la posibilidad de reproducción del Display. Otros espacios de salida estarán disponibles, de tal manera que el propio decoder Raw realice las transformaciones a otros espacios de trabajo con diferentes gamuts y diferentes valores “gamma” (término confuso, pues en realidad la función de transferencia no es sólo una función meramente exponencial, sino casi siempre mixta), pero estos parámetros se inhiben en el decoder al utilizar administración de color desde la aplicación, por lo que la codificación lineal del Raw se vuelca junto a su gamut nativo hacia el espacio de trabajo.
Síntoma de la incomprensión de la administración de color es el famoso demo reel del colorista que muestra un “antes/después” donde el antes es la codificación Log. Esto supone que la decodificación Log no la realiza con la transformación opuesta correspondiente (-OETF), sino que deshacer el bajo contraste aparente de la codificación Log supone una pericia del propio colorista, lo cual es un error conceptual.
Este error común es fácil de subsanar, comprendiendo cómo utilizar las herramientas de administración de color incluidas en todas las aplicaciones de grading.
Edi Walger - ColorDoctor

Dentro de los correctores de color no hay color alguno: el color es una sensación. La computadora te diría: hablame de números...
Y eso es la imagen para ella, sólo una sucesión de números que tarde o temprano representarán los elementos de la imagen en colores. Pinceladas una tras otra, en forma de secuencia numérica. Y con la aplicación de color, poder alterar estas sensaciones a través de una modificación matemática.
Entre aplicaciones, las funciones matemáticas no varían gran cosa: sumar, multiplicar, invertir, potenciar.
Pero el orden lo es todo. No es lo mismo sumar 1 mas 1 y luego dividir por 2, que sumar 1 a uno dividido dos:
(1+1)/2=1 ... no es igual a 1+1/2=1,5
Las redes sociales están llenas de esos cartelitos que desafían a realizar correctamente una cuenta, teniendo en cuenta qué términos resolver primero y el paréntesis lo aclara todo.
En los correctores de color pasa lo mismo, pero con muchas funciones matemáticas concatenadas, donde unas se resuelven antes que otras. Este orden define el Algorítmo del corrector, y entre Resolve y Scratch, aunque las funciones son casi las mismas, la diferencia en el algoritmo resulta en manipulaciones muy diferentes.
En Resolve, la propuesta es extender el rango dinámico ajustando negro y blanco, luego poder realizar un desplazamiento del rango dinámico, para finalmente definir la relación de contraste y su amplitud.
En cambio en Scratch el orden es totalmente distinto. Primero se define el desplazamiento global del rango dinámico, para luego ajustar la relación de contraste, y desde allí el punto blanco, la amplitud de contraste y finalmente el punto negro.
Si desearíamos reordenar las funciones matemáticas de tal manera de emular el algoritmo de un corrector dentro del otro, simplemente se deben concatenar muchos correctores y tocar sólo los parámetros en el orden deseado.
Esto en Resolve se consigue agregando nodos y en cada uno sólo operar con las funciones descriptas en el gráfico que señala el orden del algoritmo de Scratch.
En Scratch, agregar los layers necesarios para así reordenar las funciones al estilo Resolve:
Lift (invertir-multiplicar-invertir), Gain (multiplicar), Offset (sumar), Gamma (elevar a la potencia), Contrast (multiplicar la diferencia con el valor Pivot).
Resolve={ [ {1-[(1-pixel)*Lift]}*Gain+Offset ]^(1/Gamma) }Δ Pivot * Contrast
Simplemente con cinco instancias del mismo corrector se pueden reordenar las funciones elementales de corrección y emular en una aplicación el estilo de corrección de la otra, teniendo en cuenta que cada instancia deberá alterar sólo el parámetro que deseamos reordenar.
Edi Walger - ColorDoctor