On Sun, Aug 3, 2008 at 4:05 PM, <[EMAIL PROTECTED]> wrote:
> Zitat von percy tiglao <[EMAIL PROTECTED]>:
>> Bug #1: Put two tracks on top of each other. Have the top one at say,
>> 50% fade or so. (any fade that isn't 100% has the bug). Have the
>> bottom at 0% fade. The bottom track is visible, although it shouldn't
>> be. The lower the top track's fade, the more noticable the bug.
>>
>> Bug #2: Put two tracks on top of each other. Have the clip on the
>> bottom track start a few seconds after the first. Have the top one at
>> 50% fade. Mute the bottom track. There is a noticable change in
>> brightness when the clip on the bottom track starts.
>>
>> Bug #3: Put two tracks on top of each other. Have the top one at 50%
>> fade. Change the fade of the bottom track between 0% and 50%. There is
>> no difference in output despite the changes on the bottom track's
>> fade.
>>
>> Three bugs that I found... but they all have to do with the same few
>> lines of code in the render engine. Unfortunately, there is a ton of
>> copy/paste code in this source file... so most likely this bug exists
>> in other forms or on other render settings. However, this patch fixes
>> Cinelerra as far as my current project is concerned.
>
> One premise that I buy your argument is that after your patch the software
> renderer ("X11" playback driver) and the OpenGL renderer ("X11 OpenGL"
> playback
> driver) produce the exact same result (in the Composition window). And I have
> reason to believe that it does not, although I have to meditate a bit more on
> this subject. But I'm on vacation currently, and without access to my
> Cinelerra
> box.
>
> -- Hannes
>
I forgot to "reply to all", so here's the message I sent to Hannes.
----
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.
Don't worry, you're not the only one to think of a *slight* bug in
this code :-p. I don't have a patch on me right now, but I can whip
one up quickly if anyone wants it.
--Percival Tiglao
----
Let me explain why I'm 100% sure, and why I think it is only a slight
bug. The model that I'm using for the overlay is:
i1 * a1 / max + i2 * a2 * (1-a1) / max + i3 * a3 * ( 1- a2 * (1-a1)) / max ...
Where i1 is a pixel, and a1 is the alpha value for the top pixel. i2
and a2 are the values for a lower pixel, and i3 and a3 are the values
for the lowest pixel. The job of this bit of code is to combine i1 and
i2, and a1 and a2 into an equivalent statement.
Therefore... we are aiming at something along the lines of:
i_eq * a_eq / max + i3 * a3 * (1 - a_eq) / max == i1 * a1 / max + i2 *
a2 * (1-a1) / max + i3 * a3 * ( 1- a2 * (1-a1)) / max
Basically, i_eq and a_eq replace i1 and i2. A bit of arithmatic and...
i_eq * a_eq = i1 * a1 + i2 * a2 * (1-a1)
a_eq = a2 * (1-a1)
I should note that my patch is correct with the value i_eq * a_eq,
which is why it works for the case where there are only two layers.
However, because the alpha value is not set correctly, the 3rd layer
will be off, at least theoretically.
My patch should work perfectly for 2 layers or less. With 3 or more
layers... it works better than how Cinelerra used to work but is
theoretically not perfect. If anyone is interested in it then just
email me and I'll make a patch with that math. I'm currently going to
try to cut down the render time for Blends (because they are just too
darn slow for me right now)
--Percival Tiglao
_______________________________________________
Cinelerra mailing list
[email protected]
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
