0

I am trying to link coordinates I extracted from some image time series with a custom coordinate finding algorithm. In the second step there is a problem:

trackpy.linking.utils.SubnetOversizeException: Subnetwork contains 35 points

I interpret this the way that there are too many possible connections to be made between coordinates in a certain area between images 1 and 2 (starting at 0), is this correct?

If yes, how can I find out where this error occurs in the image? I looked through the code and I'm pretty sure the info is somewhere in the trackpy.linking.subnet.Subnets.compute() method:

for i, p in enumerate(dest_hash.points):
    for j in range(nn[i]):
        wp = source_hash.points[inds[i, j]]
        wp.forward_cands.append((p, dists[i, j]))
        assign_subnet(wp, p, self.subnets)

I assume that wp is the "starting point", but after wp.forward_cands.append() is called, I can only find one point in wp.forward_cands, not 35. Maybe I got it all wrong.. any help appreciated!

smcs
  • 1,772
  • 3
  • 18
  • 48

1 Answers1

1

The limit is there to prevent run-away processes (better to exit than to run forever). It may not be blowing up on the step you are checking, but some later one.

Without more code it is hard to tell exactly what you are doing, but I suggest turning down both the maximum displacement, turning down the memory, and if possible getting data at a higher frame rate.

If you are in a situation where you are getting large sub-networks I am not sure that you should trust the linking as it means the particles are moving a significant fraction of their average spacing per time step which means you are going to miss-link

T1 ...A....B....
T2 .....BA......

where each row is a timestep. The algorithm will pick to link the particles in a way that minimizes total displacement which, in this case, swaps their true identities and will bias your data towards lower than real displacements.

tacaswell
  • 84,579
  • 22
  • 210
  • 199
  • Thanks! I agree it's likely not ideal to force large subnetworks to work, but I need to understand how this was caused in the first place. I work with many very similar experiments and this is the first one with this problem, hence I was hoping for a way to locate the element(s) with too many possible successors, so as to avoid certain artifacts or improve my feature detection or adapt the trackpy arguments. Basically I want to debug my pipeline. – smcs Aug 13 '19 at 09:31