misdetections get logged as lineage_id = 0
Closed this issue · 8 comments
.. but this is the same as for mergers
we should label them as lineage_id = -1
@ilastikdev please next time add a description why and when this is a problem.
To clarify to others: @ilastikdev is talking about the values found in ilastik's export table, where we might like to distinguish mergers (that are no longer present in the image because their segmentation was refined), from false detections.
We did indeed have a special value for false detections in ilastik's tracking before we switched to hytra, and this was even noted in a comment in the method that computes the lineages: https://github.com/chaubold/hytra/blob/master/hytra/core/hypothesesgraph.py#L604. I am not sure why unused nodes get the track and lineage id 0 at all. I'll make sure this is 1 to conform to the old ilastik standard, but that means you have to change your test as well.
"I'll make sure this is 1 to conform..." you meant -1 here?
No 1. Because, if you read the line of code I linked, you'd see that ilastik used 1 for false detections before
Just a note: gui of manual tracking displays -1 track label for annotating a false detection, and
1 for the first track annotated.
I know label 1 is avoided in the tracking solution for regular tracks, but this will inevitably lead to some confusion, because tracking with learning uses both: manual tracking and hytra tracking.
I will for now, test mergers as 0's and false detections as 1's.
User that may have to post-process the tracking result will be confused.
running latest new-conservation-tracking branch mergers and also resolved mergers get logged as 0's
also false detections still get logged as 0's
which is not what we want
tests work now with hytra/master and
ilastik/fix-wrong-division-assertion
however, original mergers get logged properly as 0's
resolved mergers however do get logged as 1's
but they should be logged as their proper track id's
this is not an export problem - it is a problem of a tracking solution