Add Trackastra-Galaxy to perform object tracking with Trackastra#7893
Add Trackastra-Galaxy to perform object tracking with Trackastra#7893khaled196 wants to merge 14 commits intogalaxyproject:mainfrom
Conversation
khaled196
changed the title
| @@ -0,0 +1,81 @@ | |||
| <macros> | |||
| <token name="@TOOL_VERSION@">1.0.1</token> | |||
There was a problem hiding this comment.
I guess the main package here (the one that implements the main functionallity) is trackastra, not trackastra-galaxy, right? In that case:
| <token name="@TOOL_VERSION@">1.0.1</token> | |
| <token name="@TOOL_VERSION@">0.5.3</token> |
There was a problem hiding this comment.
The main package is tracksatra-galaxy https://github.com/bioinfbrad/trackastra-galaxy.
The tool itself is a pipeline that automates and orchestrates the process of running Trackastra on Galaxy's servers, allowing users to process large datasets efficiently
There was a problem hiding this comment.
The naming of the tool is peculiar.... It is a tool for tracking (and segmenting) that features Trackastra (and Cellpose) and came to being only specifically for Galaxy. In its journey to possibly become a Galaxy node, it got published on PyPI as a package in its own right (currently at version 1.0.1) -- this is what we're trying to turn into a Galaxy node.
The PyPI package is basically an adapter around Trackastra (and Cellpose) to
- read OME-Zarrs, and
- save into CellTrackingChallenge format,
- exposing both Python API and CLI for Galaxy.
For the PyPI, it needed to have a name, which perhaps unfortunately ended up being trackastra-galaxy to reflect what its main star is and what it is meant for...
In Galaxy itself, it could probably be named better, e.g., "tracking cells with Trackastra".... I'm open to anything.
There was a problem hiding this comment.
Is this file actually used in the tests? Couldn't find it.
There was a problem hiding this comment.
I generated the files during tests and then removed the script. I considered leaving them for potential future use.
| Galaxy exposes the key result files from this directory as outputs: | ||
|
|
||
| - **man_track.tsv**: CTC track log converted to tab-separated format | ||
| - **man_trackNNNN.tif**: Frame-wise mask images |
There was a problem hiding this comment.
Please use .tiff instead of .tif FAIR-imaging/galaxy-image-community#43
unless this contradicts some IUC policy?
There was a problem hiding this comment.
Hmm.... but the output is strictly according to the Cell Tracking Challenge format that mandates the use of .tif (not .tiff).
For example, any challenge tool would not recognize tiff-named files (I'm the author of several such tools, that's how I know). But there are 3rd party tools that may work with tiff-named files and that are far more important for the world than the official tools from CTC :-) (perhaps we don't need to be compatible with the CTC tools).
....maybe CTC should be more flexible on this in the future. But now, unf., .tif is what it should be.
| 1. **Segment and Track**: Automatically segments cell instances using Cellpose v3, then performs tracking using Trackastra | ||
| 2. **Track Only**: Performs tracking on pre-segmented data (segmentation provided by other tools) |
There was a problem hiding this comment.
In terms of maintainability, what's the advantage of providing mode (1) here?
Isn't it sufficient to only provide (2), since Cellpose v3 is already available in Galaxy?
My concern is that by "including" Cellpose v3 in this tool, a redundancy is introduced that at some point will require extra maintenance work. So if there is no real advantage, it might be better to focus on (2).
There was a problem hiding this comment.
This is a good point.
The original goal of the package indeed is to be able to track nuclei/cells, not really to segment them.
However, the tracking engine (Trackastra) itself needs both segmentation and raw data, both must be provided (and must be consistent to each other).
If the user comes with just the raw data, I wanted to give them this segmentation opportunity to just let it happen on the fly, because
- to run this segmentation today is just very easy (programatically), and
- it is somewhat safe to run it internally in the sense that the segmentation input will then for sure fit the raw input in spatial and temporal size/dimensions and content (assuming segmentation went okayish), and
- this tool was also about featuring the OME-Zarr and I don't if users can produce their segmentation and serve them in the OME-Zarr (that said, if we ask only to provide segmentation as TIFFs, we would get OME-Zarr raw input + TIFF mask input).
I'm okay to drop the segment+track regime and leave it only with the tracking mode.
I'm okay to modify the tool such that two input streams (a time-lapse for raw data; a time-lapse for segmentation masks) would be two explicit inputs to the node.
There was a problem hiding this comment.
In fact, as I'm thinking abourt it and how to improve its chance to be integrated into any workflow -->> I don't even insist on OME-Zarr :) We could brainstorm and figure out how to do both ways... to be able to read OME-Zarras well as TIFFs.
(In the code it is not a big deal... there is a reading section that massages the input, and then there is the tracking itself... I could easily have two reading sections, one for OME-Zarr, and one for TIFFs... no problem 👍 )
| <option value="cyto3" selected="true">cyto3 - Cytoplasm (recommended)</option> | ||
| <option value="cyto2">cyto2 - Cytoplasm (older model)</option> | ||
| <option value="nuclei">nuclei - Nuclei only</option> |
There was a problem hiding this comment.
Why is the Cytoplasm model recommended? Isn't it a matter of the analysis task whether nuclei or cytoplasm are subject of the analysis?
There was a problem hiding this comment.
This is a wording issue as cyto3 is the default. I have removed the term "recommended" from the text. I will also curate the rest of the help text to avoid this issue in the future.
|
Guys, MANY THANKS for your effort. I'm very much open to adopting the tool if need be. There is now a question whether a time-lapse collection (or whatever is the Galaxy counterpart/term to represent this) should be accepted as an input to the tool, and whether two such inputs should be there (in the case we would drop the auto-segmentation regime). Eventually, as I think is apparent from the discussion above, Galaxy developers would need to address how to represent the tracking... |
bernt-matthias
left a comment
bernt-matthias
left a comment
There was a problem hiding this comment.
By IUC guidelines subcommands should be wrapped in different tools.
This would also apply here.
| @@ -0,0 +1,156 @@ | |||
| <tool id="trackastra_galaxy" name="Perform object tracking" version="@TOOL_VERSION@+galaxyy@VERSION_SUFFIX@" profile="@PROFILE@"> | |||
There was a problem hiding this comment.
The name would then also be more fitting, since 1 of the tools does segmentation, or?
5 participants
FOR CONTRIBUTOR:
There are two labels that allow to ignore specific (false positive) tool linter errors:
skip-version-check: Use it if only a subset of the tools has been updated in a suite.skip-url-check: Use it if github CI sees 403 errors, but the URLs work.