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 into
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?
|
OK to remove the subcommand (the segmentation). Before I do any programming: How shall this tool be designed now w.r.t. inputs? Let me remind that this tool was also meant to be a demonstrator of using/consuming OME-Zarrs. And I don't expect that Galaxy users today can create new OME-Zarrs with segmentation results (*), nor extend the original (raw) OME-Zarrs (to have one Zarr with two channels - raw and seg). (*) They can certainly create TIFFs with segmentation. But when this lands on Galaxy storage, it makes no sense to repack/resave it into OME-Zarr.... I guess I would modify the tool as follows:
The tool would support all four combinations of input file formats: (T,T) (T,Z) (Z,T) (Z,Z). The duality of input types (T or Z) should make it easier to integrate this tool into current Galaxy workflows (that are mostly based around Ts). T = tiffs, Z = ome-zarr. Raw channel defines the tracking resolution (image size in pixels) at which the tracking will happen (this is given either by the tiffs themselves, or with the zarr+scale). Mask channel with tiffs, will be auto-resized to match the tracking resolution. Mask channel with zarr, will auto-choose the nerest better zarr pyramid level and auto-resize to the tracking resolution. Result will be stored at the tracking resolution. When reading tiffs, I expect a path to a folder that contains the tiffs. The code would internally list all The tiff input path must point to some Galaxy storage. zarr input path can be either the storage or any URL to some hosted zarr... @bernt-matthias @kostrykin Are you, please, okay with this plan? |
|
@khaled196 the proposed changes above would only need from you to change the facade but only after we confirm the plan so that we don't iterate too many times :-P |
|
The plan sounds reasonable to me. But I'm not an expert in the area. Most important point seems to be that it plays nicely with the outputs of the cellpose Galaxy tool. |
|
But note that I would also be fine with just splitting the tool into two tools (one for each branch of the conditional) .. but the outlined plan seems even better. |
|
Yes, since there is already a Cellpose node and one usually wants to post-filter the automatic segmentation results, it is indeed better to perform the segmentation in a workflow and only then wire it to this tracking tool. I trust that the above outlined plan should support this, just like @bernt-matthias is saying. @kostrykin do I get a green light from you as well?? no pressure :-) |
|
I'm not that firm with the whole Zarr topic, but as long as the tool supports arbitrary combinations of Zarr and TIFF, it sounds reasonable to me.
Why this inconsistency with Zarrs? Wouldn't it be clearer if a single multi-frame TIFF was consumed, instead of requiring a series of single-frame TIFFs? Keeping it consistent will also ease establishing input validators. For start/end parameters I think it's very handy to also allow supplying negative values, to count from the end of the sequence (e.g., |
This is a super good idea! I'll gladly add it there. |
Hmm... are we also considering processing 3D+t data? The huge TIFF (for 3D+t) would need to be somewhat 4D... yes.. It is a matter of one extra "stride" to split "very deep 3D" to 3D+t, but also very non-standard, no? Regarding OME-Zarr, I'm okay to throw it over the board at all. It was Bea and Arrate's invention to base it specifically around the OME-Zarr. But apparently, it is not fitting to the Galaxy env (yet). |
I was thinking:
|
AFAIK neither TIFF nor OME-TIFF have explicit limitations on the number of axes/dimensions for the array, so TZYX should be perfectly legal. I think, the advantage of using a single TYX or TZYX is that you don't have to care about the order of the timepoints, they are already encoded in the file structure. If the user comes with a series of separate files, it would be in the responsibility of the user to establish a proper order when concatenating the timepoints into a single file (as opposed to trying to deduce the order of lexicographically which sounds rather heuristic). But I also see the disadvantage, that the file might become very large. What's the IUC standpoint here, are many small files advantages over a single large/huge file, or rather disadvantages? @bernt-matthias @xulman: If you decide to use multiple files, I think you should use the order of the list (collection) rather than lexicographical order.
@beatrizserrano ping |
I would wait for @bernt-matthias' opinion on one-huge vs. many-smaller. My opinion on that is that
(but, I agree, having all governed within one file (and its standard) is removing some pain and assumptions from our coding, that's always nice :)) I have to learn (look around) how collections are fed into Galaxy nodes -- I was a believer until now :) that it is merely a folder, and then my tool gets a path to it. It sounds now that the collection "mechanism" is somehow giving/feeding me with paths to the individual files... or? Do you please happen to know, @kostrykin ? (would help me a lot to geting a quick pointer). |
It's not a folder, but a collection of (links to) individual datasets. Something behaving more like a directory is the directory datatype. |
Just wait until you see 6-D TIFFs :) but yes, AFAIK the whole hyperstack needs to be loaded. |
|
Many thanks, @bernt-matthias, for the explanation. Pardon me, please, one more question:
So, e.g., my proposed Is Galaxy's dataset equivalent to a single file? (I'm sorry, I'm very new to this...) |
You could create a folder in the working dir and symlink all datasets into the folder.
Yes.
No worries. |
|
[ sharing a thought: I'm ATM more leaning towards creating a dedicated
Rather than having this node "super fat" (in what all input combinations it is consuming). Plus this "pulling of TIFFs" from OME-Zarr could be beneficial for many nodes. What do you think? |
I think this is best judged by @jburel. Could you maybe have a quick look? |
|
It looks like my previous comment was not posted. |
|
Many thanks for your opinion @jburel Then, I think, it is clear that the tool must use
The discussion whether to use one multi-frame TIFF or a series of single-frame TIFFs is resolved as the OME-Zarr expresses clearly the shape of the input data (if it is 2D+t or 3D+t), and so the TIFF I/O for the segmentation data can easily recognize if it is facing multi- or single-frame TIFF(s). And it could silently support both formats.... For this tool, I'm proposing to be unable to read TIFFs as an input for the raw channel/data. Are we good on this plan? :-) (not pushing, only trying to drive constructively forward :-) ) |
|
...and I would make it create either CTC format or GEFF -- user can choose, default GEFF |
|
Thanks for your input @jburel!
Sounds good.
We already have that, no? https://usegalaxy.eu/?tool_id=toolshed.g2.bx.psu.edu/repos/imgteam/bioformats2raw/bf2raw
Sounds good, but actually I think it would be sufficient to confine yourself to just one. Maybe GEFF? |
Yes, that tool can convert pretty much anything into OME-Zarr. It's probably easy to use. I saw some easy examples, but can't certify as I'm not using it myself. And, I'd be happy if I didn't have to write another tool now :)
Well, I used to use GEFF circa one month ago, and it wasn't working well for me. But CTC was. However, GEFF should be the future :) ....so I thought, let's offer it to the users, but let's also offer them CTC as a backup solution. Just in case. |
|
Dear Friends, FYI @khaled196 , @kostrykin Just an update from my side: I'm still interested in finishing this one (semester finished only last week; teaching duties towards the end kept killing me). Second, I reworked the code (already some weeks ago) to meet what we discussed above. Pending is to double-check and test thoroughly, then to update the "facade" .xml(s) to make it talk to Galaxy. And then it should be good for your testing. |
6 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.