El flujo de trabajo referido por escena

En este artículo, aprenderá qué es el flujo de trabajo referido por escena, cómo lo usa Ansel y por qué beneficia al procesamiento de imágenes digitales en general.

Introducción

El flujo de trabajo referido por escena es la columna vertebral de la tubería de imágenes de Ansel. Es una lógica de trabajo que proviene de la industria del cine, porque es la única manera de lograr una composición robusta y sin fisuras (también conocida como alpha blending) de gráficos en capas, de los cuales dependen en gran medida las películas para mezclar efectos especiales generados por computadora con imágenes de la vida real. Para los fotógrafos, es principalmente para escenas de alto rango dinámico (HDR) (sujeto a contraluz, puestas de sol, etc.) que demuestra ser útil.

Si ha estado utilizando cualquier tipo de software de procesamiento de imágenes hasta ahora, ya debería estar familiarizado con el flujo de trabajo referido por pantalla, pero sin saber ni su nombre ni sus supuestos centrales. Explicar cómo difiere el referido por escena de este referido por pantalla no hablado al que estás acostumbrado va a ser un desafío sin explicar qué fue antes referido por pantalla.

Hacer una imagen

Cuando tomas una foto de una escena, el sensor de tu cámara convierte un espectro de luz en 3 señales eléctricas, al igual que las células del cono de la retina lo hacen antes de enviar impulsos eléctricos al nervio óptico. Los detalles están más allá del alcance de este artículo, pero supongamos que el espectro de luz se divide en tres intensidades R, G y B de tal manera que la relación de R, G y B en cada píxel es una representación bastante adecuada de la forma del espectro.

graph TD;
tO[fa:fa-bulb Fuente de luz] --> A;
    A[] --> B["fa:fa-camera Sensor (Nikon D5100)"];
    B --> C[Sensor RGB
];
    A --> D["fa:fa-eye Ojo humano"];
    D --> E[Cone LMS
];
    E ------> F["fa:fa-brain Cerebro humano"];
    F --> G[Color estímulo
];
n    C --> H["fa:fa-laptop Mucho trabajo digital"];
    H --> HH[sRGB
];
    HH --> I[fa:fa-desktop Pantalla];
    I --> J[];
    J --> K["fa:fa-eye Ojo humano / fa:fa-brain Cerebro humano"];
    K --> L[Color estímulo
];

Debemos observar que el principio y el final de la tubería gráfica son un espectro de luz que, si es idéntico, producirá el mismo estímulo de color para el observador¹. Pero los espectros de luz son en realidad bastante diferentes: los picos grandes del iluminante FL1 se han suavizado una vez que se muestran en una pantalla sRGB. La diferencia entre la escena original y su representación en pantalla proviene de las pérdidas de señal que son inevitables cuando se reduce un espectro a RGB, que está diseñado para trabajar solo con espectros similares a la luz solar (suaves). Esta suposición a menudo se olvida, y el problema que vemos aquí no es una sorpresa, dado que el iluminante FL1 tiene un CRI  de 76 %. De hecho, podemos predecir cómo un iluminante como este, aunque técnicamente equilibrado para D65, afectará la representación del color:

Entonces este iluminante hará que las superficies rojas y moradas parezcan menos saturadas de lo que deberían, en comparación con otras superficies coloreadas, y también cambiará sus tonos. Las superficies azules y verdes parecerán prácticamente no afectadas. Sin embargo, podemos notar que el color percibido real de un tal iluminante (es decir, “el tono de blanco”) no muestra un cambio visible a pesar de la diferencia de espectro. La desviación de color relativa es de hecho inferior al 0,001 % en coordenadas cromáticas u’v’. Esto es todo para mostrar que las complicaciones entre espectros (tanto del iluminante como de la luz reflejada por materiales, superficies coloreadas) y la percepción del color están lejos de ser intuitivas y claramente no son fáciles de predecir.

De manera similar, ambos órganos tecnológicos involucrados en la captura de la señal y su restitución trabajan en RGB. Pero, ninguno de los espacios RGB involucrados coincide realmente con el cono LMS. Si queremos que la imagen digital se vea remotamente similar a la percepción humana de la escena, necesitaremos trabajar arduamente para que eso suceda, manipulando digitalmente la señal RGB sin necesariamente preocuparnos por la percepción en el proceso. Será suficiente asegurar la consistencia del espectro de luz en ambos extremos.

Este es un aspecto mal entendido de la fotografía digital donde a menudo se piensa en la manipulación digital como un engaño o alteración de contenido, y la imagen en bruto a menudo se ve como una especie de verdad “neutral” u “objetiva” porque fue realizada por una máquina. La imagen producida por la máquina en realidad está bastante fuera de lugar y la manipulación digital es absolutamente necesaria para que se vea como la escena original a pesar de todas las distorsiones ópticas que ocurrieron en la cámara.

Arreglar el RGB en bruto para que se vea más o menos como lo que el espectador experimentó en la escena requiere manipular colores, utilizando al menos un perfil de color de entrada y un ajuste de balance de blancos. Desafortunadamente, estos son inexactos y aún no coincidirán exactamente con la visión humana, especialmente cuando la fuente de luz de la escena no es una luz natural (con un espectro “completo”). En el ejemplo anterior, la bombilla fluorescente muestra un espectro picado que hará que algunos colores muy particulares parezcan más saturados y brillantes que el resto, lo que será un desafío corregir.²

La propiedad de esta señal RGB en bruto es ser lineal con respecto a la escena: los valores de código RGB son aproximadamente proporcionales a la energía de la emisión de luz. Esta es la representación más cercana que podemos tomar de un espectro de luz, pendiente de una tubería completamente espectral (como en Manuka ).

Desafortunadamente, en la mayoría de los casos no podemos simplemente enviar este RGB lineal a la pantalla de la computadora, incluso después de corregir los colores para que coincidans con la visión humana, normalmente porque:

1. el rango dinámico que los sensores pueden capturar es mucho mayor que lo que las pantallas pueden representar,
2. para utilizar mejor este rango dinámico, los fabricantes de cámaras “subexponen” la escena aproximadamente 2/3 de EV, lo que hará que el RGB en bruto aparezca bastante oscuro.

Por lo tanto, al menos necesitamos aclarar los tonos medios y generalmente comprimir los reflejos, lo cual es el trabajo de la transformación de visualización.

En los firmwares de cámaras y en aplicaciones típicas de edición de imágenes, esta transformación de visualización se logra comúnmente a través de una “curva” (aunque la curva es solo la representación gráfica de la transformación, no la transformación en sí) que se asemeja a esta:

After

Before

La pendiente de esta curva determina el contraste global. Muchas aplicaciones propietarias aplicarán una curva así sin informarte y sin permitirte desactivarla, por lo que es posible que no tengas idea de lo que está sucediendo tras bambalinas. Algunas aplicaciones solo te permiten elegir una apariencia base entre “predeterminado”, “neutral”, “retrato”, “intenso”, “HDR”, etc., que cargará una curva diferente. Algunas aplicaciones incluso incorporan la curva en el perfil de color de entrada.

Trabajando en una imagen

En la sección anterior, aprendimos que tendríamos que trabajar no solo para reconstruir una representación de color creíble a partir del RGB en bruto, sino también para reorganizar el rango dinámico de la escena adecuadamente para el dispositivo de visualización de destino. Aquí, veremos cómo se realiza realmente este trabajo, estudiando más específicamente el paso “Mucha obra digital” del esquema de flujo de la sección anterior.

Si generalizamos cómo funciona cualquier software de procesamiento de imágenes, siendo editores típicos de escritorio, firmware de cámara, aplicaciones móviles, sin importar el flujo de trabajo que usan, llegamos a este diagrama de flujo:

graph TD
    A((fa:fa-sun Escena)) --> B([Lectura del sensor en bruto]);
    B --> C;
n
    subgraph Software;
      C["(Lineal) Perfilado de color"];
      C --> D[Procesamiento referido a la escena];
      D --> E["(No lineal) Transformación de visualización"];
      E --> I[Procesamiento referido a la visualización];
      I --> G[Sistema de gestión de color];
    end;
n
    G --> H([Buffer de pantalla]);
    H --> J((fa:fa-lightbulb Pantalla));
n
    style D fill:#BAFFD2;
    style I fill:#FFB7B5;

Las aplicaciones típicas de imágenes no utilizan en absoluto el procesamiento referido a la escena, o solo para algunos filtros técnicos de reconstrucción de imagen, por lo que pasan directamente del perfilado de color a la transformación de visualización. La manipulación digital sucede únicamente en el espacio de visualización, donde “blanco” se fuerza al 100% (o el valor de código 255 al trabajar en RGB de 8 bits), “negro” se fuerza al 0% (o el valor de código 0 en RGB de 8 bits), y el gris medio suele estar en medio al 45-50% (ver más detalles a continuación).

El problema de esta lógica radica en el ciclo de vida de la imagen:

graph LR;
tA[fa:fa-tree Escena] --> B[fa:fa-camera Cámara];
tB --> C[__FLUJO DE TRABAJO__];
tC --> D[fa:fa-poop Sistema de gestión de color];
tD --> E[fa:fa-desktop Pantalla SDR];
tD --> F[fa:fa-sun Pantalla HDR];
tD --> G[fa:fa-print Impresión de alta calidad];
tD --> H[fa:fa-book Libros/Revistas];
tD --> I[fa:fa-tshirt Merch];
tD --> J[fa:fa-save Archivos];

Debido a que el medio de visualización objetivo ahora puede ser cualquier cosa, desde una camiseta hasta una pantalla HDR, y todo lo que haya en medio, necesitamos usar diferentes transformaciones de visualización para considerar las propiedades del medio objetivo. Pero si usamos la transformación de visualización como el primer paso de nuestra edición, cambiarla a menudo anulará la edición subsiguiente, especialmente si utilizó máscaras paramétricas. Esto prácticamente significa que necesitas rehacer tu edición para cada medio de salida, lo cual es tedioso.

Trabajar en la parte referida a la escena del canal de procesamiento significa que trabajamos antes de la transformación de visualización y nuestra edición será inmune a las discrepancias del medio de salida. Esto es como trabajar en una “edición maestra” que permanecerá igual, sin importar el resultado, y luego lidiar con los detalles del resultado cuando exportamos la maestra. Eliminar la parte referida a la visualización del flujo de trabajo permite colapsar la transformación de visualización y los pasos de gestión de color, lo cual es muy deseable porque todos tratan con la misma tarea: mapear la “edición maestra” a cualquier medio de salida que tengamos, corrigiendo sus peculiaridades para intentar preservar la apariencia de color intencional para la audiencia.

El desafío de trabajar en la parte referida a la escena es que “blanco” ya no se puede asumir que esté anclado a un valor específico, pero puede ser algo positivo hasta el infinito. Para sortear esta falta de referencia, pasamos de un pipeline “centrado en el blanco” a uno “centrado en el gris”, donde se espera que el gris medio reflectante (el de las cartas grises) esté anclado a 0.18-0.20. Dado que el “blanco” HDR puede ser 4 veces más brillante que el “blanco” SDR, todo lo que sabemos es que todos los dispositivos tendrán un gris medio alrededor de 0.20 y todos los dispositivos podrán mostrarlo, sin importar su rango dinámico. También resulta que las imágenes de escenas naturales tienen la mayor parte de su histograma centrado alrededor de este valor.

Podemos resumir la suposición de cada flujo de trabajo a continuación:

Las codificaciones RGB son la representación digital de la imagen dentro de la computadora. No están directamente conectadas a la luminancia del mundo real, ya sea registrada en la escena original o en la pantalla de visualización. Por ejemplo, la luminancia de los píxeles negros medida en pantallas físicas estará alrededor de 0.1 Cd/m², mientras que se codificará como 0 en RGB. En el flujo de trabajo referido a la escena, a menudo necesitamos compensar el negro para que no sea un valor RGB cero para reconectarlo con su significado luminoso, en el cual confiamos.

Al trabajar en espacios RGB codificados con una OETF  (erróneamente llamada “gamma”), como sRGB, Adobe RGB o Prophoto RGB, se espera que el gris medio esté alrededor del 45% del rango de codificación.³ Las aplicaciones que tienen un pipeline de enteros de 8 bits tienen que usar RGB codificado con OETF para evitar la posterización en gradientes. Las aplicaciones que tienen un pipeline de enteros de 16 bits a menudo eligen hacer lo mismo por consistencia, aunque no es un requisito técnico en este caso. El gris medio se codificará al 18% del rango de codificación en flujos de trabajo referidos a la visualización que utilizan RGB lineal, es decir, espacios RGB despojados de su OETF/gamma.

Ahora podemos igualar las suposiciones de cada flujo de trabajo en los valores de código RGB a su significado en términos de luminancia real:

Los valores en Cd/m² en la columna referida a la visualización provienen de los estándares ISO habituales previo a la impresión. La luminancia del punto negro de la pantalla se puede definir opcionalmente en el perfil ICC del medio, lo que a menudo es el caso de perfiles de impresoras fabricados profesionalmente, para habilitar la compensación del punto negro . Dado que el OETF se decodifica dentro de la pantalla, el valor de luminancia del gris medio está conectado al valor de código RVB lineal y se encontrará al 18-20 % de la luminancia del blanco de la pantalla.

Para el flujo de trabajo referido a la escena, las luminancias del negro y del blanco coinciden con las luminancias mínimas y máximas encontradas en la escena. La referencia del gris medio es el parche de gris medio de un Color Checker (o una carta gris) iluminado bajo las mismas condiciones que el sujeto de la imagen. Por lo tanto, es posible configurar el gris medio directamente a partir de muestrear la luminancia de una carta gris en una foto de prueba.

Beneficios prácticos del flujo de trabajo referido a la escena

Hemos visto en la sección anterior que el flujo de trabajo referido a la escena te permite trabajar en tu edición maestra independientemente de cualquier medio objetivo fijo. Los beneficios de esto no terminan allí.

Primero, porque la referencia a la escena está diseñada en torno a la idea de que “blanco” no tiene un valor fijo particular, puede escalar a cualquier rango dinámico de entrada, lo que significa que se pueden usar las mismas herramientas y flujo de trabajo para procesar fotografías digitales, renderizados sintéticos o cualquier tipo de HDR compuesto.

Luego, donde realmente destaca es para todos los filtros digitales definidos ópticamente que intentan imitar efectos de la vida real, como desenfocar, desenfatizar, eliminar ruido o reconstruir señales. El ejemplo a continuación muestra la diferencia que hace aplicar un filtro de desenfoque digital, simulando un diafragma de lente, antes o después de la transformación de visualización.

After

Before

Dado que el desenfoque de lente ocurre sobre la luz, y el RGB lineal a la escena es la representación digital más cercana que podemos tener de la luz real, solo tiene sentido aplicar filtros digitales definidos ópticamente en la parte lineal de la escena del canal de procesamiento, pero el ejemplo anterior confirma visualmente la validez del razonamiento.

Se observarán efectos similares al trabajar con máscaras y composición alfa, cuando uno quiera suavizar y alisar los bordes de las máscaras para mezclarlos mejor con el entorno (lo cual, de nuevo, es un desenfoque).

¿Cómo se implementa en Ansel?

Ansel es capaz de usar tanto el flujo de trabajo referido a la visualización como el referido a la escena, porque hereda algunos módulos heredados de darktable. La mayoría de los módulos referidos a la visualización han sido reemplazados por sus contrapartes referidas a la escena, y los restantes deberían seguir en 2023.

Pronto, Ansel será completamente referido a la escena, permitiendo transformaciones de visualización más inteligentes combinadas con mapeo de gama y extracciones de perfiles ICC.

Generalmente no es posible usar módulos referidos a la visualización en la parte referida a la escena del canal de procesamiento, porque esperan un punto blanco al 100 %, y generalmente recortarán los valores RGB por encima del 100 % (algunos necesitan hacerlo para evitar inestabilidades numéricas en algoritmos). Algunos incluso esperan un punto gris al 50 %, como los modos de combinación alfa  pantalla, luz suave, luz dura, superponer, dodge, burn que procesan píxeles de manera diferente si sus valores son mayores o menores que el umbral del 50%.