- User Since
- May 28 2014, 6:51 PM (281 w, 3 d)
Mar 23 2019
can't access your sample file -- but I kind of know that problem. I encounter it as unfortunate combination of circumstances.
Dec 25 2016
Oct 19 2016
Sep 27 2016
In addition to the text changes, this diff changes and adds some images. Since Subversion diff is unable to represent binary changes, I'll attach these images here
Aug 30 2016
At some point, I'd also need some additional advice how to prepare a draft for the user manual properly. In the developer docs, I only found the hint that I should prepare the text below my user page in the blender wiki. But to judge from the page source, the manual seems to use quite a different markup style than the wiki, and I couldn't find much additional info about it yet...
thanks for the notification.
Aug 23 2016
after some testing, tweaking and further investigations, the version (rBbaaa2 + rB9c3b9) currently in master changed the pivot point to follow the weight centre of the location tracks, instead of attaching it to the image centre. The pivot point is the reference point to detect rotation and scale against, and thus this change improves the behaviour especially in very simple situations. For example, if you add only a single (location) track, this location also becomes the pivot point. If you then add just one other marker as rotation track, the stabiliser will keep the relation between those two points fixed, and scale/rotate the image accordingly to do so.
Aug 15 2016
Bugfixes and clean-up in migration code
Thanks! Hadn't retested migration after the DNA cleanup, it was a bug to set this field to zero.
Aug 12 2016
Review: introduce per call private working data context
Aug 10 2016
Aug 7 2016
Aug 6 2016
We use now a GHash in a static variable in tracking_stabilize.c
In theory, there is a possible race on initialisation. I can't judge how relevant this could be in practice. It would probably require a concurrent call to BKE_tracking_stabilize_frame for two different movie clips.
Bugfix and clean-up
No working data in DNA - attach private data via GHash
Aug 5 2016
- rebased changeset against current master
- addressed the obious points from recent review (@Sergey Sharybin (sergey))
- remove any access to deprecated rot_track
- introduce dedicated field MovieTrackingTrack::weight_stab
Aug 4 2016
Aug 3 2016
Jul 11 2016
UI fixes as indicated by @Michael P. (forest-house)
Jul 10 2016
Jul 4 2016
an update / nag
Sean Kennedy @Sean Kennedy (hype) did a functionality review some time ago
Apr 23 2016
ah, I see.
You are using the patch created automatically by the arcanist tool we use here for review (which as such is fine).
I must have updated this tool some months ago (I guess so, when I upgraded my system to Debian/Jessie). arcanist comes from its own Git repo...
Apr 22 2016
Not sure where you got the "patch" from and what the problem with the format is all about. On Unix like systems, you'd typically use the --strip=1 option for the patch command.
Update my proposal, now rebased onto current master (2.77a)
Apr 19 2016
regarding the patchset, I've ported to 2.77, but then decided to wait for 2.77a, and will publish an update rebased on top of current master next days
Mar 31 2016
what can we do to bring that review ahead?
Nov 18 2015
Jul 17 2015
PPA for Ubuntu Vivid (15.04) -- might be helpful for some people to try it out
Jul 14 2015
This is essentially the same patchset as submitted last year,
with the addition of two bugfixes (pixel_aspect handling
and fix for a possible double free).
Jul 13 2015
Jul 2 2015
Incidentally, I am waiting since more than half a year for the continuation of the review. IMHO, I have addressed all the (valid) issues pointed out by Sergey on the initial review. Moreover, I've used this extesion a lot in production work, so I think it is more than ready to get it into the hands of the users.
Aug 14 2014
What I did is not a "textbook solution", but I consider the basic technique of stabilisation so simple that I'd hesitate to call it an "Algorithm". It is just a bit of simple vector math. (Of course we need to be careful to get the sometimes insidious details correct, like e.g. the non square pixels, or the wrap-around with trigonometric functions).
Also I'd like to stress the fact that I didn't write something entirely new here. Rather, I dissected the existing code, re-organised and generalised it. From there, I tried to base that on a more clear understanding of what we're doing here: in my understanding, actually we assume a somewhat simplified model of movement, and then we "fit" this model with the measurement data. My main focus is to use a model which is as simple as possible, while still yielding usable results in practice. (regarding background, yes I am not a beginner, I have experience as a user of media software, with editing sound and image, and know the production process "from the inside". And of course I have experience in engineering of editing and video software)