Straight and premultiplied alpha store transparent color differently. Neither is universally correct: preventing halos depends on matching the alpha representation expected at every editing, filtering, and compositing stage.
Straight and Premultiplied Alpha Explained
Straight alpha stores RGB color independently from opacity. Premultiplied alpha instead scales each RGB component by the pixel’s alpha value while leaving alpha itself unchanged. In 8-bit examples, a 50%-opaque red pixel is approximately RGBA (255, 0, 0, 127) in straight form and (127, 0, 0, 127) in premultiplied form.
That distinction changes the arithmetic used for source-over blending. For an opaque destination background, with alpha expressed from 0 to 1, straight-alpha source-over blending first multiplies the source color by source alpha: source.RGB × source.A + destination.RGB × (1 − source.A). With premultiplied alpha, that multiplication is already reflected in the stored source RGB, so the calculation becomes source.RGB + destination.RGB × (1 − source.A).
These are two representations of transparent pixels, not competing quality settings. The appropriate choice is the one expected by the operation receiving the pixels.
Why Alpha Mismatches Create Dark or Bright Halos
Most visible failures occur at semi-transparent boundaries such as anti-aliased text, hair, shadows, and other soft edges. If already-premultiplied data is interpreted as straight alpha, a compositor may multiply its edge colors by alpha again. The colors become too dark, producing dark fringes.
The opposite mismatch has a different appearance. When straight-alpha pixels are treated as premultiplied, blending assumes their RGB values have already been reduced for opacity. Their contribution can therefore be too strong, creating bright, discolored, or oversaturated borders.
Premultiplied alpha is particularly useful for interpolation and filtering because RGB values in fully transparent regions cannot leak into neighboring visible pixels in the same way. However, even a suitable representation produces incorrect results when a later stage interprets it differently. A halo appearing only after an import, effect, resize, or composite is therefore a useful sign to inspect the alpha assumptions on both sides of that boundary.
How to Choose and Convert the Alpha Mode
Choose the mode required by the next application, API, effect, or renderer rather than applying a universal preference. Document the expected input and output at each handoff, and avoid conversions that are not needed.
To convert straight alpha to premultiplied alpha, multiply red, green, and blue by alpha while keeping alpha unchanged. To convert back, divide those color components by alpha when alpha is nonzero. This reverse operation has limits: when alpha is zero, premultiplication has erased the original straight RGB values, so they cannot be recovered. At low alpha values in integer images, multiplication and rounding can also discard precision that later division cannot restore exactly.
Inspect settings at import, effects, export, and compositing boundaries because software may convert internally. Validate the result with an asset containing soft transparency, not just fully opaque and fully transparent pixels. Compare it over both light and dark backgrounds; contrasting backgrounds make dark and bright edge errors easier to detect.
Conclusion
The correct alpha mode is the representation expected by the next workflow stage. Win2D illustrates why labels at one boundary may not describe internal storage: parts of its API accept straight-alpha colors, while bitmap and render-target pixels are stored and used for drawing and blending in premultiplied form.
Before delivery, check the alpha setting at every import, effect, export, and compositing handoff. Then place a soft-edged transparent asset over both light and dark backgrounds and look for dark, bright, or discolored fringes.
Disclosures and limitations
- This article was prepared with AI assistance using only the supplied research package. Material technical claims are attributed through the accompanying source IDs; implementation details can vary by file format, application, effect, and rendering pipeline.
Sources
- Premultiplied Alpha vs Straight Alpha – CG Director — CGDirector
- AVIF Premultiplied Alpha Halo Artifacts Explained – avif — salivity.github.io
- Alpha compositing – Wikipedia — en.wikipedia.org
- Alpha channels: premultiplied vs straight by Rich Young – ProVideo Coalition — ProVideo Coalition
- Premultiplied alpha – Windows apps — learn.microsoft.com
- Straight Alpha vs Premultiplied Alpha – CT Knowledge Base — kb.ct-group.com
- Premultiplied Alpha in AVIF: Mathematical Process – avif — salivity.github.io
Improve this guide
Report a problem or suggest the next question
Submissions enter a private editorial queue. They are reviewed and deduplicated before any public update or new page is created.