On Sun, Aug 10, 2008 at 4:41 PM, Johannes Sixt <[EMAIL PROTECTED]> wrote: > Therefore, even though I think your patch goes into the right direction, it is > not fully thought through, yet, and solves only a special case.
I agree. Hopefully talking it out here will make everything more clear. >> 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. (No alpha should be greater than 1). Given the right circumstances, my origional formula is also wrong (the resulting alpha value is always too small to make sense). So I decided to checkout a book from my library on this one... I'm wrong, and wikipedia is also wrong :-( . In the book "Computer Graphics: Principles and Practice. Second Edition in C" by Foley et. al, page 837, the Alpha values represent the subpixel area that the two layers cover. Therefore, there are 4 areas of interest: Area covered by the first, the area covered by the second, the area covered by both, and the area covered by neither. Assuming that the two layers have proportional overlap, the correct alpha value is therefore: a_eq = (1 - ((1 - a1) * (1 - a2))) Derivation: (1 - a1) * (1 - a2) Is the area covered by neither. (a1 is the area covered by the first, a2 is the area covered by the second. a1*a2 is _assumed_ to be the area covered by both) Checking with some math, this gives the following sample alpha values: a1 = .5, a2 = .5, a_eq = .75 a1 = .9, a2 = .1, a_eq = .91 a1 = .1, a2 = .1, a_eq = .19 a1 = 1.0, a2 = (anything), a_eq = 1 All of these make sense to me. (all a_eq are less than 1, and all of them are greater than both a1 and a2 individually) Both the book and the wikipedia page make a reference to Porter and Duff 1984. So the paper probably has better details on this sort of stuff: http://keithp.com/~keithp/porterduff/ > 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. 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) 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? --Percival Tiglao _______________________________________________ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
