287  * <p>
 288  * Note that the intermediate values, which are always in premultiplied
 289  * form, would only allow the integer red component to be either 0x00
 290  * or 0x01.  When we try to store this result back into a destination
 291  * that is not premultiplied, dividing out the alpha will give us
 292  * very few choices for the non-premultiplied red value.
 293  * In this case an implementation that performs the math in integer
 294  * space without shortcuts is likely to end up with the final pixel
 295  * values of:
 296  *
 297  * <pre>
 298  *    (A, R, G, B) = (0x01, 0xff, 0x00, 0x00)</pre>
 299  *
 300  * <p>
 301  * (Note that 0x01 divided by 0x01 gives you 1.0, which is equivalent
 302  * to the value 0xff in an 8-bit storage format.)
 303  *
 304  * <p>
 305  * Alternately, an implementation that uses floating point math
 306  * might produce more accurate results and end up returning to the
 307  * original pixel value with little, if any, roundoff error.
 308  * Or, an implementation using integer math might decide that since
 309  * the equations boil down to a virtual NOP on the color values
 310  * if performed in a floating point space, it can transfer the
 311  * pixel untouched to the destination and avoid all the math entirely.
 312  *
 313  * <p>
 314  * These implementations all attempt to honor the
 315  * same equations, but use different tradeoffs of integer and
 316  * floating point math and reduced or full equations.
 317  * To account for such differences, it is probably best to
 318  * expect only that the premultiplied form of the results to
 319  * match between implementations and image formats.  In this
 320  * case both answers, expressed in premultiplied form would
 321  * equate to:
 322  *
 323  * <pre>
 324  *    (A, R, G, B) = (0x01, 0x01, 0x00, 0x00)</pre>
 325  *
 326  * <p>
 327  * and thus they would all match.

 287  * <p>
 288  * Note that the intermediate values, which are always in premultiplied
 289  * form, would only allow the integer red component to be either 0x00
 290  * or 0x01.  When we try to store this result back into a destination
 291  * that is not premultiplied, dividing out the alpha will give us
 292  * very few choices for the non-premultiplied red value.
 293  * In this case an implementation that performs the math in integer
 294  * space without shortcuts is likely to end up with the final pixel
 295  * values of:
 296  *
 297  * <pre>
 298  *    (A, R, G, B) = (0x01, 0xff, 0x00, 0x00)</pre>
 299  *
 300  * <p>
 301  * (Note that 0x01 divided by 0x01 gives you 1.0, which is equivalent
 302  * to the value 0xff in an 8-bit storage format.)
 303  *
 304  * <p>
 305  * Alternately, an implementation that uses floating point math
 306  * might produce more accurate results and end up returning to the
 307  * original pixel value with little, if any, round-off error.
 308  * Or, an implementation using integer math might decide that since
 309  * the equations boil down to a virtual NOP on the color values
 310  * if performed in a floating point space, it can transfer the
 311  * pixel untouched to the destination and avoid all the math entirely.
 312  *
 313  * <p>
 314  * These implementations all attempt to honor the
 315  * same equations, but use different tradeoffs of integer and
 316  * floating point math and reduced or full equations.
 317  * To account for such differences, it is probably best to
 318  * expect only that the premultiplied form of the results to
 319  * match between implementations and image formats.  In this
 320  * case both answers, expressed in premultiplied form would
 321  * equate to:
 322  *
 323  * <pre>
 324  *    (A, R, G, B) = (0x01, 0x01, 0x00, 0x00)</pre>
 325  *
 326  * <p>
 327  * and thus they would all match.