Tracking gives unexpected results

[merrygoat]

The documentation says:

The tracking mode on the other hand attempts to find an optimal assignment of particle numbers between camera angles within one frame

When trying to reconstruct 3d positions, I can see that with tracking turned on, I get much better results as shown in the 3d view window. However, the particle numbers do not seem to update either in the main view window or in the output data. How can I access/retrieve the updated particle numbers?

---

To reproduce

• Load example images 500 -> 519
• Do particle identification -> to save time I only consider black rods.
• Correct results manually by adding missed particles
• Save my results (attached)
• In 3d reconstruct mode, load example calibration and transformation
• Select tracking checkbox
• Solve
• View "corrected" data (also attached) and see that particle positions change randomly over time for same numbered particle.
• Displacement graph also shows that particle assignment is still random

rods_df_black.csv
rods_df_black_corrected.csv

[merrygoat]

Sorry - wrong github issue label - it should probably be a bug rather than an enhancement.

[dmitrypuzyrev]

Thank you for pointing this out!
It might be that tracking was tested on another images/data sets and here it is inconsistent for some reason.
We will check and fix it it as soon as possible (latest in the first days of the next week).

[dmitrypuzyrev]

Hi @merrygoat,
I think we are close to undestanding/solving this issue.
The tracking/reconstruction seems to work sufficiently fine even in case of large particle numbers as in example dataset, as soon as all particles are marked in 2D close to their real positions (this is the nature of the current 3D tracking algorithm).

But I encounter a problem with saving/updating the new position data after the initial press of the solve button. As soon as I correct the position and try to solve again, the particles revert to their last "solved" coordinates. This seems to be consistent with your issue. I think this should be resolved by @a-niem soon.

[dmitrypuzyrev]

Dear @merrygoat,
sorry for the delay. We had to focus on other issues which prevented fixing this one. I will update you in the next working days.

[dmitrypuzyrev]

Hi @merrygoat,
I have fixed the issue with tracking. It seems that example data is good enough to produce meaningful results, and the issue was caused by an error in the algorithm implementation.
Please check it out on develop branch.
In case of your attached corrected endpoints data (), solve should produce a smooth average displacement around 2.5 mm between all frames, with occasional jumps between some rods pairs which are hard to resolve in 3D (but it's absolutely normal for this task). I also attach my attempt of endpoint correction with a slightly smaller average displacement.
The data saving issue was also resolved earlier by @a-niem.

[dmitrypuzyrev]

Hi @merrygoat,
the issue was already adressed and now tested in the new release.
Please confirm that tracking works correctly for you.

[mhubii]

hi @dmitrypuzyrev, please push these changes to pypi and let me know once done. I won't use the development branch, since I am reviewing stable releases. Thanks for the understanding