「（ハードウェア）テクスチャ圧縮の仕組み」は大きなトピックです。Nathanの回答の内容を複製することなく、いくつかの洞察を提供できれば幸いです。
必要条件
テクスチャ圧縮は通常、「標準」の画像圧縮技術とは異なります。たとえば、JPEG / PNGは、Beers et al。 Rendering from Compressed Texturesに。
デコード速度：非圧縮のテクスチャを使用するよりも、テクスチャの圧縮を遅くしたくありません（少なくともそれほど顕著ではありません）。また、過度のハードウェアや電力のコストをかけずに高速の解凍を実現するのに役立つため、解凍は比較的簡単である必要があります。
ランダムアクセス：特定のレンダリング中に必要なテクセルを簡単に予測することはできません。アクセスされたテクセルのサブセットMが、たとえば画像の中央にある場合、Mを決定するためにテクスチャの「前の」行のすべてをデコードする必要はありません。JPEGおよびPNGでは、ピクセルデコードが以前にデコードされたデータに依存するため、これが必要です。
あなたが「ランダム」アクセスを持っているという理由だけで、これを言ったことに注意してください、完全に任意にサンプリングしようとする必要があるという意味はありません。
圧縮率と視覚的品質：Beersらは、（納得のいくように）圧縮率を改善するために圧縮結果の品質をいくらか落とすことは価値のあるトレードオフだと主張しています。3Dレンダリングでは、おそらくデータが操作され（フィルターやシェーディングなど）、品質の低下が隠される可能性があります。
非対称エンコード/デコード：多少議論の余地があるかもしれませんが、エンコードプロセスをデコードよりもはるかに遅くすることは許容できると主張しています。デコードをハードウェアフィルレートにする必要がある場合、これは一般に許容されます。（PVRTC、ETC2、および他のいくつかの圧縮を最高品質で高速化できることは認めます）
初期の歴史と技術
テクスチャ圧縮が30年以上にわたって行われていることを知って驚く人もいるかもしれません。70年代および80年代のフライトシミュレーターは、比較的大量のテクスチャデータにアクセスする必要があり、1980年の1MBのRAMが6000ドルを超えていたため、テクスチャフットプリントの削減が不可欠でした。別の例として、70年代半ばには、少量の高速メモリとロジックでさえ、たとえば控えめな512x512 RGBフレームバッファーに十分）でも、小さな家の価格を引き下げることができました。
ただし、テクスチャ圧縮とは明示的に呼ばれていないAFAIKは、文献や特許で次のような手法への参照を見つけることができます
。数学/手順テクスチャ合成の単純な形式、
b。単一チャネルテクスチャ（4bppなど）を使用し、次にテクスチャごとのRGB値を乗算します
c。YUV、および
d。パレット（圧縮を行うヘックバートのアプローチの使用を示唆する文献）
画像データのモデリング
上記のように、テクスチャ圧縮はほとんど常に損失が大きいため、重要でないデータを処理しながらコンパクトな方法で重要なデータを表現しようとする問題の1つになります。以下で説明するさまざまなスキームには、テクスチャデータと目の応答の典型的な動作を近似する暗黙の「パラメータ化」モデルがあります。
さらに、テクスチャ圧縮は固定レートエンコーディングを使用する傾向があるため、圧縮プロセスには通常、モデルに入力されたときに元のテクスチャの適切な近似を生成するパラメータのセットを見つけるための検索ステップが含まれます。ただし、その検索ステップには時間がかかる場合があります。
（optipngなどのツールの可能性を除く、これはPNGとJPEGの一般的な使用がテクスチャ圧縮スキームと異なる別の領域です）
さらに先に進む前に、TCの理解を深めるために、主成分分析（PCA）を見てみる価値があります。これは、データ圧縮に非常に役立つ数学的なツールです。
テクスチャの例
さまざまな方法を比較するために、次の画像を使用します。
これは、RGBカラーキューブの大部分にまたがり、テクセルの15％だけが繰り返し色を使用するため、特にパレットおよびVQTCメソッドの場合、かなり厳しいイメージであることに注意してください。
PCおよび（90年代半ば以降）コンソールテクスチャ圧縮
データコストを削減するために、一部のPCゲームや初期のゲームコンソールでも、ベクトル量子化（VQ）の一種であるパレットイメージを使用していました。パレットベースのアプローチでは、与えられた画像はRGB（A）カラーキューブの比較的小さな部分のみを使用すると仮定しています。パレットテクスチャの問題は、達成される品質の圧縮率が一般にかなり控えめであることです。「GIMPを使用して」「4bpp」に圧縮されたサンプルテクスチャ
は、これがVQスキームでは比較的厳しいイメージであることに注意してください。
大きなベクトルを含むVQ（2bpp ARGBなど）
Beersらに触発されて、DreamcastコンソールはVQを使用して、2x2または2x4ピクセルブロックをシングルバイトでエンコードしました。パレットテクスチャの「ベクトル」は3次元または4次元ですが、2x2ピクセルブロックは16次元と見なすことができます。圧縮スキームは、これらのベクトルの十分な、おおよその繰り返しがあると仮定します。
VQは〜2bppで十分な品質を達成できますが、これらのスキームの問題は、依存メモリ読み取りが必要なことです：ピクセルのコードを決定するためのインデックスマップからの最初の読み取りの後に、関連付けられたピクセルデータを実際にフェッチするための秒が続きますそのコードで。キャッシュを追加すると、発生する遅延の一部を軽減できますが、ハードウェアが複雑になります。
2bpp Dreamcastスキームで圧縮されたサンプル画像は
です。インデックスマップは次のとおりです。
VQデータの圧縮はさまざまな方法で実行できますが、IIRCは、PCAを使用して行われ、2つの代表ベクトルが平均二乗誤差を最小化するように、主ベクトルに沿って16Dベクトルを導出し、次に分割しました。このプロセスは、256個の候補ベクトルが生成されるまで繰り返されました。次に、グローバルk-means / Lloydのアルゴリズムアプローチを適用して、代表を改善しました。
色空間変換
色空間変換では、PCAを利用して、色のグローバルな分布が主軸に沿って広がることが多く、他の軸に沿って広がることははるかに少ないことに注意してください。YUV表現の場合、a）長軸はしばしばルミナンス方向にあり、b）目はこの方向の変化に対してより敏感であるという仮定があります。
3dfx Voodooシステムは「YAB」を提供しました、各8ビットテクセルを322形式に分割し、ユーザー選択の色変換をそのデータに適用してRGBにマッピングする、8bpp、「狭チャネル」圧縮システムしました。したがって、主軸には8つのレベルがあり、小さい軸にはそれぞれ4つのレベルがありました。
S3 Virgeチップはわずかにシンプルな4bppスキームを備えていたため、ユーザーはテクスチャ全体に対して、4bppモノクロテクスチャとともに、主軸上にある2つの終了色を指定できます。次に、ピクセルごとの値が適切な重みで最終色をブレンドして、RGB結果を生成しました。
BTCベースのスキーム
DelpとMitchellは、数年巻き戻し、Block Truncation Coding（BTC）と呼ばれる単純な（モノクロ）画像圧縮方式を設計しました。このホワイトペーパーには圧縮アルゴリズムも含まれていますが、この目的のために、主に結果の圧縮データと解凍プロセスに関心があります。
このスキームでは、画像は通常4x4ピクセルのブロックに分割され、実際にはローカライズされたVQアルゴリズムで独立して圧縮できます。各ブロックは、2つの「値」、aとb、および4ビットのインデックスビットのセットで表され、各ピクセルに2つの値のどちらを使用するかを識別します。
S3TC：4bpp RGB（+1ビットアルファ）
画像圧縮用にBTCのいくつかのカラーバリエーションが提案されましたが、私たちにとって興味深いのはIourcha et alのS3TCです。その一部は、Hoffert et alていますAppleのQuicktimeで使用されていました。
DirectXバリアントのない元のS3TCは、RGBまたはRGB + 1ビットアルファのブロックを4bppに圧縮します。テクスチャ内の各4x4ブロックは、AとBの 2つの終了色に置き換えられ、そこから最大2つの他の色が固定ウェイトの線形ブレンドによって派生します。さらに、ブロック内の各テクセルには、これらの4色の1つを選択する方法を決定する2ビットのインデックスがあります。
たとえば、次はAMD / ATI Compressenatorツールで圧縮されたテストイメージの4x4ピクセルセクションです。（技術的には、テストイメージの512x512バージョンから取得されていますが、例を更新する時間が足りないことは許します）。
これは、圧縮プロセスを示しています。色の平均と主軸が計算されます。次に、軸上にある2つのエンドポイントを見つけるために最適な適合が実行され、それらのエンドポイントの2つの派生1：2および2：1ブレンド（または場合によっては50:50ブレンド）とともに、エラーを最小化します。次に、元の各ピクセルがこれらの色の1つにマッピングされ、結果が生成されます。
この場合のように、色が主軸で合理的に近似されている場合、誤差は比較的低くなります。ただし、下に示す隣接する4x4ブロックのように、色がより多様である場合、エラーは大きくなります。
AMD Compressonatorで圧縮されたサンプル画像は以下を生成します。
色はブロックごとに独立して決定されるため、ブロックの境界で不連続が発生する可能性がありますが、解像度が十分に高い限り、これらのブロックアーティファクトは気付かれることはありません。
ETC1：4bpp RGB
Ericsson Texture Compressionは4x4ブロックのテクセルでも動作しますが、YUVと同様に、ローカルテクセルセットの主軸は「ルマ」と非常に強く相関していると仮定しています。テクセルのセットは、平均色と、その想定軸へのテクセルの投影の高度に量子化されたスカラー「長さ」だけで表すことができます。
これにより、たとえばS3TCに比べてデータストレージコストが削減されるため、ETCでパーティショニングスキームを導入できます。これにより、4x4ブロックが水平4x2または垂直2x4サブブロックのペアに分割されます。これらはそれぞれ独自の平均色を持っています。サンプル画像は以下を生成します
。くちばしの周りの領域は、4x4ブロックの水平および垂直分割も示しています。
グローバル+ローカル
IvanovとKuzminの分散パレットまたはPVRTCのメソッドのような、グローバルスキームとローカルスキームのクロスであるテクスチャ圧縮システムがいくつかあります。
PVRTC：4＆2 bpp RGBA
PVRTCは、（実際には双線形に）アップスケールされた画像がフル解像度ターゲットの適切な近似であり、近似とターゲットの差、つまりデルタ画像が局所的に単色であると仮定します。主軸が支配的です。さらに、ローカル主軸を画像全体に補間できると想定しています。
（する：内訳を示す画像を追加する）
PVRTC1 4bppで圧縮されたテクスチャの例：：の
周りの領域：
BTCスキームと比較して、ブロックアーティファクトは通常除去されますが、ソースイメージに強い不連続性がある場合など、「オーバーシュート」が発生することがあります。ゴシキセイガイの頭のシルエット。
2bppバリアントには、当然、4bppよりも高いエラーがあります（首の近くの青い高周波数領域の精度が低下していることに注意してください）。
減圧コストに関する注意
上記のスキームの圧縮アルゴリズムには中程度から高い評価コストがありますが、特にハードウェア実装用の解凍アルゴリズムは比較的安価です。たとえば、ETC1には、少数のMUXと低精度の加算器しか必要ありません。S3TCは、ブレンドを実行するための追加ユニットを効果的にわずかに増やします。そしてPVRTC、もう少しもう一度。理論的には、これらの単純なTCスキームにより、GPUアーキテクチャはフィルタリングステージの直前まで解凍を回避できるため、内部キャッシュの有効性が最大化されます。
その他のスキーム
言及すべきその他の一般的なTCモードは次のとおりです。
ETC2-ETC1の（4bpp）スーパーセットであり、「ルマ」とうまく整合しない色分布を持つ領域の処理を改善します。1ビットアルファをサポートする4bppバリアントと、RGBA用の8bppフォーマットもあります。
ATC-事実上、S3TCの小さなバリエーションです。
FXT1（3dfx）は、S3TCテーマのより野心的なバリアントでした。
BC6およびBC7：ARGBをサポートする8bpp、ブロックベースのシステム。HDRモードとは別に、これらはETCのシステムよりも複雑なパーティションシステムを使用して、画像の色分布をより適切にモデル化しようとします。
PVRTC2：2＆4bpp ARGB。これにより、画像内の強い境界の制限を克服するモードを含む追加モードが導入されます。
ASTC：これもブロックベースのシステムですが、広範囲のbppを対象とした多数の可能なブロックサイズがあるという点で、やや複雑です。また、疑似ランダムパーティションジェネレーターを備えた最大4つのパーティション領域、インデックスデータの可変解像度、カラー精度、カラーモデルなどの機能も含まれています。