headers
johsixt | 3 Aug 2008 22:05
Picon
Favicon

Re: [CinCV] Patch: Fixed multiple track bugs (Deals with fader)

Zitat von percy tiglao <prtiglao@...>:
> 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
(Continue reading)

Permalink | Reply |
headers
percy tiglao | 4 Aug 2008 04:25
Picon

Re: [CinCV] Patch: Fixed multiple track bugs (Deals with fader)

On Sun, Aug 3, 2008 at 4:05 PM,  <johsixt@...> wrote:
> Zitat von percy tiglao <prtiglao@...>:
>> 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.
>
(Continue reading)

Permalink | Reply |
headers
Johannes Sixt | 10 Aug 2008 22:41
Picon

Re: [CinCV] Patch: Fixed multiple track bugs (Deals with fader)

On Montag, 4. August 2008, percy tiglao wrote:
> On Sun, Aug 3, 2008 at 4:05 PM,  <johsixt@...> wrote:
> > Zitat von percy tiglao <prtiglao@...>:
> >> 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.
(Continue reading)

Permalink | Reply |
headers
percy tiglao | 13 Aug 2008 19:57
Picon

Re: [CinCV] Patch: Fixed multiple track bugs (Deals with fader)

On Sun, Aug 10, 2008 at 4:41 PM, Johannes Sixt
<johannes.sixt@...> 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:
(Continue reading)

Permalink | Reply |
headers
Johannes Sixt | 13 Aug 2008 23:31
Picon

Re: [CinCV] Patch: Fixed multiple track bugs (Deals with fader)

On Mittwoch, 13. August 2008, percy tiglao wrote:
> On Sun, Aug 10, 2008 at 4:41 PM, Johannes Sixt
<johannes.sixt@...> 
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
>
(Continue reading)

Permalink | Reply |

Gmane