Draft PR that targets the work done towards TrackMate v9. #263
Conversation
This file contains 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
tinevez
changed the title
Shift-click on the button.
And remove debug code.
I am not so sure it is a good idea for the color...
and use the white LUT when the imp is not displayed as a Composite.
Noticed by @MiniMiette
Otherwise we get crashes when we have more than 4k labels. Which is not what Labkit is optimized for but we will see that in a second time. In case we change our minds on the backing integer type, right now the labkit launcher and importer classes are generic.
The re-importing of labels from Tabkit to TrackMate could fail for 2D images and labels with a large index. For instance, it failed consistently when trying to re-import labels with an index larger than 65643. This problem roots in the getSpots() method of LabkitImporter. It relies on a trick: We get the new label image, and create spots from this label image. But we want the new spots to keep track of the index in the label image they were generated from. For this, in 2D, we use the MaskUtils.fromLabelingWithRoi() method. These methods accept an image as last argument used to read a value in the label image within the spot, that is normally used for the quality value of the new spot. But the SpotRoiUtils.from2DLabelingWithRoi() method converted the extra image to ImagePlus (because I was lazy). So the label image was effectively cast on ushort for an IntegerType image, hence the problem with the max label being 65453. The solution is to rewrite the from2DLabelingWithRoi() so that it does not rely on converting to ImagePlus, but on good old iteration with imglib2.
Provided that the detector that is called is cancelable.
Make sure the detection preview panel is slanted at the bottom of its display.
The bug was causing weird issues with unedited spots being deleted, unedited spots being duplicated etc. It took me really long to understand the cause. It was hidden in the step where we go from a label image to a collection of spots. Because spots are polygons, with simplified contours, there might be some pixels on the edges of the object that are not strictly inside the label. In this importer, we read the label value in one go, by storing it in the QUALITY value of the spot, in the MaskUtils class. But since the spots have simplified contours, and since the QUALITY value is the maximal value iterated over, our approach might fail on border cases: - when the contout is approximated and include pixels from another object - and when this object has a label value higher than the lael of the spot. This commit include a temporary fix: we reiterate over the spot but takes the median value iterated over, to make sure we read the correct value for the label. Other attempts will follow, for reference. But a true fix involves making a method that returns a map from label value to spot.
This time we fix it by creating spots that do not have a simplified contours. In that case we strictly iterate over the pixels inside label and get the correct value. However the created spots have a pixelated aspect (contours are not simplified), which might not be what the user wants. We should let them choose. Still not the perfect solution, as mentionned in the previous commmit.
The re-importing of labels from Tabkit to TrackMate could fail for 2D images and labels with a large index. For instance, it failed consistently when trying to re-import labels with an index larger than 65643. This problem roots in the getSpots() method of LabkitImporter. It relies on a trick: We get the new label image, and create spots from this label image. But we want the new spots to keep track of the index in the label image they were generated from. For this, in 2D, we use the SpotRoiUtils.from2DLabelingWithRoi() method. These methods accept an image as last argument used to read a value in the label image within the spot, that is normally used for the quality value of the new spot. But the SpotRoiUtils.from2DLabelingWithRoi() method converted the extra image to ImagePlus (because I was lazy). So the label image was effectively cast on ushort for an IntegerType image, hence the problem with the max label being 65453. The solution is to rewrite the from2DLabelingWithRoi() so that it does not rely on converting to ImagePlus, but on good old iteration with imglib2.
Moving the plugin implementation out of the test class and removing the legacy injector make the test pass in maven.
Instead of the interval, so that this is consistent across TrackMate.
For the beta phase.
This works around a test failure in TrackMatePluginTest caused by the original ImageJ classes being loaded too soon. There are other ways of working around this problem, such as creating a SciJava context more eagerly, but it's a distraction from the business of testing TrackMate, and anyway we don't need imagej-legacy on the classpath. The only reason labkit-ui has imagej-legacy as a dependency is for one line of code, which can be refactored to avoid it, so hopefully the exclusion will be able to disappear later after labkit-ui is updated.
* Avoid SNAPSHOT versions. * Factor out version pins to properties. * Avoid jogamp *-main uber-JARs.
We want to retrieve spots as a map feom labels to corresponding spots.
When editing the whole movie, if the label of a new spot was using the label of an existing spot in another time-point, the existing one was removed. Because the new spot was identified as a modification of the existing one. The solution is to pass to the importer only the list of existing spots in the current time-frame.
Counterpart to the same one in SpotRoiUtils. Nota: the methods signature order should be harmonized between the two utility classes.
There is one discrepancy with the 2D part, linked to TrackMate: In 2D, one connected components will give one spot, even if several connected components belong to the same label. In 3D, it is possible to have one spot made of several disconnected components. Will have to document this.
Not implemented yet, but at least symmetric with the 2D case.
tinevez
changed the title
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.
Support 3D segmentation by adding spots with triangular meshes.
A 3D viewer for TrackMate based on the BVV.
#280
A tool to configure a sub-selection of feature analyzers.
#261
There is now a new 'plugin' that launches a configuration panel for the TrackMate feature analyzers.
It can be launched with the menu item: Edit > Options > Configure TrackMate feature analyzers.... and show this dialog:
It allows selecting or deselecting feature analyzers.
Upon pressing the Save to user defaults button, a JSON file is created:
This selection will be used next time the user launches the TrackMate GUI.
This allows skipping the computation of analyzers that the users do not need. This will become useful in particular for 3D analysis with segmentation, where iterating through all the pixels of all meshes might be very long.
However it brings a risk: because TrackMate does not manage dependencies, the user might remove an analyzer that is needed by another one (example: spot SNR requires spot intensity). This risk is not mitigated yet.
Spot is now an interface, with 3 derived class.
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<7SpotRoi-> spot has a polygon as a contour in 2DSpotMesh-> spot has a 3D meshMore elegant and extensible to app consuming TrackMate trackers with special objects.
The detection preview is cancelable.
Of course it only actually cancels the preview if the detector that is used is itself cancelable.
