Androidテクスチャ圧縮：形式の比較とコード例

最高のテクスチャ圧縮形式は何ですか？ たぶん、PNG、ETC、PVRTC、S3TC、または他の何かでしょうか？ 質問は単純ではありませんが、非常に重要です。 ビジュアルデザインの品質、Androidアプリケーションの速度とサイズは、答えに依存します。 問題は、普遍的な「最良の形式」が単に存在しないという事実によって複雑になります。 それはすべて、開発者のニーズに依存します。







テクスチャを2次元または3次元モデルに適用する技術は、コンピューターグラフィックスで広く使用されています。 これは、モデルによって表されるオブジェクトの詳細を改善するために行われます。 Androidは多くのテクスチャ圧縮形式をサポートしており、それぞれに長所と短所があります。

テクスチャとそのストレージ形式の操作に関する予備情報

テクスチャマッピングは、画像をシェイプまたはポリゴンの表面に「貼り付ける」方法です。 わかりやすくするために、図を箱と比較し、その中に何かを入れて誰かに渡すために、この箱を包む模様付きの包装紙でテクスチャを比較します。 したがって、英語の文献では、テクスチャマッピングはテクスチャラッピングとも呼ばれ、テクスチャラッピングとして翻訳できます。





最初のタンクはポリゴンモデルで、2番目のタンクはテクスチャがスーパーインポーズされる同じモデルです。



MIPカード（Mipmaps）は、メインテクスチャ用に生成される画像の最適化されたグループです。 通常、画像のレンダリング速度を上げ、画像を滑らかにする（アンチエイリアシング）ため、つまり「ステップ」ラインの効果を取り除くために作成されます。 マップの各レベル（実際には「mip」と呼ばれます-これはラスターイメージの1つであり、MIPカードに含まれるテクスチャのセットで構成されます）-これは低解像度の元のテクスチャのバージョンです。



このような画像は、テクスチャオブジェクトが遠くから見える場合や、サイズが縮小されている場合に使用されます。 MIPカードを使用するというアイデアは、私たちから遠く離れているか、寸法が小さいオブジェクトの細部を単に区別できないという事実に基づいています。 この考えに基づいて、マップのさまざまなフラグメントを使用して、オブジェクトのサイズに基づいてテクスチャのさまざまな部分を表すことができます。 これにより、メインテクスチャの小さいバージョンのテクセル（テクスチャピクセル）が大幅に少なくなるため、つまりGPUがより少ないデータを処理してテクスチャモデルを出力するため、レンダリング速度が向上します。 さらに、MIPカードは通常アンチエイリアス処理されるため、顕著なアーティファクトの数は大幅に削減されます。 ここでは、PNG、ETC（KTX）、ETC2（KTX）、PVRTC、およびS3TCの形式のMIPカードについて説明します。









MIPカード

ポータブルネットワークグラフィックス（PNG）

PNGは、情報を失うことなくグラフィックデータを圧縮するアルゴリズムを使用しているという点で特に注目に値するラスターイメージストレージ形式です。 カラーインデックス付き画像（24ビットRGBまたは32ビットRGBA）、フルカラー画像、グレースケール画像、およびアルファチャネルをサポートしています。

メリット

• この形式ではグラフィックデータの可逆圧縮が使用されるため、PNG画像は非常に高品質です。
• 8ビットと16ビットの両方の透過性をサポートします。

欠点

• ファイルが大きい。 これにより、アプリケーションのサイズとメモリ消費が増加します。
• コンピューティングリソースに対する比較的高い需要（パフォーマンスの低下につながります）。

エリクソンテクスチャ圧縮（ETC）

エリクソンテクスチャ圧縮は、4x4ピクセルブロックで動作するテクスチャ圧縮形式です。 Khronosはもともと、Open GL ES 2.0の標準形式としてETCを使用していました。 （このバージョンはETC1とも呼ばれます）。 その結果、この形式はほぼすべてのAndroidデバイスで使用できます。 OpenGL ES 3.0のリリース。 新しい標準として、ETC2形式（ETC1の改訂版）が使用されます。 2つの標準の主な違いは、ピクセルグループで動作するアルゴリズムです。 アルゴリズムの改善により、小さな画像の詳細の出力の精度が向上しました。 その結果、画質は改善されましたが、ファイルサイズは改善されていません。



ETC1およびETC2は24ビットRGBデータの圧縮をサポートしていますが、アルファチャネルを使用した画像の圧縮はサポートしていません。 さらに、ETCアルゴリズムに関連する2つの異なるファイル形式があります。これらはKTXとPKMです。



KTXは標準的なKhronos Groupファイル形式であり、多くの画像を保存できるコンテナを提供します。 KTXを使用してMIPカードを作成すると、単一のKTXファイルが生成されます。 PKMファイルの形式ははるかに単純で、そのようなファイルは主に個々の画像を保存するために使用されます。 その結果、MIPカードの作成中にPKMを使用すると、単一のKTXではなく複数のPKMファイルが作成されます。 したがって、PKM形式はMIPカードの保存には推奨されません。

メリット

• ETCファイルのサイズは、PNGファイルのサイズよりも著しく小さくなっています。
• この形式は、ほぼすべてのAndroidデバイスでハードウェアアクセラレーションをサポートしています。

欠点

• 品質はPNGほど高くありません（ETCは情報の損失を伴う画像圧縮形式です）。
• 透明度のサポートはありません。

ETCで画像を圧縮するには、 Mali GPUテクスチャ圧縮ツールとETC-Packツールを使用できます。

PowerVRテクスチャ圧縮（PVRTC）

PowerVRテクスチャ圧縮は、主にイマジネーションテクノロジーのPowerVR MBX、SGX、および不正デバイスで使用される損失の多いグラフィックデータ用の固定レベルの圧縮形式です。 iPhone、iPod、iPadで標準の画像圧縮方法として使用されます。



ETCやS3TCとは異なり、PVRTCアルゴリズムはピクセルの固定ブロックでは機能しません。 バイリニア拡大と、2つの低解像度画像の低精度ブレンドを使用します。 独自の圧縮プロセスに加えて、PVRTCは、2-bppオプション（ピクセルあたり2ビット）と4-bppオプション（ピクセルあたり4ビット）の両方に対して、RGBA形式（透明度あり）をサポートしています。

メリット

• アルファチャネルのサポート。
• RGBAは、オプション2-bpp（ピクセルあたり2ビット）およびオプション4-bpp（ピクセルあたり4ビット）をサポートします。
• ファイルサイズはPNGよりもはるかに小さいです。
• GPU PoverVRでのハードウェアアクセラレーションのサポート。

欠点

• 品質は、PNGを使用した場合ほど高くありません（PVRTCは非可逆画像圧縮形式です）。
• PVRTCはPoverVRハードウェアでのみサポートされます。
• 正方形のPOTテクスチャ、つまり幅と高さが2のべき乗であるテクスチャがサポートされますが、場合によっては長方形のテクスチャがサポートされます。

• テクスチャをこの形式に圧縮すると、時間がかかる場合があります。

圧縮には、 PVRTexToolを使用できます。

S3テクスチャ圧縮（S3TC）またはDirectXテクスチャ圧縮（DXTC）

S3テクスチャ圧縮は、圧縮レベルが固定された非可逆グラフィックデータ圧縮形式です。 その機能により、この形式は、グラフィックアクセラレータを使用するように設計された3Dアプリケーションで使用されるテクスチャの圧縮に最適です。 S3TCとMicrosoft DirectX 6.0およびOpenGL 1.3の統合は、その普及に貢献しました。 少なくとも5つの異なるS3TC形式オプション（DXT1からDXT5まで）があります。 サンプルアプリケーションは、最も一般的に使用されるオプション（DXT1、DXT3、およびDXT5）をサポートしています。



DXT1は最も強力な圧縮を提供します。 各入力16ピクセルブロックは、2つの16ビットRGB 5：6：5カラー値と2ビット4x4ルックアップテーブルで構成される64ビットブロックに変換されます。 透明度のサポートは1色に制限されています（1ビット透明度）。



DXT3は、16ピクセルの各ブロックを128ビット、アルファチャネルデータごとに64ビット、色情報ごとに64ビットに変換します。 DXT3は、透明な領域と不透明な領域の間の急激な移行を伴う画像またはテクスチャに非常に適しています。 ただし、透明度のグラデーションがなく、画像に透明な領域がある場合は、DXT1の使用を検討する価値があります。



DXT5は、DXT3と同様に、16ピクセルの各ブロックを128ビット、アルファチャネルデータごとに64ビット、色情報ごとに64ビットに変換します。 ただし、DXT3とは異なり、DXT5は、透明領域と不透明領域の間のスムーズな移行を伴う画像またはテクスチャに適しています。

メリット

• ファイルサイズは、同様のPNGファイルよりもはるかに小さくなります。
• 質の良い、色の賦課に関連する帯状のアーティファクトの割合が低い。
• 優れたコーディングおよびデコード速度。
• 複数のGPUでのハードウェアアクセラレーション。 デスクトップシステムでは、ほぼすべてのソリューションでサポートされており、Androidプラットフォームで徐々に配布されています。

欠点

• 品質はPNGの品質よりも低くなります（S3TCは情報の損失を伴う画像圧縮形式です）。
• すべてのAndroidデバイスでサポートされているわけではありません。

この形式で作業するには、 DirectXのDirectX Texture Tool （DX SDKに含まれています）を使用できます。

テクスチャデータにアクセスする

圧縮テクスチャを保存するためのほとんどのファイル形式には、画像データの前にヘッダーが含まれています。 通常、ヘッダーには、テクスチャ圧縮形式の名前、テクスチャの幅と高さ、その色深度、データサイズ、内部形式、およびファイルに関するその他の情報に関する情報が含まれています。



私たちの目標は、さまざまなファイルからテクスチャデータをロードし、それらを2次元モデルにオーバーレイして、画質とデータサイズを比較することです。 グラフィックデータの前にあるヘッダーは、テクスチャの一部として処理されるべきではありません。これを画像の断片と見なし、モデルに重ね合わせると、歪みが発生します。 さまざまなテクスチャ圧縮形式のファイルヘッダーは異なるため、各形式には個別のサポートが必要です。そうでない場合、テクスチャの読み込みと適用が正しく機能しません。

注意してください

PVRTCヘッダーは、64ビットピクセル形式（この例ではmPixelFormat）のデータメンバーの存在を考慮してパックされます。 ARM用にコンパイルされたコードでは、ヘッダーは4バイトが追加されて整列されます。その結果、元の52バイトから56バイトになります。 これは、ARMデバイスで表示されるときにイメージが歪むという事実につながります。 Intelプロセッサ用にコンパイルされたコードでは、これは起こりません。 ヘッダーパッケージは、ARMデバイスのアライメントの問題を解決するため、ARMデバイスとIntelデバイスの両方でテクスチャが正しく表示されます。





タイトルの配置によって生じるARMデバイス上の画像の歪みは次のようになります。

サンプルアプリケーションについて

以下にフラグメントを示すAndroid Texture Compressionの例により、誰もが5つの形式のテクスチャの品質をすばやく比較できます。 つまり、ポータブルネットワークグラフィックス（PNG）、エリクソンテクスチャ圧縮（ETC）、エリクソンテクスチャ圧縮2（ETC2）、PowerVRテクスチャ圧縮（PVRTC）、およびDirectXテクスチャ圧縮（DXTC）と呼ばれることもあるS3テクスチャ圧縮（S3TC）です。 。



この例は、AndroidのOpenGL ESを使用してこれらの形式のテクスチャをロードおよび使用する方法を示しています。 異なる形式で保存された画像は隣り合って配置されるため、サイズと品質を比較できます。 特定のプロジェクトの圧縮テクスチャを保存するのに最適な形式を選択すると、開発者はアプリケーションのサイズ、視覚的な画質、パフォーマンスの適切なバランスを見つけることができます。



この例では、各形式のファイルに保存されている画像が読み込まれ、モデル上のオーバーレイの座標が決定され、各テクスチャのフラグメントが表示されます。 結果は、対応する形式の4つのテクスチャに分割された単一の画像です。 フォーマットは画面上部に表示され、ファイルサイズは以下に表示されます。



ここで説明する例は、William Guoが作成したコードに基づいています。 Intel Graphics SpecialistのChristiano Ferreiraが、テクスチャ圧縮ETC2の使用例を補足しました。 ここからコードをダウンロードできます。





テクスチャ圧縮形式：サイズと品質

PNGダウンロード

この目的のために特別に作成されたKhronos OpenGLの単純なglGenerateMipmap関数を使用して、PNG MIPカードを操作できます。 Sean Barretが準備したコード、stb_image.c（一般公開されています）を使用して、PNGファイルを読み取り、ダウンロードしました。 このコードは、処理する必要があるテクスチャの一部を見つけて選択するためにも使用されます。

//      glTexImage2D( GL_TEXTURE_2D, 0, format, width, height, 0, format, GL_UNSIGNED_BYTE, pData );    //  MIP-    glGenerateMipmap( GL_TEXTURE_2D );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ETC / ETC2をダウンロード

前述のように、ETCテクスチャはKTXおよびPKMファイルに保存できます。 KTXは、複数の画像のコンテナとして使用される標準の圧縮形​​式であり、MIPカードの作成に最適です。 同様に、PKMは個々の圧縮画像を保存するために作成されたため、それに基づいてMIPカードを作成するには、多くのファイルを生成する必要があり、非効率的です。 この例でのETCのMIPカードのサポートは、KTX形式に制限されています。



Khronosは、KTXファイルからのMIPカードの読み込みをサポートする、Cで記述されたオープンソースライブラリ（libktx）を提供します。 このライブラリを使用し、テクスチャのロードを担当するLoadTextureETC_KTX関数にコードを実装しました。 KTXファイルを直接ダウンロードする機能は、ktxLoadTextureMと呼ばれます。 メモリ内のデータから目的のテクスチャをロードできます。 この関数はlibktxライブラリの一部であり、そのドキュメントはKhronos Webサイトにあります。



以下は、テクスチャを初期化し、ETC（KTX）形式のMIPカードサポートを提供するコードスニペットです。

 //   (handle)      GLuint handle = 0;   GLenum target;   GLboolean mipmapped;       KTX_error_code result = ktxLoadTextureM( pData, fileSize, &handle, &target, NULL, &mipmapped, NULL, NULL, NULL );   if( result != KTX_SUCCESS )   {       LOGI( "KTXLib couldn't load texture %s. Error: %d", TextureFileName, result );       return 0;   }   //     glBindTexture( target, handle );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVRTCをダウンロード

PVRTCテクスチャのMIPカードサポートは、もう少し複雑なタスクです。 ヘッダーを読み取った後、ヘッダーサイズとメタデータの合計に等しいオフセットが決定されます。 タイトルの後にメタデータがあり、それらは画像の一部ではありません。 生成されたマップレベルごとに、ピクセルはブロックにグループ化されます（違いは、エンコードがピクセルあたり4ビットか2ビットかによって異なります。両方ともPVRTCに適しています）。 次に、境界の検索が行われ、ブロックの幅と高さが固定されます。 次に、関数glCompressedTexImage（）が呼び出され、圧縮されたPVRTC形式の2次元画像を識別します。 次に、ピクセルデータのサイズが計算され、マップの次のフラグメントのピクセルのセットをグループ化するために、以前に見つかったオフセットに何が起こったのかが追加されます。 このプロセスは、マップを構成するすべてのテクスチャが処理されるまで繰り返されます。

 //     unsigned int offset = sizeof(PVRHeaderV3) + pHeader->mMetaDataSize;   unsigned int mipWidth = pHeader->mWidth;   unsigned int mipHeight = pHeader->mHeight;   unsigned int mip = 0;   do   {       //   ( *  * bbp/8),    32       unsigned int pixelDataSize = ( mipWidth * mipHeight * bitsPerPixel ) >> 3;       pixelDataSize = (pixelDataSize < 32) ? 32 : pixelDataSize;       //             glCompressedTexImage2D(GL_TEXTURE_2D, mip, format, mipWidth, mipHeight, 0, pixelDataSize, pData + offset);       checkGlError("glCompressedTexImage2D");       //        ,  – 1       mipWidth  = ( mipWidth >> 1 == 0 ) ? 1 : mipWidth >> 1;       mipHeight = ( mipHeight >> 1 == 0 ) ? 1 : mipHeight >> 1;       //           offset += pixelDataSize;       mip++;   } while(mip < pHeader->mMipmapCount);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ダウンロードS3TC

S3TCテクスチャを保存するファイルをダウンロードした後、そのフォーマットが決定され、ヘッダーの後ろにあるMIPカードが読み取られます。 マップフラグメントはバイパスされ、ピクセルはブロックにグループ化されます。 次に、圧縮データ内の2次元画像を識別するために、glCompressedTexImage（）関数が呼び出されます。 次に、ブロックの合計サイズがオフセットに追加されるため、マップの次のフラグメントの先頭を見つけて同じアクションを実行できます。 これは、すべてのマップレベルが処理されるまで繰り返されます。 以下は、テクスチャを初期化し、S3TC形式のMIPカードのサポートを提供するコードスニペットです。

 //     //      unsigned int offset = 0;   unsigned int width = pHeader->mWidth;   unsigned int height = pHeader->mHeight;   unsigned int mip = 0;   do   {       //         //   : size = ceil(<w>/4) * ceil(<h>/4) * blockSize       unsigned int Size = ((width + 3) >> 2) * ((height + 3) >> 2) * blockSize;        glCompressedTexImage2D( GL_TEXTURE_2D, mip, format, width, height, 0, Size, (pData + sizeof(DDSHeader)) + offset );       checkGlError( "glCompressedTexImage2D" );       offset += Size;       if( ( width <<= 1 ) == 0) width = 1;       if( ( height <<= 1 ) == 0) height = 1;       mip++;   } while( mip < pHeader->mMipMapCount );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

結論

特定の状況に応じて、圧縮テクスチャの保存に最適な形式を選択すると、画像の外観が改善され、アプリケーションのサイズが大幅に削減され、パフォーマンスが大幅に改善されます。 最適なテクスチャ圧縮方法を慎重に選択することにより、開発者とそのアプリケーションに深刻な競争上の優位性を与えることができます。 Android Texture Compressionサンプルアプリケーションは、Android環境で最も一般的な形式のテクスチャを操作する方法を示しています。 コードをダウンロードし、プロジェクトに最適なテクスチャ圧縮形式のサポートを追加します。