[tracksdata] Shift refactor track|lineage_id logic into tracksdata

[TeunHuijben]

Caroline's comment about assign_lineage_id in /annotators/_track_annotator.py:

" whole section probably should be refactored to work better with the trackdata API. The internal external IDs seems fragile - this is a place where if we used tracksdata with SQL vs with rustworkx backend it would be a different implementation, right? Also, the _assign_ids helper could be refactored to do the efficient bulk update and then used for both lineage and track ids. There might be a better way to get the tracklet IDs that would eliminate the need for graph copying too."

Also:

• TrackAnnotator._assign_tracklet_ids() is very inefficient, it loops over ALL nodes to find parent nodes...

[cmalinmayor]

@TeunHuijben this is done right?

[TeunHuijben]

@cmalinmayor, not yet.

Yes, the track_id logic has been improved significantly (mainly because we were finding parents in very different, inefficient ways). But my idea for this issue was to rely entirely on tracksdata for the track_id/lineage_id logic. Tracksdata has all functionality for this (afaik), and had the added advantage that if track_ids are changed on a subgraph, it efficiently recomputed the relevant tracks in the full graph.

This is not essential for our next release, but maybe we can keep this issue open for me to not forget we can use tracksdata for this

[cmalinmayor]

To be as efficient as the funtracks updates, tracksdata will need to incrementally update based on specific changes, not just completely recompute the connectivity when something changes. Not sure if that's currently implemented or not, but we can move the logic from the TracksAnnotator into tracksdata if not.

[TeunHuijben]

Abandon, we leave the track_id computation in funtracks, because it is faster than the tracksdata tooling. The reason is that tracksdata does a lot more than just computing track_ids, it computes the entire tracking graph, which has a lot of overhead. So algorithmically similar, it just does a lot more that we don't need in Funtracks. So lets keep it in funtracks, thereby closing this issue