VidSync News

This update includes just minor but useful bug fixes. The annoying starting position of the floating synced-playback control panel has been fixed (it should now start in the top left corner of the screen as intended). More importantly, a recently introduced bug that was causing the program to hang for 2 to 15 seconds or so during certain tasks in certain videos has been fixed. These include resizing videos, calculating calibrations, and sometimes measuring points.

I just posted another update with a minor improvement (version 1.64) over the big upgrades posted a couple weeks ago. Specificically, I changed the "reprojection error" reported for 3-D points to reflect the root mean square difference, across all cameras, between the input screen positions of a 3-D point and the expected screen positions based on back-calculating from the measured 3-D position. The previously reported reprojection error was the root of the sum of these squared differences (instead of the mean square), which reflected the same information but did not have the same intuitive meaning.

The consequence of this change is that reported reprojection errors will all be a bit smaller than they were before. This doesn't mean the measurements got more accurate; it's just a better error estimate. And I would stress that both the reprojection error and the PLD error are not indicators of real measurement error (with which they are only loosely correlated). Instead, they are primarily diagnostics to help pinpoint major calibration issues or mis-clicks during measurement.

This change only automatically affects new measurements. Old measurements will show their previous reprojection errors unless you recalculate the calibration on one of the videos, which forces all points to be recalculated.

VidSync is often used in rivers to study the behavior of fish from a stationary camera position, and it can be useful to characterize the water velocity in the region being observed — to measure which way is downstream, how fast it's flowing, or even characterize the velocity in specific locations within the region. One way to do this with VidSync is to measure the motion of small, neutrally buoyant tracers, such as natural debris particles. On the Drift Model Project, we've found that well-soaked Israeli cous cous thrown into the river several meters upstream produces a good number of highly visible, biodegradeable tracers. 

But how many of these tracers do we need to accurately characterize the velocity at a site? Using data from the above project in which we digitized trajectories of 100 particles in each of three sites on three different rivers, I ran some randomization tests to see how many tracers we needed to approximate the "true" velocity, which was assumed to be the mean velocity of all 100 tracers.  Of course, there is no single true velocity: the current at each site really does vary constantly, both over time and at different locations within the observation region. But it is nevertheless useful to figure out how many tracers are required to get an estimate that characterizes the habitat fairly well. This characterization includes both the magnitude (current speed) and direction of the mean velocity vector.

The randomization tests involved drawing a number of tracer vectors from the full set of 100 vectors with replacement, averaging them, and comparing them to the overall average of  the original 100. The results below show the "error" (absolute difference between the randomized measurement and the "real" 100-tracer measurement) in both current speed (left column) and angle (right column) for random samples ranging from 5 to 100 tracers at three sites in different streams. The black line is the mean error and 95 % confidence band is shaded in gray.

 For this study we decided to go with 40 tracers per site, which can be digitized pretty quickly and are adequate to stabilize our estimates at values very close to the larger-sample average of 100 tracers.

In the few days after making 1.60 public, I made some improvements that were worth putting out as a new version quickly. Here's what's new in 1.63:

• I improved the distortion correction algorithm substantially by (1) adding four more high-order radial and one higher-order tangential term term to the underlying model, which especially helps with extremely wide fisheye lenses but slightly improves accuracy across the board, and (2) improved the cost function and numerical minimization algorithm that find the distortion parameters. The previous distortion correction was already pretty good, so there's no rush to redo previous analyses, but there should be some slight improvements to accuracy, especially in highly distorted footage.
• Added diagnostics for the distortion model, and a page on this wiki describing the model and the meaning of the diagnostics, which are visible just below the distortion model parameters in the VidSync interface.
• Added the ability to select whether to see all distortion lines on the screen (while on the distortion tab) or just the ones on the current timecode. This makes it manageable to gather plumblines from multiple different frames in the same video and maximize input to the distortion model. This is rarely if ever necessary, but it's good to have the option.
• Added an automatic calculation of "distance to the nearest camera" for all 3-D points, which shows up in the points list on the measurement tab as well as in the spreadsheet and XML data exports.
• Added buttons to reset just the front face or back face of the calibration frame, not just both at once. This makes it possible to correct user mistakes during calibration (such as accidentally clicking on a bunch of the wrong points) by redoing the face that was messed up, without having to redo both of them.
• Added a "tally" button to the measurement interface that pops up a running list of the number of events for each type under a given object (for example showing the number of length measurements and foraging maneuvers for a particular fish, etc). 
• Fixed a bug in the distortion correction display that was causing the final, straightened lines to always appear perfectly straight. Previously, it was actually just showing a straight line between the endpoints of each corrected plumbline. Now it shows both the actual corrected plumbline and a striaght line between the endpoints as a reference to indicate how much distortion remains. 
• Updated the entire project to use the same permissive, open-source license (the MIT license) instead of a hodgepodge of outdated default copyright notices.

 

For anyone curious about the difference in mathematical methods between VidSync and its predecessor, I've written up a short page graphically comparing VidSync's method to the method of Hughes and Kelly (1996).