DXTC

DXTC（時々S3 Texture Compression　(S3TC)　ないしDXTnと呼ばれる）は、元々S3社によって開発された画像圧縮アルゴリズム技術である(US Patent #5,956,431)。この技術はSavage 3Dグラフィックスアクセラレータで用いられている。JPEGのような既存の画像圧縮アルゴリズムとは違い、DXTCは（VQのやり方に似た）単純なメモリアクセスと対になった固定レートデータ圧縮を行う。これは3Dコンピュータグラフィックスをハードウェアで支援する際、テクスチャを圧縮するのに適している。この技術は、マイクロソフトのDirectX 6.0に含まれると、ハードウェアやソフトウェアメーカーに広く採用されるようになった。S3社はもはやグラフィックスアクセラレータ市場において、リーディングカンパニーではないが、例えばコンソール用に使われているDXTC技術のライセンス料でいまだ生き長らえている。

コーデック[編集]

DXTCアルゴリズムには5つのバリエーションがある。これらはDXT1からDXT5まであり、それぞれのフォーマットに対してFourCCコードがマイクロソフトによって割り当てられている。これらはそれぞれ特定の種類のイメージデータ用に設計されている。画像はすべてのフォーマットにおいて、64ビットないし128ビットに量子化された4×4ブロックに変換され、32ビットのRGBA入力データは8:1ないし4:1に圧縮される。DXTCは非可逆圧縮アルゴリズムであるため、画像品質は落ちるが、リアルな画像を表示するには、圧縮された画像データでも十分である。アニメ風の画像や法線マップは上手く圧縮することができず、アーティファクトが生じやすい。ATIの3Dc圧縮アルゴリズムは、DXTCが持つ法線マップについての欠点を克服するように設計された、DXT5の変種である。

多くの近代的な画像圧縮アルゴリズムと同様に、実装者が特定のニーズに合わせて圧縮アルゴリズムを設計することができるようにするために、DXTCはただ画像を解凍するのに使われる方法を指定するのみである。しかし特許は圧縮アルゴリズムもカバーしている。初期の圧縮ルーチンは最適化されていなかった。それはどんどん改善されたが、最初DXTCは開発ベンダーに採用されなかった。NVIDIAのGeForceからGeForce 4までのGPUは16ビット補間のDXT1テクスチャ描画を使用していたので、色変化を伴うテクスチャを解凍する時に帯のようなノイズが載っていた。このため、テクスチャ圧縮に対してよくない印象を与えてしまったが、これはコーデック自身に基本的に関係しないものだった。

DXT1[編集]

DXT1は最も簡単なDXTCのバリエーションである。これは、16ピクセル入力から64ビットデータを出力する。この出力は16bit RGB5:6:5　2色と4x4の2ビットのルックアップテーブルからなる。

最初の色 (c0) が2番目の色 (c1) より数値的に大きいならば、他の2つの色は $c_{2}={2 \over 3}c_{0}+{1 \over 3}c_{1}$ と $c_{3}={1 \over 3}c_{0}+{2 \over 3}c_{1}$ として計算される。このモードはAppleのビデオコーデックのc0モードによく似ている。

逆に $c_{0}\leq c_{1}$ なら、 $c_{2}={1 \over 2}c_{0}+{1 \over 2}c_{1}$ になり、c3は透過色になる。

ルックアップテーブルはそれぞれのピクセル毎に色値が決定される。 $c_{0}$ だと0に相当し、 $c_{3}$ だと3が相当する。より高圧縮にするためにアルファデータは格納されない。

DXT2とDXT3[編集]

DXT2とDXT3は16ピクセル入力から128ビットデータに変換する。これは64ビットの色データに続いて64ビットのアルファチャンネルデータ（ピクセルそれぞれについて4ビット）からなり、DXT1と同様の方法でエンコードされる（ただし、アルファなしの4色バージョンが常に使われる）。DXT2では、色データにはあらかじめアルファデータが掛け合わせてあり、DXT3ではアルファデータが掛け合わされていない。普通、DXT2/3は透過色の領域と不透明色の領域の境界が鋭く変化する画像によく合う。

DXT4とDXT5[編集]

DXT4とDXT5は16ピクセル入力から128ビットデータに変換する。このデータには64ビットの色データ（DXT2ないしDXT3と同じ方法でエンコードされたもの）に続いて、64ビットのアルファチャンネルデータ（2つの8ビットアルファ値と4x4の3ビットルックアップテーブル）からなる。

$\alpha _{0}>\alpha _{1}$ であれば、6つの補間用アルファ値を以下の様に計算する。 $\alpha _{2}={{6\alpha _{0}+1\alpha _{1}} \over 7}$ , $\alpha _{3}={{5\alpha _{0}+2\alpha _{1}} \over 7}$ , $\alpha _{4}={{4\alpha _{0}+3\alpha _{1}} \over 7}$ , $\alpha _{5}={{3\alpha _{0}+4\alpha _{1}} \over 7}$ , $\alpha _{6}={{2\alpha _{0}+5\alpha _{1}} \over 7}$ ,　 $\alpha _{7}={{1\alpha _{0}+6\alpha _{1}} \over 7}$ .

逆に $\alpha _{0}\leq \alpha _{1}$ であれば、4つの補間用アルファデータを $\alpha _{2}={{4\alpha _{0}+1\alpha _{1}} \over 5}$ , $\alpha _{3}={{3\alpha _{0}+2\alpha _{1}} \over 5}$ , $\alpha _{4}={{2\alpha _{0}+3\alpha _{1}} \over 5}$ , $\alpha _{5}={{1\alpha _{0}+4\alpha _{1}} \over 5}$ と計算する。残り2つは $\alpha _{6}=0$ と $\alpha _{7}=255$ とする。ルックアップテーブルはそれぞれのピクセルのアルファ値に従って決定される。 $\alpha _{0}$ は0に割り当てられ、 $\alpha _{7}$ は7に割り当てられる。DXT4の色データはアルファ値がすでに掛け合わせてあり、DXT5の色データはそうではない。DXT4/5は補間アルファ色値を用いているので、DXT2/3よりアルファ値（透過具合）がだんだん変化していくものについては非常によい結果をもたらす。DXT5は最も柔軟な汎用圧縮アルゴリズムだと考えられる。

FOURCC	内容	Alpha premultiplied?	圧縮率	テクスチャタイプ
DXT1	不透明色 / 1-bit Alpha	N/A	8:1 / 6:1	単純なアルファなし
DXT2	明示的なアルファ値	Yes	4:1	鋭く変化するアルファ値をもつ
DXT3	明示的なアルファ値	No	4:1	鋭く変化するアルファ値をもつ
DXT4	補間アルファ値	Yes	4:1	徐々に変化するアルファ値をもつ
DXT5	補間アルファ値	No	4:1	徐々に変化するアルファ値をもつ

コーデック[編集]

DXT1[編集]

DXT2とDXT3[編集]

DXT4とDXT5[編集]

関連項目[編集]