Conversation
A SpotDetector for 3D images that work by running a spot segmentation algorithm on 2D slices, and merging results using a tracker. This yield a label image that is then converted to 3D meshes using the LabelImageDetector. This is a convenience class, made to be used in specialized SpotDetectorFactory with specific choices of detector and merging strategy.
When using the configure(Settings) method, the morphology analyzers were not added to the Settings object, even when selected.
The spot feature analyzer factories are directly read from the user selection.
I was using it before and trash it in the overhaul. But this one is about 30x faster. So let's put it back, with some adapting. Noticed by @Mini-Miette
This is crucial, as some analyzers depend on others to have been computed. This is implemented following the priority of the analyzer factories, which is known by the provider. The provider returns a list of keys, in priority order, so we must make sure to reproduce this order with the user selection. Hence the gymnastic in the configure(Settings) method.
Spot -> the main interface, used by default in trackers. Define basic methods to get and store feature values. SpotBase -> Plain spots, like for TrackMate v<7 SpotRoi -> spot has a polygon as a contour in 2D SpotMesh -> spot has a 3D mesh More elegant and extensible to app consuming TrackMate trackers with special objects.
Adapting the demo from Tobias. This currently requires the 'mesh' branch in the bvv repo to work. Right now it can display the 3D image (possibly multi-channel) over time, along with the meshes in spots (if there is no mesh, nothing is shown). There is still so much to do but this is cool!
Modified so that the color of individual meshes can be changed at runtime. We also add a white halo so that object contours are visible over the black background.
Can be changed live using TrackMate display settings panels.
…le spots. Noticed by Laura Xénard @Mini-Miette Fix #260
One bug of my Eclipse installation results in not having exceptions shown in the console.
…-page Mode the Displaysettings config in the Preferences dialog and clean duplicate code
We cannot create a KDTree if the spot collection to search is empty. This was silently failing the spot linking, because the exception is caught somewhere else.
Make the keys used to interact with the model configurable
Trickier that it looks like, since tracks can be appaearing or disappearing when spots or edges are added and removed. Got the help of Claude for this one.
so that they can be undone.
If a spot was added then removed in one transaction, it messed with the event content. This fixes it.
So that we can use it for undo / redo tests.
We only store the feature and properties of spots and edges that have changed, not all of them.
Redo was not doing anything when spots were moved. Also added handling the hypothetical case where a user could move a spot from one frame to another. Though the GUI does not let us do that.
Undo / redo for manual edits in TrackMate
Undo / redo for the segmentation editor
Add _JAVA_OPTIONS to enable headless mode for GUI tests on Ubuntu runners. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Another attempt... Set MAVEN_OPTS environment variable in GitHub Actions workflow to enable headless mode for GUI tests on Ubuntu runners.
TrackMatePluginTest requires GUI initialization which fails on headless CI runners. Skip the test when java.awt.headless=true. The test will still run locally with a display available.
Use GraphicsEnvironment.isHeadless() to detect if running in a headless environment (like GitHub Actions CI) and skip the test that requires GUI initialization. The test runs normally on local machines with a display.
The spot is recentered after mesh recalculation. We should probably forbid direct mesh modication, by making it read only.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
TrackMate v9 - new major version
The main features we want to bring in the v9 are the following:
1/ Full support for 3D segmentation. 3D segmentation results will be represented by a surface object, and there will be a 3D viewer, and 3D morphological features.
2/ Change of file format. TrackMate v9 will ditch the XML file that has been in used since v2.2, and use GEFF instead, via GEFF-java
3/ All Python tools will be called using Appose. The previous way (introduced in v8) of calling Python
tools via command lines will be removed entirely.
Support for 3D segmentation
There is a lot of work already done for the support of 3D segmentation. The API support for feature 1/ should be ready to test. The 3D surface API is provided by imglib2-mesh. The 3D viewer relies on the bvv.
If you want to write a segmentation module that works in 3D, there are facilities to help. For instance, if the output of your segmentation algorithm is a 3D label image, you can use the facilities e.g. in SpotMeshUtils.
For an example, check the LabelImageDetector
This causes the most important API change. The core Spot class, that represents objects to track, is not a class anymore but an interface. In TrackMate there are now 3 implementations of this interface
GEFF as the main file format
See #352
We are dropping the old XML file format in favor of GEFF. This will probably cause the most breaking changes to users, but I am convinced it is for the best, since quasi ALL tracking tools are adopting the same file format. So with this change, you will be able to run tracking in TrackMate and directly analyze the results in Python without the need to export to a specific file format. And conversely, you will be able to import results from another tracker and edit them in TrackMate.
This also means that we will remove the TrackMate code that was doing exports to and imports from other file formats, in an effort to shrink the code base.
However, it will still be possible to open TrackMate XML files in TrackMate v9.
Python interoperability with Appose
Appose is fantastic. So it will be the main way of adding integrating algorithms in TrackMate.
We thought initially of making a dedicated API in TrackMate to facilitate using Appose, but realized in the Pasteur hackathon that this is not the best idea. Paradoxically, TrackMate will not know of Appose.
Here is why: It is actually a better idea to write the integration of a Python algorithm at a lower level, ideally with plain imglib2. This way, the work done here can be reused many times, for instance in Fiji, in Icy, in TrackMate and in Mastodon.
The best example so far is the new Cellpose integration. There is a imglib2-cellpose artifact. This artifact depends only on Appose and imglib2, and is used in a Fiji plugin, in an Icy plugin and in the new version of the TrackMate-Cellpose module.
None of these 3 user-facing plugins know that the calls to Cellpose rely on Appose, and it is very good this way. For a user it means that there is only one environment installed on their disk to run Cellpose in any of these apps. This env is carefully brewed and maintained by only a few people, but used by many. We don't want to have one cellpose-appose for each Java app that wants Cellpose, duplicating efforts, wasting disk space.
We recommend using the same approach for other Python algos. If you want to integrate a Python algo, you can take inspiration from imglib2-cellpose
I give below a list of integration that have been started.
TrackMate modules with a Python algo that need to be (re)written with Appose