Unityのテクスチャ容量は、画像の幅・高さ、1画素あたりのビット数（bpp）、ミップマップの有無で見積もれます。PNGのファイル容量と、GPUで使うテクスチャの容量は別です。
容量の計算に加え、旧Unity向けのディザリングとPVRTC対策を紹介します。掲載画像は過去の比較です。紹介する3つのスクリプトは古いAPIを使っており、現行Unityへの導入・実機動作は確認していません。
画像素材の減色のためのディザリング処理について
容量節約のために画像素材を減色しつつ、UIの表示品質も維持したい場面があります。
容量を抑えやすいRGBA16bitを選択する場合、そのまま変換するとグラデーション部分にマッハバンドが目立つことがあります。
ディザリングは細かなノイズを加えて階調の段差を目立ちにくくする処理です。失われた階調を復元するものではなく、素材や表示倍率によっては粒状感が目立ちます。
unity-dither4444はインポート時にRGBA4444へ変換する旧スクリプトです。以下はコードの処理内容を確認するための説明で、現行環境にそのまま導入する手順ではありません。
旧スクリプトの処理と導入前の確認
- 配布元のTextureModifier.csを読み、対象Unityに合わせた移植が必要か確認する。作業用コピーで検証し、元画像とプロジェクトを退避する
- 旧TextureImporterType.GUIやtextureFormatを使うため、GUIをAdvancedへ置き換えるだけの修正では現行環境への対応にならない。使用するUnityのインポート設定APIに合わせて見直す
- 処理対象の判定は末尾がDither.pngのファイル。ただし前処理では、対象判定より前にtextureTypeを書き換えるため、対象外の画像にも影響し得る。判定の位置も修正・確認する
- 移植後に対象画像だけを再インポートし、RGBA4444の画質・容量と、対象外画像の設定が変わらないことを確認する
ダウンロード：https://github.com/keijiro/unity-dither4444
上図は過去にGIMPで処理した画像とunity-dither4444を比較したものです。この素材では後者の階調が目立ちにくくなりましたが、設定・素材の違いを含むため、常に優れるという比較ではありません。
本記事の3つの配布スクリプトは、いずれも同名のTextureModifierクラスを定義しています。同じプロジェクトへそのまま併置すると競合します。併用する場合はクラス名の整理と、各インポート処理の対象限定・処理順の検証が必要です。
PVRTCの画像をきれいに表示する方法
テクスチャ圧縮形式PVRTCを使用すると、画像の輪郭が乱れたり、アルファ抜けの境界にノイズが生じたりすることがあります。
以下はPVRTCを使っていた旧環境の対策です。まず対象端末が対応する圧縮形式と画質を比較してください。現行環境でPVRTCを一律に選ぶことを勧めるものではありません。
方法1：透明部分の最適化
unity-pvr-cleanerは、アルファが0の画素をRGB各0.5・アルファ0に置き換え、PVRTC_RGBA4へ圧縮します。背景色に自動で最適化する処理でも、PNGを書き出す処理でもありません。
- 配布元の旧コードを読み、APIの移植と対象外画像へ影響しない前処理への修正を行う
- この処理の対象判定は、ファイル名の末尾がPVR.pngかどうか
- 移植を検証した作業用プロジェクトで再インポートし、実際の画質とインポート設定を確認する
ダウンロード：https://github.com/keijiro/unity-pvr-cleaner
※画像サイズが大きいとインポート処理に時間がかかるため注意してください。
方法2：アルファマスクを使用
- 配布元の旧コードを読み、APIの移植と対象外画像へ影響しない前処理への修正を行う
- 旧コードはビルド対象によりPVRTC_RGB4、ETC_RGB4、DXT1を選ぶ。旧BuildTarget.iPhoneなどを使うため、そのまま現行Unityへ導入しない
- 末尾がwith alpha.pngの画像から、RGB画像とアルファ値をRGBに入れたマスクを作る
- 移植を検証した作業用プロジェクトで再インポートし、実際の画質とインポート設定を確認する
- 旧Custom/SpriteWithMaskシェーダーは元テクスチャと生成したマスクを参照する。使用中の描画パイプラインへの対応も確認する
- シェーダーのColor初期値はRGBA各0.5。内部で2倍するため各0.5が基準であり、255から127への変更を必須手順としない
ダウンロード：https://github.com/keijiro/unity-alphamask
配布シェーダーはマスクのR値を3乗してアルファに使います。0.5は0.125になるため、元画像の半透明をそのまま再現しません。また、4bppのRGB画像と4bppのマスクを使う場合、合計は8bpp相当です。マスク生成で追加されるアセットと、ビルド対象切替後の再インポートも管理してください。
結果
- 方法1：過去の比較画像では上部のノイズが減りました。素材によって結果が異なり、処理時間も確認が必要です。
- 方法2：過去の比較では半透明の境界が強く出ました。配布シェーダーの3乗処理がアルファを変えるため、意図するぼかしになるか確認してください。旧コードにはETC_RGB4を使う分岐もあります。
テクスチャの圧縮形式とGPU容量の目安
ミップマップなしの容量の求め方
基本レベルの容量（バイト）は幅 × 高さ × bpp ÷ 8で見積もります。bppはビット単位なので8で割ります。ブロック圧縮の最小サイズや端数の丸め、ヘッダー、CPU側コピーなどはこの式に含みません。PNG・JPEGや配布ビルドのファイル容量とは区別してください。
同じ解像度での容量比較
2の累乗の正方形を前提にした理論上の概算です。全ミップ列は基本レベルの約4/3倍で計算し、圧縮ブロックの最小サイズなどは省略しています。すべてKiB単位（1 KiB＝1,024バイト）です。
4bppの列はPVRTC 4bppやETC_RGB4などの概算に使えますが、ETC系を含めすべての形式が4bppとは限りません。最後の列はミップなしの比較であり、特定ソフトによる追加圧縮の効果を示すものではありません。
| サイズ（Pixel） | 32bpp・全ミップ（KiB） | 16bpp・全ミップ（KiB） | 4bpp・全ミップ（KiB） | 4bpp・ミップなし（KiB） |
|---|---|---|---|---|
| 2048×2048 | 21,845.3 | 10,922.7 | 2,730.7 | 2,048.0 |
| 1024×1024 | 5,461.3 | 2,730.7 | 682.7 | 512.0 |
| 512×512 | 1,365.3 | 682.7 | 170.7 | 128.0 |
| 256×256 | 341.3 | 170.7 | 42.7 | 32.0 |
| 128×128 | 85.3 | 42.7 | 10.7 | 8.0 |
| 64×64 | 21.3 | 10.7 | 2.7 | 2.0 |
Mipmapについて
Mipmapとは元テクスチャの縮小画像を段階的に保持した仕組みで、テクスチャが画面上で小さく描画される際に参照されます。
各レベルの幅と高さは、1つ前のレベルから半分（2の累乗分の1）ずつ小さくなります。
例：128×128pixelのテクスチャの場合、64×64や32×32などのテクスチャ群が順次生成されます。
常に元の大きさで表示するUIなどでは、ミップ生成を外すと容量を減らせます。一方、縮小表示されるUIや遠方のオブジェクトでは、ミップがちらつきやジャギーを抑えるため、画質を見て判断します。
圧縮率の目安
- 同じ解像度・ミップ条件で32bpp → 16bpp：容量約50%削減
- 同じ解像度・ミップ条件で16bpp → 4bpp：容量約75%削減。画質と端末の形式対応は別途確認
- 同じ形式で全ミップあり → ミップなし：概算で約25%削減。圧縮形式自体の改善による削減ではない
Unityに関する他の記事は、まとめ一覧よりご確認いただけます。
2Dとスプライトの記事は、ほかにもあります。
まとめ
Mipmap：縮小表示の有無と画質を確認して生成を判断します。Unity公式のミップマップ解説も参照してください。
ディザリング：RGBA4444への減色で階調の段差を目立ちにくくする方法です。紹介コードは移植と動作検証が必要です。
PVRTC対策：透明画素のRGB調整や別マスクは画質が改善する場合がありますが、半透明の変化や追加容量を伴います。
圧縮形式：対象端末の対応、画質、容量を比較して選びます。Unity公式のテクスチャ形式の案内から対象環境の仕様を確認してください。
よくある質問：Unityのテクスチャ画像に関するTIPS
この記事では、どんなテクスチャのTIPSを紹介していますか？
GPUで使うテクスチャの容量計算、ミップの容量差、旧Unity用ディザリング・PVRTC対策です。PNGなどの元ファイルの容量とは別に考えます。
ディザリング処理は、なぜ必要ですか？
RGBA4444などへの減色で階調の段差が目立つ場合に、ノイズで目立ちにくくする方法です。常に必要な処理ではなく、素材によって粒状感が目立つこともあります。
ディザリング処理の手順は？
紹介するunity-dither4444は旧APIを使うため、そのまま現行Unityへ配置する手順としては使えません。対象外画像の設定変更を防ぐ修正も含め、作業用コピーで移植・検証してください。末尾Dither.pngが処理対象です。
PVRTCの画像が乱れるときは、どうしますか？
対象端末で使える圧縮形式を比較したうえで、透明画素のRGB調整や別マスクを検討します。ここで紹介する旧スクリプトの現行Unity・実機での動作は未確認です。
2つの方法には、どんな違いがありますか？
方法1は完全に透明な画素のRGBを調整します。方法2は別のマスクを追加し、配布シェーダーはマスク値の3乗をアルファに使うため半透明が変わります。Colorの初期値は各0.5で、4bppの画像2枚なら合計8bpp相当です。
テクスチャのファイルサイズは、どう求めますか？
基本レベルの容量は幅 × 高さ × bpp ÷ 8バイトです。2048×2048の32bppなら16 MiB、全ミップ込みの概算は約21.33 MiBです。圧縮ブロックの最小サイズやCPU側コピーなどを含めた実際の使用量、PNGやビルドのファイル容量とは一致しない場合があります。
Mipmapとは何ですか？
元画像の幅と高さを半分ずつにした縮小画像の系列です。全系列の容量は基本レベルの約1/3が追加されます。元の大きさのUIでは不要な場合がありますが、縮小表示では画質改善に役立ちます。
圧縮率の目安を教えてください。
同じ解像度・ミップ条件なら32bppから16bppで約50%、16bppから4bppで約75%減ります。同じ形式で全ミップを外した場合の約25%削減とは区別してください。対応形式・画質は対象端末で確認が必要です。