When using the predict_dataframe, a column named frame_y appears (possibly since I used pd.merge). The column name should be modified and the documentation should be added to let the users understand what it is. Note the values can have different values from those for the frame index when the minimum frame in the dataframe is larger than zero.

https://zenodo.org/record/1063531 may be included as a new 3D dataset for testing
haesleinhuepf/napari-laptrack#15

Hi @yfukai ,

this is just to let you know that I started a napari-laptrack plugin which uses LapTrack as dependency. It has just basic functionality yet. I'm planning to expand it iteratively based on collaborations; implementing what people need. In case you would like to collaborate on this, just let me know. Contributions (issues, PRs) are welcome. I'm also happy to share write-access to github and pypi repositories if that's of interest for you. Otherwise, it's fine, too. I'm happy to maintain it alone. No pressure. May I just ask for one little thing: In case you update LapTrack and break backwards compatibility, consider letting me know by creating an issue.

Big thanks for programming LapTrack! It's awesome.

Best,
Robert

P.S.: Feel free to close this issue; it's just a notification anyway 🙂

Hello, I've been using laptrack to generate tracks for some cell tracking challenge data, and I wanted to compute the TE and TP scores using the calc_scores function. However, I realized the calc_scores function was finding fewer overlapping tracks than expected, and after looking at the implementation and the tests, I think it's because it expects that track-id is the same in ground truth and predicted tracks.

For example, if I change the current pred_tree in test_scores.py by swapping track indices 1 and 2, all the tests fail, even though the graph and the tracks are exactly the same:

    pred_tree = nx.from_edgelist(
        [
            ((0, 0), (1, 0)),
            ((1, 0), (2, 0)),
            ((2, 0), (3, 0)),
            ((4, 0), (5, 0)),
            ((2, 0), (3, 2)), # 1
            ((1, 2), (2, 1)), # 2
            ((2, 2), (3, 1)), # 2
            ((3, 2), (4, 2)), # 1
            ((4, 1), (5, 2)), # 1
        ]
    )

It's possible I'm misunderstanding how to use the function, but I would've expected that as long as the tracks overlap, it wouldn't matter what integer value was assigned to the track-id. Otherwise, it seems like some track id matching is required?

Please let me know if I've misunderstood anything!

Hello

I am new to your cool work here.

I am doing some 3D tracking (in time) of some labeled images.

I am trying some preliminary runs with your example @ laptrack/docs/examples
/3D_tracking.ipynb

And I get an AssertionError at:

track_df, split_df, merge_df = lt.predict_dataframe(

File ~.conda\envs\tracking\Lib\site-packages\laptrack_tracking.py:763 in predict_dataframe
coords, frame_index = convert_dataframe_to_coords_frame_index(

File ~.conda\envs\tracking\Lib\site-packages\laptrack\data_conversion.py:81 in convert_dataframe_to_coords_frame_index
coords = convert_dataframe_to_coords(

File ~.conda\envs\tracking\Lib\site-packages\laptrack\data_conversion.py:45 in convert_dataframe_to_coords
assert np.array_equal(np.arange(df[frame_col].max() + 1), [g[0] for g in grps])

I am not an expert here. But i would like to get some idea on where this could be going wrong.
In the labels are not always continuous, meaning that in some frames some labels are not present and so on. so there is not a good trajectory like you have your example.

Hope this is enough information.

Thanks
:)

Sometimes we represent the data with pd.DataFrame or other formats. Conversion b/w input/output representations should be implemented.

I found using ray with the nextflow is difficult. Adding other backends should make sense.

Hello @yfukai,

laptrack uses scikit-image version 0.19. Is there a special reason for this or would it also work with 0.22.* or higher?

Best,
drchrisch

Now some of the code is not covered by the test. It will be great if we could raise the coverage to 100% (excluding some special-case part that are hard to cover.)

Currently, frames with no point is not allowed. This, annotated by None or an empty array, should be allowed.

It's better if we can make the PR automatically.
Possibly follow https://conda-forge.org/docs/maintainer/updating_pkgs.html

For the parallel_backend option in

Implement a command line tool for image/CSV input/output.

It would be great if we

• include the updated overlap calculation by https://github.com/haesleinhuepf/napari-laptrack/blob/895ba40a2f17d4d9403ff3609e4c8759b8a6e7bf/napari_laptrack/_function.py#L232 .
• make an "official" implementation of overlap-based tracking.

Using a sparse matrix with lap, the value 0 is assumed to be infinite, and thus not connected. One needs to add an offset to the matrix elements corresponding to finite values.