Ilastik tracking results as .csv file - meaning of rows with 0,0,0 location?

Hi,

I have a question about the export plugin for .csv files for the ilastik tracking workflow.
I am tracking endosomes in a 3D+t series using the automated tracking workflow with a probability map and raw image as input.
I then export the tracking results as .csv as I want to visualize them in napari.

Looking at individual tracks I see certain frames where the position of the tracked object is 0, 0, 0 in the table. This is true for most tracks. I am not sure what this is supposed to mean, does it indicate disappearance/reappearance of the object? If so, it may be better to indicate this with NaN or with a boolean column disappeared. The 0, 0, 0 location should not be a valid tracking result as the jump from the last good position to 0,0,0 dramatically exceeds the valid search range for a match. Also, there is no object at 0,0,0 that I am aware of.

Here’s some code snippets of how I process the results in Python:

df = pd.read_csv("/home/volker/Merged_Cell_02-data_CSV-Table.csv")
tracks = []
for trackId in df.trackId.unique():
    if trackId > 0:
        tmp = df[df.trackId==trackId]
        track = np.vstack((tmp.frame,tmp.Convex_Hull_Center_0, tmp.Convex_Hull_Center_1, tmp.Convex_Hull_Center_2)).T
        tracks.append(track)

Looking at one of the tracks I see the 0,0,0 position in rows 14, 15, 25, 26, 27.
I see similar blocks of 0,0,0 in most tracks.

> tracks[0]
array([[  0. , 173.5, 324. ,  13. ],
       [  1. , 173.5, 317.5,  11. ],
       [  2. , 176.5, 319.5,  13. ],
       [  3. , 175.5, 319. ,  11.5],
       [  4. , 173.5, 315.5,  11.5],
       [  5. , 174. , 311. ,  12. ],
       [  6. , 176. , 315. ,  11. ],
       [  7. , 188. , 307.5,  24. ],
       [  8. , 188. , 309. ,  24.5],
       [  9. , 189.5, 310.5,  25. ],
       [ 10. , 192. , 308.5,  25. ],
       [ 11. , 195. , 307. ,  23. ],
       [ 12. , 189.5, 309. ,  24.5],
       [ 13. , 192. , 311. ,  28. ],
       [ 14. ,   0. ,   0. ,   0. ],
       [ 15. ,   0. ,   0. ,   0. ],
       [ 16. , 193.5, 312. ,  24.5],
       [ 17. , 191.5, 311.5,  24.5],
       [ 18. , 192. , 310.5,  24. ],
       [ 19. , 187. , 305.5,  24. ],
       [ 20. , 189.5, 308. ,  26. ],
       [ 21. , 189.5, 302.5,  21. ],
       [ 22. , 193. , 302. ,  20. ],
       [ 23. , 193. , 307.5,  24. ],
       [ 24. , 187.5, 314.5,  29. ],
       [ 25. ,   0. ,   0. ,   0. ],
       [ 26. ,   0. ,   0. ,   0. ],
       [ 27. ,   0. ,   0. ,   0. ],
       [ 28. , 191.5, 313.5,  28. ],
       [ 29. , 195.5, 313.5,  28. ],

Any help on what the 0,0,0 should represent would be greatly appreciated. This is with version 1.4.0b5 on Linux (bundled download).
Tagging @k-dominik

Edited to add:
I just thought maybe it is related to the Convex hull centre computation, but the zeros are also there when I use the Center_of_the_Object_{0|1|2} columns.

Ok, so I started looking into the source code and see that you assign a 0 when an IndexError exception is thrown here: https://github.com/ilastik/ilastik/blob/63791b8b7e77bdf17bd86e7cf85e73652a495e69/ilastik/plugins_default/tracking_csv_export.py#L130
Not quite sure under whether it is disappearance for a few frames that would cause this index error in the feature table, but I would suggest that assigning 0 or 9999 as a magic numbers in this case is not really desirable behaviour.

Hello @VolkerH,

not one hundred percent sure, but could it be possible that those are actually mergers - so objects that only logically exist, but are actually part of a bigger object. Could you check the column mergerId, which should point to the joint object that should also have a position associated.

1 Like

Hi @k-dominik,
thanks for the quick reply.
I just looked at the mergerLabelId column and I can indeed see that I get a non-zero value in that column for the rows where the convex hull coordinates are 0,0,0.

However, I also noticed that my statement above was wrong (due to interactive experimentation in the notebook … forgot to rerun a cell) … the problem only seems to exist for the convex hull coordinates and not for the object coordinates.

Anyway, I think I have enough to get started with finding out how to visualize the tracks.
Thanks again.

1 Like

Hi @VolkerH,

would you, at some point, be willing to share your notebook with the community? :slight_smile:

Sure, will do when it is presentable. At the moment it is more like some scribbeling on the back of an enevlope.
Also, the visualization currently relies on a PR that adds a Tracks layer to napari, authored by @quantumjot . This has not yet been merged into napari: https://github.com/napari/napari/pull/1361

2 Likes

Any feedback on that Tracks layer PR would be very helpful btw! :slightly_smiling_face:

3 Likes

Initial feedback from me is that I like it and find it very snazzy. Need to work with the Track layer some more to provide more meaningful feedback on usability.

3 Likes

Just revisiting this, after being away for a while and also working on other things.
While picking up where I left, I noticed another peculiarity about columns/features related to my original post.
Looking at the columns of the .csv export of the tracking results there are feature columns called

Object_Center_*

as well as

Center_of_the_object_*

The Object_Center_* coordinates are floating points and behave similarly to the Convex_Hull_Center* coordinates in that there are 0,0,0 coordinates.

The Center_of_the_Object_* coordinates are integer values and do not contain the 0,0,0 coordinates.

Index(['frame', 'labelimageId', 'trackId', 'lineageId', 'parentTrackId',
       'mergerLabelId', 'Convexity_0', 'Number_of_Defects_0',
       'Mean_Defect_Displacement_0', 'Mean_Defect_Area_0',
       'Variance_of_Defect_Area_0', 'Convex_Hull_Center_0',
       'Convex_Hull_Center_1', 'Convex_Hull_Center_2', 'Object_Center_0',
       'Object_Center_1', 'Object_Center_2', 'Object_Area_0',
       'Kurtosis_of_Intensity_0', 'Kurtosis_of_Intensity_1',
       'Maximum_intensity_0', 'Maximum_intensity_1', 'Mean_Intensity_0',
       'Mean_Intensity_1', 'Minimum_intensity_0', 'Minimum_intensity_1',
       'Principal_components_of_the_object_0',
       'Principal_components_of_the_object_1',
       'Principal_components_of_the_object_2',
       'Principal_components_of_the_object_3',
       'Principal_components_of_the_object_4',
       'Principal_components_of_the_object_5',
       'Principal_components_of_the_object_6',
       'Principal_components_of_the_object_7',
       'Principal_components_of_the_object_8', 'Radii_of_the_object_0',
       'Radii_of_the_object_1', 'Radii_of_the_object_2',
       'Skewness_of_Intensity_0', 'Skewness_of_Intensity_1',
       'Total_Intensity_0', 'Total_Intensity_1', 'Variance_of_Intensity_0',
       'Variance_of_Intensity_1', 'Bounding_Box_Maximum_0',
       'Bounding_Box_Maximum_1', 'Bounding_Box_Maximum_2',
       'Bounding_Box_Minimum_0', 'Bounding_Box_Minimum_1',
       'Bounding_Box_Minimum_2', 'Size_in_pixels_0', 'Center_of_the_object_0',
       'Center_of_the_object_1', 'Center_of_the_object_2'],
      dtype='object')

PS. Now that the Tracks layer has found its way into the napari master (thanks again @quantumjot !) I will start on that tutorial notebook.

1 Like

Here’s a notebook that shows the basic steps on how to visualize the ilastik tracking output (in .csv format) using the napari Tracks layer on top of the segmenation labels and raw volumes. However, the dataset is currently not included.
Now that the Tracks layer API is fixed it is really straightforward.

The notebook still needs a bit of polishing and (more work) a smaller dataset that is of a suitable size for sharing, not sure when I’ll get to that.

1 Like