<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>I just read over everything pretty quickly, and it sounds very promising! I too have tried to use stabilization in a production environment and found it slightly lacking. A long time ago (maybe a year?) I was pestering a certain developer (one I pester a lot!) about why there isn't a stabilize scale option. Seems to make sense there should be one since there's already position and rotation. But anyway... what I really wanted to comment on was the idea of a pivot point. This would be SO useful, having access to a definable pivot point in the compositor. It's almost necessary when doing common compositing things like removals and replacements. I don't know about the idea of a "dynamically calculated" pivot point, if that means it's going to be moving around a lot and animating itself. That could present some issues in a compositing environment where a pivot point is useful.<div><br></div><div>Great ideas, though! Glad to see stabilization getting some love!</div><div><br></div><div>Sean<br><br><div>> Date: Thu, 5 Jun 2014 02:58:54 +0200<br>> From: prg@ichthyostega.de<br>> To: bf-vfx@blender.org<br>> Subject: [Bf-vfx] Improving the 2D stabilization tool<br>> <br>> -----BEGIN PGP SIGNED MESSAGE-----<br>> Hash: SHA1<br>> <br>> Am 04.06.2014 11:49, schrieb Thomas Beck:<br>> > I really like your ideas that you're pushing forward. I read your <br>> > explanations on the github page and have to say that I found the current <br>> > stabilization sometimes frustrating too. As it was more or less a "plus" on<br>> > our projects I didn't care that much though.<br>> <br>> > To continue with your voyage, consider to subscribe to the BF-VFX list...<br>> <br>> <br>> Hello all,<br>> <br>> so let's move a more focussed discussion to the VFX-list.<br>> <br>> As mentioned in my initial post to BF-committers, I started looking into<br>> the implementation of Blender's 2D stabilisation tool, prompted by problems<br>> encountered when using this feature on my own footage. I found it surprisingly<br>> difficult to get the desired stabilisation result -- in fact to get any decent<br>> result at all, especially when the shot involves more elaborate camera and<br>> object movement, like travelling, panning and perspective changes.<br>> <br>> > 2014-06-02 7:27 GMT+02:00 Ichthyostega <prg@ichthyostega.de>:<br>> <br>> > You can find my code as a branch on top of current master <br>> > https://github.com/Ichthyostega/blender.git<br>> <br>> > Branch: stabilizer_rework<br>> <br>> > (note: you might want to skip the "[private]..." commits at start of the<br>> > branch; I am building on Debian-stable<br>> <br>> <br>> > I've written some notes (daft version) to the github wiki:<br>> <br>> > https://github.com/Ichthyostega/Blender/wiki<br>> <br>> > In the same github repo, there is a branch "stabilizer_demo" It contains a<br>> > blend file to check out my new features.<br>> <br>> <br>> <br>> Meanwhile I've finished an initial round of rework, which I'd like to present<br>> as starting point for discussion. With these changes, the original issues<br>> are resolved for me, but there remains some integration work, where I'd<br>> need some help.<br>> <br>> - - keyframes and animation on track weights and parameters of 2D stabilisation<br>> can be defined and play back as expected in MovieClipEditor, but can't be<br>> handled in the usual way for automation (NLA, F-Curves), nor does the<br>> animation work at all for playback in the compositor, sequence editor<br>> or final render.<br>> <br>> My guess is that a "movie clip" is not a scene object in the usual sense<br>> <br>> <br>> - - to combine autoscale (and further ideas for development) with such<br>> animated parameters, I'd need a way to "cue" the automation to other<br>> values than the current frame (and this in a subroutine which might<br>> be called e.g. for initialisation while in playback)<br>> <br>> <br>> - - also, I am not so familiar with the compositor nodes and I still have<br>> to find out how the final rendering is actually performed; I need to<br>> do the same modifications to the transformation function I did<br>> successfully to the display in the MovieClipEditor<br>> <br>> <br>> Beyond that, my approach of systematically summing up contributions to<br>> various parameter measurements opens some perspectives for further work:<br>> <br>> - - the problem with the pivot point, what options to offer?<br>> - - maybe include a solving for the pivot point? And if so, then globally,<br>> per single frame or per range of frames?<br>> - - in theory, the pivot point for zooming could be different to the<br>> one used to measure and compensate rotation. Not sure how noticeable<br>> the differences are we get when ignoring this distinction.<br>> <br>> - - a dynamically calculated pivot point would imply that this pivot point<br>> needs to be part of the "stabilisation data". This would mean to<br>> extend the public API and esp. it would mean to extend the compositing<br>> node to deliver this pivot information alongside with position, scale<br>> and rotation.<br>> <br>> - - the "autoscale" function is a nice idea, but in its current shape<br>> it is unusable in practice: Usually, it scales away almost everything.<br>> - - What would be needed is a dynamic autoscale, which could also get us a<br>> starting point for the target position / target rotation / target zoom<br>> setting automatically.<br>> - - to get that to work, my guess is that we'd need to build in some amount<br>> of damping. For example considering the current frame and the neighbouring<br>> frames, but use a simple window function (e.g. gaussian bell curve) to<br>> weight the neighbours.<br>> <br>> - - are there further parameter which could be measured and then compensated?<br>> In my experiments -- since the basic stabilisation works very well now --<br>> typically I saw a residual shearing movement, which is due to 3D perspective<br>> and possibly due to lens distortion. In theory, any systematic distortion<br>> or movement that can be modelled can be measured and compenstated<br>> <br>> - - BUT the glaring question is where to stop with adding features.<br>> A really good tool always requires some limitation and focus to<br>> the reasonable and typical patterns of usage.<br>> <br>> Any discussion, review, critique, thoughts and proposals appreciated<br>> <br>> <br>> Cheers,<br>> Hermann Vosseler<br>> (aka "Ichthyostega")<br>> <br>> <br>> <br>> <br>> <br>> -----BEGIN PGP SIGNATURE-----<br>> Version: GnuPG v1.4.12 (GNU/Linux)<br>> Comment: Using GnuPG with Icedove - http://www.enigmail.net/<br>> <br>> iEYEARECAAYFAlOPwM4ACgkQZbZrB6HelLI65QCgtJCR8tYsoulN6nKN4Q9RufgT<br>> WBEAn0qW+HB6vNXHKqJjuR8Glfnar/oA<br>> =LmW3<br>> -----END PGP SIGNATURE-----<br>> _______________________________________________<br>> Bf-vfx mailing list<br>> Bf-vfx@blender.org<br>> http://lists.blender.org/mailman/listinfo/bf-vfx<br></div></div> </div></body>
</html>