On Mittwoch, 13. August 2008, percy tiglao wrote: > On Sun, Aug 10, 2008 at 4:41 PM, Johannes Sixt <[EMAIL PROTECTED]> wrote: > >> Actually, upon further calculation... I am 100% sure there is a bug in > >> my code. The alpha value is set to max, which is wrong. I'm supposed > >> to set alpha to my predicted value of a2 * (1-a1) and then divide r g > >> and b by this new alpha. > > > > I don't immediately see that this is the correct alpha value. And why do > > you divide RGB values? OpenGL certainly never does it. > > Well, thats just how my model worked out. Now, I admit that I just > made up my model on the fly and probably should have put more research > into it... but it certainly looked "better" than the max approach that > the current codebase uses. Anyway, the Wikipedia page you put up > looked funny to me. The formulas didn't make sense in my head, and > I'll explain here. > > >> a_eq = a2 * (1-a1) > > > > I think the correct alpha value must be > > > > a_eq = a2 * (1-a1) + a2 > > That is the one from the wikipedia page. However, given the following > alpha values: > a2 == .9 > a1 == .1 > > Then the resulting a_eq is 1.71, which is clearly wrong.
Make this a_eq = a2 * (1-a1) + a1 which is identical to > a_eq = (1 - ((1 - a1) * (1 - a2))) ;) > > Your left-hand side is a pre-multiplied color value. I haven't thought > > through whether the render pipeline uses pre-multiplied colors. It seems > > to make sense. In this case: > > > > - we shouldn't multiply by the alpha value again in the compositing stage > > > > - we don't need to divide by alpha, because we need to check for > > zero-division. > > > > - it is incorrect that the transfer_RGBA8888_to_RGB888() function is used > > to display the resulting image, which multiplies the alpha again. > > > > There's another issue to think about: Are the RGB values of the (source) > > media (that have an alpha channel) pre-multiplied by there alpha values > > or not? Shouldn't we use the same convention when we write (rendered) > > media? I don't know what is customary. > > > > And another one: The first layer must be multiplied by the fade value and > > the alpha channel must be set up accordingly for media that do not have > > an alpha value. Does this happen at all times? > > These are many good points... and I really don't know what to say. I > guess I should study the source code more. Personally I think that *if* we change something in this area, then we do it with the same math the OpenGL renderer uses. Then we have one valid reference after which we can model the software renderer (after we fix the one instance where OpenGL renderer gets the alpha value wrong). The trouble is that this influences existing projects. > I do know the following > though. > > * The fade value is taken into account before the "Blend" phase. The > fader render node just multiplies the alpha value by the current fade > value. For images without an alpha channel... I don't know what > happens. From my experiments with cinelerra, I'd say it isn't set up > correctly (If you set the mode to one without an alpha channel, only > the top image shows. The bottom image does not blend through) Well, if the color model doesn't have an alpha channel, then alpha blending cannot happen. But fading an image towards black can be regarded as the correct operation. That's just a matter of definition. > As a side note: we need to redo this analysis on the just released > Cinelerra4 source code and see what has changed. Or do you think it > would be better to instead patch up Cinelerra2 for now? I don't know. Did Cinelerra4 change in this area? I haven't looked at it, yet. -- Hannes _______________________________________________ Cinelerra mailing list [email protected] https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
