Tracker Video Analysis and Modeling Tool tested

On Friday in our physics lab, we tested using Tracker Video Analysis and Modeling Tool for Physics Education from Cabrillo College, the local community college.  We’re using version 4.50 which seems to work much better than the version I tried months ago, when I first heard about the tool.

I ran into some trouble with the autotracking with the .MTS files (AVCHD 1080i format) from my Everio HD camera, so I e-mailed the developer (Doug Brown) and asked for advice.  I also suggested that the program should recognize the .MTS extension and handle the interlaced image as a 59.94 fps at half the resolution, instead of 29.97 fps.  He responded that there is a way to use only the odd or even frames (though not both to get double the sampling rate, though he’ll look into that).

The trick is to use the Deinterlace filter (Video|Filters|New|Deinterlace menu).  You can specify to use either the odd half frames or the even half frames.  When I did that with the clips we recorded on Friday, it helped a bit, but not as much as I hoped.

I tried re-recording a clip today, using less compression on the camera (uXP instead of XP).  The clip I produced this way has only minor interlacing artifacts left when using the odd or even half frames. There is still considerable elongation of the ball in the image, which may be due to insufficient light and a long exposure time. The acceleration readings were much more nearly constant in the new clip (except during four or five frames around the contact with the floor) than before, but there still was a consistent droop in acceleration, which I attribute to drift in the tracking—the edge of the ball shifted gradually in the image being searched for.

I also tried manually marking the ball’s position, which worked somewhat better than the autotracker.  The calculation of acceleration still shows artifacts around the bounce, with the very brief but large acceleration from the collision spread out over 150 msec.  Doing a better job of that would require that the Tracker software try fitting a more sophisticated model—one that assumes nearly constant acceleration with occasional very large impulses, rather than smooth changes in acceleration.  The position data is pretty clean, so it should be possible to model the bounce and try to fit a constant acceleration plus big spike model to the data, with free parameters being the time and magnitude of the spike.   The time would have to be specified at much less than the frame rate: perhaps to the nearest millisecond. I think that this sort of fitting may be a bit much for my students to do efficiently, but they might be able to a manual fit or a brute force search.

I should try again with a bright light on the ball.  I should also try a dark ball on a light background, which may work better (more light means that the auto exposure may integrate over a shorter time).  So for future motion capture, we’ll want to use as little compression as possible, and deinterlace the video, and I may want to use dark-on-light instead of light-on-dark.  We’ll also probably want to do our own extraction of velocity or acceleration, to avoid artifacts around collisions.