[Bf-vfx] Stabilizer: ideal usage

[Sean Kennedy]

An idea for implementing a "fade out" on Stab Weights (from 1 to 0, or a fade in from 0 to 1) could be to set a number of frames over which the fade out should occur, say 10 or 15 (input by the user), then just click Apply, and it does it automatically to any track that doesn't run the entire length of the shot, or that doesn't start or end on the first or last frame.


That could also be set up to just work on the selected tracks.


I did this manually to a long panning shot last night, fading between 5 tracks, and it worked very nicely.


Sean


________________________________
From: Ichthyostega <prg at ichthyostega.de>
Sent: Thursday, September 1, 2016 7:36 AM
To: Blender tracking and VFX list
Subject: Re: Stabilizer: ideal usage


...we're here already in the middle of an interesting discussion about
what is still lacking with the current state of the 2D stabilizer.

Thus I'd propose we'll move to the VFX mailing list, and I've
posted this response already there...

On 01.09.2016 07:11, Sean Kennedy wrote:
> Also, another question - is it possible to see the keyframes created when
> animating the Stab Weight in the dope sheet or graph editor?


No, and this is indeed one of the further topics on my todo list regarding
stabilization. If I understand the problem correct, the current implementation
in blender erroneously assumes that all animated properties live within the
3D scene. But in fact, Blender's animation system is completely generic,
and thus nothing prevents us from animating *any* property which is in
a data block and bound to the UI.

Thus here we're now happily animating values which are *not* part of the
3D scene, but rather somewhere in the postprocessing graph.

Thus, when you try to open and init a new dope sheet or F-curve editor,
Blender just misses those animation data -- in spite of them being there,
being persistent and working just fine when you actually "drive" the timeline.

as said -- this is my guess. I don't know actually, because if I knew, I had
probably fixed it already, since it is an annoyance in practice. :-D
> What about the "expected" tools, if those are keyframed, can we see the keys
> anywhere? I'm guessing we cannot. If we can, I couldn't find them.

same problem. Can't access them with the regular animation editors.


> Also, when animating the "expected" tools to compensate for the stabilized
> motion, is the curve applied to these keyframes a smooth curve or linear?

Again, I don't know. But I know that the moment you add animation to those
params, Blender creates a new F-curve behind the scenes. We know this because
the stabilizer explicitly fetches and evaluates these F-curves, in order to
work correct whenever it has to visit another frame than the "current" frame
for its calculations.

Thus probably it is just like the default behaviour for every F-curve


> And watching your original demo video again, Hermann, WOW. It must have
> taken a long time to animate all the Stab Weights on that footage!

It is manageable if you proceed in a systematic way. But yes, stabilizing such
an shot with extended movements does take some time.

Also I was thinking about possible ways how to support and speed up this task.
Unfortunately I am somewhat lacking inspiration here. The only thing I could
imagine is some operator, where you'll select two animation tracks (assumed
that we've managed to make them visible in the dope sheet) and then somehow
"cross-fade" them. That would be at least some support to speed up that
boring task, but even this is a bit of a challenge to specify it on
a technical level. What precise does "cross-fade" mean? What if those
two tracks have multiple overlapping intervals? What if more than two
tracks are selected?

-- Hermann


PS: in practice you do not need to cross-fade *all* irregular tracks,
    only those which cause a visible jump. Which typically is on the
    end facing away from the anchor frame, and also only if that
    track creates a specific "drag" which differs from the effect
    of the remaining tracks


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-vfx/attachments/20160901/e49ef373/attachment.htm