DXT 图片压缩(DXTC/DirectX Texture Compression Overview)

这两天在写 DDS 格式的解码程序。DDS 是微软为 DirectX 开发的一种图片格式，MSDN 上可以查到其文件格式说明： http://msdn2.microsoft.com/en-us/library/bb172993.aspx

其中的 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 级过度的插值。关于 DXT3 和 DXT5 的压缩算法，在 MSDN 上也可以找到详细的文章：Textures with Alpha Channels




至于 DXT2 和 DXT4 实际用的不多，从数据压缩算法上来讲，它们完全等同于 DXT3 和 DXT5 。区别只在于颜色数据是否经过 alpha 预乘。

既然是否作 alpha 预乘都可以在 dds 文件中使用专门的 4 字节标识，我奇怪的是，DXT1 中那么重要的通道信息居然不在 dds 文件头中表示出来。真不知道设计文件格式的人怎么想的。 >_<