[Bf-vfx] Improving the 2D stabilization tool :: Next Steps

[Sergey Sharybin]

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...

A for shear/trapecoid -- i'm not really sure what's that. Artifact caused
by the rolling shutter?

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.

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..



On Sun, Jun 8, 2014 at 9:12 PM, Ichthyostega <prg at ichthyostega.de> wrote:

> Am 08.06.2014 15:25, schrieb Sergey Sharybin:
> > 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.
>
> of course, but can you then animate (add keyframes) on those values
> displayed
> in pixel space, yet still have the data in the keyframe in normalised
> coords?
>
> > Wouldn't mind having feedback from Sebastian as well.
>
>
> IMHO this topic is of some relevance, because -- if we want to do things
> properly -- the pivot point must become part of the stabilisation data.
> Otherwise we will never get a clean design, esp. when it comes to nodes.
>
> The part *applying* the transformation must be (and is indeed currently)
> separate from the part which *measures* the stabilisation data. Thus
> the whole data feed needs to be explicit.
>
> Right now we have (translation[2], angle, scale)
>
> What we need at least is (translation[2], pivot[2], angle, scale)
> As extension, we could consider to add a shear / trapezoid component,
> simply because these are the missing parts to complete an affine-linear
> transformation.
>
> I fully agree with you that we do not want to compensate lens distortions.
> But these shear/trapezoid movements are not due to lens errors, but due
> to perspective and tilting of the camera. If you want to do masking and
> rotoscoping, then for sure you want those shear/trapezoid movements
> compensated to. If you go just for a stabilised image, these remaining
> movments are quite annoying too
>
>
> A nasty concern regarding the components in the stabilisation data is
> that they are used as cache key. We should reconsider this part too,
> maybe change the cache to store just a hash of the parameters?
>
> Cheers,
> Hermann
>
>
>
>
> _______________________________________________
> Bf-vfx mailing list
> Bf-vfx at blender.org
> http://lists.blender.org/mailman/listinfo/bf-vfx
>



-- 
With best regards, Sergey Sharybin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-vfx/attachments/20140608/6c3ef2bb/attachment.htm