Skip to content

TrackMate v9 - #353

Draft
tinevez wants to merge 359 commits into
masterfrom
v9
Draft

TrackMate v9#353
tinevez wants to merge 359 commits into
masterfrom
v9

Conversation

@tinevez

@tinevez tinevez commented Jul 24, 2026

Copy link
Copy Markdown
Member

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

  • SpotBase that represents a spot with only X,Y,Z and radius coordinates (the original TrackMate <v7 spots)
  • SpotRoi, that represents 2D spots that have a polygon as shapes. Introduced with TrackMate 7
  • SpotMesh, spots with 3D shape, with a 3D mesh.

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

Algo Repo Status Integration in TrackMate Who
Cellpose https://github.com/imglib/imglib2-cellpose Done Ready to test @StRigaud @gletort @tinevez
StarDist https://github.com/uw-loci/cellcast ? ? Not done @elevans @ctrueden
YOLO https://github.com/imglib/imglib2-yolo Not done Not done @tinevez @msphan @gletort
Omnipose https://github.com/imglib/imglib2-omnipose Not done Not done @tinevez
Trackastra ? Not done Not done ?
? ? ? ? ?

tinevez and others added 30 commits June 29, 2026 13:46
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.
tinevez and others added 30 commits August 7, 2026 15:08
…-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.
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: In Progress

Development

Successfully merging this pull request may close these issues.

3 participants