pipeline de cor do darktable
A maioria dos aplicativos de processamento de imagens teve origem nos anos 1990 e/ou herdaram o fluxo de trabalho desses anos. Estes aplicativos processavam imagens codificadas com números inteiros de 8 bits sem sinal porque era mais eficiente em memória e computacionalmente. No entanto, devido ao uso de um formato inteiro (o que implica em erros de arredondamento) eles tiveram que aplicar um “gama” (essencialmente uma função de transferência aplicando uma potência de 1/2,2 ou 1/2,4 para codificar os valores de RGB) e aumentar a profundidade de bits em condições de pouca luz para reduzir os erros de arredondamento (os seres humanos são muito mais sensíveis aos detalhes em pouca luz). Os formatos de números inteiros de 8 bits também estão tecnicamente limitados ao intervalo de 0-255. Qualquer coisa fora deste intervalo se desborda e se recorta ao limite mais próximo.
Estes fluxos de trabalhos, que utilizam representações limitadas do RGB e possivelmente transformações não lineares para codificar sinais RGB, se denominam “relativos à exibição”. Se baseiam na suposição de que a imagem foi preparada para sua visualização em uma etapa inicial da pipeline de processamento e incorpora suposições codificadas de forma rígida sobre os valores RGB de preto, cinza médio e branco. A maioria dos algoritmos de processamento de imagens usados nestes fluxos de trabalho foram ajustados em torno destas suposições. Por exemplo, o modo de mesclagem de sobreposição espera um cinza médio codificado à 50% (ou 128 na codificação de número inteiro).
Infelizmente, a escala não linear, que é mandatória para realizar o trabalho de codificação de números inteiros, quebra o relacionamento natural entre os valores dos pixels. A tonalidade e a saturação mudam de maneira imprevisível e as relações de valor entre os pixels vizinhos são dilatadas ou comprimidas de modo que os gradientes também se alterem de forma imprevisível.
Pipelines relativas à exibição rompem filtros óticos (focagem e desfocagem de lentes), composição alfa (que se baseia em definições óticas e geométricas de oclusão) e gradientes de cores (relações locais entre crominância e luminância de pixels). Tão pouco escalam bem as imagens HDR, o que levou ao desenvolvimento de muitos métodos de mapeamento de tons locais e globais questionáveis e o infame “aspecto HDR” da década de 2010.
Os computadores modernos não estão restritos às mesmas limitações computacionais dos anos 1990 e podem trabalhar com pixels cujos valores são completamente ilimitados (de 0 ao infinito) e codificados como números reais (usando formatos de ponto flutuante). Estas possibilidades permitem o que denominamos de fluxo de trabalho “relativo à cena”, no qual pixels podem reter seus relacionamentos radiométricos originais ao longo da maior parte da pipe de processamento. No fluxo de trabalho relativo à cena, os pixels são preparados para exibição no último estágio da pipeline, na transformação para visualização. Isto significa que os valores RGB dos pixels são mantidos proporcionais à intensidade da emissão da luz registrada pela câmera na cena, permitindo uma composição alfa precisa e emulações de filtro ótico, enquanto se escala para qualquer alcance dinâmico por meio do mesmo algoritmo (tanto SDR como HDR).
No entanto, pipelines relativas à cena perdem os convenientes valores fixos de branco, cinza médio e preto que caracterizam as pipelines relativas à exibição, e estabelecer estes valores, de acordo com a cena e as condições de realização da fotografia, agora é responsabilidade do usuário. Isto requer uma interface com o usuário mais complexa.
Ademais, uma vez que os valores relativos à cena devem ser fisicamente significativos, pixels não podem possuir uma intensidade zero. Isso significaria que não possuem nenhuma luz e a existência de zero luz rompe muitos algoritmos fisicamente precisos. De fato, o branco e o preto não significam nada com respeito à cena original, que é somente uma coleção de luminâncias com diferentes intensidades. O fluxo de trabalho relativo à cena simplesmente tem como objetivo reatribuir algumas luminâncias da cena arbitrárias ao que aparecerá em branco ou preto na mídia de saída.
As versões do darktable anteriores à 2.6 possuíam uma pipeline relativa à exibição não linear, assumindo que uma transformação não linear ocorre no início da pipe e o cinza médio foi codificado como 50%. No entanto, nem todos os módulos e filtros recortam valores de pixels acima de 100%, deixando aberta a possibilidade de recuperar esses valores mais adiante na pipe.
A transformação da visualização do módulo fílmico, introduzida no darktable 2.6, foi o primeiro passo na direção de uma pipeline relativa à cena e atrasou a preparação para visualização obrigatória, não linear, para o final da pipe, junto com a capacidade de configurar valores personalizados de preto, cinza e branco. O módulo de balanço de cor então introduziu uma maneira de lidar com uma definição variável de cinza médio.
A partir do darktable 3.2, os usuários puderam escolher entre os dois fluxos de trabalho que definiam configurações padrão consistentes, módulos e ordem da pipeline tanto para o processamento relativo à exibição como para o relativo à cena.
No darktable 3.4, foram introduzidas opções de mascaramento e mesclagem completamente relativas à cena, o que permite definir máscaras para valores de pixels superiores à 100% e o uso somente de operadores de mesclagem ilimitados.
Mudar para o processamento relativo à cena é um salto cognitivo para a maioria dos usuários experientes, que estão acostumados a pensar em formas relativas à exibição. Em um fluxo de trabalho relativo à exibição, costuma-se ancorar o valor de branco e deixar que os ajustes de tonalidade girem ao redor deste ponto, tratando de maximizar o brilho e evitar o recorte. Em um fluxo de trabalho relativo à cena, os valores de branco e preto são fluídos e se adaptam à mídia de saída. É recomendável que usuários ancorem o cinza médio (que será preservado no estado para qualquer mídia de saída) e permitam que a transformação para visualização (fílmico) dilate ou contraia o alcance dinâmico ao redor deste ponto. Uma vez que o branco HDR de 10 bits é 4 vezes mais brilhante que o branco SDR de 8 bits, qualquer definição rígida de “branco” se torna irrelevante. Mas a ancoragem do cinza médio é na realidade mais conveniente, já que mantém o brilho médio da imagem inalterado durante a transformação para visualização.
Alguns módulos (níveis, níveis rgb, curva de tons, curva rgb) são intrinsecamente incompatíveis com um fluxo de trabalho relativo à cena, porque sua interface gráfica sugere implicitamente valores RGB que estão delimitados dentro do intervalo 0-100%. Apesar das operações de pixel que eles realizam poderem ser usadas em fluxos de trabalho relativos à cena ou à exibição porque não estão limitados internamente, sua interface de controle não permite que pixels sejam selecionados fora do intervalo 0-100%.
De maneira semelhante, os modos de mesclagem como superposição, luz linear, luz suave, luz intensa, escurecer, clarear, etc, possuem todos limites codificados que internamente esperam codificação não linear relativa à exibição.
No darktable 3.4 em diante, passar o cursor sobre o cabeçalho de um módulo exibe uma dica detalhando o espaço de cor, intervalos e codificações que o módulo espera, usa e produz. Aqui estão as definições dos termos usados:
- linear
- Os valores de pixels são proporcionais à emissão radiométrica da cena, de maneira que permitam uma precisa emulação dos filtros físicos.
- não-linear
- Os valores dos pixels são re-escalonados de modo que as luzes baixas recebem um intervalo de codificação maior, geralmente para remapear para o cinza médio de referência de 18,45% para um valor entre 46 e 50%.
- relativo à exibição
- Os valores do pixel devem estar entre 0 e 100% do alcance dinâmico, onde 100% é entendido como a luminância de uma superfície branca refletida à 20% (a parte branca do Cartão de Cor) e 0% é entendido como a máxima densidade da mídia de saída (tinta preta saturada ou retro iluminação mínima do painel de LED).
- relativo à cena
- Os valores de pixel devem ser superiores à zero até o infinito. O significado dos valores de pixels específicos deve ser definido pelo usuário em tempo de execução. Os valores relativos à cena não implicam automaticamente em uma codificação linear, escalada radiometricamente.