<div dir="ltr">internally all the stabilization values are to be stored in normalized [0..1] space in order to be re-applied for the proxied movie. For the interface they might be relatively easily converted to pixel space.<div>
<br></div><div>I didn't have much time to look into the patch yet, so not sure what is the exact reasoning for this. It might some some other approaches as well...</div><div><br></div><div>Wouldn't mind having feedback from Sebastian as well.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jun 8, 2014 at 8:34 AM, Ichthyostega <span dir="ltr"><<a href="mailto:prg@ichthyostega.de" target="_blank">prg@ichthyostega.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">> Am 05.06.2014 08:10, schrieb Sergey Sharybin:<br>
>> - Not sure why animated weight is not applied in compositor. It should<br>
>> work just fine, seems i'll need to have a closer look into the code. And<br>
>> yes, it's not editable in animation editors. This is something to<br>
>> implement still.<br>
<br>
> I have investigated that a bit more. I added a movie clip editor to the<br>
> Compositor screen. In the MCE, I can see the animated target position and<br>
> track weight properties.<br>
<br>
> But strange enough, neither the MCE view, nor the backdrop in compositor<br>
> shows the effect of those target position parameters. When I switch to the<br>
> tracking screen, on the same frame the effect of these parameters is<br>
> visible.<br>
<br>
<br>
</div>Looks like I could clarify that behaviour: it was NOT a problem with automation.<br>
Automation works fine, in MCE, sequence editor, compositor and final output.<br>
<br>
<br>
After a lot of poking around with the debugger in the datastructures, I<br>
found that the instance of the MCE I was using to set up the automation<br>
had -- by accident -- the proxy settings enabled. While other instances<br>
of the MCE and the video sequencer worked with the full size.<br>
<br>
Now, since the position stabilisation itself is calculated in normalised<br>
coordinates, while of course the target position in the GUI uses absolute<br>
coordinates, the automation values don't give the correct result for another<br>
canvas size -- and I misinterpreted that as if the automation wasn't working<br>
at all.<br>
<br>
Conclusion: should probably redefine the target position settings to use<br>
relative values too. Meaning +1 == shift by a full image width (or height).<br>
<br>
This is probably less intuitive for the user -- but is there any other way<br>
around that problem? That is: can we somehow display absolute values in the GUI,<br>
yet have relative values in the DNA and Blender will set Keyframes in terms<br>
of the relative values??<br>
<br>
Cheers,<br>
Ichthyo<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
<br>
<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>
</div></div></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>