Blog

La relación entre la magnitud física que provoca un estímulo y la respuesta sensorial obtenida nunca posee una proporción lineal. Ya fue estudiado por Weber, y reformulada por Fechner en forma de Ley científica, en el siglo 19. Para simplificarla, podría decirles que la Ley establece que la primera copa que bebamos no producirá el mismo efecto que la décima.
Cineon fue una codificación desarrollada por Kodak para no guardar datos binarios obtenidos por el escaner de película donde el stock fotográfico no poseía respuesta alguna. Esto sucedía debido a que el haluro de plata del stock era desarrollado para poseer una respuesta no lineal similar al sistema visual humano, y la codificación cineon lo que permitía era eliminar datos de la respuesta lineal del sensor electrónico del escaner, resultando en la reducción del archivo original de 16 bits en un archivo de apenas 10 bits sin sacrificar calidad alguna.
El efecto fotoeléctrico, el cual permite al sensor electrónico del escaner o de una cámara transducir fotones en señal eléctrica, sí posee una proporción lineal. Por lo que todo sensor internamente se vale de una respuesta lineal al estímulo. Entonces a diferencia del cine analógico, en una cámara de cine digital estos datos de luces altas sí existen. Esta respuesta puede almacenarse de manera cruda en un archivo Raw. Este archivo grande y absoluto, al no coincidir con la respuesta no lineal del sistema visual humano distribuirá gran cantidad de datos en los tonos que consideramos muy brillantes y muy poquitos datos en los oscuros.
Sin embargo existen métodos para reducir esta inequidad entre las luces altas y las bajas, modificando la relación original entre lo óptico (luz) y lo eléctrico (señal), a través de una función matemática de transferencia: Opto-electrical Transfer Function. OETF.
Estas funciones de alguna manera redistribuyen los bits entre los stops captados por la cámara, lo cual posibilita guardar el gran rango dinámico de la cámara en un contenedor de sólo 12 o 10 bits. Son las denominadas codificaciones Log, como S-Log, V-Log, Log-C, C-Log, D-Log y otras que son mencionadas con el adjetivo film, como el anterior RedLogFilm, reemplazado hoy por el Log3G10, o el FilmGamma de BMC. Todas estas codificaciones deben deshacerse con las funciones opuestas o OETF -¹ antes de comenzar a trabajar sobre ellas.
Por otro lado poseemos dispositivos de reproducción electrónicos, los cuales deberán establecer una relación inversa entre la señal y la luz emitida resultante, estableciendo una función de transferencia electro-óptica, o EOTF. En el caso de los displays de rango dinámico estandar, una función matemática de transferencia exponencial en vez de logarítmica es suficiente para que la señal almacenada haga su transducción a luz de manera coherente. Esta función exponencial se denomina Gamma.
Entonces Gamma y Log son funciones matemáticas que sirven para acomodar valores dentro de rangos dinámicos estándares o extendidos. Gamma 2,2 o 2,4, incluso 2,6 son valores utilizados para convertir electricidad en luz en pantallas de computadora, TVs SDR o proyectores de cine SDR. La mayoría de las funciones de transferencia son mixtas, esto quiere decir que poseen porciones del rango dinámico codificadas en partes lineales, exponenciales y logarítmicas. Es por ello que a veces conviene llamar a las OETF con sus letras S (Sony) V (Varicam) C (Canon o si está al final, “tipo Cineon” de ARRI) y no “Log” a secas, pues son funciones compuestas y no puramente “Log”. Lo mismo sucede con sRGB que puede parecer gamma 2,2 pero en realidad es una combinación de una porción de codificación lineal con una codificación gamma 2,4. La decodificación hacia los flat panels es conocida como BT.1886 e internamente es un gamma 2,4 exacto, paradojas del argot técnico.
El HDR debido a que expresa un rango dinámico enorme en una señal de de apenas 10 o 12 bits también utiliza codificaciones híbridas, como el HLG (Hybrid Log Gamma) o el PQ (Perceptual Quantizer, o ST.2084).
Pero entonces, qué quieren expresar esas “Curvas” opcionales de cámaras, como las Cinestyle, Cinelike D, V, o el RedGamma4, estas son también codificaciones que luego se deshacen antes de comenzar a trabajar? Son maneras de obtener mayor latitud de la cámara en un contenedor de video?
No!
Son funciones matemáticas, las cuales en un eje cartesiano expresarían una curva la cual intenta ser similar a la curva sensitométrica pero del positivo, y no imitar la respuesta del negativo.
Para qué se utilizarían entonces? Para realizar una corrección de color en cámara, de manera tal de poder grabar en un contenedor de video de 10 u 8 bits una imagen procesada desde el sensor que nos brinde detalles en bajas y altas, de manera similar a lo que realizaba la copia positiva con su curva sensitométrica. Este proceso, realizado con herramientas de corrección de color digitales se denomina Tone Mapping.
Este resultado es agradable a la vista, pues de alguna manera emula lo que realiza involuntariamente el músculo del iris en el ojo humano, el cual es capaz de acomodarse rápidamente permitiendo ver un stop extra en lo claro o oscuro, variando el diámetro pupilar en tiempo real. Esta búsqueda de detalle se encuentra más saciada cuando la imagen visualizada posee detalles suficientes en lo oscuro y lo claro, lo cual puede conseguirse con una “curva en forma de letra Ese”.
  • Los modos de grabación “Standard” suelen referirse a codificaciones de estándares como HD Rec.709 o UHD Rec.2020, de rango dinámico estandar o SDR.
  • El video HDR se codifica bajo la Rec.2100 con HLG o PQ, ambas con los primarios 2020 del UHD.
  • Los modos de grabación “Log” se refieren a convertir la señal lineal a una OETF que permita guardar los primarios nativos de cámara en contenedores de 10 o 12 bits.
  • Los modos Cine se refieren a características de la imagen cinematográfica respecto a la apariencia o “look”, los cuales son agradables a primera vista. Se refieren más al positivo que al negativo.
Pero así como la película positiva, los modos “Cine” no son modos de grabación que brindan una latitud extra, sino que se trata de un Tone Mapping realizado en tiempo real por la cámara, pero partiendo del “readout” HDR del sensor. Es entonces sólo una buena alternativa para cuando no se pueda grabar archivos mayores que 8 o 10 bits, los cuales tienen más limitaciones para portar codificaciones Log.
Así que cuidado con las curvas peligrosas!
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