La profundidad de color de 24 bits no es suficiente?

Noté que en gradientes muy suaves, la profundidad de color de 24 bits no es suficiente, ya que puedes ver las transiciones del color. Esto sobresale más en escenas oscuras o cielos nocturnos.

¿Por qué nadie cambia la profundidad de color a dos bytes por canal? Sé que sería mucho trabajo y que habría que reparar mucho hardware, pero me resulta un poco molesto. Realmente no creo que la tecnología del hardware no sea lo suficientemente madura.

Entonces, ¿por qué nadie hace eso?

Aquí hay una foto de "The War Z" donde puedes ver lo que quiero decir:

Usted mismo lo dijo más o menos: "Lo sé, sería mucho trabajo y mucho hardware tendría que ser reemplazado". Si bien el final del hardware de gráficos en realidad sería relativamente sencillo (si es costoso, duplicar el tamaño de todas las texturas y búferes de cuadros está lejos de ser trivial), el 'ecosistema' para imágenes de mayor profundidad de color simplemente no está en su lugar para el tipo de medida que hace que este sea un gasto que valga la pena en nombre de cualquier persona, ya que ningún fabricante de LCD se está enfocando en tratar de obtener hasta 16 bits por píxel (aunque ha habido algunos experimentos con 10BPP, que convenientemente aún ajusta una señal RGB en un 32- canal de bits).

En resumen, es simplemente demasiado trabajo para lo que la mayoría de las personas considera todavía muy poca ganancia. Puede ser 'un poco molesto', pero ese nivel de molestia es tan bajo que otras mejoras en la calidad de la imagen han tenido prioridad.

Sí, no eres la primera persona en notar esto . :) Con las altas relaciones de contraste de hoy, 8 bits por componente no son suficientes para hacer un gradiente suave sin bandas visibles, a menos que se use tramado.

El uso de más de 8 bits por canal en una pantalla se denomina " color profundo " por los fabricantes de pantallas. No está muy extendido debido a un problema de huevo y gallina. Una pantalla de color profundo es inútil sin una tarjeta de video que puede generar colores profundos y un motor de juego que admita el renderizado a colores profundos. Del mismo modo, no tiene sentido un motor de juego o una tarjeta de video que admita colores profundos sin la pantalla. Por lo tanto, no hay muchos incentivos para que los fabricantes de hardware y los desarrolladores de juegos agreguen soporte para esta tecnología, ya que desde cualquier extremo, no hay mercado para justificar el costo del desarrollo.

Además, hay otras formas de arreglar las bandas debido a la precisión limitada de 8 bits. Como mencioné anteriormente, los motores de juego pueden usar el tramado para ocultar las bandas.

^{(Imagen de un gato con una paleta de 256 colores, sin y con tramado. Creado por el usuario de Wikipedia Wapcaplet , utilizado bajo la licencia CC-By-SA 3.0 ).}

Agregar un ligero tramado de ± 0.5 / 255 antes de escribir el valor de píxel en el framebuffer es extremadamente efectivo para ocultar las bandas en gradientes suaves, y esencialmente imperceptible. Si estás en un motor HDR, lo haces durante la etapa de mapeo de tonos.

Finalmente, como otros han señalado, la compresión de textura puede ser una fuente más grande de artefactos similares a bandas en la imagen que la precisión de 8 bits. Esto puede ser lo que está sucediendo con el cielo en esa imagen, aunque es difícil de decir: tiene tanta compresión JPEG que cualquier artefacto debido a la compresión DXT está prácticamente inundado.

También vale la pena señalar que muchos paneles LCD ni siquiera son de 8 bits por canal. Los más baratos tienden a usar menos bits y usan varios trucos para tratar de ocultarlo. Por ejemplo, podrían cambiar rápidamente entre dos colores adyacentes para representar el uno en el medio. http://www.anandtech.com/show/1557/3

Hay algunos detalles sobre cómo DXGI admite 10 bits por canal y más brillante que los colores blancos en http://msdn.microsoft.com/en-us/library/windows/desktop/jj635732%28v=vs.85%29.aspx

D3D también ha soportado más de 8 bits por canal durante años. No hay nada que impida que un desarrollador haga un tramado de 16 bits por canal a 8 bits si cree que es una buena idea.

Por supuesto, eso no ayudará mucho si los datos de origen (textura, etc.) son solo de 8 bits (o más probablemente DXT1, que efectivamente es de 5-6-5 bits por canal). Creo que eso es lo que pasa con el cielo en esa captura de pantalla (un desenfoque gaussiano de 8 bpp lo hace mucho más suave para mí) pero es difícil estar seguro.

La respuesta de Steven Stadnicki es correcta: los juegos rara vez usan texturas de mayor precisión porque requieren demasiada memoria de textura y, en consecuencia, demasiado ancho de banda de memoria al muestrear la textura en un sombreador de píxeles. Sin embargo, hay soluciones que no requieren grandes texturas. (Publicaría esto como un comentario, pero es demasiado largo).

Homeworld resuelve este problema al codificar la imagen del cielo como gradientes de vértice . Esta técnica funciona muy bien para imágenes grandes de baja frecuencia (es decir, gradientes suaves), como cielos, donde la textura cubre una gran cantidad de píxeles en el juego.

Otra posible solución es aplicar la normalización del histograma a su imagen del cielo. Si los datos de textura se encuentran dentro de un rango de valores estrecho, como un cielo nocturno oscuro, la mayoría de los bits en cada canal de color no llevan datos útiles. En cambio, haz esto:

• Crea la textura original en un formato de 16 bits, como un TIFF de 16 bits.
• Cuando prepare sus texturas para el motor del juego, encuentre el píxel más oscuro presente en la imagen y realice un seguimiento de esto como un desplazamiento. Digamos que este valor de píxel es 0.1 en un rango posible de 0-1.
• Luego, encuentre el píxel más brillante y reste el píxel más oscuro para obtener el rango de valores en la imagen. Entonces, si el píxel más brillante sigue siendo bastante oscuro, digamos 0.35, el rango es solo 0.35 - 0.1 = 0.25. Solo el 25% del rango de valores está presente en la imagen.
• Genera tu textura DXT / BC comprimida en el juego. Resta el valor más oscuro de cada píxel y multiplícalo para usar todo el rango de colores. En el cálculo de ejemplo, restamos nuestro valor oscuro de 0.1 y, dado que solo está presente el 25% del rango de valores disponibles, multiplicamos cada valor de píxel por 4x para crear la textura en el juego. Asegúrese de hacer todo esto antes de cuantificar su imagen de origen de 16 bits hasta la entrada de 8 bpp al compresor DXT. La imagen de salida ahora utilizará todo el rango de valores admitidos por el formato del juego. Estamos asignando todos nuestros bits para representar los valores realmente presentes en la imagen.
• Almacene el desplazamiento del valor oscuro (0.1) y el rango (0.25) en metadatos en alguna parte. Pase estos como entradas a su sombreador de píxeles.
• En el código de sombreador de píxeles, muestree su textura desplazada y expandida, conviértala en un valor flotante y luego multiplique / agregue para restaurar el valor de color original. En otras palabras, multiplique por 0.25 y agregue 0.1 para restaurar el valor almacenado en la imagen de origen.

Asegúrese de que el código del sombreador sea gamma correcto . Si hace cálculos matemáticos (iluminación y postprocesamiento) en muestras de textura que no se convierten del espacio de color sRGB a espacio lineal, verá artefactos de bandas como el que usted describe. La corrección gamma se creó para ayudar a aliviar este tipo de problema al asignar más bits a valores oscuros donde sus ojos son más sensibles a los cambios de valores. Pero puede romper fácilmente las cosas si no tiene en cuenta la corrección gamma al calcular, por ejemplo, iluminación, exposición o efectos posteriores al procesamiento. Las preguntas frecuentes sobre Gamma son útiles.

24 bits no es suficiente, pero es mucho más común que problemas como este sean causados ​​por algoritmos de compresión de imagen, alias u otros artefactos digitales. Además, no pase por alto el papel de la tecnología de pantalla: no importa cuáles sean las entradas digitales, es posible que la pantalla no produzca los pasos apropiados en el brillo real.