モジュール java.desktop
パッケージ java.awt

クラスAlphaComposite

java.lang.Object
java.awt.AlphaComposite
すべての実装されたインタフェース:
Composite

public final class AlphaComposite extends Object implements Composite
AlphaCompositeクラスは、グラフィックスとイメージの混合や透明化の効果を実現するために、ソース色とデスティネーション色を組み合わせるための基本的なアルファ合成ルールを実装します。 このクラスで実装される特定のルールは、T. PorterおよびT. Duff共著の『Compositing Digital Images』(SIGGRAPH 84, 253 - 259)に記述されている一連の基本的な12の規則です。 このドキュメントでは、その著書で説明されている定義および概念について、ある程度の知識があることを前提としています。

このクラスは、PorterとDuffによって定義された標準の式を拡張し、係数を1つ追加しています。 AlphaCompositeクラスのインスタンスには、合成式で使用する前に、ソースのピクセルの透明度や範囲を変更できるアルファ値を格納できます。

PorterとDuffの著書で定義された式はすべて、対応するアルファ成分によってあらかじめ乗算された色成分を処理するように定義されています。 ColorModelクラスおよびRasterクラスでは、ピクセル・データをあらかじめ乗算された形式でも、乗算されていない形式でも保存できるため、式を適用する前に、すべての入力データをあらかじめ乗算された形式に正規化する必要があり、ピクセル値を格納する前に、すべての結果をデスティネーションによって要求された形式に調整して戻さなければならない可能性があります。

このクラスで定義するのは、純粋な数学的観念における色とアルファ値の合成の式だけです。 この式の正確な適用は、データをソースから取得し、デスティネーションに保存する方法によって異なります。 詳細は「実装の注意」を参照してください。

PorterとDuffの著書では、合成式の説明で次の係数が使われています。

ファクタ
ファクタ 定義
As ソース・ピクセルのアルファ成分
Cs あらかじめ乗算された形式でのソース・ピクセルの色成分
Ad デスティネーション・ピクセルのアルファ成分
Cd あらかじめ乗算された形式でのデスティネーション・ピクセルの色成分
Fs ソース・ピクセルのうち、出力に関係する部分
Fd デスティネーション・ピクセルのうち、出力に関係する部分
Ar 結果として得られるアルファ成分
Cr あらかじめ乗算された形式での結果の色成分

以上の係数を使用して、PorterとDuffは合成係数FsおよびFdを選択して、12種類の目的の視覚効果を生成する12とおりの方法を定義しています。 FsおよびFdを決定する式は、視覚効果を指定する12のstaticフィールドの記述で指定します。 たとえば、SRC_OVERの記述では、Fs = 1およびFd =(1-As)を指定します。 合成係数を決定する一連の式がわかったら、それらを各ピクセルに適用し、次の一連の式を使用して、結果を生成できます。

      Fs = f(Ad)
      Fd = f(As)
      Ar = As*Fs + Ad*Fd
      Cr = Cs*Fs + Cd*Fd

次の係数を使用して、PorterとDuffの著書の合成式の拡張を説明します。

ファクタ
ファクタ 定義
Csr ソース・ピクセルのraw色成分の1つ
Cdr デスティネーション・ピクセルのraw色成分の1つ
Aac AlphaCompositeインスタンスの「特殊」アルファ成分
Asr ソース・ピクセルのrawアルファ成分
Adr デスティネーション・ピクセルのrawアルファ成分
Adf デスティネーションに保存される最終アルファ成分
Cdf デスティネーションに保存される最終raw色成分

入力の準備

AlphaCompositeクラスは、ソースのアルファに適用する追加のアルファ値を定義します。 この値は、AlphaCompositeのアルファによってrawソース・アルファとrawソース色の両方を乗算して指定されたアルファを持つピクセルに対して、最初に暗黙的なSRC_INルールをソース・ピクセルに適用しているかのように適用します。 これは、PorterとDuffの合成式で使用されるアルファを生成する次のような式になります。

      As = Asr * Aac 
ソースraw色成分はすべてAlphaCompositeインスタンスのアルファで乗算する必要があります。 さらに、ソースがあらかじめ乗算された形式でない場合に、色成分をソース・アルファで乗算する必要があります。 そのためPorterとDuff式のソース色成分を生成する式は、ソース・ピクセルがあらかじめ乗算されているかどうかによって異なります。
      Cs = Csr * Asr * Aac     (if source is not premultiplied)
      Cs = Csr * Aac           (if source is premultiplied) 
デスティネーション・アルファを調整する必要はありません。
      Ad = Adr 

デスティネーションの色成分はあらかじめ乗算された形式でない場合にのみ調整する必要があります。

      Cd = Cdr * Ad    (if destination is not premultiplied)
      Cd = Cdr         (if destination is premultiplied) 

合成式の適用

調整済みのAsAdCs、およびCdを標準PorterとDuff式で使用して、合成係数FsおよびFdを計算し、次に結果のあらかじめ乗算されている成分ArおよびCrを計算します。

結果の準備

結果は、あらかじめ乗算されていないデータを格納するデスティネーション・バッファに戻す場合にのみ、次の式を使用して調整する必要があります。

      Adf = Ar
      Cdf = Cr                 (if dest is premultiplied)
      Cdf = Cr / Ar            (if dest is not premultiplied) 
結果として得られるアルファがゼロの場合の除算は定義されていないため、その場合の除算は無視して「ゼロで除算」を避け、色成分はすべてゼロのままにしておきます。

パフォーマンス上の制約

パフォーマンス上の理由のため、AlphaCompositeクラスによって作成されるCompositeContextオブジェクトのcomposeメソッドに渡すRasterオブジェクトには、あらかじめ乗算されたデータを使用することをお薦めします。 ソースRasterまたはデスティネーションRasterのどちらかがあらかじめ乗算されていない場合、合成処理の前後に適切な変換を行います。

実装の注意

  • BufferedImageクラスに挙げられた不透明イメージの一部の種類など、ソースでピクセルのアルファ値を格納していない場合が多くあります。 そうしたソースにはすべてのピクセルに1.0のアルファを指定します。
  • さらに、デスティネーションに、このクラスによって実行された合成計算の結果として得られるアルファ値を格納する場所がない場合も多くあります。 そのため、そうしたデスティネーションではこのクラスで生成される結果として得られるアルファ値が暗黙的に破棄されます。 そうしたデスティネーションでは、格納された色値をあらかじめ乗算されていないものとして扱い、色値を格納してアルファ値を破棄する前に、結果として得られるアルファ値によって結果の色値を除算する必要があります。
  • 結果の精度は、デスティネーションのピクセルの保存方法によって異なります。 2、3から十数の一連の合成処理には少なくとも、デスティネーションとして、色およびアルファ成分あたり最低8ビットの領域を提供するイメージ形式が適切です。 成分あたりの領域が8ビット未満のイメージ形式では、結果の丸め誤差が目立たない1つまたは2つの合成処理にしか使用できません。 色成分を別に格納しないイメージ形式は、すべての種類の半透明合成に適していません。 たとえば、BufferedImage.TYPE_BYTE_INDEXEDは合成処理のデスティネーションとして使用すべきではありません。限定されたパレットからピクセルを選択して、合成式の結果に合わせる必要があるため、すべての処理で大きな誤差が生じる可能性があるからです。
  • ほぼすべての形式で、ピクセルは上記の参照式で使われている浮動小数点値ではなく、離散的な整数として格納されます。 実装では、整数ピクセル値を0.0から1.0の範囲の浮動小数点値にスケーリングするか、整数の範囲ですべてを処理する少し変更した式を使用し、参照式に似た結果を生成することもできます。

    一般に、整数0は浮動小数点値0.0と同等とみなされ、整数2^n-1 (nは表現のビット数)は1.0と同等とみなされるように、整数値が浮動小数点値と関連付けられます。 8ビット表現では、0x00は0.0を表し、0xffは1.0を表します。

  • 内部実装では一部の式を概算することも、一部のステップを省略して不要な処理を避けることもできます。 たとえば、成分あたり8ビットの領域を使用するあらかじめ乗算されていないアルファ値を持つ離散整数イメージがあるとします。 ほぼ透明な濃い赤の格納される値は次のようになります。
        (A, R, G, B) = (0x01, 0xb0, 0x00, 0x00)

    整数値演算を使用し、この値がSRCモードで、特殊アルファを使用せずに結合されている場合、数値演算の結果は(整数形式で)次のようになります。

        (A, R, G, B) = (0x01, 0x01, 0x00, 0x00)

    中間値は常にあらかじめ乗算された形式であり、整数値の赤の成分は0x00または0x01のどちらかのみになります。 この結果をあらかじめ乗算されていないデスティネーションに戻そうとする場合、アルファを除算すると、あらかじめ乗算されていない赤の値の選択肢はほとんどありません。 この場合、ショートカットなしで、整数スペースで数値演算を実行する実装の最終的なピクセル値は次のようになります。

        (A, R, G, B) = (0x01, 0xff, 0x00, 0x00)

    (0x01を0x01で除算すると1.0になり、これは8ビット格納形式での値0xffに等しくなります。)

    あるいは、浮動小数点演算を使用する実装では、より正確な結果が生成され、元のピクセル値に戻り、ラウンド・オフ・エラーはほとんど発生しません。 あるいは、整数値演算を使用する実装では、浮動小数点スペースで実行した場合に、式は色値の仮想NOPになるため、無修正のピクセルをデスティネーションに転送でき、すべての数値演算を避けることができます。

    これらの実装はすべて同じ式に従おうとしますが、整数と小数点数値演算、および短縮した式と完全な式のさまざまなトレードオフが必要です。 そうした違いを相殺するため、あらかじめ乗算された結果の形式が実装とイメージ形式で一致していることのみを期待することがもっとも望ましいと考えられます。 この場合、あらかじめ乗算された形式で表された両方の答えが次に等しくなります。

        (A, R, G, B) = (0x01, 0x01, 0x00, 0x00)

    したがって、それらはすべて一致します。

  • 式を単純化する技法によって計算の効率を上げるため、実装によっては、あらかじめ乗算されていないデスティネーションで、0.0の結果アルファ値が発見された場合に、実行方法を変更することがあります。 SRCルールでは、アルファによる除算を取り除くという単純化は、分母(アルファ)が0の場合に有効ではありません。 しかし、結果はあらかじめ乗算されている形式で見た場合にのみ正確であることを期待すべきであるため、結果として得られるアルファが0の場合は必然的に結果の色成分は関係なく、この場合の正確な動作は期待できません。
関連項目: