Profundidade de cor de 24 bits não é suficiente?

Percebi que em gradientes muito suaves, a profundidade de cores de 24 bits não é suficiente, como você pode ver as transições da cor. Isso aparece mais em cenas escuras ou no céu noturno.

Por que ninguém altera a profundidade de cor para dois bytes por canal? Eu sei que isso daria muito trabalho e muito hardware teria que ser reequilibrado, mas acho isso um pouco chato. Realmente não acho que a tecnologia do hardware não esteja madura o suficiente.

Então, por que ninguém está fazendo isso?

Aqui está uma foto de "The War Z", onde você pode ver o que quero dizer:

Você mais ou menos disse: "Eu sei, isso daria muito trabalho e muito hardware teria que ser substituído". Embora o final do hardware gráfico seja relativamente simples (se caro - dobrar o tamanho de todas as texturas e buffers de quadros está longe de ser trivial), o 'ecossistema' para imagens com maior profundidade de cor simplesmente não está no lugar. tipo de medida que faz com que isso seja um gasto valioso em nome de qualquer pessoa, já que nenhum fabricante de LCD está se concentrando em tentar obter até 16 bits por pixel (embora tenha havido alguns experimentos no 10BPP, que convenientemente ainda encaixam um sinal RGB em um 32- canal de bits).

Em suma, é simplesmente muito trabalho para o que a maioria das pessoas considera ainda pouco ganho. Pode muito bem ser "um pouco chato", mas esse nível de aborrecimento é tão pequeno que outras melhorias na qualidade da imagem têm tido prioridade.

Sim, você não é a primeira pessoa a perceber isso . :) Com as altas taxas de contraste atuais, 8 bits por componente não são suficientes para obter um gradiente suave sem faixas visíveis - a menos que o pontilhamento seja usado.

O uso de mais de 8 bits por canal em um monitor é chamado de " cores profundas " pelos fabricantes do monitor. Não é muito difundido por causa de um problema de galinha e ovo. Um display colorido profundo é inútil sem uma placa de vídeo que possa produzir cores profundas e um mecanismo de jogo que suporte a renderização para cores profundas. Da mesma forma, não há sentido em um mecanismo de jogo ou em uma placa de vídeo que suporte cores profundas sem a tela. Portanto, não há muito incentivo para os fabricantes de hardware e desenvolvedores de jogos adicionarem suporte a essa tecnologia, pois em ambos os lados, não há mercado para justificar o custo do desenvolvimento.

Além disso, existem outras maneiras de corrigir as faixas devido à precisão limitada de 8 bits. Como mencionei anteriormente, os mecanismos de jogo podem usar o pontilhamento para ocultar as faixas.

^{(Imagem de um gato com uma paleta de 256 cores, sem e com pontilhamento. Criado pelo usuário Wapcaplet da Wikipedia , usado sob a licença CC-By-SA 3.0 .)}

A adição de uma ligeira oscilação de ± 0,5 / 255 antes de gravar o valor do pixel no buffer de quadros é extremamente eficaz para ocultar faixas em gradientes suaves e essencialmente imperceptível. Se você estiver em um mecanismo HDR, faça isso durante o estágio de mapeamento de tom.

Finalmente, como outros observaram, a compactação de textura pode ser uma fonte maior de artefatos semelhantes a faixas na imagem do que a precisão de 8 bits. Pode ser o que está acontecendo com o céu nessa imagem, embora seja difícil dizer - tem tanta compressão JPEG que qualquer artefato devido à compressão DXT está praticamente inundado.

Também vale a pena notar que muitos painéis LCD não têm nem 8 bits por canal. Os mais baratos tendem a usar menos bits e usar vários truques para tentar escondê-lo. Por exemplo, eles podem alternar rapidamente entre duas cores adjacentes para representar a outra. http://www.anandtech.com/show/1557/3

Há alguns detalhes sobre como o DXGI suporta 10 bits por canal e cores mais brilhantes que o branco em http://msdn.microsoft.com/en-us/library/windows/desktop/jj635732%28v=vs.85%29.aspx

O D3D também suporta mais de 8 bits por canal há anos. Não há nada que impeça um desenvolvedor de diminuir de 16 bits por canal para 8 bits se acharem que é uma boa ideia.

É claro que isso não ajudará muito se os dados de origem (textura etc.) forem de apenas 8 bits (ou mais provável DXT1, que é efetivamente 5-6-5 bits por canal). Acredito que é o que há com o céu nessa captura de tela (um borrão gaussiano de 8 bpp torna muito mais suave para mim), mas é difícil ter certeza.

A resposta de Steven Stadnicki está correta - os jogos raramente usam texturas de precisão mais alta porque exigem muita memória de textura e, conseqüentemente, muita largura de banda de memória ao amostrar a textura em um pixel shader. No entanto, existem soluções que não exigem grandes texturas. (Eu postaria isso como um comentário, mas é muito longo.)

O Homeworld resolve esse problema codificando a imagem do céu como gradientes de vértice . Essa técnica funciona muito bem para imagens grandes e de baixa frequência (ou seja, gradientes suaves) - como céus - onde a textura cobre um grande número de pixels no jogo.

Outra solução possível é aplicar a normalização do histograma à sua imagem do céu. Se os dados da textura estiverem dentro de um intervalo de valores estreito, como um céu noturno escuro, a maioria dos bits em cada canal de cor não carregará dados úteis. Em vez disso, faça o seguinte:

• Crie a textura original em um formato de 16 bits, como um TIFF de 16 bits.
• Ao preparar suas texturas para o mecanismo de jogo, encontre o pixel mais escuro presente na imagem e acompanhe-o como um deslocamento. Digamos que esse valor de pixel seja 0,1 em um intervalo possível de 0-1.
• Em seguida, encontre o pixel mais brilhante e subtraia o pixel mais escuro para obter o intervalo de valores na imagem. Portanto, se o pixel mais brilhante ainda estiver muito escuro - digamos 0,35 - o intervalo será de apenas 0,35 - 0,1 = 0,25. Apenas 25% da faixa de valores está presente na imagem.
• Gere sua textura no jogo compactada em DXT / BC . Subtraia o valor mais escuro de cada pixel e multiplique para usar todo o intervalo de cores. No cálculo de exemplo, subtraímos nosso valor sombrio de 0,1 e, como apenas 25% do intervalo de valores disponível está presente, multiplicamos cada valor de pixel por 4x para criar a textura no jogo. Certifique-se de fazer tudo isso antes de quantizar sua imagem de origem de 16 bits até a entrada de 8bpp no ​​compressor DXT. A imagem de saída agora utilizará todo o intervalo de valores suportados pelo formato do jogo. Estamos alocando todos os nossos bits para representar os valores realmente presentes na imagem.
• Armazene o deslocamento do valor escuro (0,1) e o intervalo (0,25) nos metadados em algum lugar. Passe esses dados como entradas para seu pixel shader.
• No código de sombreador de pixel, prove sua textura expandida e deslocada, converta-a em um valor flutuante e faça uma multiplicação / adição para restaurar o valor da cor original. Em outras palavras, multiplique por 0,25 e adicione 0,1 para restaurar o valor armazenado na imagem de origem.

Verifique se o código do sombreador está correto para a gama . Se você fizer matemática (iluminação e pós-processamento) em amostras de textura que não são convertidas do espaço de cores sRGB em espaço linear, verá artefatos de faixas como o que você descreve. A correção gama foi criada para ajudar a aliviar esse tipo de problema, alocando mais bits aos valores escuros, onde seus olhos são mais sensíveis às mudanças de valor. Mas você pode facilmente quebrar as coisas se não considerar a correção de gama ao calcular, por exemplo, iluminação, exposição ou FX pós-processamento. O FAQ sobre Gamma é útil.

24 bits não é suficiente, mas é muito mais comum que problemas como esse sejam causados ​​por algoritmos de compactação de imagem, alias ou outros artefatos digitais. Além disso, não negligencie o papel da tecnologia de exibição - independentemente das entradas digitais, a exibição pode não produzir as etapas apropriadas no brilho real.