原文转载自： 纹理压缩
贴图是在 3D 场景中，增加真实性的一个重要的工具。就像一般的影像一样，贴图的大小愈大，它的图像就愈精细。事实上，贴图往往需要比一般的影像更大。因为，在 3D 场景中，观察者可能会很靠近贴图，使得贴图需要放大很多倍，而造成模糊的现象。所以，一般来说，如果可能的话，贴图愈大就愈好。
不过，贴图是非常占用内存空间的。现在的贴图都是以不压缩的形式存放在显示内存中，而目前常用的贴图格式是 16 bits、24 bits 和 32 bits。下表列出一些贴图大小所占用的空间：
| 贴图大小 | 16 bits | 16 bits mipmap | 24 bits | 24 bits mipmap | 32 bits | 32 bits mipmap |
| 64×64 | 8 KB | 10.6 KB | 12 KB | 16 KB | 16 KB | 21 KB |
| 256×256 | 128 KB | 170 KB | 192 KB | 256 KB | 256 KB | 340 KB |
| 1024×1024 | 2 MB | 2.6 MB | 3 MB | 4 MB | 4 MB | 5.3 MB |
常用的图像文件格式有BMP，TGA，JPG，GIF，PNG等；
不过象JPG这种常见图像压缩格式对于多数应用的内存占用和显示总线带宽占用并没有直接的好处，因为还得解压缩成原始像素再传给显卡，而且还有加载时的解碼计算负担。这是因为显卡的纹理解碼硬件不理解JPG格式。所以，在没有显卡硬件支持的情况下，用压缩格式保存纹理没什么意义，特别是对于手持移动设备来说，解碼象JPG这种复杂格式是很浪费电的。
考虑到现代游戏对纹理图片的严重依赖，及相应的对视频总线的巨大压力，硬件实时解压缩获得了广泛的支持，不过这个还没有一种格式获得多个厂家的支持。在OpenGL ES里已经为此定义了一个标准接口glCompressedTexImage2D(…, format, …, data)，不过纹理数据的格式则没有标准，要参考厂商的SDK或文档获得format值。这也就意味着，使用了压缩纹理之后就不能跨平台了。
常用的纹理格式有R5G6B5，A4R4G4B4，A1R5G5B5，R8G8B8, A8R8G8B8等。
文件格式是图像为了存储信息而使用的对信息的特殊编码方式，它存储在磁盘中，或者内存中，但是并不能被GPU所识别，因为以向量计算见长的GPU对于这些复杂的计算无能为力。这些文件格式当被游戏读入后，还是需要经过CPU解压成R5G6B5，A4R4G4B4，A1R5G5B5，R8G8B8, A8R8G8B8等像素格式，再传送到GPU端进行使用。
纹理格式是能被GPU所识别的像素格式，能被快速寻址并采样。举个例子，DDS文件是游戏开发中常用的文件格式，它内部可以包含A4R4G4B4的纹理格式，也可以包含A8R8G8B8的纹理格式，甚至可以包含DXT1的纹理格式。在这里DDS文件有点容器的意味。
OpenGL ES 2.0支持以上提到的R5G6B5，A4R4G4B4，A1R5G5B5，R8G8B8，A8R8G8B8等纹理格式，其中 R5G6B5，A4R4G4B4，A1R5G5B5每个像素占用2个字节(BYTE)，R8G8B8每个像素占用3个字节，A8R8G8B8每个像素占用4个字节。
对于一张512*512的纹理的话，R5G6B5格式的文件需要占用512KB的容量，A8R8G8B8格式的文件需要占用1MB的容量；如果是1024*1024的纹理，则各需要2M和4M的容量，这对于动辄需要几十、几百张甚至更多纹理的游戏，上G容量的游戏在移动平台上是不容易被接受的(当然，还是有1、2G的大作的，里面包含了几千张的纹理) 。
现在一般的显示适配器上通常装有 32MB 的显示内存。如果每个贴图都要 2MB 的话，即使不计 frame buffer 所占用的空间，也只能使用 16 张贴图。这显然是不可接受的。所以，现在的游戏通常无法使用很大的贴图。
然而，在储存一般的影像的时候，通常会使用某些压缩方式。现在常见的 JPEG 压缩，可以达到 1:6 甚至 1:12 的压缩比。如果把类似的压缩方式应用在贴图上，不就可以大量减少贴图所用的空间了吗？
不幸的是，一般的影像压缩方式，是没有办法用在贴图上面的。因为，显示芯片在存取贴图时，是一种「随机存取」的动作。也就是说，显示芯片通常会需要以任意 的顺序存取贴图里的数据。一般的压缩方式如 JPEG，都利用了 variable length 的 coding，简单的说，它们必需以一定的顺序才能解开。因此，不能用这种方式来压缩贴图。
一种压缩方式，是改变颜色空间。例如，3dfx 的 YAB 格式，就是一种不同的颜色空间。利用 YAB，每个像点只需要 8 bits，就可以达到接近 16 bits 的效果。不过，无论如何，这样都使颜色的数目减少。因此，整个贴图的色彩变化就受到了限制。
另一种方式，就是用传统的「调色盘」结构。利用一个 256 种颜色的调色盘，就可以把贴图以 8 bits 的方式储存。不过，虽然它的色彩空间较大（可以是 24 bits 或 32 bits），但是总颜色数目还是不能超过 256 种。所以，它的应用范围仍然有限。
现在常用的贴图压缩方式，则是利用以区块为基础的方式。通常的做法是，把贴图切割成许多小区块，再对各个区块进行压缩。例如，S3TC 就是把贴图切成 4×4 的小区块。利用这种做法，就可以对区块进行某种处理（通常就是 vector quantization 或是其变形），显示芯片也可以区块为单位，进行随机的存取动作。因此，这是适合用在贴图的方式。
不过，区块的大小会影响到压缩的效果。一般来说，区块愈大，就能有愈高的压缩比。不过，愈大的区块也会使额外的负担增加。因为显示芯片只能以区块为单位来读取贴图数据，如果区块愈大，则每个区块中就可能会有愈多的数据是不需要的。所以，也不能任意把区块的大小加大。
在Beers，Agrawala和Chaddha于1996发表的一篇影响深远的论文基于已压缩纹理的渲染[1]中，他们列举四项纹理压缩的特点，使其不同于其他图像压缩技术。
- 解压速度：由于最好能直接从已压缩的纹理直接渲染，为了尽可能地不影响性能，解压缩要尽可能快。
- 随机访问：由于几乎不可能预测纹素被访问的顺序，任何纹理压缩算法必须允许对其中纹素的随机访问。所以几乎所有的纹理压缩算法都以块为单位压缩和存储纹素，当某一纹素被访问时，只有同一块中若干纹素被读取和解压缩。这项需求也排除了很多压缩率较高的图像压缩方式，例如JPEG和行程长度编码。
- 压缩率和图像质量：由于人眼的不精确性，相比于其他应用领域，图像渲染更适宜使用有损数据压缩。
- 编码速度：纹理压缩对压缩速度要求不高，因为绝大多数情况下，纹理只需要进行一次压缩。
由于其数据访问模式是事先知道的，纹理压缩常作为整个
绘图管线的一部分，在绘制时对动态地已压缩数据进行解压缩。而反过来绘制管线也可以通过纹理压缩技术来降低对于
带宽和存储的需求。在
纹理贴图中，已压缩纹理和没有经过压缩的纹理使用起来基本没有区别，都可以被用来存储颜色数据或其他数据，例如
凹凸贴图或
法线贴图，也都可以和
Mipmapping或
各向异性过滤等共同使用。
主流纹理压缩标准：ETC、PVRTC、S3TC首先说OpenGL ES标准中的，2.0版规范中将ETC(Ericsson Texture Compression)作为基本的纹理压缩标准，这是大部分移动GPU都会支持的纹理标准。 OpenGL ES 3.0中还引入了ETC2、EAC纹理压缩格式，二者基本一致，只不过EAC主要用于1-2信道数据的情况。目前ECT2还在改进中，除了高通的Adreno 320之外还没有移动GPU支持，Tgera 4也不行。
此外，OpenGL ES 3.0中还有一种可选纹理压缩格式——ASTC(Adaptive Scalable Texture Compression，自适应扩展纹理压缩)，这是ARM提出的，去年被Khronos组织认可，纳入到标准中来，不过并不是强制性的，目前也只有Mali-T600系列支持。Imagination旗下的PowerVR GPU支持的是PVRTC(PowerVR texture compression)和ETC，高通的Adreno 2xx系列支持ETC之外还有3Dc和ATITC。后两者都是原来的ATI开发的，Adreno 320除了前面三种标准之外还支持ETC2纹理压缩。ARM的Mali-300/400系列支持ETC，Mali-T600还多了ASTC纹理支持。NVIDIA的Tegra系列更有趣。之前的说法称Tegra支持自己的纹理格式，实际上除了通用的ETC之外，Tegra支持的纹理叫做S3TC(S3 Texture Compression)，也被称为DXTn或者DXTC。 S3TC是S3公司在1999年引入的，后来被DX 6.0和OpenGL 1.3吸收为官方标准，DXTC相当于Windows版的名字，S3TC是OpenGL中的名字。说到S3TC，之前苹果和HTC大打专利战的时候就涉及到了这个标准。 S3已经归为VIA威盛旗下，HTC和威盛又有同一个老板——王雪红。为了支持HTC打专利战，威盛去年就把S3部门出售给了HTC，算是左手倒右手吧。S3TC是DX显卡都支持的标准，NVIDIA也在Tegra中支持了这个标准，S3TC根据不同算法又分为DXT1-DXT5这五个级别，Terga支持的实际上是DXT1、DXT3和DXT5。Vivante的GC系列也支持ETC和S3TC，跟NVIDIA的Tegra路线相同。以前都说Vivante支持的是NVIDIA Tegra的纹理数据，实际上二者是选择了共同的路线而已，DXT也不是NVIDIA的专利。
基于OpenGL ES的压缩纹理有常见的如下几种实现：1. ETC1（Ericcson texture compression) //共同支持度最高2. PVRTC(PowerVR texture compression)3. ATITC(ATI texture compression)对于使用NVIDIA Tegra2芯片的手机如Motorola XOOM，ATRIX和DRIOID BIONIC则支持如下的纹理压缩4. S3TC(S3 texture compression)
ETC是最通用的纹理压缩格式，不过ETC并不招厂商待见，因为ETC纹理压缩不支持Alpha通道，只能用于压缩不透明的材质，不过ETC也有自己的优点，几乎所有的安卓设备都可以支持ETC压缩的GPU加速。S3TC无论压缩速度还是压缩比都不错，也支持GPU加速，而且是桌面显卡通用的压缩格式，看起来是最完美的选择，可惜的是移动市场跟PC不一样，大家各自为王，NVIDIA现在还没强大到让其他GPU厂商低头采用S3TC标准的程度，因为S3TC说到底还是一种私有的标准，有专利上的麻烦。ETC2压缩标准补全了ETC1不支持Alpha通道的缺陷，支持更高质量的RGBA(RGB+Alpha)压缩，而ARM提出的ASTC标准在压缩速度和质量上比S3TC要好，但是这两种压缩格式都是新出的，支持的厂商实在太少了。
ETC1:ETC1格式是OpenGL ES图形标准的一部分，并且被所有的Android设备所支持。扩展名为: GL_OES_compressed_ETC1_RGB8_texture，不支持透明通道，所以仅能用于不透明纹理。当加载压缩纹理时，<internal format>参数支持如下格式：
GL_ETC1_RGB8_OES(RGB，每个像素0.5个字节)
PVRTC:被 用在Motorola的一些机器上，比如DROID系列。GPU为Imagination Technologies的PowerVR SGX 530。OpenGL ES的扩展名为: GL_IMG_texture_compression_pvrtc，支持预处理压缩。当加载压缩纹理时，<internal format>参数支持如下几种格式：
COMPRESSED_RGB_PVRTC_4BPPV1_IMG (RGB 4 bit per pixel)
COMPRESSED_RGB_PVRTC_2BPPV1_IMG (RGB 2 bit per pixel)
COMPRESSED_RGBA_PVRTC_4BPPV1_IMG (RGB 4 bit per pixel with alpha channel)
COMPRESSED_RGBA_PVRTC_2BPPV1_IMG (RGB 2 bit per pixel with alpha channel)
ATITC:
当前使用该种纹理压缩的机器有Nexus One。支持的OpenGL ES扩展名为: GL_ATI_texture_compression_atitc。当加载压缩纹理时，<internal format>参数支持如下类型的纹理：
ATC_RGB_AMD (RGB textures)
ATC_RGBA_EXPLICIT_ALPHA_AMD (RGB textures using explicit alpha encoding)
ATC_RGBA_INTERPOLATED_ALPHA_AMD (RGBA textures using interpolated alpha encoding)
S3TC
也 被称为DXTC，在PC上广泛被使用，但是在移动设备上还是属于新鲜事物。在使用NVIDA芯片的手机上被使用。OpenGL ES扩展名为: GL_EXT_texture_compression_dxt1和GL_EXT_texture_compression_s3tc。当加载压缩纹理 时，<internal format>的参数有如下几种格式：
GL_COMPRESSED_RGB_S3TC_DXT1 (RGB data is compressed, alpha is always 1.0)
GL_COMPRESSED_RGBA_S3TC_DXT1 (RGB data is compressed, alpha is either 1.0 or 0.0)
GL_COMPRESSED_RGBA_S3TC_DXT3 (RGB data is compressed, alpha is stored as 4 bits)
GL_COMPRESSED_RGBA_S3TC_DXT5 (RGB data is compressed, alpha is a weighted average of 8-bit values)
在程序在开始检测这些可用的扩展很重要。对于ETC1压缩来说，使用ETC1Util.isETC1Supported()即可。可以使用android.openGL.getString(GL10.GL_EXTENSIONS)解析字符串获取更多的可用扩展。
以下是其它较常见的压缩模式的细节介绍
VQTC (Vector Quantization Texture Compression)
首先，我们会介绍一种简单的贴图压缩方式：VQTC。
VQTC 是由 NEC/Videologic 的 PowerVR 系列所使用的一种贴图压缩方式，但是因为 PowerVR 系列一直没有得到很大的成功，所以 VQTC 一直未受到重视。而现在 Videologic 最新的 Kyro 显示芯片也不再支持 VQTC。不过，因为 VQTC 相当简单，所以还是简单做个介绍。
VQTC 是使用 vector quantization 的方式，所以叫
VQTC。它的原理是：把贴图切成许多相同大小的区块（例如 2×2 或 4×4），对这些区块做 vector quantization。例如，可以从这些区块中，找出 4096 个最具代表性的区块。这样一来，每个区块就只需要存放 index，也就是 12 bits 的空间。
显示芯片在读取贴图数据时，要先将整个向量（即 4096 个区块）读入显示芯片中的一个向量表。这个动作对每个贴图只需要做一次。在读取各个 texel 时，则是先判断出所需的 texel 所在的区块（以 2×2 的区块来说，就是把位置坐标分别除以二），读取 index，再从向量表中查出区块的内容。基本上，这些动作都非常简单。
在压缩比方面，以上面的例子来说，如果使用 256×256 32bpp 的贴图，并使用 2×2 的区块，那么贴图就有 128×128 = 16384 个区块。找出 4096 个最具代表性的区块后，整个贴图需要的空间就是 4096 个区块再加上 16384 个 index 的空间，即 4096×16 + 16384×1.5 = 88 KB。和原来未压缩所需要的 256KB 相比，它的压缩比约为 1:2.9。
如果是更大的贴图，则可以使用更大的区块（例如 4×4），不过，这样会使质量变差。但是，经由选择不同的区块大小，和区块的数目，就可以调整出质量和压缩比的平衡点。这是 VQTC 的优点之一。
不过，VQTC 并非没有缺点的。事实上，VQTC 最大的
缺点，就是
「不能做部分更新」 。简单的说，如果想要更新一个 VQTC 贴图中的一小部分，几乎可以说是不可能的，除非将贴图重新压缩，或是牺牲一些质量，使用原有的向量来压缩。当然，对大部分的情形来说，这并不是个严重的问题；因为需要做部分更新的情形，通常是相当少见的。
另外，VQTC 也不太适合处理有「透明度」（即 alpha channel）的贴图。一般来说，如果贴图中有 alpha channel，会对 VQTC 的质量造成影响。
VQTC 现在已经不常用了（也许只在 Dreamcast 游戏机中还被使用）。目前最流行的贴图压缩，则是由 S3 所开发的 S3TC。我们会在下一篇文章中介绍这个方法。
S3TC (S3 graphics Texture Compression)
这篇文章将会简单介绍有名的 S3TC 贴图压缩方式。
S3TC 是由 S3 公司所发展出来的，最早用在它的 Savage 系列显示芯片中。虽然 Savage 显示芯片并不算成功，但是 S3TC 却因为微软公司将其加入 DirectX 而变得相当成功。微软向 S3 授权 S3TC 技术后，其它公司若在 DirectX 中支持 S3TC（在 DirectX 中称为 DXTC），则不需另外再付给 S3 费用，因此得到了相当程度的支持。
S3TC 包括五种贴图压缩格式，在 DirectX 中，分别称为 DXT1 ~ DXT5。这些不同的贴图压缩格式，其实就是为了透明度（即 alpha channel）所设计的。
DXT1 是 S3TC 中，最基本的压缩格式。它是用来处理「没有 alpha channel」或是「alpha channel 为 1 bit」的贴图。其它的压缩方式都是只是 DXT1 的变化而已。
DXT1 所用的方法，和 VQTC 类似，也是将贴图切成许多小区块，然后再利用 vector quantization 的方式来压缩。不过，和 VQTC 不同的是，DXT1 的区块总是 4×4 的大小，而且它将 vector quantization 用在区块内，而不是像 VQTC 对所有的区块做 vector quantization。
对每个 4×4 的区块，储存了两个 16 bits 的颜色，颜色的格式是 5-6-5 的 RGB。从这两个颜色，可以用线性内插的方式，得到另外两个颜色。简单的说，如果这两个颜色分别是 RGB0 和 RGB1，那 RGB2 和 RGB3 可以由下面的式子求出：
RGB2 = (2 * RGB0 + 1 * RGB3) / 3
RGB3 = (1 * RGB0 + 2 * RGB3) / 2
这样就得到了四个颜色。区块中的每个 texel 则是以一个 2 bits 的 index 表示。如果 index = 0，则表示这个 texel 的颜色是 RGB0；index = 1 则是 RGB1；index = 2 则是 RGB2；index = 3 则是 RGB3。以这样的方式储存，每个区块只需要 16×2 + 2x4x4 = 64 bits。因此，在压缩 16 bits 的贴图时，压缩比是 1:4。
DXT1 同时也可以处理「具有 1 bit alpha channel」的贴图。一般来说，在贴图中使用 1 bit 的 alpha channel，就是用来注明「透明」的地方。因此，DXT1 的处理方式，是牺牲一个颜色，用它的表示「透明」的 texel。
如果一个区块需要存放透明色的话，那么，颜色的产生方式，就变成：
RGB2 = (RGB0 + RGB1) / 2
和前面一样，texel 的 index 仍是 2 bits。index = 0 ~ 2 时，分别是表示 RGB0 ~ RGB2。当 index = 3 时，就表示这个 texel 是「透明」的，它的颜色是黑色，且 alpha = 0。
不过，要怎么区分「有 alpha」和「没有 alpha」的情形呢？DXT1 使用了一个简单的方法：如果 RGB0 比 RGB1 要大的话，那就表示区块是没有 alpha 的。相反的，就表示有 alpha channel 了。
当 alpha channel 不只是 1 bit 时，就需要其它的方式了。DXT2 ~ DXT5 就是在处理这种情形。因为它的原理和 DXT1 是相同的，所以就不再多介绍了。不过，DXT2 ~ DXT5 每个 4×4 区块需要 128 bits，也就是说，它们的压缩比只有 DXT1 的一半。
因为 S3TC 是针对每个 4×4 的区块做压缩，所以可以对贴图做
「部分更新」的动作。要更新贴图中的某些部分，只要需更新这些部分的区块即可，其它的区块则完全不会被影响。所以，「部分更新」是很容易做到的。
在下一篇文章中，会简单介绍 3dfx 的 FXT1 贴图压缩
FXT1 (3dfx Texture Compression )
在这篇文章中，会简单介绍 3dfx 的 FXT1 贴图压缩技术。
基本上，FXT1 和 S3TC 是非常类似的。不过，FXT1 使用 8×4 的区块，而非 S3TC 的 4×4 区块。而且，相对于 S3TC 只有一种压缩方式（即 DXT1，DXT2 ~ DXT5 只是将 DXT1 加上 alpha channel 而已），FXT1 有四种不同的方式。这使得在压缩的时候，可以针对不同的情形，使用最适当的压缩方式。
FXT1 有四种压缩方式，都是使用 8×4 的区块。第一种方式称为
CC_HI，用来压缩使用 1 bit alpha channel 来表示「透明 texel」的贴图。
CC_HI 和 DXT1 非常类似，它也是存放两个颜色。不过，和 DXT1 不同的是，CC_HI 用的是 15 bits 5-5-5 RGB 的格式，而不是 16 bits 5-6-5 RGB 的格式。
利用线性内插的方式（类似 DXT1 的方式），CC_HI 的两个颜色会内插出五个颜色，合起来是七个颜色，再加上一个颜色表示「透明 texel」。每个 texel 则使用 3 bits 的 index 来指向这八个颜色。另外，CC_HI 使用 2 bits 的 mode bits 来表示这个区块是 CC_HI 格式。所以，一个 8×4 的区块需要 2 + 2×15 + 32×3 = 128 bits。因此，
如果贴图是 16 bits 的话，压缩比就是 1:4。
第二种方式称为
CC_CHROMA，它是专门用来存放没有 alpha channle 的贴图。 基本上，CC_CHROMA 的方式很简单：它存放四个 15 bits 的颜色，每个 texel 则用一个 2 bits 的 index 指向这四个颜色。它的 mode bits 是 3 bits，还有一个未使用的 bit，所以它需要的空间是 3 + 1 + 4×15 + 32×2 = 128 bits。
第三种方式称为
CC_MIXED，这个模式非常的复杂。它将 8×4 的区块分成两个 4×4 的小区块，每个小区块有两个 16 bits 5-6-5 RGB 的颜色。每个小区块中的压缩方式则和 DXT1 几乎是相同的，但是它不是用颜色的大小来区分「是否有 alpha channel」，而是用一个 alpha bit 来区分。这个模式需要的空间也是 128 bits。
第四种方式则是
CC_ALPHA，是用来处理具有多位 alpha channel 的模式（类似 DXT2 ~ DXT5）。它使用三个 20 bits 5-5-5-5 ARGB 格式的颜色，并有两种模式：第一种模式，每个 texel 的 index（2 bits）指向这三个颜色，而第四个颜色则是表示「透明 texel」。第二种模式，则是将区块分成两个小区块，并使用类似 DXT1 的方式（第一个小区块用 COLOR0 和 COLOR1 为基础色，而第二个小区块则用 COLOR1 和 COLOR2 为基础色），只不过有加上 alpha channel。这个格式的 mode bit 是 3 bits，再加上一个「模式 bit」，所以需要的空间是 3 + 1 + 20×3 + 32×2 = 128 bits。
基本上，FXT1 的压缩比和 S3TC 并没有很大的差别，但是一般来说，效果（特别是压缩 24 bits 或 32 bits 的贴图）则比 S3TC 要好一些。不过，它的区块较大，也会使显示芯片在处理时的效率较差。
FXT1 和 S3TC 都有相对应的 OpenGL extension 来提供支持。所以，如果想要取得更详细的资料，可以到 OpenGL® Extension Registry 网站取得。S3TC 的 extension 称为 GL_EXT_texture_compression_s3tc，而 FXT1 的 extension 则称为 GL_3DFX_texture_compression_FXT1。在 extension 的文件中，有详细的格式说明。
压缩纹理工具的使用
每种压缩纹理以及相应的厂商都提供了压缩纹理的工具，工具都分两个版本：
a. 可视化转换工具 (给美工或小白少量使用)
b. 命令行转换工具 (给程序批量使用)
下面对每个工具的用法进行说明。
1）Imagination Technologies PowerVR
工具下载地址
http://www.imgtec.com/powervr/insider/sdkdownloads/index.asp?installer=Windows%20Installer
可视化转换界面
命令行转换脚本
for %%i in (*.tga) do PVRTexTool.exe -f PVRTC4 -i %%i
(将本目录下的所有tga文件，转换成"PVRTC4"编码格式的pvr文件，不带mipmap)
详细使用说明：PvrTexTool.exe /?
2）Qualcomm Adreno
工具下载地址
https://developer.qualcomm.com/mobile-development/mobile-technologies/gaming-graphics-optimization-adreno/tools-and-resources
可视化转换界面
命令行转换脚本
for %%i in (*.tga) do QCompressCmd.exe %%i %%i.ktx "ATC RGBA Explicit" yes
(将本目录下的所有tga文件，转换成"ATC RGBA Explicit"编码格式的ktx文件，带mipmap)
详细使用说明：QCompressCmd.exe /?
3）ARM Mali
工具下载地址
http://malideveloper.arm.com/develop-for-mali/mali-gpu-texture-compression-tool/
可视化转换界面
命令行转换脚本
for %%i in (*.tga) do PVRTexTool.exe -f ETC -i %%i
(将本目录下的所有tga文件，转换成"ETC"编码格式的pvr文件，不带mipmap这里还是使用的PVRTexTool.exe，也可以使用QCompressCmd.exe)
详细使用说明：PVRTexTool.exe /?
4）nVIDIA Tegra
可以使用DirectX SDK中自带的DirectX Texture Tool进行转换
可视化转换界面
命令行转换脚本
for %%i in (*.tga) do texconv.exe -f DXT5 %%i
(将本目录下的所有tga文件，转换成"DXT5"编码格式的dds文件，不带mipmap)
详细使用说明：TexConv.exe /?
参考网址
http://www.opengpu.org/forum.php?mod=viewthread&tid=417
http://zh.wikipedia.org/wiki/%E7%BA%B9%E7%90%86%E5%8E%8B%E7%BC%A9
http://m.mydrivers.com/newsview.aspx?id=266555&cid=1&p=2
http://www.blogjava.net/demibug/archive/2011/12/16/366543.html
http://www.cnblogs.com/luming1979/archive/2013/02/04/2891421.html