predict.NearestVelocityPredict() does not link particles

[alexandermm]

Hi,

I followed the tutorial in: http://soft-matter.github.io/trackpy/v0.5.0/tutorial/walkthrough.html

I would like to use the velocity prediction function predict.NearestVelocityPredict() used here: http://soft-matter.github.io/trackpy/v0.5.0/tutorial/prediction.html

However when I run it, it does not link the recognized features. I am trying to use a speed of 4 pixels/frame in the downward direction.

The ipython notebook I am using can be found in: https://www.dropbox.com/s/k5gzeojsl6gpkyc/particle_stream_stats_short.ipynb?dl=0

The video that is used in the notebook is at: https://www.dropbox.com/s/ci1khn0tti4cg8i/bench_1_short.cine?dl=0

Thank you for your time, Alex

[nkeim]

Hi! Thanks for this question. How are you using the predictor? I don't see it in that notebook.

It sounds like you know your particles' approximate velocity in advance, and the motions are approximately uniform. For simplicity you might wish to implement the constant-velocity predictor in the first example, or to supply an initial guess to NearestVelocityPredict or DriftPredict. Just don't forget that typically, moving "down" in the movie is toward larger y coordinates. I recommend trying something like

pred = tp.predict.DriftPredict(initial_guess=(0, 4))
t = pred.link(...)

[alexandermm]

Hi Nathan,

Thank you for the help, I think I was using -4 for the speed before. I got the code to work with either of the following lines of code:

pred = tp.predict.DriftPredict(initial_guess=(0, 4)) t = pred.link_df(f, pixel_travel_between_frames, memory=particle_frame_gap)

pred = tp.predict.NearestVelocityPredict(initial_guess_vels=(0, 4)) t = pred.link_df(f, pixel_travel_between_frames, memory=particle_frame_gap)

However I still get a lot of paths where the path seems to move sideways from one path to another one on the side. Does that depend on the initial velocity guess? From what I read in http://soft-matter.github.io/trackpy/v0.5.0/tutorial/prediction.html this speed should update. Are there any other variables I can change in NearestVelocityPredict to alleviate this issue?

Thank you, Alex

[nkeim]

Great! Yes, the predictor uses the velocities in only the last span frames, with the default span = 1, so the guess is just for the beginning. However, if particles are not being tracked correctly, the predictions for their subsequent positions will be wrong, and the algorithm may never correct itself.

If you are having trouble with tracks jumping around, it might help to use a larger span, and also use DriftPredict which averages over all particles, instead of trying to follow single particles.

As an alternative approach, you could try even harder to follow single particles by using NearestVelocityPredict and making search_range something smaller, like 1 pixel. In other words, the particle has to be within 1 px of the predicted position, or it is dropped. This works if the particle's velocity is changing slowly. Your tracks may be shorter but they will have fewer errors.

Finally, there is one crazy thing you could try in this challenging situation: Because they are different distances from the camera, your particles are differentiated by size, signal, or mass. You could use one of those quantities as a "z coordinate", rescaled so that its fluctuations are comparable to the fluctuations in x and y. Then you can just do the tracking in 3D.