【OFX Keyframe curve bug 】

Comments

Marco. wrote on 4/24/2018, 10:34 AM

Yes, the curve type used in ProType Titler offers a much better reprentation of how the parameters would work.

NickHope wrote on 4/24/2018, 10:34 AM

Could you share a sample project?...

@Marco. Link was in my comment above. https://drive.google.com/file/d/1TcCjHeiCK9VOwkh53501Lgu7cdhT7MCu/view?usp=sharing

Another simpler demo would be to replicate the shape of, for example, a Fast Fade curve with a Manual curve and then see the difference.

Marco. wrote on 4/24/2018, 10:37 AM

"The curve can't represent the speed or else the timeline would be useless."

But it does. It represents holds, slow-downs, speed-ups. All can be done without changing the place/time position of the keyframes. It isn't best way to use curves, imho, but that's the way they work for OFX in Vegas Pro.

Marco. wrote on 4/24/2018, 10:45 AM

Nick, I just took a look into your sample project but still think what we get there is expected behaviour. There is a slightly different speed up which affects the beginning of the curve. It is very slight but given the curve is speed not parameter value this is pretty much what I'd expect.

Maybe I could show a better mathematical representation later.

NickHope wrote on 4/24/2018, 10:47 AM

Here's another project. One track has a Fast Fade and the other track has a Manual curve that closely approximates the Fast Fade. I was careful not to "overshoot". Put the cursor at 3.5 seconds and you'll see a huge difference in luminance between the 2 events.

https://drive.google.com/file/d/1md4NcnocJvwhHAwbhsj2aNOzGzB3NzAe/view?usp=sharing

Former user wrote on 4/24/2018, 11:01 AM

If I put two keyframes 2 seconds apart, regardless of the curve, holds etc, it better get there in 2 seconds or I would want my money back.

Marco. wrote on 4/24/2018, 11:34 AM

Nick, thanks for your second sample. Actually this one is strange. Can't see any logic behind the difference there.

Wolfgang S. wrote on 4/25/2018, 2:38 AM

The problem is that the numeric value does not correspond to the curve. This is clearly visible when overshooting. You can also see it when a new keyframe is added to a drawn graph. Then the point jumps to the right place.


What numeric values are you talking about?

The spline lines, that become visible after you have set the keyframe to "Manual" or "split Manual", have not the function to Change the numeric values of the keyframe. The only function of the spline lines is to adjust the shape of the curve between the keyframes.

Sure the numeric values of the curve between keyframes will be influenced how you set the spline lines. But that is ok because the spline lines have the function to adjust the shape of the curve = they have an Impact to numeric values between key Frames.

 

Desktop: PC AMD 3960X, 24x3,8 Mhz * GTX 3080 Ti (12 GB)* Blackmagic Extreme 4K 12G * QNAP Max8 10 Gb Lan * Resolve Studio 18 * Edius X* Blackmagic Pocket 6K/6K Pro, EVA1, FS7

Laptop: ProArt Studiobook 16 OLED * internal HDR preview * i9 12900H with i-GPU Iris XE * 32 GB Ram) * Geforce RTX 3070 TI 8GB * internal HDR preview on the laptop monitor * Blackmagic Ultrastudio 4K mini

HDR monitor: ProArt Monitor PA32 UCG-K 1600 nits, Atomos Sumo

Others: Edius NX (Canopus NX)-card in an old XP-System. Edius 4.6 and other systems

Wolfgang S. wrote on 4/25/2018, 2:54 AM

Could you share a sample project?...

@Marco. Link was in my comment above. https://drive.google.com/file/d/1TcCjHeiCK9VOwkh53501Lgu7cdhT7MCu/view?usp=sharing

Another simpler demo would be to replicate the shape of, for example, a Fast Fade curve with a Manual curve and then see the difference.

Also this is not a bug. In the first keyframe you have set the splin line to something like 30 or 40 degree, so a gradient that generates the form of the curve.

But the normal start Position of the splin line is in the horizontal - so 0 degree. You see that if you change the first keyframe back to "smooth fade" and then back to "manual" or "split manual".

The only point that is missing here in the GUI of the filter is that we have no sliders where we can adjust the splin line. But that would make the GUI more complicated - because what would be necessary is the gradient for both sides of the splin line (with "split manual" that can be different) and the length of both sides of the splin line (with "split manual" the lenght can be different).

So that is not a bug really. What we see here is that this function is complicated and one needs some training and tests to understand the mathematical concept behind the splin lines.

Desktop: PC AMD 3960X, 24x3,8 Mhz * GTX 3080 Ti (12 GB)* Blackmagic Extreme 4K 12G * QNAP Max8 10 Gb Lan * Resolve Studio 18 * Edius X* Blackmagic Pocket 6K/6K Pro, EVA1, FS7

Laptop: ProArt Studiobook 16 OLED * internal HDR preview * i9 12900H with i-GPU Iris XE * 32 GB Ram) * Geforce RTX 3070 TI 8GB * internal HDR preview on the laptop monitor * Blackmagic Ultrastudio 4K mini

HDR monitor: ProArt Monitor PA32 UCG-K 1600 nits, Atomos Sumo

Others: Edius NX (Canopus NX)-card in an old XP-System. Edius 4.6 and other systems

NickHope wrote on 4/25/2018, 5:04 AM

Could you share a sample project?...

@Marco. Link was in my comment above. https://drive.google.com/file/d/1TcCjHeiCK9VOwkh53501Lgu7cdhT7MCu/view?usp=sharing

Another simpler demo would be to replicate the shape of, for example, a Fast Fade curve with a Manual curve and then see the difference.

Also this is not a bug. In the first keyframe you have set the splin line to something like 30 or 40 degree, so a gradient that generates the form of the curve.

But the normal start Position of the splin line is in the horizontal - so 0 degree. You see that if you change the first keyframe back to "smooth fade" and then back to "manual" or "split manual".

The only point that is missing here in the GUI of the filter is that we have no sliders where we can adjust the splin line. But that would make the GUI more complicated - because what would be necessary is the gradient for both sides of the splin line (with "split manual" that can be different) and the length of both sides of the splin line (with "split manual" the lenght can be different).

So that is not a bug really. What we see here is that this function is complicated and one needs some training and tests to understand the mathematical concept behind the splin lines.

This is the Fast Fade curve:

This is the Manual curve. It's almost identical to the Fast Fade curve:

At the cursor position, the luminance with the Fast Fade curve is RGB 166:

At the same position, the luminance with the Manual curve is RGB 61:

You think that's OK?

Marco. wrote on 4/25/2018, 5:34 AM

I think Nick's sample shows a bug. I tweaked that project file a little bit to make the two curves even more identical but in a certain range the values drift apart a lot which should not be the case. If you have same curves with same keyframe positions there should be no difference in the result.

matthias-krutz wrote on 4/25/2018, 7:06 AM

I have once again created a sample project in VP15. I used the visually easy to estimate rotation.

 

Desktop: Ryzen R7 2700, RAM 32 GB, X470 Aorus Ultra Gaming, Radeon RX 5700 8GB, Win10 2004

Laptop: T420, W10, i5-2520M 4GB, SSD, HD Graphics 3000

VEGAS Pro 14-18, Movie Studio 12 Platinum, Vegasaur, HOS, HitfilmPro

Wolfgang S. wrote on 4/25/2018, 7:22 AM

 

This is the Fast Fade curve:

This is the Manual curve. It's almost identical to the Fast Fade curve:

Nick, for sure there are splin lines set in the second graph that you do not Show. Make a click to the keyframe and have a look how the splin line looks like. For sure they do not have a gradient of zero.

And that means simply that the settings are wrong if you wish to have a smooth curve.

And yes, that is ok.

 

Desktop: PC AMD 3960X, 24x3,8 Mhz * GTX 3080 Ti (12 GB)* Blackmagic Extreme 4K 12G * QNAP Max8 10 Gb Lan * Resolve Studio 18 * Edius X* Blackmagic Pocket 6K/6K Pro, EVA1, FS7

Laptop: ProArt Studiobook 16 OLED * internal HDR preview * i9 12900H with i-GPU Iris XE * 32 GB Ram) * Geforce RTX 3070 TI 8GB * internal HDR preview on the laptop monitor * Blackmagic Ultrastudio 4K mini

HDR monitor: ProArt Monitor PA32 UCG-K 1600 nits, Atomos Sumo

Others: Edius NX (Canopus NX)-card in an old XP-System. Edius 4.6 and other systems

lan-mLMC wrote on 4/25/2018, 7:23 AM

Quite surprising that this bug doesn't seem to have been mentioned before. I guess most users are happy with the standard curve shapes. I've never used a manual curve.

I just want adjust parameter by  Keyframe curve to get the very smooth motion effects.

just like what after effects 's keyframe curve can do.

@lan-mLMC If it worked correctly, the curve shape in your 2nd picture link would give an "overshoot" in motion and the picture-in-picture would "bounce back" to the final position at the end of the animation. Is that really what you want?

Yes,what you said is what I want. I want the parameter value to follow the curve accurately but obviously it dosen't.

lan-mLMC wrote on 4/25/2018, 7:28 AM

In ProType Titler we can see how it should work, I think.

Quite surprising that this bug doesn't seem to have been mentioned before. I guess most users are happy with the standard curve shapes. I've never used a manual curve.

The faulty behavior was the reason why I did not take it.

Very nice! In ProType Titler the curve work very normally, but same or similar curve can't work normally in OFX.

Wolfgang S. wrote on 4/25/2018, 7:31 AM

Nick, here you go. You will see the difference in the splins used:

http://www.mediafire.com/file/uu4ofaw4lx6otms/splin_ohne_Anstieg.JPG

http://www.mediafire.com/view/ytql8hbe2hg8auo/spline_mit_Anstieg.JPG

Last changed by Wolfgang S. on 4/25/2018, 7:37 AM, changed a total of 2 times.

Desktop: PC AMD 3960X, 24x3,8 Mhz * GTX 3080 Ti (12 GB)* Blackmagic Extreme 4K 12G * QNAP Max8 10 Gb Lan * Resolve Studio 18 * Edius X* Blackmagic Pocket 6K/6K Pro, EVA1, FS7

Laptop: ProArt Studiobook 16 OLED * internal HDR preview * i9 12900H with i-GPU Iris XE * 32 GB Ram) * Geforce RTX 3070 TI 8GB * internal HDR preview on the laptop monitor * Blackmagic Ultrastudio 4K mini

HDR monitor: ProArt Monitor PA32 UCG-K 1600 nits, Atomos Sumo

Others: Edius NX (Canopus NX)-card in an old XP-System. Edius 4.6 and other systems

NickHope wrote on 4/25/2018, 7:34 AM

Quite surprising that this bug doesn't seem to have been mentioned before. I guess most users are happy with the standard curve shapes. I've never used a manual curve.

I just want adjust parameter by  Keyframe curve to get the very smooth motion effects.

just like what after effects 's keyframe curve can do.

@lan-mLMC If it worked correctly, the curve shape in your 2nd picture link would give an "overshoot" in motion and the picture-in-picture would "bounce back" to the final position at the end of the animation. Is that really what you want?

Yes,what you said is what I want. I want the parameter value to follow the curve accurately but obviously it dosen't.

OK. Well seeing as the manual curve doesn't seem to be working properly without an overshoot, I don't see it working correctly with the overshoot any time soon. So unfortunately I think you'll have to "fudge" the behaviour you want by using more keyframes and experimenting with the standard curves.

lan-mLMC wrote on 4/25/2018, 7:44 AM

Quite surprising that this bug doesn't seem to have been mentioned before. I guess most users are happy with the standard curve shapes. I've never used a manual curve.

I just want adjust parameter by  Keyframe curve to get the very smooth motion effects.

just like what after effects 's keyframe curve can do.

@lan-mLMC If it worked correctly, the curve shape in your 2nd picture link would give an "overshoot" in motion and the picture-in-picture would "bounce back" to the final position at the end of the animation. Is that really what you want?

Yes,what you said is what I want. I want the parameter value to follow the curve accurately but obviously it dosen't.

OK. Well seeing as the manual curve doesn't seem to be working properly without an overshoot, I don't see it working correctly with the overshoot any time soon. So unfortunately I think you'll have to "fudge" the behaviour you want by using more keyframes and experimenting with the standard curves.

OK. Hopefully it will be fixed later.

NickHope wrote on 4/25/2018, 7:51 AM

I'll report it via a support request and report back any response.

Marco. wrote on 4/25/2018, 8:22 AM

"In ProType Titler the curve work very normally, but same or similar curve can't work normally in OFX."

ProType Titler's interpolation curve and OFX interpolation curve are different types of curves which you can't compare. Even with the given issue fixed for OFX curves it would not behave same like ProType Titler's does.

Wolfgang S. wrote on 4/25/2018, 8:22 AM

Funny that you guys think that that is a bug - if it is an adjustment done by the user.

Desktop: PC AMD 3960X, 24x3,8 Mhz * GTX 3080 Ti (12 GB)* Blackmagic Extreme 4K 12G * QNAP Max8 10 Gb Lan * Resolve Studio 18 * Edius X* Blackmagic Pocket 6K/6K Pro, EVA1, FS7

Laptop: ProArt Studiobook 16 OLED * internal HDR preview * i9 12900H with i-GPU Iris XE * 32 GB Ram) * Geforce RTX 3070 TI 8GB * internal HDR preview on the laptop monitor * Blackmagic Ultrastudio 4K mini

HDR monitor: ProArt Monitor PA32 UCG-K 1600 nits, Atomos Sumo

Others: Edius NX (Canopus NX)-card in an old XP-System. Edius 4.6 and other systems

Marco. wrote on 4/25/2018, 8:29 AM

But why should same keyframes and identical curve output different values? I'd agree if there are differences in the curves or if the values would differ just a bit, but even with a precise conformance of both curves the values differ a lot. Makes no sense to me.

lan-mLMC wrote on 4/25/2018, 9:06 AM

But why should same keyframes and identical curve output different values? I'd agree if there are differences in the curves or if the values would differ just a bit, but even with a precise conformance of both curves the values differ a lot. Makes no sense to me.

That means the keyframe curve for OFX in VEGAS is designed  imperfectly. I hope it will work well like what in After Effects.