Currently it is a messy/undefined, how the settings are configured and applied with multiple trackscheme or BDV windows.

For example, if I open two TrackScheme windows each has it's own display settings and seetings dialog. If I change the definition of a custom style "mystyle" in one of the settings dialogs, this is not changed in the other dialog, and actually the only way to make this accessible in the other window is to save the settings to disk and close and re-open the window.

We need a central management of trackscheme styles.
Then, we need to decide, whether we want to
a) choose one style that applies for all windows, or
b) choose one style per window.
I think (a) makes more sense.

For the BDV overlays it is a different story. I think there users definitely could want to use different settings for different windows. Probably it would make sense to split the settings into two parts. One part is the same for all windows, e.g., colors and strokes. How long the edge "tails" are, etc, can change per window. Still, a style could set defaults for these but can be overridden per window?

this was motivated in the context of collaborative tracking: a user wanted to auto-tag spots that he/she has added,
this is an extension of the original idea (which was: added linked spots inherit tags from the source spot)

the auto-tagging set is empty by default

Animate time in navigateTo.

In BDV window do not jump to destination timepoint, but smoothly interpolate just like spatial coordinates are interpolated.

In TrackMate 2 you can only get features for spots, edges and tracks.

But a track is a connected component of a graph (a sub-graph). For instance, a cell followed up through all its divisions makes a single track. End users desire features to be calculated for branches, because they typically match a biological object (e.g. a daughter cell before it divides).

For this, we need a way to access, store and compute branches, which is another issue.

Several improvements to be made to the BDV overlay for the lineage data.

• Option to show links also ahead in time in BDV.
• Option to show arrow-heads.
• BDV style preview like for the TrackScheme settings.
• Configurable colors in Bdv window (probably more complicated than it sounds because of the depth-fading and color-fading on links, etc. Also a UI design challenge...)

The following line is from the old code, which should be removed.

Get inspiration from what was done with MaMuT for the same issue.

• there could be a settings for in which corner the color legend (tags) in TS should appear
• reset the view on BDV
• importing your own segmentations as an alternative to using the detector

Summary

The save button and Save Project command fail with the following error when the project is created from .h5/.xml.
The save as... button works.

Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
	at org.mastodon.mamut.project.MamutProject.openForWriting(MamutProject.java:170)
	at org.mastodon.mamut.ProjectManager.saveProject(ProjectManager.java:317)
	at org.mastodon.mamut.ProjectManager.saveProject(ProjectManager.java:303)
	at org.scijava.ui.behaviour.util.RunnableAction.actionPerformed(RunnableAction.java:47)
	at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2022)
	at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2348)
	at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402)
	at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259)
	at javax.swing.AbstractButton.doClick(AbstractButton.java:376)
	at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:842)
	at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:886)
	at java.awt.Component.processMouseEvent(Component.java:6539)
	at javax.swing.JComponent.processMouseEvent(JComponent.java:3324)
	at java.awt.Component.processEvent(Component.java:6304)
	at java.awt.Container.processEvent(Container.java:2239)
	at java.awt.Component.dispatchEventImpl(Component.java:4889)
	at java.awt.Container.dispatchEventImpl(Container.java:2297)
	at java.awt.Component.dispatchEvent(Component.java:4711)
	at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4904)
	at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4535)
	at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4476)
	at java.awt.Container.dispatchEventImpl(Container.java:2283)
	at java.awt.Window.dispatchEventImpl(Window.java:2746)
	at java.awt.Component.dispatchEvent(Component.java:4711)
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:760)
	at java.awt.EventQueue.access$500(EventQueue.java:97)
	at java.awt.EventQueue$3.run(EventQueue.java:709)
	at java.awt.EventQueue$3.run(EventQueue.java:703)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:84)
	at java.awt.EventQueue$4.run(EventQueue.java:733)
	at java.awt.EventQueue$4.run(EventQueue.java:731)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:730)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

How to reproduce

1. Create a new Mastodon project from .h5/.xml
2. Run Save Project

Environment

The latest version of Mastodon on Fiji running on Ubuntu 18.04 (64-bit)
Version on the launcher panel: 1.0.0-beta-18-SNAPSHOT-11121b463e1d7c1221dab58642b973882df8ea7f

Investigation

projectRoot at org.mastodon.mamut.project.MamutProject.openForWriting(MamutProject.java:170) is null

Suggestioin

Redirect to save as... when the project is newly created.

@tinevez said you wanted more issues to be filed https://twitter.com/jytinevez/status/1329023718190931968

It would be wonderful if it would be possible to use Mastodon directly on the currently open Fiji image instead of needing to export the image first to BDV format. This would make it much easier for me to switch workflows to Mastodon from TrackMate, especially for the cases when Mastodon will scale better.

Thank you!

Do you consider switching to JavaFX at some point or not at all ?

I am asking because of a current project on which I won't have a lot of time to work on anytime soon : trackmate-sc/TrackMate#89

So I could consider to develop it directly for the TM v3.

Hi,
don't remembering all shortcuts by heart (and being lazy and irresponsible -- by just trying keystrokes), happened to me a couple of times that I've killed completely Mastodon (and Fiji) by pressing Cmd+Q. I did that in an attempt to increase radius of a spot, which is decreased with Q and I did too much, and I was hoping that something like alt+q, shift+q, cmd+q might do the opposite...

BTW: Cmd+, opens also the Preference dialog of Fiji (the single check-box one with "Clear preferences").

Was on Mac.
Vlado

BranchVertex and BranchEdge are explicitly tied to Spot and Link, and are living in the mamut packages.
Their name should reflect this.

There is half a timepoint more visible, when it should actually just end at the line

In TrackScheme, edges are not painted correctly if the source or target vertex is "away" from the painted area. For instance, this is what is correctly painted with an edge for which source and target are in the rendered area:

If we zoom in a little bit so as to put some target vertices out of the rendered area, they loose their edge (in a literal way):

It would be great if Mastodon plugins could be scripts. As a proof of concept for that, a FeatureComputer in Jython or so would be awesome.

• while annotating a dataset, move to the last timepoint,
• move mouse over some spot in BDV,
• press A (add linked spot) and it gets a bit crazy... would expect nothing to happen actually

TS seems to add another time point (a new line appears in TS) but does allow to see it (to scroll over it). BDV shows ellipses from the last time point and also from the new just-beyond time point. At least, this is what it looks like from outside.

How can I help?

Issue

MIN_RADIUS can prevent us from adjusting the spot size to a tiny object.

Investigation

Currently, MIN_RADIUS is hard-coded here to 1.0, which can be too large sometimes.

Suggestion

• make it customizable from Preferences
• change the value of MIN_RADIUS to 0.0 or very small value

On this dataset I have run into this issue: the connection lines that span across multiple time points occasionally disappear as a function of zoom. Have a look into this recordings, on Mac:

behaviour 1

behaviour 2

In TrackMate 2, feature analyzers can depend on each other via the priority flag of the SciJava annotation.

Instead, we want a feature analyzer to explicitly declare on what other feature analyzers it depends.

... when commit 2d42d4b is considered.

It seems to have something to do with the recent upgrade to bigdata-core-9.X because

• I couldn't trace any recent change in the AddSpotAndLinkIt class
• an especially the here it does not advance the view
• and a bit below the wrong time point is read out

As a consequence, it creates new linked spots in the same timepoint... breaking all assumptions and making TrackScheme behave funky in result

Besides, at least on my (updated, recent) Linux the shortcuts work lazily... not every shortcut seems to be processed/captured. And when I change them in Preferences->Keymap, the change does not seem to become effective at all..
(the Mastodon shipped with Fiji works well on my box)

A mode for BdvOverlay where ellipsoids are only shown for the track that contains the focussed vertex

It is at the moment probably unclear to new users that the File Dialog popping up when "new project" is clicked means "Select a BDV file with image data". It would be good to instead have a dialog open, with a (appropriately) file field for the BDV file, and then once a fitting file was selected enabling "OK"/"Create project" button on the dialog.

Track velocity is calculated frame to frame, which, to the uninformed user, gives a fake report of velocity. (Diffusing particles do not have velocity, or immobile particles will have the noise of assignment as velocity).

Is it possible to incorporate MSD vs t fitting?

MastodonPlugin.setAppModel(MastodonPluginAppModel appModel) is called when a new project is opened.

When no project is open, it is called with appModel == null.
This should be changed, so that is is called with a non-null appModel. Some plugins (e.g., now the Merging-Plugin don't need open projects)

But do not depend on TrackMate itself.
Probably copy the String keys, even if it is fragile.

• branch trackscheme views
• branch bdv views
• branch table views

• Feature computation system.
• Integration into the UI.
• [ ]
  A few feature examples:

for branch links:

• Branch duration.
• Branch displacement.

for branch spots:

• Number of incoming / outgoing / total branches.
• Hierarchy level (root = 0, children of root = 1, etc) so that we can build the hierarchy graph.

Spot intensity calculation error

I analyze a two-channel dataset (20 timepoints, 3D images 20x1024x1024) with Mastodon (Fiji v1.53o, everything updated). It works fine to extract spots and links. But when I run "compute features" I get a java error for feature "Spot intensity" and only for this feature.

Exception in thread "Feature computation thread" java.lang.ArrayIndexOutOfBoundsException: 76
at org.mastodon.mamut.feature.SpotIntensityFeatureComputer.run(SpotIntensityFeatureComputer.java:200)
at org.mastodon.feature.DefaultFeatureComputerService.compute(DefaultFeatureComputerService.java:253)
at org.mastodon.mamut.feature.MamutFeatureComputerService.compute(MamutFeatureComputerService.java:79)
at org.mastodon.mamut.MamutFeatureComputation$MyFeatureComputerService.compute(MamutFeatureComputation.java:138)
at org.mastodon.feature.ui.FeatureComputationController$2.run(FeatureComputationController.java:128)

I did analyze a few other dataset earlier whithout getting this error. Were there some changes in the feature calculation part recently?

Hi,
this dataset consists of frames t1.tif till t9.tif with timepoints 1 till 9 (according to its DBV's dataset.xml. However, when opened as "New project" in Mastodon, the timepoints are treated 0 till 8 (in BDV as well as in TS). Now, when exporting into Mamut's .xml, the spot definitions are with timepoints 1 till 9, e.g.
<SpotsInFrame frame="9" />,
and definitions of spots from the first frame are missing (but their ID's are referenced from definitions of tracks). Also the
<AllSpots nspots="154">
counts all spots and is larger than number of lines with individual spot definitions in the created Mamut's .xml.

In TrackMate 2, a spot feature can depend only on a spot feature. It cannot depend on an edge feature, because edges are always generated later, and their features are calculated once the spot features are already there.

This is why for instance a spot cannot have a feature that state to what track number it belongs to.

In TrackMate 3 we want the feature dependencies to be heterogenous, so that a spot feature can depend on anything.

This implies that there should be a way to deal with required features that are not here (for instance, you can compute the track a spot belongs to if the tracks have not been generated yet). This particular sub-issue is then probably linked to issue #1.

Hello,

I noticed that upon importing some TGMM data into a Mastodon project, the number of green dots (where each green dot is a gaussian) appears to change if you zoom in and out -- this is probably a bug, since the number of gaussians should stay constant!
I attach a figure showing this occurrence at three different zoom levels for the same time point.

For your reference, my OS is Ubuntu 18.04. Thank you!

Though features can be defined any time in an application, only those defined at compile time are deserialized properly.

I had a hard time understanding what was going on, and I think that this is linked to the fact that some features are handled in static initializers and in static methods

Here is roughly the code flow for deserialization of a Model:

• a Model instance is created. At this line (https://github.com/fiji/TrackMate3/blob/model-edit-actions/src/main/java/org/mastodon/revised/model/mamut/Model.java#L55) the ModelFeatures class is referenced.

• In the static initializer of this class, an ObjFeature is created for vertex labels (https://github.com/fiji/TrackMate3/blob/model-edit-actions/src/main/java/org/mastodon/revised/model/mamut/ModelFeatures.java#L11).

• Doing so, this feature is registered in a static field of FeatureRegistry.

• The feature serializer is registered in a static field of FeatureSerializers (https://github.com/fiji/TrackMate3/blob/model-edit-actions/src/main/java/org/mastodon/revised/model/mamut/ModelFeatures.java#L15)

• Now the model is instantiated and empty.

• Calling `'loadRaw' will deserialize the graph (vertices and edges) and then call 'RawFeatureIO.readFeatureMaps( fileIdMap.vertices(), vertexFeatures, ois );' to deserialize features.

• This method relies on the FeatureRegistry to get the Feature instance corresponding to the String key stored in the raw file. If the feature with said key is not in the registry - i.e was not declared before the call to loadRaw - the registry will return null.

This happens for all features created after the model was instantiated or/and loaded.

As of now, only properties of the Model are undoable because the recorder are created at model construction time.
TagSets are based on PropertyMaps so they could be made undoable, but right now it does not work because they are not registered in the GraphUndoRecorder

This is important for performance (e.g. GUI responsivity: we need to quickly retrieve the spot closest to a click location).

This is tricky, because we allow for incremental model changes. The Kd-tree cannot be recomputed for each single change, otherwise the performance will degrade quickly, which is not the desired effect. A system to cache changes must be implemented, which is another issue.

It can happen that the Mastodon crashes when modifying the graph several times via its highlight or focus.

The diagnosis is as follow (based on the unify-views branch):

A graphChanged event ends up in calling the paint() method of the TrackSchemePanel.

The paint() method does mainly two things, in the following order:

• It recompute the graph layout: All TrackScheme vertices get a new value for X. This calls the layout() method of the LineageTreeLayout class.
• It regenerates the ScreenEntities for the new layout. This involves creating new ScreenVertexes and ScreenEdges properly linked to the TrackScheme items currently displayed. This calls the cropAndScale() method of the LineageTreeLayout class.

Between the call of layout() and cropAndScale(), the ScreenEntities are invalid. They may correspond to TrackScheme items that moved or disappeared because of the graph change event.

This issue is caused by the fact that several classes are notified when the layout() method is finished, and interrogate the ScreenEntities. For instance for this bug:

1. A graphChanged event ends up in calling the paint() method of the TrackSchemePanel.

2. The paint() method calls the layout() method of the LineageTreeLayout class.

3. When the layout is done, The LayoutListener of the class are notified (via `layoutChanged()).

4. One of these listener is the InertialScreenTransformListener. It notifies its TransformListener (via transformChanged()).

5. This transform listener is the InteractiveDisplayCanvasComponent`. It has several listeners it forward this event to.

6. One of them is the MouseHighlightHandler. Calling its transformChanged() method causes it to try an grab the currently highlighted edge or vertex.

7. To do so, it calls the getEdgeAt() or getVertexAt() method of the AbstractTrackSchemeOverlay class.

8. These two methods rely on ScreenEntities to retrieve the desired TrackScheme item, but at this time, they are not valid. They link to TrackScheme items that may have been deleted or moved. Calling a second graph modification event with these items is what causes the crash.

From @tpietzsch:

The failed tests on Travis are probably all due to AWT being used.
I modified one of the "erroring" tests to explicitly catch all exceptions and print to stdout.
ec34e21

Travis says:

Running org.mastodon.feature.update.UpdateStackSerializationSeriesTest
WARNING: Creating property map for a collection/pool that does not manage PropertyMaps!
WARNING: Creating property map for a collection/pool that does not manage PropertyMaps!
WARNING: Creating property map for a collection/pool that does not manage PropertyMaps!
WARNING: Creating property map for a collection/pool that does not manage PropertyMaps!
Jul 18, 2019 11:21:37 AM java.util.prefs.FileSystemPreferences$1 run
INFO: Created user preferences directory.
TrackScheme style file /home/travis/.mastodon/trackschemestyles.yaml not found. Using builtin styles.
Bdv style file /home/travis/.mastodon/rendersettings.yaml not found. Using builtin styles.
ColorMap file /home/travis/.mastodon/colormaps.yaml not found. Using builtin colormaps.
Feature color mode file /home/travis/.mastodon/colormodes.yaml not found. Using builtin styles.
Keymap list file /home/travis/.mastodon/keymaps//keymaps.yaml not found. Using builtin styles.
java.awt.HeadlessException: 
No X11 DISPLAY variable was set, but this program performed an operation which requires it.
	at java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:204)
	at java.awt.Window.<init>(Window.java:536)
	at java.awt.Frame.<init>(Frame.java:420)
	at java.awt.Frame.<init>(Frame.java:385)
	at javax.swing.SwingUtilities$SharedOwnerFrame.<init>(SwingUtilities.java:1763)
	at javax.swing.SwingUtilities.getSharedOwnerFrame(SwingUtilities.java:1838)
	at javax.swing.JDialog.<init>(JDialog.java:272)
	at javax.swing.JDialog.<init>(JDialog.java:206)
	at org.mastodon.revised.mamut.TgmmImportDialog.<init>(TgmmImportDialog.java:62)
	at org.mastodon.revised.mamut.ProjectManager.<init>(ProjectManager.java:112)
	at org.mastodon.revised.mamut.WindowManager.<init>(WindowManager.java:163)
	at org.mastodon.feature.update.UpdateStackSerializationSeriesTest.createProjectWithPendingChanges(UpdateStackSerializationSeriesTest.java:96)
	at org.mastodon.feature.update.UpdateStackSerializationSeriesTest.test(UpdateStackSerializationSeriesTest.java:75)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59)
	at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:115)
	at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:102)
	at org.apache.maven.surefire.Surefire.run(Surefire.java:180)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:350)
	at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1021)
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.043 sec <<< FAILURE!
A simple workaround is disabling these tests on Travis, something like this
https://github.com/bigdataviewer/bigdataviewer-vistools/blob/d6479aef7e4994e94b68d9c3aee6f160a188d6e4/src/test/java/bdv/util/BdvHandlePanelGarbageCollectionTest.java#L22

A better fix would be to fix ProjectManager etc to be able to run headless.

• core graph coloring based on branch graph features
• branch graph coloring based on branch graph features.
• branch graph coloring based on tag-sets.

...to prevent from accidental position adjustment or removal,
locking involves all edges that link between two locked spots

use-case: Have to sets of spots -- fixed well-tracked set of spots and WIP set of spots

Behaviour to implement.

• Jump between cell divisions with “v" (forward) and “b" (backwards) - in already traced cell lineages.
• Selection behaviours to select
  • a whole track
  • track upward in time
  • track downward in time
    from a selection.

Action framework.

• Generate missing spots across a gap over several frames by interpolating new spot positions.
• Automatic cell naming within tracks. To complete this one, we require a documented naming scheme.

Feature framework.

• Maintain a set of manual labels (10 or so) for each spot. Should be manually editable, ideally a bit like an enum type (you can have 1000 cells but their 'state' label has only 5 values).
• Generate spot colouring from feature.
• Store, make editable and display a manual color for spots.

Currently, for example PoolObjectList.contains(obj) checks whether an object with the same internal id as obj is contained in the list:

    public boolean contains( final Object obj )
    {
        return ( obj instanceof PoolObject )
                ? indices.contains( ( ( PoolObject< ?, ? > ) obj ).getInternalPoolIndex() )
                : false;
    }

This should work sufficiently well for now and for TrackMate3 use case but it's not really correct.
There are two problems:

• obj might be from a different pool.
• the equals() method of the concrete PoolObject instance might be overridden.

In both cases, contains() will do the wrong thing.

PoolObjectList.contains() is just an example of the general problem. We will have to decide on a consistent way to handle equality and then implement it everywhere...