ハードウェアテクスチャ圧縮はどのように機能しますか?


13

ピクセル配列と比較してデータを圧縮することは明らかです。

しかし、通常の圧縮(png、jpegなど)と何が違うのでしょうか?


「通常の圧縮」とは何ですか-JPEGやPNGのようなものですか?これらとDXTやASTCなどのハードウェアでサポートされている形式との違いについて質問していますか?
ネイサンリード

6
(ついに、私が少し知っているテーマ!)PNG / JPEGと違うのはランダムアクセスです。Texel(XY)にアクセスする場合、そのテクセルを生成するために必要なデータの小さなフットプリントをすばやく判断できます。JPGまたはPNGでは、すべてのデータを解凍する必要がある場合があります。ウィキペディアの記事のセクション1および2 は、良い要約です。
サイモンF

SimonFが書いたように。これは非常に広範な質問であり、答えはどのタイプに興味があるかによって異なります。たとえば、DXTの仕様を見ましたか?
イマレット

回答:


24

Simonのコメントが示唆しているように、ハードウェアテクスチャ圧縮と他の一般的に使用される画像圧縮の大きな違いの1つは、前者がエントロピーコーディングを使用しないことです。エントロピーコーディングとは、ZIPなどのコンテナ形式、GIF、JPEG、PNGなどの多くの一般的な画像形式、および多くの一般的なオーディオで見られるように、ソースデータでよく発生するパターンまたは繰り返しパターンを表す短いビット文字列の使用ですおよびビデオ形式。

エントロピーコーディングはあらゆる種類のデータの圧縮に適していますが、本質的に可変圧縮率を生成します。画像の一部の領域にはほとんど詳細がなく(または、使用しているコーディングモデルによって詳細が予測される)、非常に少ないビットが必要な場合もありますが、エンコードするのにより多くのビットが必要な複雑な詳細がある場合があります。これにより、圧縮データのどこで特定の(x、  yのピクセルを見つけることができるかを計算する簡単な方法がないため、ランダムアクセスの実装が難しくなります。)座標。また、ほとんどのエントロピーコーディングスキームはステートフルであるため、ストリーム内の任意の場所で単純にデコードを開始することはできません。正しい状態を構築するには、最初から始めなければなりません。ただし、テクスチャサンプリングにはランダムアクセスが必要です。これは、シェーダーがテクスチャ内の任意の場所からいつでもサンプリングできるためです。

したがって、ハードウェア圧縮では、エントロピーコーディングではなく、固定比率のブロックベースのスキームを使用します。たとえば、DXT / BCn圧縮では、テクスチャは4x4ピクセルブロックにスライスされ、それぞれが64ビットまたは128ビット(選択された形式に応じて)でエンコードされます。ASTC、異なるフォーマットは12×12までの4×4のブロックサイズを使用し、全てのブロックが128ビットで符号化されます。ビットが画像データをどのように表現するかの詳細はフォーマットによって異なります(同じ画像内でブロックごとに異なる場合もあります)が、比率が固定されているため、ハードウェアはブロックを見つけるメモリの場所を簡単に計算できます指定された(xy)ピクセルを含み、各ブロックは自己完結型であるため、他のブロックとは独立してデコードできます。

ハードウェアテクスチャ圧縮のもう1つの考慮事項は、デコードをハードウェアで効率的に実装できることです。これは、重い数学演算と複雑なデータフローが強く嫌われることを意味します。たとえば、BCn形式は、ブロックごとにいくつかの8ビット整数演算を実行して小さなルックアップテーブルを作成し、ピクセルごとに適切なテーブルエントリを検索するだけでデコードできます。これにはオンチップの領域がほとんど必要ありませんが、これはおそらく複数のブロックを並行してデコードしたいため、デコードハードウェアのコピーがいくつか必要になるため重要です。

対照的に、JPEGのようなDCTベースの形式では、ブロック内のピクセル間でさまざまな中間値を交換およびブロードキャストする複雑なデータフローは言うまでもなく、ピクセルごとに重要な計算が必要です。(DCTデコードの厄介な詳細については、この記事を参照してください。)これはハードウェア実装にとって非常に粗末なものになるでしょう。 。


素晴らしい答え。また、状況によっては、専用のハードウェアに依存するのではなく、ピクセルシェーダーでクライアントコードを使用して圧縮し、デコードできることを記載した論文があることも追加できます。私はそれを現実世界で使用することを知りません、それは研究のためだけの価値があるかもしれませんが、存在します。
v.oddou

1
@ Nathan-Reed re transform-b​​ased compression、実際には、MicrosoftのTalismanプロジェクトは(モードの1つとして)DCTを使用したTRECと呼ばれる圧縮スキームを使用しましたが、JPEGとは異なり、ブロックへのランダムアクセスを許可しました(アドレス)。これにより、さまざまなブロックの可変長データが許可されますが、HWの間接指定は不快です。これが、VQ TCが時代遅れになった理由です。FWIW約12のTCアイデアB4 PVRTCを試しました。一部は固定レートの変換ベースでしたが、「欠落」係数はまだビットを使用しています。BTCのような固定係数位置は、「無料」情報を意味します。
サイモンF

2
@ネイサン・リード。私が見たところから、すべてのHWデコーダーは純粋な論理パス(ビットデコード、データルックアップ、データパスでの数学)で実装できますが、ループ/レジスタの必要はありません。テクスチャルックアップにサイクルレイテンシを追加するスキームを知っていますか?(私は楽しみのためにVHDL ETC1デコーダーを実装しました)各テクスチャユニット(TU)にはデコーダーが埋め込まれているという印象を受けました。
ロマンピコイ

30

「(ハードウェア)テクスチャ圧縮の仕組み」は大きなトピックです。Nathanの回答の内容を複製することなく、いくつかの洞察を提供できれば幸いです。

必要条件

テクスチャ圧縮は通常、「標準」の画像圧縮技術とは異なります。たとえば、JPEG / PNGは、Beers et al。 Rendering from Compressed Texturesに

  1. デコード速度:非圧縮のテクスチャを使用するよりも、テクスチャの圧縮を遅くしたくありません(少なくともそれほど顕著ではありません)。また、過度のハードウェアや電力のコストをかけずに高速の解凍を実現するのに役立つため、解凍は比較的簡単である必要があります。

  2. ランダムアクセス:特定のレンダリング中に必要なテクセルを簡単に予測することはできません。アクセスされたテクセルのサブセットMが、たとえば画像の中央にある場合、Mを決定するためにテクスチャの「前の」行のすべてをデコードする必要はありません。JPEGおよびPNGでは、ピクセルデコードが以前にデコードされたデータに依存するため、これが必要です。
    あなたが「ランダム」アクセスを持っているという理由だけで、これを言ったことに注意してください、完全に任意にサンプリングしようとする必要があるという意味はありません。

  3. 圧縮率と視覚的品質:Beersらは、(納得のいくように)圧縮率を改善するために圧縮結果の品質をいくらか落とすことは価値のあるトレードオフだと主張しています。3Dレンダリングでは、おそらくデータが操作され(フィルターやシェーディングなど)、品質の低下が隠される可能性があります。

  4. 非対称エンコード/デコード:多少議論の余地があるかもしれませんが、エンコードプロセスをデコードよりもはるかに遅くすることは許容できると主張しています。デコードをハードウェアフィルレートにする必要がある場合、これは一般に許容されます。(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スキームで圧縮されたサンプル画像は 2bpp VQ結果です。インデックスマップは次のとおりです。2bpp VQインデックスマップ

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つの「値」、ab、および4ビットのインデックスビットのセットで表され、各ピクセルに2つの値のどちらを使用するかを識別します。

S3TC:4bpp RGB(+1ビットアルファ)
画像圧縮用にBTCのいくつかのカラーバリエーションが提案されましたが、私たちにとって興味深いのはIourcha et alのS3TCです。その一部は、Hoffert et alていますAppleのQuicktimeで使用されていました。

DirectXバリアントのない元のS3TCは、RGBまたはRGB + 1ビットアルファのブロックを4bppに圧縮します。テクスチャ内の各4x4ブロックは、ABの 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つのパーティション領域、インデックスデータの可変解像度、カラー精度、カラーモデルなどの機能も含まれています。


1
うわー、これはどこかのブログ投稿になります!素晴らしい答えです!
-glampert

2
助けてくれてうれしいです。ブログに関しては、10年前にこれを書きましたが、実際にそれをする時間はありません。
サイモンF
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.