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

[Ichthyostega]

Hello Sergey,

just answering right away, but please take your time; lets continue
this discussion some days ahead, when you've gotten a chance to read
the code....


Am 08.06.2014 17:26, schrieb Sergey Sharybin:
> 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).

yes it is.


> It probably wasn't an issue since changing proxy is likely invalidates 
> stabilization model.

When you change the proxy settings, Blender throws away all your automation
data on 2D related stuff. (I was lucky to have checked in my test scene
into git). We should investigate that; user might spend hours to set up
that automation.

But you can still have several instances of the MovieClipEditor in your
workspace with varying proxy settings, but using the same stabilisation
data. This was what caused the confusion (and miscalculation) in my case,
some invocations got a different image size.


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

In the long run, I learned to prefer a clear separation of concerns
and clearly logical definition over "convenience" of working with values.
If another programmer can't understand the meaning of values,
chances are that s/he'll misinterpret them.

And the combination of canvas height, weight, aspect ratio and pixel aspect
ratio, together with scaling for display is just notoriously complicated and
confusing.


So yes, we should change the existing interface and turn the translation
vector (and a pivot to be added) into normalised coordinates. Maybe we can
even remove the matrix entirely from the public BKE_* functions and turn
it into an implementation detail?


And another point: right now, the translation is *output* in pixel space
(we want to change this), but internally translation values are passed on
as normalized to [0..1].
IMHO, they should rather be normalised with respect to the canvas height.
Because of aspect ratio, you can't do any angular calculations with these
normalised values, which makes the code unnecessary complicated (you need
to pass height and aspect down into the last implementation function).


Cheers,
Ichthyo