<div dir="ltr">Hi,<div><br></div><div>Nice to hear someone finally goes solving stupidness of the current 2D stabilizer.</div><div><br></div><div>Didn&#39;t check the code but ideas seems indeed much better than the current ones. Would be cool to see them in action. Do you have some videos which you can show to Sebastian and Sean? :)</div>
<div><br></div><div>Also, do you mind putting the patch to the review at <a href="http://developer.blender.org">developer.blender.org</a>? Easiest way to do it is to use arcanist [1]. This way we can start check on the code and probably point into some better solutions there. Doing early code review always helps.</div>
<div><br></div><div>It&#39;ll also make it so more users can apply the patch and play around with it.</div><div><br></div><div>Also, just for the ideas, you might also consider using information from 3D solver and do some sort of frame re-projection into a camera after applying some momentum to it (applying some sort of low-pass filter on the camera trajectory).</div>
<div><br></div><div>Now, about some questions you&#39;re raising:</div><div><br></div><div>- Not sure why animated weight is not applied in compositor. It should work just fine, seems i&#39;ll need to have a closer look into the code. And yes, it&#39;s not editable in animation editors. This is something to implement still.</div>
<div><br></div><div>- Compensating distortion -- that&#39;s a separate topic which is currently being handled by either runtime frame undistortion or building undistorted proxy. I don&#39;t think dealing with this should be a part of 2D stabilization.</div>
<div><br></div><div>- As for other lens effects which you might want to compensate is the rolling shutter. But that&#39;s completely separate topic as well. We don&#39;t deal with this in the solver pipeline and dealing with this is rather a tricky business. You need to be very careful choosing what you&#39;re gonna to do with this in order to preserve solvability of the footage.</div>
<div><br></div><div>And i agree, better to stop adding features, wrap up current improvements and continue doing improvements when current ones are in the master branch. For this it&#39;ll help having the patch in the code review tool as was mentioned above. Assign me (i&#39;m &quot;sergey&quot; in the developer.b.o) as a reviewer there and i&#39;ll have a closer look.</div>
<div><br></div><div>[1] <a href="http://wiki.blender.org/index.php/Dev:Doc/Tools/Code_Review#Use_Arcanist">http://wiki.blender.org/index.php/Dev:Doc/Tools/Code_Review#Use_Arcanist</a></div></div><div class="gmail_extra"><br>
<br><div class="gmail_quote">On Thu, Jun 5, 2014 at 7:55 AM, Sean Kennedy <span dir="ltr">&lt;<a href="mailto:mack_dadd2@hotmail.com" target="_blank">mack_dadd2@hotmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



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