VidSync News

Another small update to 1.66

Jason Neuswanger Wednesday May 25, 2016
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.

Tiny update to 1.64

Jason Neuswanger Wednesday March 23, 2016

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.

Estimating water velocity from tracers measured in VidSync

Jason Neuswanger Thursday March 17, 2016

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.

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

  • «
  • 1 (current)
  • 2