Talk:Alpha compositing/Archive 1

Archive 1

Why alpha?

In the German wp a user asked why the alpha channel was called alpha channel. Does anybody has got an idea? --PhilippWeissenbacher 17:51, May 14, 2005 (UTC)

My guess: RGBA color space Mion 16:28, 21 January 2006 (UTC)

I found a reference and added the information to RGBA color space. --130.234.180.167 23:02, 3 July 2006 (UTC)

Required Details

This article is missing a lot of important information. Before I propose replacement, I'll throw out what I'd like to see included:

• a separate article, Coverage (Computer Science), talking about representation of partially transparent images
• a photorealistic example (showing the result of combining at least 3 layers (A over (B over C)))
• refocus article on the general case of blending pixels, both with arbitrary coverage
• clarification between discussion of blending whole images and the blending of two specific pixels
• discussion of different formulations of the compositing operators (mention whether they are associative or not)
• a small table of all possible operations (T. Porter and T. Duff, "Compositing Digital Images", SIGGRAPH 84, 253-259)
• a Separate section about implementation that discusses using associativity to allow distribution/parallelization, 0-1-only alpha bitmaps, integer-only representations, lookup table usage, setting up glBlendFunc

-- Rndmcnlly 01:00, 16 September 2006 (UTC)

New example image?

I think the example image is useless, as it doesn't demonstrate what alpha really is, it looks just like hue + saturation (because it's alpha blended on white). What you need is some real world images alpha-blended together. Like maybe a landscape and a dragonfly with semi-transparent wings. 82.139.87.148 (talk) 05:44, 1 October 2009 (UTC)

Confusion

RGB triple should instead be RGBA 4-tuple?

I find this line to be confusing: "Thus, assuming that the pixel color is expressed using RGB triples, a pixel value of (0.0, 0.5, 0.0, 0.5) implies a pixel which is fully green and has 50% coverage."

Seems like it should be (0.0, 1.0, 0.0, 0.5) and called a RGBA 4-tuple. I'm afraid to change it, because maybe I just don't get it!

24.106.89.6 12:43, 5 September 2007 (UTC)

I've added this: (Explanation: The RGB values are the first three values, (0, 0.5, 0) and the alpha value is the fourth, 0.5. If the color were fully green, its RGB would be (0, 1, 0). Since this pixel is using a premultiplied alpha, all of the RGB values in the ordered triplet (0, 1, 0) are multiplied by 0.5 and then the alpha is added to the end to yield (0, 0.5, 0, 0.5). ) --Rajah (talk) 15:45, 5 May 2008 (UTC)

This explanation is not much help because two of the three colour values are zero. What would the premultipled alpha be if the RGB values were, for example, (0.3, 0.4, 0.5)? —Preceding unsigned comment added by 193.72.68.35 (talk) 13:28, 13 May 2010 (UTC)

Moved list of Operating Systems

There was a list of Operating Systems which support alpha compositing stuffed into the section defining it mathematically. I felt that this wasn't the right place to put this information, so I added an "Applications" section and added a little bit of additional information. It could stand to be reviewed and fleshed out, perhaps with some sort of notes about what exactly each of the OS's support blending. (widgets in a window but not the windows themselves? transparent windows but only opaque widgets? completely arbitrary arrangements of transparent windows and widgets?)

I don't know how important the list is, but somebody obviously went to some trouble to make it, so I am hesitant to just toss it. I also added a link to Compositing software which seems like it should be somewhere in the article, even if that section is removed. —Preceding unsigned comment added by 76.169.41.151 (talk) 04:14, 19 September 2010 (UTC)

Errors

>Image editing applications that allow reordering of layers generally prefer this second approach.

No, Image editing applications that allow reordering of layers generally don't use premultiplied color. —Preceding unsigned comment added by 192.150.10.200 (talk) 03:22, 23 February 2011 (UTC)

> it is common to also multiply the color by the alpha value, to save on additional multiplications during compositing.

Incorrect because the compositing operator can be reduced to a single multiply anyway. T*a + B*(1-a) === B + (T-B)*a —Preceding unsigned comment added by 192.150.10.200 (talk) 03:28, 23 February 2011 (UTC)

>Premultiplied alpha also has some advantages over normal alpha blending because premultiplied alpha blending is associative and linear interpolation gives better results.

This does not seem to have a reference, and is not supported by the rest of the article. —Preceding unsigned comment added by 192.150.10.200 (talk) 03:35, 23 February 2011 (UTC)

Added new section on analytic derivation of the over operator

The new section describes how to derive the over operator analytically. It is different from the approach outlined by Bruce Wallace (which is much more convoluted IMO.) I know also a second approach on how to derive the operator, which is similar to the one by Bruce, but it relies on using Bayesian probability.

Any feedback is welcome. I also agree that the section called "alpha blending" needs to be merged with the first section. Meanderix (talk) 20:07, 20 November 2010 (UTC)

I believe the formula can be compacted further: Co=(Aa/Ao)(Ca-Cb)+Cb 68.81.139.28 (talk) 03:38, 1 February 2012 (UTC)

Over algorithm section is confusing

I am a computer programmer who is new to compositing. I came here to learn how to do it. I found the section on the over operator to be incredibly confusing. In particular, the initial mentioned formula

$C_{o}=C_{a}\alpha _{a}+C_{b}\alpha _{b}\left(1-\alpha _{a}\right)$

appears to have the property that if you take a layer and put a transparent layer behind a partially transparent image, the composited image differs from the original image! That can't possibly be right. I see that if you then use the version where you divide by the new alpha value, this problem does not occur. However, the article would have made much more sense to me if the original formula had not beent here at all. It would make more sense to start with the sane version. Crazy variants should be left out entirely, so that a reader who is trying to learn the subject does not waste mental cycles on them. William Jockusch (talk) 15:43, 4 October 2012 (UTC)

Merger

Merge what with which? William Jockusch (talk) 15:44, 4 October 2012 (UTC)

For

• Merge it. They're the same thing. Ayavaron 21:12, 10 September 2006 (UTC)
• Merge it. The information in blending is basically the A Over B formula when B is opaque. Alancnet 10:26, 14 September 2006 (UTC)
• Merge it. Neither article tells the whole story now. I do, however, think [Alpha Blending] is the better title -- many other uses of "composite" are applied to reversable or decomposable preocesses. I think of blending as producing an inseparable product. Rndmcnlly 23:42, 15 September 2006 (UTC)
• Merge. In particular, the alpha blending article raises the important point that a single alpha channel is not the only option for this technique. The compositing article should mention this, and discuss the limitations of conventional RGBA compositing, such as inaccuracy in depictions of transparency in composites, especially with refractive or colored transparent elements.

Intro / Abstract

The introduction goes into too much detail in the second paragraph. The introduction should offer more real life examples before explaining the technology, and mention why this is important and worthy of inclusion. I'm learning about this as a newbie and the tech crap is sort of mind boggling in minutiae with no real overview of what this is and why it's useful and what distinguishes it from other, similar concepts. JazzyGroove 15:32, 15 September 2009 (PST).

Agreed, the intro paragraphs are both vague and over-detailed. E.G.:

It is often useful to render image elements in separate passes, and then combine the resulting multiple 2D images into a single, final image in a process called compositing. For example, compositing is used extensively when combining computer rendered image elements with live footage.

We're told the technique is useful, but not why it's useful, especially relative to other techniques. Useful in what way? What's gained? What's lost? Then an example is given, but no reason is given for the example. --AC (talk) 03:05, 10 April 2012 (UTC)

___________________________

I Agree, I also came here to figure out how to use transparency in an icon I need to make. I was hoping to find a simple answer that would tell me how to do it, instead I find something more suited to digital graphic engineering. Every graphic program I have used has a very hard time explaining transparency and how to do it in simple terms so someone can do it and get on with the creation they are working on without all the background technology. What ever the description is it should include non-web page methods. 98.216.193.104 (talk) 18:14, 24 December 2013 (UTC)

Applications

Are there any valid reasons for having the Applications section? It seems nowadays there are too many Applications too list and almost every modern OS supports alpha-blending. — Preceding unsigned comment added by 24.4.33.160 (talk) 01:33, 11 November 2012 (UTC)

I also don't see the importance of having a list of Applications that support alpha-blending. Furthermore, it is incomplete. Since there hasn't been any objections since 2012, I'll go ahead and remove it. — Preceding unsigned comment added by 216.38.147.4 (talk) 17:55, 8 July 2015 (UTC)

Possible error

According to Porter & Duff, the over operator solves to c_O = c_A*1+c_B*(1-a_A), which is equivalent to C_O = (C_A*a_A+C_B*a_B*(1-a_A))/a_O, which is the second formula mentioned, not the first. The first formula, B' = F*a + B*(1-a), was mentioned in passing as being similar to the over function, but not equal. 64.229.30.184 05:54, 23 May 2007 (UTC)

sep

Hmm. I'm another reader, who finds the first equation in flat contradiction of the others (the later "premultiplied" rule and the "associative" rule seem to be equivalent, but the first equation looks just plain wrong). Also it's not made clear the relation between the "over" operation in the first section and the "Alpha Blending" section below. 212.44.20.129 (talk) 11:26, 20 May 2008 (UTC)

There is an error on the second formula, is Ao (alpha zero) instead Aa (alpha a). —Preceding unsigned comment added by 80.205.86.211 (talk) 11:22, 9 October 2008 (UTC)

French Wikipedia page has a bit different and maybe more applicaple equations. It should be considered changing this page closer to the French page since the equations on French page http://fr.wikipedia.org/wiki/Alpha_blending handle output alpha channel a bit more consistently. It should be mentioned that C_o = C_a \alpha_a + C_b \alpha_b \left(1 - \alpha_a\right) needs to be devided by output alpha for correct RGB pixel values. This is presented clearly in French Wikipedia equations. — Preceding unsigned comment added by 91.155.87.158 (talk) 06:23, 26 September 2011 (UTC)

I agree with the above complaints and I fixed this to match the French page. This entry shouldn't have had a blatant mathematical contradiction between the definition of c_O and C_O for seven years. — Preceding unsigned comment added by 166.175.57.129 (talk) 23:08, 11 July 2015 (UTC)

Assessment comment

The comment(s) below were originally left at Talk:Alpha compositing/Comments, and are posted here for posterity. Following several discussions in past years, these subpages are now deprecated. The comments may be irrelevant or outdated; if so, please feel free to remove this section.

merge to alpha compositing

Substituted at 17:58, 5 June 2016 (UTC)

Composing alpha blending with gamma correction

Alpha blending, not taking into account the gamma correction

Alpha blending, taking into account the gamma correction A demonstration with python code can be found here

The RGB values stored in computer images are actually not the real light intensities, but they have been transformed by a Gamma correction, in order to optimize the usage of bits when encoding an image.

The gamma correction can be roughly summarised as below:

• let $displayed_{RGB}$ be the RGB intensity that is displayed on the screen (in normalised intensities, i.e between 0 and 1)
• let $stored_{RGB}$ be the RGB intensity that is stored as bits in the computer memory (in normalised intensities also)
• let $\gamma$ be the "decoding" gamma of 2.2 of the $stored_{RGB}$ image ($\gamma$ has a typical value of 2.2)

Then we have the following relation:

$displayed_{RGB}={stored_{RGB}}^{\gamma }$

Thus, when dealing with computer stored RGB values, alpha blending will look much better it the gamma correction is unapplied before averaging the images and re-applied afterwards. For more detailed information, refer to the video Computer Color is Broken by MinutePhysics

For example, if one wants to superimpose an image named $overlay_{rgb}$ with an alpha channel $overlay_{\alpha }$ onto a background image $background_{rgb}$, then the resulting image $out_{rgb}$ can be calculated like this:

$out_{rgb}=({overlay_{rgb}}^{\gamma }\times overlay_{\alpha }+{background_{rgb}}^{\gamma }\times (1-overlay_{\alpha }))^{1/\gamma }$

Note: $out_{rgb}$ is the image as it will be stored in the computer memory; and it will be displayed as $out_{rgb}^{\gamma }$ on the computer display.

Pthomet (talk) 19:15, 5 April 2018 (UTC)

Why "alpha"?

Not in any way to dispute the term "alpha" itself, as it is the term that is used. But why was it named alpha? Are there a beta, gamma, delta, etc. compositing? It might also help for the answers of these questions to be in the article itself. - Gilgamesh (talk) 05:49, 1 September 2018 (UTC)

Advertising in this article

Is this even allowed? I would recommend re-writing this to remove the blatant advertising without compromising the information given. --2602:30A:2C3A:6810:6A05:CAFF:FE14:624F (talk) 18:10, 3 July 2018 (UTC)

Can you please be more specific which phrases you mean? You could also simply improve those phrases yourself. --RainerBlome (talk) 16:33, 2 February 2019 (UTC)

The image "Partially transparent A and B, A out B" seems wrong

In the "Partially transparent A and B" row, it looks like the intersection between A and B in "A out B" isn't fully transparent in the image. Shouldn't this be fully transparent?

If not, then why is the resulting intersection color of "A in B" different from "A out B"?

--My2Cents (talk) 17:40, 31 August 2020 (UTC)

I'd say the image is correct. The key for understand is the "conceptual sub-pixel overlay" diagrams at the bottom row.

For "A out B" $C_{o}=C_{A}$ and $\alpha _{o}=\alpha _{A}(1-\alpha _{B})$. So in the intersection we get a non-zero alpha.

For "A in B" $C_{o}=C_{A}$ and $\alpha _{o}=\alpha _{A}\alpha _{B}$. So it's non-zero alpha again.

The colors in both cases are the same, but the alpha values are different. Presumably because $\alpha _{B}>0.5$. Accordingly "A out B" is more transparent than "A in B".

bungalo (talk) 18:38, 31 August 2020 (UTC)

Thanks for enlightening me!

I feel the "conceptual sub-pixel overlay" is hard to grasp. It only explains two of the four quadrants. Wouldn't the article benefit from elaborating on all the four quadrants or by adding the mathematical formula for each of the cases?

My2Cents (talk) 20:50, 7 September 2020 (UTC)

GIMP ?

"blue (0,0,1,1/2) on red (1,0,0,1)" or "red (1,0,0,1/2) on blue (0,0,1,1)" give (β,0,β,1) where β=187/255≃.733 or 188/255≃.737 (not 1/2 !). Why ? any ref ?   <STyx @ (I promote Geolocation) 23:13, 25 November 2020 (UTC)

Must be gamma correction. When working in sRGB, 1/2 is gamma-compressed into 0.73536, which will be dithered between 187 and 188 when storing in 8-bits. bungalo (talk) 17:22, 6 January 2021 (UTC)

Inconsistent notation

Some legend is necessary. What the hell is OutA ? (unsigned comment)

Let me guess: out stands for output and A stands for Alpha? bungalo (talk) 23:10, 2 March 2021 (UTC)

You are raising a valid point though: this article doesn't use a consistent notation through out. I see the following notations used:

$C_{o},\alpha _{o},C_{a},\alpha _{a},C_{b},\alpha _{b}$

$\mathrm {out} _{RGB},\mathrm {out} _{A},\mathrm {src} _{RGB},\mathrm {src} _{A},\mathrm {dst} _{RGB},\mathrm {dst} _{A}$

${\text{out}}_{\text{rgb}},{\text{overlay}}_{\text{rgb}},{\text{overlay}}_{\alpha },{\text{background}}_{\text{rgb}}$

I'm not sure yet what notation is the best. I do, however, prefer the terms "source" and "destination" to the generic "a" and "b", because they are more common in the field and communicate purpose.

If there's no objection, I'll follow up with editing the article to follow a single notation. bungalo (talk) 18:28, 3 March 2021 (UTC)

I removed the offending text, and used the first convention throughout (this is the convention from Duff's paper). bungalo (talk) — Preceding undated comment added 00:15, 4 March 2021 (UTC)

Premultiplied shouldn't be presented as an afterthought

The article shows over blending for straight alpha first, and only then tries to make a case for premultiplied alpha in a somewhat apologetic tone. Granted, that's how many people learn of alpha, thinking like painters diluting color, but that's not the mathematically correct way of dealing with it.

IMO this article should be reversed -- the premultiplied formulae should be given first, and then an explanation about how straight alpha should be dealt with. Interestingly early versions of this article included the formula for premultiplied alpha but not the straight alpha.

Note that this is also what Duff's paper does. bungalo (talk) 23:05, 5 March 2021 (UTC)

Now that I've started looking at #Description more carefully, yeeep. The fancy operations by Duff are only defined in the premultiplied form -- it's not impossible to convert them to straight, but it's complex and OR. Artoria2e5 🌉 07:29, 30 June 2023 (UTC)

The Cairo Graphics Library documentation gives the Porter-Duff formulae in non-pre-multiplied form, if you're looking for a source: https://www.cairographics.org/operators/

rerdavies (talk) 02:07, 20 August 2023 (UTC)

Premult alpha section cleanup

I did some minor cleanup of this section, mostly removing/combining sentences that said the same thing. I also tagged the section as containing original research. Everything in the section is more or less correct, but I don't have good sources on hand to cite the stuff written in it. I did remove one dubious sentence:

Fires and flames, glows, flares, and other such phenomena can only be represented using associated / premultiplied alpha.

While this is true for Physically_based_rendering, that's not the only application of alpha blending by far. This sentence could be re-added with this context ("When using PBR, ... such phenomena can only be correctly represented..."), but that would also need a citation.

JadeMatrix (talk) 05:37, 9 April 2023 (UTC)

I think you missed the point (granted, not your fault, because the text wasn't very clear to begin with). That "fires and flames" sentence seems to be a misplaced example of when encoding additive regions within the same image can be useful. For a better example I'd use 'fire and smoke' -- the former is emissive, the later is absorptive; and it is a common need to encode both within the same sprite for a particle system.

Calling this PBR is a stretch. PBR is about generating the images, and it can use either premultiplied or straight alpha, as well as other formulas to blend colors (e.g. atmospheric absorption requires multiplicative blending which is neither pre nor straight alpha). On the other hand, straight vs premuliplied is a method of encoding the composited image. bungalo (talk) 06:14, 9 April 2023 (UTC)

My point was that the sentence was poorly-worded enough or missing enough context to be untrue. Premultiplied alpha is not strictly necessary for rendering these effects. That's why I suggested rewording it to add some form of description as to when it is true, such as for combined emissive/occlusive textures under PBR. You're right though, premult alpha isn't the only way to handle these textures in PBR. Honestly though I'd just rather leave the sentence out; the section's wordy enough as it is, and adding words to this sentence to describe when it's applicable won't help. JadeMatrix (talk) 13:04, 10 April 2023 (UTC)

In fact, it's only true if you're using a fixed-point framebuffer. Duff may have needed it in 1984, but floating-point framebuffers and HRDI images are commonplace. It's definitely not true anymore. Probably easiest to just not regret having deleted it. rerdavies (talk) 02:35, 20 August 2023 (UTC)

Missing Porter-Duff Operators, and Stained Glass Windows

The comment "For some applications, a single alpha channel is not sufficient..." needs fixing. The stained glass example is unfortunate. The Porter-Duff Source-Out and Dest-Out operators (which are missing from the list of operators at the head of the article) allow for subtractive color computations. You can use those operators for stained-glass effects.

It is true that Porter-Duff operators provide an approximation to actual physical perception of mixed colors. See the Metamerism article for a reasonable explanation of why RGB color mixing is a non-physical approximation. But, those problems with stained glass that do exist won't be fixed by three channels of alpha. 3 channels isn't helpful. If you use source Source-Out, 1 channel is perfectly sufficient. And if one channel isn't good enough, you're going to need infinite channels (continuous spectrum computations). There is no three.

On a more adventurous note, it might be worth explicitly acknowledging Porter-Duff compositing operators, or even reframing the entire article around Porter-Duff compositing operators, which are now a standard feature of all major graphics packages written since 1984, on Windows, Mac, Linux, and Color Postscript. I'm pretty sure there are eight compositing operators, not 4. Source-Out, Dest-Out, XOR, not sure what the last one is.

As a professional programmer working in the graphics field since forever, I think the article should be explictly Porter-Duff operators from start to finish.

rerdavies (talk) 03:27, 20 August 2023 (UTC)

I see no problem with that section other than a lack of a source.

In particular, I don't understand how source/dest out operator helps with it. How would you use it to encode a stained glass window that has a red, a green, and a blue transparent glass segments? Stained glass requires multiplicative blending rather than subtractive, and multiplicative blending is not one of the Porter-Duff operations.

Yes -- for correct spectral composition you'd need more than four channels -- and the text acknowledges that.

As for the number of compositing operators -- it's either 12, 9, or 5 depending on how you count. This article talks about the 5 unique non-trivial operators: over, in, out, atop, xor. If you double-count the asymmetrical operators (e.g A over B vs. B over A) then it's 9. There're also three trivial ones: 0, A, B -- which adds up to the 12 in Porter-Duff paper, but I don't think that they're worth mentioning in this article.

Graphics packages tend to have other compositing methods (often called blend modes) that aren't part of the Porter-Duff paper, and aren't really related to alpha compositing that much. Perhaps you're confusing it with those? bungalo (talk) 02:38, 21 August 2023 (UTC)

Linear alpha

Not sure the claim "alpha is always linear" is correct. In HTML/Webkit, Opacity and color alpha both use an sRGB curve. Photoshop: sRGB. PNG: configurable. I'm poking at a Cairo framebuffer to figure out whether their framebuffers are linear or sRGB alpha.

Unfortunately, it's not difficult to find disreputable sources for "alpha is always linear", and difficult to find sources for "alpha isn't always linear". So a [citation needed] isn't going to cut it. But I do think the claim is wrong.

rerdavies (talk) 03:27, 20 August 2023 (UTC)

Seems you're right; I changed the offending text, though I don't can't find good sources. Couldn't even find the relevant part in the SVG/CSS specs. bungalo (talk) 02:14, 21 August 2023 (UTC)