乗算済みアルファ、はい、またはいいえ？

乗算済みアルファを使用する必要がありますか？トム・フォーサイスの記事を読むと、それは非常に簡単です。プリマルチプライ済みアルファ（AKA加法ブレンディング）はあらゆる意味で優れています。
ただし、あらかじめ乗算されたアルファには1つの大きな欠点があるようです。ツールでは十分にサポートされていません。

乗算済みアルファを使用しましたか？

ツールのサポートはどうですか？

特に、gimpがあらかじめ乗算されたアルファ画像をうまく編集できるとは思いません。乗算済みアルファをエクスポートするためのgimpプラグインはありますか？外部ツールはどうですか？

現時点では、XNA 3.1と事前乗算アルファを使用しています（ネイティブの事前乗算アルファサポートは4.0で追加されました）。

ほとんどの場合、時間を節約し、画像の透明な領域が正しい色になるようにすることができます。Silverlightにも移植します。これは、デフォルトで事前乗算を行います。

XNAには、事前にマルチアルファ処理を追加することが非常に簡単になるコンテンツパイプラインがあります。

そのリンクには、変換を行うためのコードが含まれています。すべてのピクセルについて：

c.R = (byte)(c.R * c.A / 255);
c.G = (byte)(c.G * c.A / 255);
c.B = (byte)(c.B * c.A / 255);

コンテンツパイプラインを使用することについては、言うべきことがたくさんあります。XNAを使用していないがVisual Studioを使用している場合は、自分で1つにまとめることができます。他のIDE /ビルドプロセスも可能でなければなりません。

そして最後に、ビルドにコンテンツ処理ステップがない場合（そして、とにかくコンテンツが多くない場合は）、実行時にテクスチャをロードするときと同じくらい簡単に事前乗算を実行できます。テクスチャの読み込み時間に一定の要素が追加されます。

（意味が明確でない場合：事前に乗算されたアルファ画像を編集するべきではありません。可能であれば事前に乗算された画像をエクスポートするか、より良い前処理を行ってください。）

たまたまXNAを使用している場合は、事前に乗算されたアルファがかなりサポートされています。通常、変換はコンテンツパイプラインで行われますが、自分で行うことを妨げるものは何もありません。

エンジンでデフォルトで事前乗算されたアルファを使用します（アーティストは、何らかの特殊効果が必要な場合、マテリアル定義ファイルで事前乗算されないように強制できます）

お気づきのように、ツールは事前に乗算されたアルファをうまく処理しません。アーティストは、カラーチャネルとアルファチャネルを完全に独立して設定できます。アーティストがプレマル以外のアルファを使用してテクスチャイメージを作成できるように設定しました（これはアーティストの頭脳ではより簡単に思われます）。エンジンのテクスチャフォーマットに変換するツールは、デフォルトでアルファを乗算します。スイッチがあるので、絶対に必要な場合は、事前乗算されていないものを生成できます。