¿Cómo funciona la compresión de textura de hardware?

Es obvio que comprime los datos en comparación con la matriz de píxeles.

Pero, ¿qué lo hace diferente de la compresión normal (como png, jpeg)?

Como aludió el comentario de Simon, una diferencia importante entre la compresión de textura de hardware y otra compresión de imagen comúnmente utilizada es que la primera no usa codificación de entropía. La codificación de entropía es el uso de cadenas de bits más cortas para representar patrones comunes o repetitivos en los datos de origen, como se ve en formatos de contenedor como ZIP, muchos formatos de imagen comunes como GIF, JPEG y PNG, y también en muchos audios comunes y formatos de video.

La codificación de entropía es buena para comprimir todo tipo de datos, pero intrínsecamente produce una relación de compresión variable. Algunas áreas de la imagen pueden tener pocos detalles (o el modelo de codificación que está usando predice bien los detalles) y requieren muy pocos bits, pero otras áreas pueden tener detalles complejos que requieren más bits para codificar. Esto hace que sea difícil implementar el acceso aleatorio, ya que no hay una forma directa de calcular en qué parte de los datos comprimidos puede encontrar el píxel en el dado ( x ,  y) coordenadas. Además, la mayoría de los esquemas de codificación de entropía tienen estado, por lo que no es posible simplemente comenzar a decodificar en un lugar arbitrario de la secuencia; tienes que comenzar desde el principio para construir el estado correcto. Sin embargo, el acceso aleatorio es necesario para el muestreo de textura, ya que un sombreador puede muestrear desde cualquier ubicación de una textura en cualquier momento.

Entonces, en lugar de la codificación de entropía, la compresión de hardware utiliza esquemas basados ​​en bloques de relación fija. Por ejemplo, en la compresión DXT / BCn , la textura se divide en bloques de 4 × 4 píxeles, cada uno de los cuales está codificado en 64 o 128 bits (dependiendo del formato elegido); en ASTC , los diferentes formatos utilizan tamaños de bloque de 4 × 4 hasta 12 × 12, y todos los bloques están codificados en 128 bits. Los detalles de cómo los bits representan los datos de la imagen varían entre formatos (e incluso pueden variar de un bloque al siguiente dentro de la misma imagen), pero debido a que la relación es fija, es fácil para el hardware calcular en qué parte de la memoria encontrar el bloque que contiene un píxel ( x , y ) dado , y cada bloque es autónomo, por lo que puede decodificarse independientemente de cualquier otro bloque.

Otra consideración en la compresión de texturas de hardware es que la decodificación debe implementarse eficientemente en hardware. Esto significa que las operaciones matemáticas pesadas y el flujo de datos complejo están fuertemente desfavorecidos. Los formatos BCn, por ejemplo, se pueden decodificar haciendo un puñado de operaciones matemáticas de enteros de 8 bits por bloque para llenar una pequeña tabla de búsqueda, y luego simplemente buscando la entrada de tabla apropiada por píxel. Esto requiere muy poca área en el chip, lo cual es importante porque probablemente desee decodificar varios bloques en paralelo y, por lo tanto, necesita varias copias del hardware de decodificación.

En contraste, los formatos basados ​​en DCT como JPEG requieren una cantidad no trivial de matemáticas por píxel, sin mencionar un flujo de datos complejo que intercambia y transmite varios valores intermedios a través de píxeles dentro de un bloque. (Consulte este artículo para conocer algunos de los detalles sangrientos de la decodificación DCT). Esto sería mucho más grosero para la implementación de hardware, lo que supongo es por qué AFAICT, ningún hardware de GPU ha implementado compresión de textura basada en DCT o wavelet .

"Cómo funciona la compresión de texturas (hardware)" es un tema importante. Espero poder proporcionar algunas ideas sin duplicar el contenido de la respuesta de Nathan .

Requisitos

La compresión de textura generalmente difiere de las técnicas de compresión de imagen 'estándar', por ejemplo, JPEG / PNG en cuatro formas principales, como se describe en el Renderizado de texturas comprimidas de Beers et al . :

1. Velocidad de decodificación : no desea que la compresión de textura sea más lenta (al menos no notablemente) que usar texturas sin comprimir. También debería ser relativamente sencillo descomprimir, ya que eso puede ayudar a lograr una descompresión rápida sin excesivos costos de hardware y energía.

2. Acceso aleatorio : no puede predecir fácilmente qué elementos de texto se requerirán durante un render determinado. Si algún subconjunto, M , de los elementos de texto accedidos proviene, por ejemplo, del medio de la imagen, es esencial que no tenga que decodificar todas las líneas 'anteriores' de la textura para determinar M ; con JPEG y PNG esto es necesario ya que la decodificación de píxeles depende de los datos decodificados previamente.
   Tenga en cuenta que, habiendo dicho esto, solo porque tenga acceso "aleatorio", no significa que deba intentar muestrear completamente arbitrariamente

3. Tasa de compresión y calidad visual : Beers et al argumentan (convincentemente) que perder algo de calidad en el resultado comprimido para mejorar la tasa de compresión es una compensación valiosa. En la representación 3D, los datos probablemente serán manipulados (por ejemplo, filtrados y sombreados, etc.) y, por lo tanto, es posible que se oculte alguna pérdida de calidad.

4. Codificación / decodificación asimétrica : aunque quizás sea un poco más polémico, argumentan que es aceptable que el proceso de codificación sea mucho más lento que la decodificación. Dado que la decodificación debe ser a tasas de llenado de HW, esto es generalmente aceptable. (Admito que la compresión de PVRTC, ETC2 y algunos otros con la máxima calidad podría ser más rápida)

Historia y técnicas tempranas

Puede sorprender a algunos saber que la compresión de texturas ha existido durante más de tres décadas. Los simuladores de vuelo de los años 70 y 80 necesitaban acceso a cantidades relativamente grandes de datos de textura y dado que 1 MB de RAM en 1980 era> $ 6000 , reducir la huella de textura era esencial. Como otro ejemplo, a mediados de los años 70, incluso una pequeña cantidad de memoria y lógica de alta velocidad, por ejemplo, suficiente para un modesto buffer de cuadro RGB de 512x512 ) podría hacer retroceder el precio de una casa pequeña.

Sin embargo, AFAIK, que no se conoce explícitamente como compresión de textura, en la literatura y las patentes puede encontrar referencias a técnicas que incluyen:
a. formas simples de síntesis de textura matemática / procesal,
b. uso de una textura de un solo canal (por ejemplo, 4bpp) que luego se multiplica por un valor RGB por textura,
c. YUV, y
d. paletas (la literatura sugiere el uso del enfoque de Heckbert para hacer la compresión)

Modelado de datos de imagen

Como se señaló anteriormente, la compresión de textura es casi siempre con pérdidas y, por lo tanto, el problema se convierte en tratar de representar los datos importantes de una manera compacta mientras se elimina la información menos significativa. Los diversos esquemas que se describirán a continuación tienen un modelo implícito 'parametrizado' que se aproxima al comportamiento típico de los datos de textura y de la respuesta del ojo.

Además, dado que la compresión de textura tiende a usar codificación de velocidad fija, el proceso de compresión generalmente incluye un paso de búsqueda para encontrar el conjunto de parámetros que, cuando se introducen en el modelo, generarán una buena aproximación de la textura original. Sin embargo, ese paso de búsqueda puede llevar mucho tiempo.
(Con la posible excepción de herramientas como optipng , esta es otra área donde el uso típico de PNG y JPEG difiere de los esquemas de compresión de textura)

Antes de seguir avanzando, para ayudar a comprender mejor la CT, vale la pena echar un vistazo al Análisis de componentes principales (PCA) , una herramienta matemática muy útil para la compresión de datos.

Textura de ejemplo

Para comparar los diversos métodos, usaremos la siguiente imagen:

Tenga en cuenta que esta es una imagen bastante resistente, especialmente para los métodos de paleta y VQTC, ya que abarca gran parte del cubo de color RGB y solo el 15% de los texels usan colores repetidos.

PC y (después de mediados de los 90) Compresión de textura de consola

Para reducir los costos de datos, algunos juegos de PC y las primeras consolas de juegos también utilizaron imágenes de paleta, que es una forma de Vector Quantisation (VQ). Los enfoques basados ​​en paletas suponen que una imagen dada solo usa porciones relativamente pequeñas del cubo de color RGB (A). Un problema con las texturas de paleta es que las tasas de compresión para la calidad alcanzada son generalmente bastante modestas. El ejemplo de textura comprimido a "4bpp" (usando GIMP) produjo nuevamente que esta es una imagen relativamente difícil para los esquemas VQ.

VQ con vectores más grandes (por ejemplo, 2bpp ARGB)

Inspirada por Beers et al, la consola Dreamcast utilizó VQ para codificar bloques de 2x2 o incluso de 2x4 píxeles con bytes individuales. Mientras que los "vectores" en las texturas de la paleta son de 3 o 4 dimensiones, los bloques de píxeles de 2x2 pueden considerarse de 16 dimensiones. El esquema de compresión supone que hay suficientes repeticiones aproximadas de estos vectores.

Aunque VQ puede lograr una calidad satisfactoria con ~ 2bpp, el problema con estos esquemas es que requiere lecturas de memoria dependientes: una lectura inicial del mapa de índice para determinar el código del píxel es seguida por un segundo para obtener los datos de píxel asociados con ese código Los cachés adicionales pueden ayudar a aliviar parte de la latencia incurrida, pero agrega complejidad al hardware.

La imagen de ejemplo comprimida con el esquema 2bpp Dreamcast es . El mapa de índice es:

La compresión de los datos de VQ se puede hacer de varias maneras, sin embargo, IIRC , lo anterior se hizo usando PCA para derivar y luego dividir los vectores 16D a lo largo del vector principal en 2 conjuntos de modo que dos vectores representativos minimizaran el error cuadrático medio. El proceso luego se repitió hasta que se produjeron 256 vectores candidatos. Luego se aplicó un enfoque global de algoritmo k-means / Lloyd's para mejorar a los representantes.

Transformaciones del espacio de color

Las transformaciones del espacio de color también hacen uso de PCA, señalando que la distribución global del color a menudo se extiende a lo largo de un eje principal con mucha menos extensión a lo largo de los otros ejes. Para las representaciones YUV, las suposiciones son que a) el eje mayor está a menudo en la dirección de la luma y que b) el ojo es más sensible a los cambios en esta dirección.

El sistema 3dfx Voodoo proporcionó "YAB" , un sistema de compresión de "canal estrecho" de 8 bpp que dividió cada texel de 8 bits en un formato 322, y aplicó una transformación de color seleccionada por el usuario a esos datos para mapearlos en RGB. El eje principal tenía 8 niveles y los ejes más pequeños, 4 cada uno.

El chip S3 Virge tenía un esquema ligeramente más simple de 4 bpp que permitía al usuario especificar, para toda la textura , dos colores finales, que deberían estar en el eje principal, junto con una textura monocromática de 4 bpp. El valor por píxel luego mezcló los colores finales con los pesos apropiados para producir el resultado RGB.

Esquemas basados ​​en BTC

Rebobinando algunos años, Delp y Mitchell diseñaron un esquema de compresión de imagen simple (monocromo) llamado Block Truncation Coding (BTC) . Este documento también incluyó un algoritmo de compresión pero, para nuestros propósitos, estamos interesados ​​principalmente en los datos comprimidos resultantes y en el proceso de descompresión.

En este esquema, las imágenes se dividen, por lo general, en bloques de píxeles de 4x4, que se pueden comprimir de forma independiente con, de hecho, un algoritmo VQ localizado. Cada bloque está representado por dos "valores", a y b , y un conjunto de 4x4 de bits de índice, que identifican cuál de los dos valores usar para cada píxel.

S3TC : 4bpp RGB (+ 1 bit alfa)
Aunque varios colores variantes de BTC para la compresión de imágenes se propuso, de interés para nosotros es Iourcha y cols S3TC , algunos de los cuales parece ser un redescubrimiento de la obra un tanto olvidada de Hoffert et al que se fue utilizado en Apple Quicktime.

El S3TC original, sin las variantes de DirectX, comprime bloques de RGB o RGB + 1 + Alfa a 4 bpp. Cada bloque 4x4 en la textura se reemplaza por dos colores finales, A y B , de los cuales se derivan hasta otros dos colores mediante mezclas lineales de peso fijo. Además, cada texel en el bloque tiene un índice de 2 bits que determina cómo seleccionar uno de estos cuatro colores.

Por ejemplo, la siguiente es una sección de 4x4 píxeles de la imagen de prueba comprimida con la herramienta AMD / ATI Compressenator. ( Técnicamente, está tomado de una versión de 512x512 de la imagen de prueba, pero perdona mi falta de tiempo para actualizar los ejemplos ). Esto ilustra el proceso de compresión: se calcula el promedio y el eje principal de los colores. Luego se realiza un mejor ajuste para encontrar dos puntos finales que 'se encuentran' en el eje que, junto con las dos mezclas derivadas 1: 2 y 2: 1 (o en algunos casos una mezcla 50:50) de esos puntos finales, que minimiza el error Cada píxel original se asigna a uno de esos colores para producir el resultado.

Si, como en este caso, los colores son razonables aproximados por el eje principal, el error será relativamente bajo. Sin embargo, si, como en el bloque 4x4 vecino que se muestra a continuación, los colores son más diversos, el error será mayor.

La imagen de ejemplo, comprimida con el compresor AMD produce:

Dado que los colores se determinan independientemente por bloque, puede haber discontinuidades en los límites del bloque pero, siempre que la resolución se mantenga lo suficientemente alta, estos artefactos de bloque pueden pasar desapercibidos:

ETC1 : 4bpp RGB
Ericsson Texture Compression también funciona con bloques 4x4 de texels, pero supone que, al igual que YUV, el eje principal de un conjunto local de texels a menudo está muy relacionado con "luma". El conjunto de elementos de textura puede representarse mediante un color promedio y una 'longitud' escalar altamente cuantizada de la proyección de los elementos de textura sobre ese eje asumido.

Como esto reduce los costos de almacenamiento de datos en relación con, por ejemplo, S3TC, permite a ETC introducir un esquema de partición, mediante el cual el bloque 4x4 se subdivide en un par de subbloques horizontales 4x2 o verticales 2x4. Cada uno tiene su propio color promedio. La imagen de ejemplo produce: El área alrededor del pico también ilustra la partición horizontal y vertical de los bloques 4x4.

Global + Local

Hay algunos sistemas de compresión de texturas que son un cruce entre esquemas globales y locales, como el de las paletas distribuidas de Ivanov y Kuzmin o el método de PVRTC .

PVRTC : 4 y 2 bpp RGBA
PVRTC supone que una imagen mejorada (en la práctica, bilinealmente) es una buena aproximación al objetivo de resolución completa y que la diferencia entre la aproximación y el objetivo, es decir, la imagen delta, es localmente monocromática, es decir tiene un eje principal dominante. Además, se supone que el eje principal local se puede interpolar a través de la imagen.

(para hacer: Agregar imágenes que muestran el desglose)

El ejemplo de textura, comprimido con PVRTC1 4bpp produce: con el área alrededor del pico: en comparación con los esquemas BTC, los artefactos de bloque generalmente se eliminan, pero a veces puede haber "sobreimpulso" si hay discontinuidades fuertes en la imagen de origen, por ejemplo, alrededor La silueta de la cabeza del lorikeet.

La variante de 2bpp tiene, naturalmente, un error mayor que el de 4bpp (tenga en cuenta la pérdida de precisión alrededor de las áreas azules de alta frecuencia cerca del cuello) pero podría decirse que aún es de calidad razonable:

Una nota sobre los costos de descompresión

Aunque los algoritmos de compresión para los esquemas descritos anteriormente tienen un costo de evaluación de moderado a alto, los algoritmos de descompresión, especialmente para implementaciones de hardware, son relativamente económicos. ETC1, por ejemplo, requiere poco más que unos pocos MUX y sumadores de baja precisión; S3TC efectivamente un poco más unidades de adición para realizar la mezcla; y PVRTC, un poco más de nuevo. En teoría, estos esquemas simples de TC podrían permitir que una arquitectura de GPU evite la descompresión hasta justo antes de la etapa de filtrado, maximizando así la efectividad de los cachés internos.

Otros esquemas

Otros modos TC comunes que deben mencionarse son:

• ETC2: es un superconjunto (4bpp) de ETC1 que mejora el manejo de regiones con distribuciones de color que no se alinean bien con 'luma'. También hay una variante de 4 bpp que admite alfa de 1 bit y un formato de 8 bpp para RGBA.

• ATC: es efectivamente una pequeña variación en S3TC .

• FXT1 (3dfx) fue una variante más ambiciosa del tema S3TC .

• BC6 y BC7: un sistema basado en bloques de 8bpp que admite ARGB. Además de los modos HDR, estos usan un sistema de partición más complejo que el de ETC para intentar mejorar la distribución del color de la imagen del modelo.

• PVRTC2: ARGB de 2 y 4 bpp. Esto introduce modos adicionales, incluido uno para superar las limitaciones con fuertes límites en las imágenes.

• ASTC: Este también es un sistema basado en bloques, pero es algo más complicado porque tiene una gran cantidad de posibles tamaños de bloque dirigidos a una amplia gama de bpp. También incluye características como hasta 4 regiones de partición con un generador de particiones pseudoaleatorio y resolución variable para los datos de índice y / o precisión de color y modelos de color.