AlphaComposite class implements basic alpha
compositing rules for combining source and destination colors
to achieve blending and transparency effects with graphics and
images.
The specific rules implemented by this class are the basic set
of 12 rules described in
T. Porter and T. Duff, "Compositing Digital Images", SIGGRAPH 84,
253-259.
The rest of this documentation assumes some familiarity with the
definitions and concepts outlined in that paper.
This class extends the standard equations defined by Porter and
Duff to include one additional factor.
An instance of the AlphaComposite class can contain
an alpha value that is used to modify the opacity or coverage of
every source pixel before it is used in the blending equations.
It is important to note that the equations defined by the Porter
and Duff paper are all defined to operate on color components
that are premultiplied by their corresponding alpha components.
Since the ColorModel and Raster classes
allow the storage of pixel data in either premultiplied or
non-premultiplied form, all input data must be normalized into
premultiplied form before applying the equations and all results
might need to be adjusted back to the form required by the destination
before the pixel values are stored.
Also note that this class defines only the equations for combining color and alpha values in a purely mathematical sense. The accurate application of its equations depends on the way the data is retrieved from its sources and stored in its destinations. See Implementation Caveats for further information.
The following factors are used in the description of the blending equation in the Porter and Duff paper:
Factor Definition As the alpha component of the source pixel Cs a color component of the source pixel in premultiplied form Ad the alpha component of the destination pixel Cd a color component of the destination pixel in premultiplied form Fs the fraction of the source pixel that contributes to the output Fd the fraction of the destination pixel that contributes to the output Ar the alpha component of the result Cr a color component of the result in premultiplied form
Using these factors, Porter and Duff define 12 ways of choosing
the blending factors Fs and Fd to
produce each of 12 desirable visual effects.
The equations for determining Fs and Fd
are given in the descriptions of the 12 static fields
that specify visual effects.
For example,
the description for
SRC_OVER
specifies that Fs = 1 and Fd = (1-As).
Once a set of equations for determining the blending factors is
known they can then be applied to each pixel to produce a result
using the following set of equations:
Fs = f(Ad) Fd = f(As) Ar = As*Fs + Ad*Fd Cr = Cs*Fs + Cd*Fd
The following factors will be used to discuss our extensions to the blending equation in the Porter and Duff paper:
Factor Definition Csr one of the raw color components of the source pixel Cdr one of the raw color components of the destination pixel Aac the "extra" alpha component from the AlphaComposite instance Asr the raw alpha component of the source pixel Adr the raw alpha component of the destination pixel Adf the final alpha component stored in the destination Cdf the final raw color component stored in the destination
The AlphaComposite class defines an additional alpha
value that is applied to the source alpha.
This value is applied as if an implicit SRC_IN rule were first
applied to the source pixel against a pixel with the indicated
alpha by multiplying both the raw source alpha and the raw
source colors by the alpha in the AlphaComposite.
This leads to the following equation for producing the alpha
used in the Porter and Duff blending equation:
As = Asr * AacAll of the raw source color components need to be multiplied by the alpha in the
AlphaComposite instance.
Additionally, if the source was not in premultiplied form
then the color components also need to be multiplied by the
source alpha.
Thus, the equation for producing the source color components
for the Porter and Duff equation depends on whether the source
pixels are premultiplied or not:
Cs = Csr * Asr * Aac (if source is not premultiplied) Cs = Csr * Aac (if source is premultiplied)No adjustment needs to be made to the destination alpha:
Ad = Adr
The destination color components need to be adjusted only if they are not in premultiplied form:
Cd = Cdr * Ad (if destination is not premultiplied) Cd = Cdr (if destination is premultiplied)
The adjusted As, Ad, Cs, and Cd are used in the standard Porter and Duff equations to calculate the blending factors Fs and Fd and then the resulting premultiplied components Ar and Cr.
The results only need to be adjusted if they are to be stored back into a destination buffer that holds data that is not premultiplied, using the following equations:
Adf = Ar Cdf = Cr (if dest is premultiplied) Cdf = Cr / Ar (if dest is not premultiplied)Note that since the division is undefined if the resulting alpha is zero, the division in that case is omitted to avoid the "divide by zero" and the color components are left as all zeros.
For performance reasons, it is preferrable that
Raster objects passed to the compose
method of a CompositeContext
object created by the
AlphaComposite class have premultiplied data.
If either the source Raster
or the destination Raster
is not premultiplied, however,
appropriate conversions are performed before and after the compositing
operation.
BufferedImage class, do not store alpha values
for their pixels. Such sources supply an alpha of 1.0 for
all of their pixels.
BufferedImage.TYPE_BYTE_INDEXED
should not be used as a destination for a blending operation
because every operation
can introduce large errors, due to
the need to choose a pixel from a limited palette to match the
results of the blending equations.
Typically the integer values are related to the floating point values in such a way that the integer 0 is equated to the floating point value 0.0 and the integer 2^n-1 (where n is the number of bits in the representation) is equated to 1.0. For 8-bit representations, this means that 0x00 represents 0.0 and 0xff represents 1.0.
(A, R, G, B) = (0x01, 0xb0, 0x00, 0x00)
If integer math were being used and this value were being
composited in
SRC
mode with no extra alpha, then the math would
indicate that the results were (in integer format):
(A, R, G, B) = (0x01, 0x01, 0x00, 0x00)
Note that the intermediate values, which are always in premultiplied form, would only allow the integer red component to be either 0x00 or 0x01. When we try to store this result back into a destination that is not premultiplied, dividing out the alpha will give us very few choices for the non-premultiplied red value. In this case an implementation that performs the math in integer space without shortcuts is likely to end up with the final pixel values of:
(A, R, G, B) = (0x01, 0xff, 0x00, 0x00)
(Note that 0x01 divided by 0x01 gives you 1.0, which is equivalent to the value 0xff in an 8-bit storage format.)
Alternately, an implementation that uses floating point math might produce more accurate results and end up returning to the original pixel value with little, if any, roundoff error. Or, an implementation using integer math might decide that since the equations boil down to a virtual NOP on the color values if performed in a floating point space, it can transfer the pixel untouched to the destination and avoid all the math entirely.
These implementations all attempt to honor the same equations, but use different tradeoffs of integer and floating point math and reduced or full equations. To account for such differences, it is probably best to expect only that the premultiplied form of the results to match between implementations and image formats. In this case both answers, expressed in premultiplied form would equate to:
(A, R, G, B) = (0x01, 0x01, 0x00, 0x00)
and thus they would all match.
AlphaComposite object that implements the opaque CLEAR rule
with an alpha of 1.0f.Fs = 0 and Fd = 0, thus:
Ar = 0 Cr = 0
AlphaComposite object that implements the opaque DST rule
with an alpha of 1.0f.Fs = 0 and Fd = 1, thus:
Ar = Ad Cr = Cd
Fs = (1-Ad) and Fd = As, thus:
Ar = As*(1-Ad) + Ad*As = As Cr = Cs*(1-Ad) + Cd*As
Fs = 0 and Fd = As, thus:
Ar = Ad*As Cr = Cd*As
Fs = 0 and Fd = (1-As), thus:
Ar = Ad*(1-As) Cr = Cd*(1-As)
Fs = (1-Ad) and Fd = 1, thus:
Ar = As*(1-Ad) + Ad Cr = Cs*(1-Ad) + Cd
AlphaComposite object that implements the opaque DST_ATOP rule
with an alpha of 1.0f.AlphaComposite object that implements the opaque DST_IN rule
with an alpha of 1.0f.AlphaComposite object that implements the opaque DST_OUT rule
with an alpha of 1.0f.AlphaComposite object that implements the opaque DST_OVER rule
with an alpha of 1.0f.AlphaComposite object that implements the opaque SRC rule
with an alpha of 1.0f.Fs = 1 and Fd = 0, thus:
Ar = As Cr = Cs
Fs = Ad and Fd = (1-As), thus:
Ar = As*Ad + Ad*(1-As) = Ad Cr = Cs*Ad + Cd*(1-As)
Fs = Ad and Fd = 0, thus:
Ar = As*Ad Cr = Cs*Ad
Fs = (1-Ad) and Fd = 0, thus:
Ar = As*(1-Ad) Cr = Cs*(1-Ad)
Fs = 1 and Fd = (1-As), thus:
Ar = As + Ad*(1-As) Cr = Cs + Cd*(1-As)
AlphaComposite object that implements the opaque SRC_ATOP rule
with an alpha of 1.0f.AlphaComposite object that implements the opaque SRC_IN rule
with an alpha of 1.0f.AlphaComposite object that implements the opaque SRC_OUT rule
with an alpha of 1.0f.AlphaComposite object that implements the opaque SRC_OVER rule
with an alpha of 1.0f.AlphaComposite object that implements the opaque XOR rule
with an alpha of 1.0f.Fs = (1-Ad) and Fd = (1-As), thus:
Ar = As*(1-Ad) + Ad*(1-As) Cr = Cs*(1-Ad) + Cd*(1-As)
Composite object.AlphaComposite.
The result is true if and only if
the argument is not null and is an
AlphaComposite object that has the same
compositing rule and alpha value as this object.
AlphaComposite. If this
AlphaComposite does not have an alpha value, 1.0 is returned.AlphaComposite object with the specified rule.AlphaComposite object with the specified rule and
the constant alpha to multiply with the alpha of the source.
The source is multiplied with the specified alpha before being composited
with the destination.AlphaComposite.wait methods.
The awakened thread will not be able to proceed until the current thread relinquishes the lock on this object. The awakened thread will compete in the usual manner with any other threads that might be actively competing to synchronize on this object; for example, the awakened thread enjoys no reliable privilege or disadvantage in being the next thread to lock this object.
This method should only be called by a thread that is the owner of this object's monitor. A thread becomes the owner of the object's monitor in one of three ways:
synchronized statement
that synchronizes on the object.
Class, by executing a
synchronized static method of that class.
Only one thread at a time can own an object's monitor.
wait methods.
The awakened threads will not be able to proceed until the current thread relinquishes the lock on this object. The awakened threads will compete in the usual manner with any other threads that might be actively competing to synchronize on this object; for example, the awakened threads enjoy no reliable privilege or disadvantage in being the next thread to lock this object.
This method should only be called by a thread that is the owner
of this object's monitor. See the notify method for a
description of the ways in which a thread can become the owner of
a monitor.
toString method returns a string that
"textually represents" this object. The result should
be a concise but informative representation that is easy for a
person to read.
It is recommended that all subclasses override this method.
The toString method for class Object
returns a string consisting of the name of the class of which the
object is an instance, the at-sign character `@', and
the unsigned hexadecimal representation of the hash code of the
object. In other words, this method returns a string equal to the
value of:
getClass().getName() + '@' + Integer.toHexString(hashCode())
The current thread must own this object's monitor. The thread
releases ownership of this monitor and waits until another thread
notifies threads waiting on this object's monitor to wake up
either through a call to the notify method or the
notifyAll method. The thread then waits until it can
re-obtain ownership of the monitor and resumes execution.
As in the one argument version, interrupts and spurious wakeups are possible, and this method should always be used in a loop:
synchronized (obj) {
while (<condition does not hold>)
obj.wait();
... // Perform action appropriate to condition
}
This method should only be called by a thread that is the owner
of this object's monitor. See the notify method for a
description of the ways in which a thread can become the owner of
a monitor.The current thread must own this object's monitor.
This method causes the current thread (call it T) to place itself in the wait set for this object and then to relinquish any and all synchronization claims on this object. Thread T becomes disabled for thread scheduling purposes and lies dormant until one of four things happens:
A thread can also wake up without being notified, interrupted, or timing out, a so-called spurious wakeup. While this will rarely occur in practice, applications must guard against it by testing for the condition that should have caused the thread to be awakened, and continuing to wait if the condition is not satisfied. In other words, waits should always occur in loops, like this one:
synchronized (obj) {
while (<condition does not hold>)
obj.wait(timeout);
... // Perform action appropriate to condition
}
(For more information on this topic, see Section 3.2.3 in Doug Lea's
"Concurrent Programming in Java (Second Edition)" (Addison-Wesley,
2000), or Item 50 in Joshua Bloch's "Effective Java Programming
Language Guide" (Addison-Wesley, 2001).
If the current thread is interrupted by another thread while it is waiting, then an InterruptedException is thrown. This exception is not thrown until the lock status of this object has been restored as described above.
Note that the wait method, as it places the current thread into the wait set for this object, unlocks only this object; any other objects on which the current thread may be synchronized remain locked while the thread waits.
This method should only be called by a thread that is the owner
of this object's monitor. See the notify method for a
description of the ways in which a thread can become the owner of
a monitor.
This method is similar to the wait method of one
argument, but it allows finer control over the amount of time to
wait for a notification before giving up. The amount of real time,
measured in nanoseconds, is given by:
1000000*timeout+nanos
In all other respects, this method does the same thing as the method of one argument. In particular, wait(0, 0) means the same thing as wait(0).
The current thread must own this object's monitor. The thread releases ownership of this monitor and waits until either of the following two conditions has occurred:
notify method
or the notifyAll method.
timeout
milliseconds plus nanos nanoseconds arguments, has
elapsed.
The thread then waits until it can re-obtain ownership of the monitor and resumes execution.
As in the one argument version, interrupts and spurious wakeups are possible, and this method should always be used in a loop:
synchronized (obj) {
while (<condition does not hold>)
obj.wait(timeout, nanos);
... // Perform action appropriate to condition
}
This method should only be called by a thread that is the owner
of this object's monitor. See the notify method for a
description of the ways in which a thread can become the owner of
a monitor.