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や配布ビルドのファイル容量とは区別してください。
2048×2048の32bppなら、2048 × 2048 × 32 ÷ 8＝16,777,216バイト、つまり16 MiBです。
全ミップ込みでは約4/3倍となり、概算で約21.33 MiBになります（1 MiB＝1,048,576バイト）。
計算値と実際のメモリ使用量が違うとき
容量を比較するときは、元画像ではなく、対象プラットフォーム向けにインポートした後の幅・高さ・形式を使います。
- Projectウィンドウで画像を選び、Texture Import Settingsの対象プラットフォームのタブを確認します。Max Sizeで縮小されていないか、Formatがどの形式になっているかを調べます。
- ミップ生成の有無をそろえて比較します。容量表の全ミップ値は全レベルを保持する概算で、実行時に読み込む量とは区別します。
- Read/Write Enabledを確認します。有効な場合はCPUから画素を扱うためのコピーが追加されます。GetPixelsなどを使う処理がないか確認してから、無効化できるか判断します。
- 対象端末がその圧縮形式に対応するか確認します。非対応の場合は展開後のデータもメモリに保持され、指定したbppだけでは使用量を説明できません。
Crunchは配布時の容量を抑える追加圧縮です。
読み込み時にDXTまたはETCへ戻すため、同じGPU形式なら、Crunchだけで実行時のテクスチャメモリが減るわけではありません。
設定の根拠はUnity 6.3 LTSのプラットフォーム別設定、Texture.isReadable、圧縮形式とCrunchの解説です。
この設定説明は2026年10月26日に公式資料へ照合しましたが、現行Unityでの画面操作や実機のメモリ計測は行っていません。
同じ解像度での容量比較
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公式のテクスチャ形式の案内から対象環境の仕様を確認してください。