Compresión de texturas S3

La compresión de texturas S3 ( S3TC ) (a veces también llamada DXTn , DXTC o BCn ) es un grupo de algoritmos de compresión de texturas con pérdida relacionados , desarrollados originalmente por Iourcha et al. de S3 Graphics, Ltd. ^{[ 1 ] [ 2 ]} para su uso en su acelerador de gráficos por computadora Savage 3D . El método de compresión es sorprendentemente similar a la compresión de celdas de color publicada anteriormente , ^{[ 3 ]} que a su vez es una adaptación de la codificación de truncamiento de bloques publicada a finales de la década de 1970. A diferencia de algunos algoritmos de compresión de imágenes (por ejemplo, JPEG ), la compresión de datos de tasa fija de S3TC junto con el acceso a memoria única (cf. compresión de celdas de color y algunos esquemas basados ​​en VQ ) lo hizo muy adecuado para su uso en la compresión de texturas en gráficos por computadora 3D acelerados por hardware . Su posterior inclusión en DirectX 6.0 y OpenGL 1.3 de Microsoft (a través de la extensión GL_EXT_texture_compression_s3tc ) propició la adopción generalizada de la tecnología entre los fabricantes de hardware y software. Si bien S3 Graphics ya no compite en el mercado de aceleradores gráficos, se cobraron tarifas de licencia por el uso de la tecnología S3TC hasta octubre de 2017, por ejemplo, en consolas de videojuegos y tarjetas gráficas. El amplio uso de S3TC generó un requisito de facto para que los controladores de OpenGL la soportaran, pero su condición de estar sujeta a patentes representó un obstáculo importante para las implementaciones de código abierto , ^{[ 4 ]} mientras que existían enfoques de implementación que intentaban evitar las partes patentadas. ^{[ 5 ]}

Algunas de las múltiples patentes de la USPTO sobre compresión de textura S3 (por ejemplo, la US 5956431 A) expiraron el 2 de octubre de 2017. ^{[ 6 ]} Sin embargo , al menos una patente de continuación, la US 6,775,417 , tuvo una prórroga de 165 días. Esta patente de continuación expiró el 16 de marzo de 2018.

Existen cinco variantes del algoritmo S3TC (denominadas DXT1 a DXT5 , en referencia al código FourCC asignado por Microsoft a cada formato), cada una diseñada para tipos específicos de datos de imagen. Todas convierten un bloque de píxeles de 4×4 en una cantidad de 64 o 128 bits, lo que resulta en relaciones de compresión de 6:1 con datos de entrada RGB de 24 bits o 4:1 con datos de entrada RGBA de 32 bits . S3TC es un algoritmo de compresión con pérdida , lo que provoca una degradación de la calidad de la imagen, un efecto que se minimiza al poder aumentar las resoluciones de textura manteniendo los mismos requisitos de memoria. Las imágenes dibujadas a mano, similares a dibujos animados, no se comprimen bien, ni tampoco los datos de mapas normales , que suelen generar artefactos . El algoritmo de compresión 3Dc de ATI es una modificación de DXT5 diseñada para superar las deficiencias de S3TC con respecto a los mapas normales. id Software solucionó los problemas de compresión del mapa normal en Doom 3 moviendo el componente rojo al canal alfa antes de la compresión y volviéndolo a mover durante el renderizado en el sombreador de píxeles . ^{[ 7 ]}

Al igual que muchos algoritmos modernos de compresión de imágenes, S3TC solo especifica el método utilizado para descomprimir las imágenes, lo que permite a los desarrolladores diseñar el algoritmo de compresión según sus necesidades específicas, aunque la patente aún cubre los algoritmos de compresión. Las tarjetas Nvidia GeForce 256 a GeForce 4 también utilizaban interpolación de 16 bits para renderizar texturas DXT1, lo que provocaba bandas al descomprimir texturas con gradientes de color. Esto, una vez más, generó una impresión desfavorable de la compresión de texturas , ajena a los fundamentos del códec en sí.

DXT1 (también conocido como compresión de bloques 1 o BC1) es la variación más pequeña de S3TC, que almacena 16 píxeles de entrada en 64 bits de salida, que consisten en dos valores de color RGB 5:6:5 de 16 bits.${\displaystyle c_{0}}$y${\displaystyle c_{1}}$y una tabla de búsqueda de dos bits de 4×4.

Si${\displaystyle c_{0}>c_{1}}$(compare estos colores interpretándolos como dos números sin signo de 16 bits), luego se calculan otros dos colores, de manera que para cada componente,${\textstyle c_{2}={2 \over 3}c_{0}+{1 \over 3}c_{1}}$y${\textstyle c_{3}={1 \over 3}c_{0}+{2 \over 3}c_{1}}$. Este modo funciona de forma similar al modo 0xC0 del códec de vídeo original de Apple . ^{[ 8 ]}

De lo contrario, si${\displaystyle c_{0}\leq c_{1}}$, entonces${\textstyle c_{2}={1 \over 2}c_{0}+{1 \over 2}c_{1}}$y${\displaystyle c_{3}}$El negro transparente corresponde a un formato alfa premultiplicado . Este color a veces provoca un borde negro alrededor del área transparente cuando se utiliza el filtrado de textura lineal y la prueba alfa, debido a que los colores se interpolan entre el color del texel opaco y el texel transparente negro vecino.

Luego se consulta la tabla de búsqueda para determinar el valor de color de cada píxel, correspondiendo un valor de 0 a${\displaystyle c_{0}}$y un valor de 3 correspondiente a${\displaystyle c_{3}}$.

DXT2 y DXT3 (también conocidos colectivamente como Block Compression 2 o BC2) convierten 16 píxeles de entrada (correspondientes a un bloque de píxeles de 4x4) en 128 bits de salida, que consisten en 64 bits de datos del canal alfa (4 bits para cada píxel) seguidos de 64 bits de datos de color, codificados de la misma manera que DXT1 (con la excepción de que siempre se utiliza la versión de 4 colores del algoritmo DXT1 en lugar de decidir qué versión usar en función de los valores relativos de${\displaystyle c_{0}}$y${\displaystyle c_{1}}$).

En DXT2, los datos de color se interpretan como premultiplicados por alfa ; en DXT3, se interpretan como no premultiplicados por alfa. Por lo general, DXT2/3 son adecuados para imágenes con transiciones alfa abruptas, entre áreas translúcidas y opacas.

DXT4 y DXT5 (también conocidos colectivamente como Block Compression 3 o BC3) convierten 16 píxeles de entrada en 128 bits de salida, que consisten en 64 bits de datos del canal alfa (dos valores alfa de 8 bits y una tabla de búsqueda de 4×4 de 3 bits) seguidos de 64 bits de datos de color (codificados de la misma manera que DXT1).

Si${\displaystyle \alpha _{0}>\alpha _{1}}$, luego se calculan otros seis valores alfa, de tal manera que${\textstyle \alpha _{2}={{6\alpha _{0}+1\alpha _{1}} \over 7}}$,${\textstyle \alpha _{3}={{5\alpha _{0}+2\alpha _{1}} \over 7}}$,${\textstyle \alpha _{4}={{4\alpha _{0}+3\alpha _{1}} \over 7}}$,${\textstyle \alpha _{5}={{3\alpha _{0}+4\alpha _{1}} \over 7}}$,${\textstyle \alpha _{6}={{2\alpha _{0}+5\alpha _{1}} \over 7}}$, y${\textstyle \alpha _{7}={{1\alpha _{0}+6\alpha _{1}} \over 7}}$.

De lo contrario, si${\textstyle \alpha _{0}\leq \alpha _{1}}$, se calculan otros cuatro valores alfa de tal manera que${\textstyle \alpha _{2}={{4\alpha _{0}+1\alpha _{1}} \over 5}}$,${\textstyle \alpha _{3}={{3\alpha _{0}+2\alpha _{1}} \over 5}}$,${\textstyle \alpha _{4}={{2\alpha _{0}+3\alpha _{1}} \over 5}}$, y${\textstyle \alpha _{5}={{1\alpha _{0}+4\alpha _{1}} \over 5}}$con${\displaystyle \alpha _{6}=0}$y${\displaystyle \alpha _{7}=255}$.

Luego se consulta la tabla de búsqueda para determinar el valor alfa de cada píxel, donde un valor de 0 corresponde a${\displaystyle \alpha _{0}}$y un valor de 7 correspondiente a${\displaystyle \alpha _{7}}$Los datos de color de DXT4 están premultiplicados por alfa, mientras que los de DXT5 no. Debido a que DXT4/5 utilizan un esquema de alfa interpolado, generalmente producen mejores resultados para gradientes de alfa (transparencia) que DXT2/3.

Las texturas BCn se pueden comprimir aún más para su almacenamiento y distribución en disco ( supercompresión de texturas ). Una aplicación descomprimiría esta capa adicional y enviaría los datos BCn a la GPU como de costumbre.

BCn se puede combinar con Oodle Texture, un preprocesador con pérdida que modifica la textura de entrada para que la salida de BCn se comprima más fácilmente con un compresor LZ77 ( optimización de tasa-distorsión ). BC7 específicamente también puede usar "bc7prep", un paso sin pérdida para recodificar la textura en un formato más compresible (que requiere su inversa en la descompresión). ^{[ 11 ]}

Crunch es otra herramienta que realiza RDO y opcionalmente una recodificación adicional. ^{[ 12 ]}

En 2021, Microsoft produjo un algoritmo de compresión "BCPack" específicamente para texturas comprimidas con BCn. Las Xbox Series X y S cuentan con soporte de hardware para descomprimir flujos BCPack. ^{[ 13 ]}

• S2TC , solución alternativa sin patente
• FXT1
• Superficie DirectDraw
• PVRTC
• Compresión de texturas escalable adaptativa (ASTC)
• Compresión de texturas de Ericsson (ETC1 y ETC2)
• Compresión de celdas de color

• Oficina de Patentes y Marcas de los Estados Unidos, Base de datos de texto completo e imágenes de patentes, resultado para US 5956431 A
• Búsqueda de asignación de patente de la USPTO para US 5956431 A