[Bf-vfx] Improving the 2D stabilization tool :: Demo Video

Sebastian König sebastiankoenig at posteo.de
Sat Aug 23 04:23:38 CEST 2014


Hey!
I didn’t follow that closely yet, but found the video quite interesting! So yesterday I built with the patch and it works quite well. I think the workflow can be improved still, but I should test a bit more for that. The thing that is really nice is to be able to „counteranimate“ the expected location, which I believe would also be what you’d do in other compositing apps (that have a „canvas“). Since we don’t have a canvas in compositor yet, your approach seems reasonable and the clip editor also seems like a good place for that. UI wise it would be nice to have some kind of handle for that. Maybe when using stabilization it could just have a point to grab and move, just as with the new tweaking center for masks?
But yeah, I should test this a bit more when I find the time. 
Nice work so far, and thanks for putting your time into this!

Cheers,

Seb
 
-- 
Sebastian König
Körnerstraße 28
04107 Leipzig
Germany
sebastiankoenig at posteo.de
www.blendFX.com
www.3dzentrale.com

Am 22. August 2014 bei 00:26:05, Sean Kennedy (mack_dadd2 at hotmail.com) schrieb:

That's all very exciting! Glad to hear you have ideas and intentions to keep improving it. :)


> Date: Thu, 21 Aug 2014 03:25:54 +0200
> From: prg at ichthyostega.de
> To: bf-vfx at blender.org
> Subject: Re: [Bf-vfx] Improving the 2D stabilization tool :: Demo Video
>
> On 21.08.2014 01:19, Sean Kennedy wrote:
> > I was up in Vancouver at Siggraph last week, so I've only gotten a chance to
> > watch this video today.
>
> > Really nice! Very impressive work, and Blender has definitely been needing
> > some kind of scaling stabilization since stabilizing was introduced.
> > I'd love to see these tools get into trunk. It's great that you took some
> > good, real world video to demo on, video with all the problems typical
> > stabilization projects run in to.
>
> thanks, I really appreciate your understanding, and indeed, the real-world usage
> situation can be rather insidious at times. Doing this example showed me that
> it is possible to get acceptable results with what I've implemented thus far,
> which makes me think it's the right moment to aim for review and inclusion
> of this version, to get it in the hands of more people.
>
> But it also showed me that the process is still laborious and the tool could
> support the process of stabilising footage better in several ways; I'd like to
> follow up on these, while I really hope to get more feedback to shape those
> next ideas. To some degree, modest additional "automagic" could help, but I am
> reluctant to engage in developing an elaborate automatic algorithm which turns
> out to be not so helpful when put under real-world stress.
>
> Bjorn (sunboy) commented already on the review page, and I will definitively
> have a closer look into his add-on; a lowpass looks like one of these ideas
> to be explored further -- a physical steadycam is likewise some kind of a
> lowpass after all
>
>
> > Are the keyframes you set in the Expected position tool panel viewable in the
> > curve editor? I imagine they are, just want to make sure.
>
> In theory yes. In practice no.
> Let me explain. The animation system of blender is entirely generic, thus you
> can animate (almost) all parameters found in the data blocks making up a blender
> scene. Thus, if we use a persistent parameter and hook it up into the GUI, you
> can press the "I" key and animate it through keyframes.
>
> In fact, this system turns out to be more generic than what the GUI for
> animation curve editing assumes. Meaning that this curve editor and animation
> sequence handling makes some seemingly innocuous assumptions as to *where*
> the animation data is attached -- and these turn out to be too limited.
> Thus, if you have animation data attached to a property which belongs directly
> to the 3D model, then the animation editor can find this data by descending
> top level into the current scene. Unfortunately, our animation data is attached
> to the post processing stages of the output graph (more precisely, to the
> movie clip editing data) and from the looks the current setup of the
> animation editors simply don't have this possibility "on the radar"
>
> I haven't investigated that problem yet (and I'd appreciate any hint of the
> more experienced blender coders); but off the top of my head, I can't see
> why this should not be doable.
>
> Cheers,
> Hermann
> (Ichthyo)
>
> _______________________________________________
> Bf-vfx mailing list
> Bf-vfx at blender.org
> http://lists.blender.org/mailman/listinfo/bf-vfx
_______________________________________________  
Bf-vfx mailing list  
Bf-vfx at blender.org  
http://lists.blender.org/mailman/listinfo/bf-vfx  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-vfx/attachments/20140823/4d244c1b/attachment.htm 


More information about the Bf-vfx mailing list