Zooming animations should be smoother

[Andrea Gualano]

Zoom (i.e. scale) is currently linearly interpolated, which gives a strange "non-linear" feeling to the animation.
What one would expect is (I think) geometric interpolation: i.e. the half point of the animation is zoomed by sqrt(scale).

[Andrea Gualano (andrea-gualano)]

Please note that this is not related to the overall linearity of the animation.
This means that a linear animation should have geometric zoom and a non-linear animation should use a composition of the two functions.

[Andrea Gualano (andrea-gualano)]

See for example the animation between the full image and the first step of test_images/rotations.svg

[Andrea Colangelo (warp10)]

I have just merged the branch from Daniele De Luca adding quadrating interpolation. Mind checking this patch? Does it address this bug? Should we rather implement a cubic interpolation?

[Andrea Gualano (andrea-gualano)]

No, they are two different issues.
One is the perceived speed of the animation: Daniele's patch addresses this issue by having a slow-fast-slow animation instead of the constant speed of the previous version.
A different issue is how you interpolate each variable to get a given percentage of the transition. The current interpolation of the zoom variables makes them look like zoom is moving faster (or slower, depending on direction) than the other variables.
There are in fact two separate interpolation functions in action: the first acts on time, to give you the desired animation speed; the other one acts on Region objects, to give you intermediate views.
The current trunk code merges the two steps in a single function. I have code on my experimental branch to separate them; I'd like to adapt the code for the current trunk ASAP.

[Andrea Gualano (andrea-gualano)]

Test image attached.
You can see that when moving from "0" to "5" it looks like the animation is accelerating (and decelerating in the reverse direction); this is exactly the artifact I was describing. The same can be seen animating from "0" to "9" and vice versa.
The error is clearer if you change the code in region.py line 125 to use "linear_interpolation", but I think with this presentation it should be visible even using the quadratic interpolator. This is because non linear stuff masks interpolation errors (which is a good thing in production code).