ETC1形式のモバイルグラフィックスとオープンユーティリティの圧縮

無料で遊べるモバイルゲームの開発に伴い、新しいグラフィックスが新しい機能とともに定期的に追加されています。 その一部はディストリビューションに含まれており、一部はゲーム中にダウンロードされます。 RAMサイズが小さいデバイスでアプリケーションを実行するために、開発者はハードウェア圧縮テクスチャを使用します 。







ETC1形式は 、OpenGL ES 2.0を搭載したすべてのAndroidデバイスでのサポートに必須であり、消費されるRAMを最適化するための良い出発点です。 PNG、JPEG、WebP形式と比較して、ETC1テクスチャの読み込みは、メモリの通常のコピーによる集中的な計算なしで実行されます。 低速メモリから高速メモリに送信されるテクスチャデータのサイズが小さくなるため、ゲームのパフォーマンスも向上します。



OpenGL ES 3.0を搭載したデバイスでは、ETC1形式のテクスチャを使用できます。これは、改良されたETC2形式のサブセットです 。

ETC1形式での圧縮テクスチャの使用

ETC1形式にはRGBカラーコンポーネントのみが含まれているため、アルファブレンディングを無効にしてペイントすることをお勧めする不透明な背景に適しています。



透明なグラフィックスをどうしますか？ そのために、2つのテクスチャETC1（以降-2xETC1）を使用します。



-最初のテクスチャに元のRGBを保存します。

-2番目のテクスチャで、元のアルファ（以降-A）をRGBコンポーネントにコピーして保存します。



次に、2xETC1ピクセルシェーダーで、次の方法で色を復元します。

uniform sampler2D u_Sampler; uniform sampler2D u_SamplerAlpha; varying vec2 v_TexCoords; varying vec4 v_Color; void main() {    vec4 sample = texture2D(u_Sampler, v_TexCoords);    sample.a = texture2D(u_SamplerAlpha, v_TexCoords).r;    gl_FragColor = sample * v_Color; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ETC1形式に圧縮する前にアトラスを準備する機能

ETC1形式は独立した4x4ピクセルブロックを使用するため、異なる要素が共通ブロックに入らないように、アトラスに配置された要素の位置を4ピクセルに揃えることをお勧めします。



アトラスに配置されたすべての要素は、1〜2ピクセルの厚さの追加の保護フレームが必要なので、面積がわずかに増加します。 これは、レンダリングの分数座標（スプライトの滑らかな動きによる）とテクスチャのバイリニアフィルタリングによるものです。 何が起こっているのかを数学的に正当化するには、別の記事が必要です。



多角形のアトラスの場合、要素は許容可能な距離まで離婚します。 4TC ETC1ブロックはすべて、2x4または4x2のストリップのペアで構成されているため、2ピクセルの距離でも良好な断熱効果が得られます。

ETC1形式に定性的に圧縮できるものは何ですか？

無料のユーティリティの中から選択できます。



-ETC2Comp ;

-Mali GPUテクスチャ圧縮ツール 。

-PVRTexTool ;

-rg-etc1



高品質のグラフィック圧縮を行うには、知覚の特性を考慮した知覚指標を設定し、低速モードと最適モードを選択する必要があります。 テクスチャ2048x2048を定性的に圧縮しようとすると、これは長いプロセスであることがわかります...おそらく、多くの開発者が中高速の高速な代替手段に制限されている理由です。 もっと良くすることは可能ですか？



Playrixプログラマーの1人による独自のユーティリティEtcCompressのゼロからの作成の話は、ETC1形式のグラフィックスの最終的な圧縮が訪問中に3時間の訪問を超えた2014年1月にさかのぼります。

ETC1形式での高品質圧縮のアイデア

ETC1形式は独立したブロック形式です。 したがって、個々のブロックを圧縮する古典的なアプローチを使用しますが、これは十分に並列化されています。 もちろん、ブロックのセットを考慮することでブロックの結合を改善することもできますが、この場合、アトラス要素に属することに関する情報が必要になり、タスクの計算の複雑さが急激に増加します。



dssimユーティリティは、圧縮結果の比較に適しています。



ブロックごとに、コードで最適なCompressBlockColor関数を見つけるために、4つの可能なエンコードモードすべてを実行する必要があります。



-2つの2x4ストリップ（それぞれ独自の基本的な4ビットカラーを持つ）は、コードでCompressBlockColor44（...、0）を呼び出します。

-コードでCompressBlockColor44（...、1）を呼び出す2つの4x2ストリップ。それぞれが独自の基本的な4ビットカラーを持ちます。

-2つの2x4ストリップ、最初のコードは基本的な5ビット色、2番目のコードはCompressBlockColor53（...、2）を呼び出すコードで3ビットの範囲の最初のコードとは基本色が異なります。

-2つの4x2ストリップ、最初は基本的な5ビット色、2番目は3ビット範囲の最初と基本色が異なるコードで、CompressBlockColor53（...、3）を呼び出します。

2x4、444 + 444	4x2、444 + 444	2x4、555 + 333	4x2、555 + 333

エラーといえば、多くのユーティリティは従来のPSNRを使用します。 このメトリックも使用します。 表から重みを選択します 。

 PixelError = 0.715158 * (dstG - srcG)^2 + 0.212656 * (dstR - srcR)^2 + 0.072186 * (dstB - srcB)^2
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

係数に1000を掛けて丸めることにより、整数値になります。 4x4ブロックの初期エラーはkUnknownError = (255^2) * 1000 * 16 + 1



になります255



は色成分の最大エラー、 1000



は重みの固定合計、16はピクセル数です。 このようなエラーはint32_t



適合します。 整数の2乗は、 ガンマ2.2を考慮することに意味が近いことに気付くかもしれません。



PSNRには弱点があります。 たとえば、パレットc1 = c0 - d



およびc2 = c0 + d



から選択して色c0



塗りつぶしをコーディングすると、同じエラーd^2



発生します。 これは、あらゆる種類のチェッカーを伴うc1



とc2



間のランダムな選択を意味します。



結果を改善するために、ブロック内の最終計算がSSIMによって実行されます。 コードでは、これは、SSIM_INIT、SSIM_UPDATE、SSIM_CLOSE、SSIM_OTHER、SSIM_FINALのマクロを使用して、ComputeTableColor関数で実行されます。 考えは、最高のPSNR（見つかったエンコードモード）を持つすべてのソリューションに対して、最高のSSIMを持つソリューションが選択されるということです。



ブロックコーディングモードごとに、基本色のすべての可能な組み合わせを実行する必要があります。 独立した基本色の場合、CompressBlockColor44関数は、GuessColor4関数の2つの呼び出しでストライプを独立して圧縮します。



GuessColor4関数は、偏差とベースカラーコンポーネントを反復処理します。

 for (int q = 0; q < 8; q++)   for (int c0 = 0; c0 < c0_count; c0++) // G, c0_count <= 16       for (int c1 = 0; c1 < c1_count; c1++) // R, c1_count <= 16           for (int c2 = 0; c2 < c2_count; c2++) // B, c2_count <= 16               ComputeErrorGRB(c, q);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

依存するベースカラーの場合、ストリップサイクルが二重にネストされるため、アルゴリズムの複雑さが増します。 CompressBlockColor53関数は、偏差を列挙します。

 for (int qa = 0; qa < 8; qa++)   for (int qb = 0; qb < 8; qb++)       AdjustColors53(qa, qb);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

AdjustColors53関数は、2つの基本色のコンポーネントを列挙します。

 for (int a0 = 0; a0 < a0_count; a0++) // G, a0_count <= 32   for (int a1 = 0; a1 < a1_count; a1++) // R, a1_count <= 32       for (int a2 = 0; a2 < a2_count; a2++) // B, a2_count <= 32           ComputeErrorGRB(a, qa);           for (int d0 = Ld0; d0 <= Hd0; d0++) // G, d0_count <= 8               for (int d1 = Ld1; d1 <= Hd1; d1++) // R, d1_count <= 8                   for (int d2 = Ld2; d2 <= Hd2; d2++) // B, d2_count <= 8                       b = a + d;                       ComputeErrorGRB(b, qb);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

提示された徹底的な検索は、同様のユーティリティの最高の圧縮モードよりも高速ではありませんが、これは徹底的な検索であり、さらに高速化されます。



2xETC1グラフィックスの場合、一般的な場合の完全に透明なピクセルは、ゼロアルファが乗算される任意のRGBカラーを持つことができます。









重要ではないピクセルは無視できます。そのため、最初はFilterPixelsColorの呼び出しであるコードでフィルタリングします。 一方、すべての透明ピクセルが重要というわけではありません。少なくとも1〜2ピクセルの保護フレームと境界を白くする効果を思い出してください 。



したがって、ステンシルを作成します。この場合、ゼロは重要でないピクセルを意味し、正の値は重要なピクセルを示します。 ステンシルは、OutlineAlpha関数であるコードにストローク（通常は1ピクセルまたは2ピクセルのサイズ）を適用することにより、チャネルAに基づいて作成されます。



実践が示しているように、ステンシルを使用すると、オブジェクトの圧縮された境界が改善され、目に見えないブロックがすぐに適切にパッケージ化されたジップブラックの色になります。 リストされたユーティリティを含むRGBとAの個別の圧縮と比較して、品質の顕著な向上をもたらすのはステンシルのアイデアです。









したがって、2xETC1圧縮は、EtcMainWithArgs関数に実装された次の手順で表すことができます。



1）チャネルAをETC1形式に圧縮します。

2）圧縮されたチャネルAを解凍します。

3）可視のストロークを作成します（A> 0）。ステンシルを取得します。

4）ステンシルを考慮して、RGBチャンネルをETC1形式に圧縮します。

ETC1形式への品質の圧縮を加速するためのアイデア

ユーティリティがその用途を見つけるためには、結果の品質に加えて、動作時間も重要です。 考慮された網羅的ブロック圧縮アルゴリズムは、貪欲なアルゴリズムに基づいたものを含む、作業過程における迅速な初期ヒューリスティック推定および有用なカットオフに値します。



独立したブロック形式の場合、増分圧縮は簡単に実装できます。 たとえば、前の圧縮の結果が保存されたとき。



この場合、パッカーは出力ファイルを読み取って解凍し、既存のエラーを計算しようとしています。これが最初の解決策になります。 ファイルが存在しない場合、ゼロの初期解が取得されます。 コードでは、これはLoadEtc1、CompressBlockColor、MeasureHalfColorです。



次の手順では、複雑さを増すアルゴリズムを使用して既存のソリューションの改善を試みます。 したがって、高速のCompressBlockColor44が最初に呼び出され、次に低速のCompressBlockColor53が呼び出されます。 将来のこのようなチェーン設計により、圧縮をETC2形式に統合できるようになります。



ネストされたループで列挙を開始する前に、色成分のコンテキストで解決策を見つけることは理にかなっています。 事実、最良の解決策は、各コンポーネントG、R、Bの最良の解決策の総誤差よりも小さい誤差を持つことはできません。多くの場合、結果の誤差は著しく大きくなり、ETC1アルゴリズムの非線形性と複雑さを特徴づけます。



色成分によるソリューションは、GuessStateColorおよびAdjustStateColor構造で表されます。 偏差テーブルg_tableの各値について、ハーフストリップのエラーが計算され、フィールドnode0、node1、node2に保存されます。 さらに、GuessStateColorインデックス[0x00..0x0F]は、可能なすべてのベースカラーg_colors4の計算されたエラーを格納し、インデックス[0x10]が最適なソリューションです。 AdjustStateColorの場合、最適なソリューションはインデックス[0x20]に格納され、可能なすべての基本色はg_colors5から取得されます。



カラーコンポーネントによるエラー計算は、InitLevelErrors関数によって以前に計算されたg_errors4、g_errors5テーブルに基づいて、ComputeLevel、GuessLevels、AdjustLevels関数によって実行されます。



色成分を導入するエラーの昇順で整理することは価値があります;このため、フィールドnode0、node1、node2はSortNodes10およびSortNodes20関数によってソートされます。



並べ替えを高速化するために、テーマサイトで計算された並べ替えネットワークが使用されます。



並べ替える前に、見つかったソリューションを超える大きなエラーを破棄することは理にかなっています。 これにより、フィールドnode0、node1、node2の要素数が大幅に削減され、ソートと列挙が大幅に高速化されます。



ComputeErrorGR関数を使用して現在のG、Rの最適なソリューションを見つけることにより、色成分G、R、Bの3番目のネストされたループを切断しようとすることができます。 ところで、これらはプロファイラーのホットスポットです。



依存ベースカラーモードでは、検出されたエラーが多くの場合色成分の楽観的予測を超え、同時にカットオフ基準であるため、良好な加速により各半分の最適なソリューションが検索されます。



ウォークおよびボトム機能がこれを行います。



AdjustColors53関数を64回呼び出すと、同じベースカラーパラメーターを使用してComputeErrorGR関数とComputeErrorGRB関数を繰り返し呼び出すことができるため、呼び出しの結果をキャッシュします。 次に、キャッシュを迅速に初期化するために、3番目の色コンポーネントで遅延計算を使用できます。



AdjustStateColor構造体では、LazyGRによってクリアされたErrorsG、ErrorsGRフィールド、およびErrorsGRBフィールドにより、パフォーマンスが大幅に向上します。



さまざまなアルゴリズムの改善後、SIMDを使用します。この場合、ソリューションは整数SSE4.1で公開されています。 1ピクセルのデータはint32x4_tとして保存されます。



_mm_adds_epu8および_mm_subs_epu8コマンドは、ベースカラーと偏差から4色パレットを計算するのに便利です。



関数ComputeErrorGRBおよびComputeErrorGRは、ほとんどの場合、ビット深度が十分なので、_mm_madd_epi16コマンドによって最適化された部分的に展開されたループを最初に使用します。 大きなエラーの場合、2番目のサイクルは「遅い」_mm_mullo_epi32コマンドで機能します。



ComputeLevel関数は、4つの基本色値のエラーを一度に計算します。



1つのチャンネルAを圧縮するには、結果のRGB圧縮コードを単純化できます。 ネストされたループが著しく少なくなり、パフォーマンスが向上します。

達成された結果

上記のアプローチは、ハードウェア形式ETC1の圧縮テクスチャを使用することにより、AndroidバージョンのゲームのRAM要件を削減できます。



アトラスを生成するためのスクリプトと圧縮ユーティリティ自体は、アーティファクトを防止し、圧縮されたグラフィックの品質を改善する問題に注意を払います。



驚くべきことに、圧縮されたグラフィックの品質を改善するとともに、圧縮自体を加速することができました！ Gardenscapesプロジェクトでは、Intel Core i7 6700プロセッサーでアトラスをETC1形式に圧縮するのに24秒かかります。 これは、アトラス自体を生成するよりも高速で、以前の高速圧縮ユーティリティよりも数倍高速です。 提案された増分圧縮は19秒で行われます。



結論として、Intel Core i7 6700プロセッサ上のWin64 のEtcCompressユーティリティによって提供される8192x8192 RGBテクスチャの圧縮例を示します。

 x:\>EtcCompress Usage: EtcCompress [/retina] src [dst_color] [dst_alpha] [/debug result.png] x:\>EtcCompress 8192.png 1.etc /debug 1.png Loaded 8192.png Image 8192x8192, Texture 8192x8192 Compressed 4194304 blocks, elapsed 10988 ms, 381716 bps Saved 1.etc Texture RGB wPSNR = 42.796053, wSSIM_4x2 = 0.97524678 Saved 1.png x:\>EtcCompress 8192.png 1.etc /debug 2.png Loaded 8192.png Image 8192x8192, Texture 8192x8192 Loaded 1.etc Compressed 4194304 blocks, elapsed 6487 ms, 646570 bps Saved 1.etc Texture RGB wPSNR = 42.796053, wSSIM_4x2 = 0.97524678 Saved 2.png x:\>fc /b 1.png 2.png   1.png  2.png FC:   
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このユーティリティがモバイルグラフィックスを効率的かつ迅速に圧縮するのに役立つことを願っています。