DXT纹理压缩格式解析

傷城~ 2022-08-18 02:17 350阅读 0赞

我们知道游戏中对于3D物体表面细节的表现最重要的还是靠贴图来实现的，那么越是高分辨率越是真彩色的贴图自然表现力也是越强，但是同时带来的问题是所需占用的内存会成倍的上升，而节省内存这一点在目前的游戏中还是非常非常重要的。 所以各个平台上都在使用纹理压缩的技术，让纹理贴图在内存占用和显示效果能达到一个尽可能的平衡。在DirectX中，使用一种叫做DXT的纹理压缩技术，目前这种技术被大部分显卡所支持，通过对DXT的了解，我们可以对纹理压缩技术管中窥豹。 DXT是一种DirectDraw表面，它以压缩形式存储图形数据，该表面可以节省大量的系统带宽和内存。即使不直接使用DXT表面渲染，也可以通过 DXT格式创建纹理的方法节省磁盘空间。Direct3D提供了D3DFMT\_DXT1 ~ D3DFMT\_DXT5共5种压缩纹理格式。其中，D3DFMT\_DXT1支持15位RGB和1位alpha图形格式，D3DFMT\_DXT2、D3DFMT\_DXT3支持12位RGB和4位alpha，D3DFMT\_DXT4、D3DFMT\_DXT5则采取了线性插值方式生成alpha。

![0_128957655546pa.gif][]

**DXT1**  
 DXT1格式主要适用于不具透明度的贴图或仅具一位Alpha的贴图（非完全透明则即完全不透明），对于完全RGB565格式的贴图，DXT1具有4：1的压缩比，即平均每个像素颜色占4位，虽然压缩比并不是很好，但是DXT的特性使得它更适合用于实时游戏之中。  
DXT1将每4×4个像素块视为一个压缩单位，压缩后的4×4个像素块占用64位，其中有2个16位的RGB颜色和16个2位索引，格式描绘如下图所示：

![0_1289576513cIi8.gif][]

DXT1中的两个RGB颜色负责表示所在压缩的4×4像素块中颜色的两个极端值，然后通过线性插值我们可以再计算出两个中间颜色值，而16个2位索引则表明了这4×4个像素块所在像素的颜色值，2位可以表示4种状态，刚好可以完整表示color\_0，color\_1以及我们通过插值计算出的中间颜色值color\_2和color\_3，而对于具有一位Alpha的贴图，则只计算一个中间颜色值，color\_3用来表示完全透明。  
对于如何判断DXT1格式是表示不透明还是具有1位alpha的贴图，则是通过两个颜色值color\_0和color\_1来实现的，如果color\_0的数值大于color\_1则表示贴图是完全不透明的，反之则表示具有一位透明信息。  
**DXT2、DXT3**  
DXT2和DXT3可以表示具有更复杂的透明信息的贴图，这两种格式采用的是显式的Alpha表示，我们知道了在DXT1中，我们使用64位数据来描述4\*4的像素块的颜色信息，在DXT2和DXT3中，这部分颜色信息是不变的，而是通过另附加64位数据也就是每个像素4位来表示他们的Alpha透明信息，而这4位的Alpha的信息通常情况下我们可以采用直接编码的方式来表示即可。  
这样每个4×4像素块占用128位也就是8个字，0~3字表示透明信息；4~7表示前面描述的颜色的信息。  
DXT2和DXT3的不同之处在于，DXT2中颜色是已经完成了Premultiplied by alpha操作（已完成颜色与alpha的混合，当透明度发生改变时，直接改变整体颜色值，不必再单独复合），DXT3的Alpha信息则是相对独立的，之所以要区分开了则是为了适应不同的需要，因为有些场合需要独立的Alpha信息。

![0_12895765426rEb.gif][]

**DXT4、DXT5**  
DXT4、DXT5也是用于表示具有复杂的透明信息的贴图，与2和3不同的是4和5的Alpha信息是通过线性插值计算所得，类似于DXT1的颜色信息。同样的，每4×4的像素块的透明信息占用64位，所不同的是，64位中采用了2个8位的alpha值和16个3位的索引值，既然每个像素的索引占3位，那么可以表示8种不同的透明状态。  
在这里插值的方法有两种，一种用于表示具有完全透明和完全不透明的状态，另一种则是仅在给出的极端值alpha\_0和alpha\_1中进行插值。区分的方法也是通过比较alpha\_0和alpha\_1的大小来实现的，如果alpha\_0大于alpha\_1，则通过插值计算剩下的6个中间alpha值；否则，只通过插值计算4个中间alpha值，alpha\_6直接赋值0，alpha\_7直接赋值255。  
DXT4和DXT5的区别同DXT2和DXT3的区别相同，DXT4的颜色值是理解为已经完成Premultiplied by alpha操作的。  
另外需要注意的是，所有的压缩纹理格式都是2的幂，因为纹理压缩的单位是4×4像素，所以如果贴图的大小位16×2或者8×1这样的比例，系统会同样采用4×4的单位进行压缩，会造成一定的空间浪费，同样的大小会被占用，只是不会参与使用而已。

原文地址：[http://blog.csdn.net/lhc717/article/details/6802951][http_blog.csdn.net_lhc717_article_details_6802951]

这两天在写 DDS 格式的解码程序。DDS 是微软为 DirectX 开发的一种图片格式，MSDN 上可以查到其文件格式说明：DDS File Reference 。  
  
  
其中的 DXT 图片压缩格式，现在已经为绝大多数 3D 显卡硬件所支持。（它使用了由 S3 公司所发明的一种有损图象压缩算法。btw, 在我的那本书中，P232 有所提及）。DXT 格式 也叫作 S3TC ，现在可以被流行看图软件直接显示的图象格式中，只有 .dds 文件支持这种压缩。为了开发方便，我们的引擎也就支持了 .dds 文件的加载。  
  
  
一起做引擎的同事希望即使在硬件不支持的时候，我们也能正常加载并使用贴图，所以便有了对 DXT 软解码的需求。  
  
  
好在以前研究过一些，写起来也不麻烦。  
  
  
DXT1 支持 1 bit 的 alpha 通道。这个其实是可选的。每个 4x4 的块可以根据需要有或没有这个透明通道。不需要 alpha 通道时，每个块可以有四种颜色（其中两个是插值得到的）；需要 alpha 通道时，则只能有三种颜色，11 被保留用来描述透明的点。区分是否用通道，要根据每个块开始的两个高彩颜色值：color\_0 和 color\_1 。如果 color\_0 在数值上（当作无符号短整型）大于 color\_1 则没有通道。  
  
  
可惜的是，在 dds 文件的文件头中，没有任何一个地方描述了：整个图片是否有至少一个块包含了 alpha 通道。但是在 3d 程序中，却需要知道这一信息以使程序可以更高效的运行。  
  
  
对于软解码程序，更需要知道这一信息。因为带通道时，我们需要把数据解码成 RGBA5551 的格式；而不带通道时，则需要解码成 RGB565 格式。  
  
  
一开始我以为需要扫描整个数据段，检查是否至少有一个块的 color\_0 小于等于 color\_1 。实际看了几个用工具生成的 dds 文件才发现自己错了。nvidia 的 dxt tools 压缩 DXT1 图片时，需要手动指明是否需要 1 bit 的通道。如果你指定不带通道，那么每个 4x4 数据块头上的两个调色盘颜色值的大小次序是无关的（这样做，由于插值方案的差异，有可能得到更好一点的图象质量）。也就是说，只有压缩图片的人知道图片上是否有通道，而文件头上并无记录。  
  
  
DXT3 就是在 DXT1 的基础上，增加了 4bit 的 alpha 通道，每个 4x4 块多用了 64bit 来保存这些 alpha 通道信息。（数据储存时，在每个数据块中，alpha 通道信息放在颜色信息的前面）  
  
  
DXT5 对 alpha 通道的储存作了改进，有点意思，值得一提 :D 。它依旧用 64bit 储存 16 个 alpha 信息。前面 2 个字节（16bit）保存了当前块的最大 alpha 值和最小 alpha 值。接下来的 48 bit ，每个像素占用 3bit 空间，刚好描述 4x4 个像素。  
  
  
当 alpha\_0 大于 alpha\_1 时，我们后面的 3bit 可以表示 8 级的插值；反之则保留 110 和 111 分别表示 alpha 为 0 和 255 的情况，中间可以有 6 级过度的插值。  
  
  
至于 DXT2 和 DXT4 实际用的不多，从数据压缩算法上来讲，它们完全等同于 DXT3 和 DXT5 。区别只在于颜色数据是否经过 alpha 预乘。  
  
  
既然是否作 alpha 预乘都可以在 dds 文件中使用专门的 4 字节标识，我奇怪的是，DXT1 中那么重要的通道信息居然不在 dds 文件头中表示出来。真不知道设计文件格式的人怎么想的。 >\_<

原文地址：[云风的blog][blog]

[0_128957655546pa.gif]: /images/20220731/3650017da2734fc18fd02abfbd60558e.png
[0_1289576513cIi8.gif]: /images/20220731/e2456ecea6854df4b24d2e9064f9a0c5.png
[0_12895765426rEb.gif]: /images/20220731/87b12744c8714d04a89acbcdb38b0ceb.png
[http_blog.csdn.net_lhc717_article_details_6802951]: http://blog.csdn.net/lhc717/article/details/6802951
[blog]: http://blog.codingnow.com/2007/05/dxt.html