Examples of AlphaComposite

ae.java.awt.AlphaComposite

The 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
A_s the alpha component of the source pixel
C_s a color component of the source pixel in premultiplied form
A_d the alpha component of the destination pixel
C_d a color component of the destination pixel in premultiplied form
F_s the fraction of the source pixel that contributes to the output
F_d the fraction of the destination pixel that contributes to the output
A_r the alpha component of the result
C_r a color component of the result in premultiplied form

Factor	Definition
A_s	the alpha component of the source pixel
C_s	a color component of the source pixel in premultiplied form
A_d	the alpha component of the destination pixel
C_d	a color component of the destination pixel in premultiplied form
F_s	the fraction of the source pixel that contributes to the output
F_d	the fraction of the destination pixel that contributes to the output
A_r	the alpha component of the result
C_r	a color component of the result in premultiplied form

Using these factors, Porter and Duff define 12 ways of choosing the blending factors F_s and F_d to produce each of 12 desirable visual effects. The equations for determining F_s and F_d are given in the descriptions of the 12 static fields that specify visual effects. For example, the description for SRC_OVER specifies that F_s = 1 and F_d = (1-A_s). 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:

 F_s = f(A_d) F_d = f(A_s) A_r = A_s*F_s + A_d*F_d C_r = C_s*F_s + C_d*F_d

The following factors will be used to discuss our extensions to the blending equation in the Porter and Duff paper:

Factor Definition
C_sr one of the raw color components of the source pixel
C_dr one of the raw color components of the destination pixel
A_ac the "extra" alpha component from the AlphaComposite instance
A_sr the raw alpha component of the source pixel
A_dr the raw alpha component of the destination pixel
A_df the final alpha component stored in the destination
C_df the final raw color component stored in the destination

Factor	Definition
C_sr	one of the raw color components of the source pixel
C_dr	one of the raw color components of the destination pixel
A_ac	the "extra" alpha component from the AlphaComposite instance
A_sr	the raw alpha component of the source pixel
A_dr	the raw alpha component of the destination pixel
A_df	the final alpha component stored in the destination
C_df	the final raw color component stored in the destination

Preparing Inputs

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:

 A_s = A_sr * A_ac

All 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:

 C_s = C_sr * A_sr * A_ac     (if source is not premultiplied) C_s = C_sr * A_ac           (if source is premultiplied)

No adjustment needs to be made to the destination alpha:

 A_d = A_dr

The destination color components need to be adjusted only if they are not in premultiplied form:

 C_d = C_dr * A_d    (if destination is not premultiplied) C_d = C_dr         (if destination is premultiplied)

Applying the Blending Equation

The adjusted A_s, A_d, C_s, and C_d are used in the standard Porter and Duff equations to calculate the blending factors F_s and F_d and then the resulting premultiplied components A_r and C_r.

Preparing Results

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:

 A_df = A_r C_df = C_r                 (if dest is premultiplied) C_df = C_r / A_r            (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.

Performance Considerations

For performance reasons, it is preferrable that Raster objects passed to the compose method of a {@link CompositeContext} object created by theAlphaComposite 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.

Implementation Caveats

Many sources, such as some of the opaque image types listed in the BufferedImage class, do not store alpha values for their pixels. Such sources supply an alpha of 1.0 for all of their pixels.
Many destinations also have no place to store the alpha values that result from the blending calculations performed by this class. Such destinations thus implicitly discard the resulting alpha values that this class produces. It is recommended that such destinations should treat their stored color values as non-premultiplied and divide the resulting color values by the resulting alpha value before storing the color values and discarding the alpha value.
The accuracy of the results depends on the manner in which pixels are stored in the destination. An image format that provides at least 8 bits of storage per color and alpha component is at least adequate for use as a destination for a sequence of a few to a dozen compositing operations. An image format with fewer than 8 bits of storage per component is of limited use for just one or two compositing operations before the rounding errors dominate the results. An image format that does not separately store color components is not a good candidate for any type of translucent blending. For example, 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.
Nearly all formats store pixels as discrete integers rather than the floating point values used in the reference equations above. The implementation can either scale the integer pixel values into floating point values in the range 0.0 to 1.0 or use slightly modified versions of the equations that operate entirely in the integer domain and yet produce analogous results to the reference 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.
The internal implementation can approximate some of the equations and it can also eliminate some steps to avoid unnecessary operations. For example, consider a discrete integer image with non-premultiplied alpha values that uses 8 bits per component for storage. The stored values for a nearly transparent darkened red might be:
```
 (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.
Because of the technique of simplifying the equations for calculation efficiency, some implementations might perform differently when encountering result alpha values of 0.0 on a non-premultiplied destination. Note that the simplification of removing the divide by alpha in the case of the SRC rule is technically not valid if the denominator (alpha) is 0. But, since the results should only be expected to be accurate when viewed in premultiplied form, a resulting alpha of 0 essentially renders the resulting color components irrelevant and so exact behavior in this case should not be expected.

@see Composite @see CompositeContext

com.google.code.appengine.awt.AlphaComposite
com.jgraph.gaeawt.java.awt.AlphaComposite

java.awt.AlphaComposite

The following factors are used in the description of the blending equation in the Porter and Duff paper:

Factor Definition
A_s the alpha component of the source pixel
C_s a color component of the source pixel in premultiplied form
A_d the alpha component of the destination pixel
C_d a color component of the destination pixel in premultiplied form
F_s the fraction of the source pixel that contributes to the output
F_d the fraction of the destination pixel that contributes to the output
A_r the alpha component of the result
C_r a color component of the result in premultiplied form

Factor	Definition
A_s	the alpha component of the source pixel
C_s	a color component of the source pixel in premultiplied form
A_d	the alpha component of the destination pixel
C_d	a color component of the destination pixel in premultiplied form
F_s	the fraction of the source pixel that contributes to the output
F_d	the fraction of the destination pixel that contributes to the output
A_r	the alpha component of the result
C_r	a color component of the result in premultiplied form

 F_s = f(A_d) F_d = f(A_s) A_r = A_s*F_s + A_d*F_d C_r = C_s*F_s + C_d*F_d

The following factors will be used to discuss our extensions to the blending equation in the Porter and Duff paper:

Factor Definition
C_sr one of the raw color components of the source pixel
C_dr one of the raw color components of the destination pixel
A_ac the "extra" alpha component from the AlphaComposite instance
A_sr the raw alpha component of the source pixel
A_dr the raw alpha component of the destination pixel
A_df the final alpha component stored in the destination
C_df the final raw color component stored in the destination

Factor	Definition
C_sr	one of the raw color components of the source pixel
C_dr	one of the raw color components of the destination pixel
A_ac	the "extra" alpha component from the AlphaComposite instance
A_sr	the raw alpha component of the source pixel
A_dr	the raw alpha component of the destination pixel
A_df	the final alpha component stored in the destination
C_df	the final raw color component stored in the destination

Preparing Inputs

 A_s = A_sr * A_ac

 C_s = C_sr * A_sr * A_ac     (if source is not premultiplied) C_s = C_sr * A_ac           (if source is premultiplied)

No adjustment needs to be made to the destination alpha:

 A_d = A_dr

The destination color components need to be adjusted only if they are not in premultiplied form:

 C_d = C_dr * A_d    (if destination is not premultiplied)  C_d = C_dr         (if destination is premultiplied)

Applying the Blending Equation

Preparing Results

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:

 A_df = A_r C_df = C_r                 (if dest is premultiplied) C_df = C_r / A_r            (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.

Performance Considerations

For performance reasons, it is preferrable that Raster objects passed to the compose method of a {@link 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.

Implementation Caveats

Many sources, such as some of the opaque image types listed in the BufferedImage class, do not store alpha values for their pixels. Such sources supply an alpha of 1.0 for all of their pixels.
Many destinations also have no place to store the alpha values that result from the blending calculations performed by this class. Such destinations thus implicitly discard the resulting alpha values that this class produces. It is recommended that such destinations should treat their stored color values as non-premultiplied and divide the resulting color values by the resulting alpha value before storing the color values and discarding the alpha value.
The accuracy of the results depends on the manner in which pixels are stored in the destination. An image format that provides at least 8 bits of storage per color and alpha component is at least adequate for use as a destination for a sequence of a few to a dozen compositing operations. An image format with fewer than 8 bits of storage per component is of limited use for just one or two compositing operations before the rounding errors dominate the results. An image format that does not separately store color components is not a good candidate for any type of translucent blending. For example, 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.
Nearly all formats store pixels as discrete integers rather than the floating point values used in the reference equations above. The implementation can either scale the integer pixel values into floating point values in the range 0.0 to 1.0 or use slightly modified versions of the equations that operate entirely in the integer domain and yet produce analogous results to the reference 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.
The internal implementation can approximate some of the equations and it can also eliminate some steps to avoid unnecessary operations. For example, consider a discrete integer image with non-premultiplied alpha values that uses 8 bits per component for storage. The stored values for a nearly transparent darkened red might be:
```
 (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.
Because of the technique of simplifying the equations for calculation efficiency, some implementations might perform differently when encountering result alpha values of 0.0 on a non-premultiplied destination. Note that the simplification of removing the divide by alpha in the case of the SRC rule is technically not valid if the denominator (alpha) is 0. But, since the results should only be expected to be accurate when viewed in premultiplied form, a resulting alpha of 0 essentially renders the resulting color components irrelevant and so exact behavior in this case should not be expected.

@see Composite @see CompositeContext @version 10 Feb 1997

Examples of java.awt.AlphaComposite

        Color green = Color.green;
        Color transparentBlue = new Color(0, 0, 255, 128);
        Color transparentGreen = new Color(0, 255, 0, 128);


        // Define AlphaComposites
        AlphaComposite srcOver = AlphaComposite.SrcOver;
        AlphaComposite srcOverTransparent = AlphaComposite.getInstance(AlphaComposite.SRC_OVER, .5f);


        // Define rectangle
        Rectangle rect = new Rectangle(10, 40, 100, 50);


        // Define thick stroke

View Full Code Here

Examples of java.awt.AlphaComposite

    public boolean equals(Object o) {
        if (o instanceof SVGComposite) {
            SVGComposite svgc = (SVGComposite)o;
            return (svgc.getRule() == getRule());
        } else if (o instanceof AlphaComposite) {
            AlphaComposite ac = (AlphaComposite)o;
            switch (getRule().getRule()) {
            case CompositeRule.RULE_OVER:
                return (ac == AlphaComposite.SrcOver);
            case CompositeRule.RULE_IN:
                return (ac == AlphaComposite.SrcIn);

View Full Code Here

Examples of java.awt.AlphaComposite

     * @param g2d the Graphics2D to use
     */
    public void paint(Graphics2D g2d){
        if ((composite != null) &&
            (composite instanceof AlphaComposite)) {
            AlphaComposite ac = (AlphaComposite)composite;
            if (ac.getAlpha() < 0.001)
                return;         // No point in drawing
        }
        Rectangle2D bounds = getBounds();
        if (bounds == null) return;

View Full Code Here

Examples of java.awt.AlphaComposite

            Element filterDef = null;
            if(composite.getRule() != AlphaComposite.SRC_OVER){
                // Note that the extra alpha is ignored by using the
                // majorComposite. The extra alpha is already represented
                // by the SVG_OPACITY_ATTRIBUTE value.
                AlphaComposite majorComposite =
                    AlphaComposite.getInstance(composite.getRule());
                filterDef = (Element)compositeDefsMap.get(majorComposite);
                defSet.add(filterDef);


                // Process the filter value

View Full Code Here

0 1 2 3 4 5

TOP

All source code are property of their respective owners. Java is a trademark of Sun Microsystems, Inc and owned by ORACLE Inc. Contact coftware#gmail.com.