Imagens HDR lineares semi-flutuantes de 16 bits como texturas (difusa / albedo)?


10

Então, eu estive pensando nisso por um tempo e tentei procurar no Google por uma resposta, mas sem sucesso.

Se todas as suas texturas forem imagens LDR de 8 bits, como JPEGs, isso não poderá causar conflitos com o controle de exposição / mapeamento de tom durante a renderização. Ou seja, se você ajustar a exposição de renderização da sua imagem, que deve expor detalhes nas texturas que realmente não existem, uma vez que foram restringidas pela baixa faixa dinâmica. Portanto, não faria sentido também ter as texturas como imagens HDR, salvas como .exr, no espaço linear de cores com half-float de 16 bits para obter uma boa representação de cores (a flutuação "cheia" de 32 bits pode ser um exagero?). Ter valores de cores mais detalhados e corretos também pode ter um efeito sobre o IG e como o sangramento de cores é calculado?

Ou simplesmente não é necessário, pois o resultado final da renderização que desejamos provavelmente será semelhante ao nível de exposição da textura quando foi fotografada de alguma maneira? E como a câmera fotografa principalmente em 12-14 bits, você teria que fazer várias exposições da textura e fazer todo esse trabalho extra para juntar todas em um HDRI.

Edit: Para esclarecer, estou mais interessado nisso do ponto de vista da renderização foto-realista, com renderizadores de traços de raios (como mental ray, V-Ray, Arnold etc.) com simulações de luz total e iluminação global, em vez de motores de jogos em tempo real.

Respostas:


8

Na produção de filmes, quase nunca usamos texturas de 8 bits para cores / albedo, por causa de faixas etc. (JPEG é especialmente problemático, pois, por especificação, é sRGB em vez de valores lineares). ) ou valores inteiros não assinados de 16 bits para texturas de cores / albedo.


1
Uau, obrigado @LarryGritz! Considerando que você trabalha para a Sony Pictures Imageworks, considero você uma fonte muito confiável! :) Mas como você captura essas texturas? A maioria das câmeras filma apenas em arquivos RAW de 14 bits. Você possui câmeras especiais com sensores lineares de 16 bits? Ou você tira várias exposições de texturas, assim como a iluminação baseada em imagens HDRI? Ou você simplesmente captura com a câmera RAW de 14 bits e a salva como "16 bits"? Ow e qual formato de arquivo você usa, .tiff (.tx, .tex) ou .exr? Mais uma vez obrigado pela sua contribuição !! :)
Kristoffer Helander

1
@KristofferHelander: A conversão da captura de 14 bits para uma representação de 16 bits da faixa de 0-1 é facilmente alcançada por multiplicação. Mas a maioria das nossas texturas é pintada, não é fotografada - algumas vezes, diretamente no formato de 16 bits, outras em sRGB e depois convertidas em 16 bits quando "linearizadas" para serem usadas como textura. Não há necessidade de HDR para texturas de albedo.
Larry Gritz

1
@KristofferHelander: Para texturas albedo, tendemos a usar TIFF com dados inteiros de 16 bits (o que chamamos de .tx é apenas o formato TIFF, mas lado a lado e com a multirresolução de mapa MIP armazenada como várias sub-imagens no arquivo TIFF). Para dados HDR verdadeiros, como capturas de ambiente, usamos o OpenEXR. A saída do renderizador também tende a ser OpenEXR.
Larry Gritz

8

Sim, em alguns casos extremos é possível que a iluminação HDR e o mapeamento de tons exponham problemas de faixas nas texturas coloridas. Nesses casos, ter uma profundidade de bits mais alta para as texturas pode ser útil. No entanto, na minha experiência, a maioria dos materiais e situações comuns de iluminação não apresentam esse problema, e a maioria das texturas em um jogo típico é boa em 8 bits (ou até menos - os jogos costumam usar a compressão BC1, o que os reduz para 5) 6-5 bits).

As pessoas usam alvos de renderização HDR porque uma única cena pode conter magnitudes de brilho muito diferentes, como uma sala escura na qual é possível ver através de uma janela um exterior iluminado pelo sol 10 a 100 vezes mais brilhante que a sala. No entanto, as texturas coloridas não têm uma gama tão grande de magnitudes. Eles representam refletâncias, que são inerentemente na faixa de [0, 1] e, na prática, poucos materiais cotidianos são inferiores a cerca de 2 a 5% de refletância. Portanto, uma imagem de 8 bits (com codificação gama) geralmente pode representar cores difusas e especulares com precisão suficiente.

É verdade que a combinação de uma textura bastante escura com iluminação muito brilhante ou uma configuração de câmera extremamente superexposta pode mostrar faixas no quadro final, mas esse seria um caso mais incomum.

Um caso em que você provavelmente desejaria uma textura HDR são os materiais emissivos, especialmente para sinais de néon e fontes de luz semelhantes. A textura apareceria com seu valor ampliado para aparecer como uma fonte de luz brilhante no jogo, portanto, nesse caso, uma imagem de 8 bits poderia facilmente mostrar faixas.

Finalmente, ainda pode ser útil trabalhar com maior precisão (por exemplo, precisão de 16 bits) se possível ao capturar e criar texturas, simplesmente porque oferece mais espaço para processar a imagem sem causar problemas de precisão. Por exemplo, se você precisar ajustar níveis ou equilíbrio de cores, perderá um pouco de precisão; que pode introduzir faixas (especialmente se você fizer isso várias vezes) ao iniciar a partir de uma imagem de origem de 8 bits. Uma fonte de 16 bits seria mais resistente a esses problemas. No entanto, a textura final usada no jogo provavelmente ainda será compactada para 8 bits.


combination of a quite dark texture with very bright lighting or an extremely overexposed camera setting can show banding in the final framemuito bom insight. Mas podemos observar que a codificação gama está aqui precisamente para mitigar esse ponto. Se ele tem o problema, por que não tentar um expoente gama superior? isso inibiria o uso de samplers sRGB de hardware.
v.oddou

Obrigdo por sua contribuição. Mas, para esclarecer, estou mais interessado nisso do ponto de vista da renderização foto-realista, com renderizadores de traços de raios (como mental ray, V-Ray, Arnold etc.) com simulações de luz total e iluminação global, em vez de real motores de jogos antigos.
Kristoffer Helander

@KristofferHelander É bom saber, mas acho que o que escrevi provavelmente se aplica também à renderização offline. Mas admito que não tenho muita experiência direta nessa área.
Nathan Reed

@NathanReed Sim, você certamente fez alguns realmente bons pontos lá :)
Kristoffer Helander

5

Gostaria de convidar os leitores a ler este artigo sobre a tecnologia de rasterização de mecanismo Quake 2, explicada em detalhes , se eles tiverem tempo.

Se TLDR, preste atenção a esta imagem: insira a descrição da imagem aqui

O que vemos é o canal Albedo , é o que você deseja codificar em 16 bits, se eu entender sua pergunta corretamente.
Não vou dizer " se poderia ser codificado em 256 cores para jogos no passado, por que precisaríamos de 281474976710656 (ou seja, 281 trilhões) em novos jogos? ", Mesmo que eu queira, mas isso soa como o cara rabugento da pixar de Acima. Mais construtivamente, se você notou nesta imagem, tudo está no mesmo nível de iluminação . Mais particularmente, a intensidade máxima possível que preserva a saturação desejada. (ou seja, no espaço HSV, V está no máximo)

A ênfase é fundamental, quase não precisamos de bits porque o albedo não tem profundidade para codificar de qualquer maneira. A dinâmica vem do sombreamento, faz sentido trabalhar f32por componentes dentro dos sombreadores e produzir para f16renderizar alvos. Mas armazenar texturas de albedo f16não apenas é um exagero, mas também é um grave prejuízo injustificado para a nossa preciosa largura de banda.


Obrigdo por sua contribuição. Mas, para esclarecer, estou mais interessado nisso do ponto de vista da renderização foto-realista, com renderizadores de traços de raios (como mental ray, V-Ray, Arnold etc.) com simulações de luz total e iluminação global, em vez de real motores de jogos antigos. Atualizei minha postagem original.
Kristoffer Helander
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.