<div dir="ltr">Guess you're talking about runtime-evaluated stabilization matrix. it might indeed be in pixel space (i'm not really sure from the top of my head). It probably wasn't an issue since changing proxy is likely invalidates stabilization model. Need to check code for this.<div>
<br></div><div>For runtime stuff we can store pixels space (if it's more convenient to work with). For this i don't see the issue..It's just matter of storing of "persistent" data (like pivots, principals and so) in the normalized space.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jun 8, 2014 at 9:23 PM, Sergey Sharybin <span dir="ltr"><<a href="mailto:sergey.vfx@gmail.com" target="_blank">sergey.vfx@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Yes, you can have stuff stored internally in normalized coords and visualize it in a pixel space. Kind of the same happens with rotation anyway -- it's degrees in the interface and radians internally. Would probably need to do some tweaks to fcurve scaling...<div>
<br></div><div>A for shear/trapecoid -- i'm not really sure what's that. Artifact caused by the rolling shutter?</div><div><br></div><div>Caching you'd probably want to re-work anyway. Currently it's caching single frame only and stores stabilization matrix in the cache to see whether frame is to re-stabilized. For the first time the same thing is gonna to work i guess? Hash i don't really think would work, thinking storing data which is used to transform original frame to a stable one (matrix, decoupled transformation elements whatever else) is what's more robust here.</div>
<div><br></div><div>Anyway, can you give me tomorrow (tuesday max) to look into the patch and to get into topics you're talking about in more details? Things are a bit crazy here with preparing the release. Meaning, need to have some bigger picture in head in order to give really useful suggestions..</div>
<div><br></div></div><div class="gmail_extra"><div><div class="h5"><br><br><div class="gmail_quote">On Sun, Jun 8, 2014 at 9:12 PM, 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">Am 08.06.2014 15:25, schrieb Sergey Sharybin:<br>
<div>> internally all the stabilization values are to be stored in normalized<br>
> [0..1] space in order to be re-applied for the proxied movie. For the<br>
> interface they might be relatively easily converted to pixel space.<br>
<br>
</div>of course, but can you then animate (add keyframes) on those values displayed<br>
in pixel space, yet still have the data in the keyframe in normalised coords?<br>
<div><br>
> Wouldn't mind having feedback from Sebastian as well.<br>
<br>
<br>
</div>IMHO this topic is of some relevance, because -- if we want to do things<br>
properly -- the pivot point must become part of the stabilisation data.<br>
Otherwise we will never get a clean design, esp. when it comes to nodes.<br>
<br>
The part *applying* the transformation must be (and is indeed currently)<br>
separate from the part which *measures* the stabilisation data. Thus<br>
the whole data feed needs to be explicit.<br>
<br>
Right now we have (translation[2], angle, scale)<br>
<br>
What we need at least is (translation[2], pivot[2], angle, scale)<br>
As extension, we could consider to add a shear / trapezoid component,<br>
simply because these are the missing parts to complete an affine-linear<br>
transformation.<br>
<br>
I fully agree with you that we do not want to compensate lens distortions.<br>
But these shear/trapezoid movements are not due to lens errors, but due<br>
to perspective and tilting of the camera. If you want to do masking and<br>
rotoscoping, then for sure you want those shear/trapezoid movements<br>
compensated to. If you go just for a stabilised image, these remaining<br>
movments are quite annoying too<br>
<br>
<br>
A nasty concern regarding the components in the stabilisation data is<br>
that they are used as cache key. We should reconsider this part too,<br>
maybe change the cache to store just a hash of the parameters?<br>
<br>
Cheers,<br>
Hermann<br>
<div><div><br>
<br>
<br>
<br>
_______________________________________________<br>
Bf-vfx mailing list<br>
<a href="mailto:Bf-vfx@blender.org" target="_blank">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></div></div><div class="">-- <br><div><span style="color:rgb(102,102,102)">With best regards, Sergey Sharybin</span></div>
</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>