Deprecated: Array and string offset access syntax with curly braces is deprecated in /www/604fa5ff1ad38/htdocs/misc/typo3/phar-stream-wrapper/src/PharStreamWrapper.php on line 445

Deprecated: Array and string offset access syntax with curly braces is deprecated in /www/604fa5ff1ad38/htdocs/sites/all/modules/entity_translation/includes/translation.handler.inc on line 1764
Mala Praxis con Log | Edi Walger

Mala Praxis con Log

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