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.

Noticed by @m-albert

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.

… spots.

Use the new label immg to spot method to get spots AND the
label they come from.

Also better message when closing the editor.

If a ROI exists in the input image when launching the LabKit editor,
only the image and the spots present in the ROI are sent to the
editor. Spots touching the borders are not imported.

Normally pressing space and dragging should move the view, as
for normal ImageJ tools. The removed line was preventing it.

When editing a sub-portion of the image, the spots outside the ROI
are not imported in the editor. It is possible that the user creates
a new label in LabKit that will have the same id that an existing
spot outside the ROI.
Before this fix, the spots in that case were replaced by the new ones,
creating a mess.
The fix consists in reminding what spots are imported in the LabKit
editor, then compariing to this list the new ids when reimporting
from the editor.

Simplified, removing the menu, the segmentation features and the
segmenter features.
Somply done by copy-pasting Matthias classes and removing the lines
with the features to prune.

This time it was due to confusion between a map from spot ID to spots,
and a map from label value to spot.
I fixed it by rewriting everything in terms of label values in the
labeling. So we do not need to keep track of the spot ID anymore. The
labels could be anything. They are still equal to spot ID + 1, because
it is convenient to debug.

Still not good enough, the vertices are not iterated in a monotonic
manner.

Better but still not good enough: some points on the contours
are repeated.

Also do not add duplicate points on the contour (happens often
when there is no smoothing).
Still not good: there are some cases where the loop breaks
too early.

Much cleaner. Still does not work for not simple meshes.
Probably because of border cases where we have vertices that lie
exactly on the plane we are interesecting with.

This class is the 3D counterpart of SpotRoi. It stores the object
shape as a mesh, and has (for now) a few methods to facilitate
painting it and creating it.
The mesh are stored with coordinates relative to the spot center
(mesh center is at 0,0,0). The same for the bounding box. The
mesh coordinates are expected to be in physical coordinates, not
pixel coordinates.

and write them in holders provided by the user.

…bel images.

…eir spots.

We simply reslice the mesh at the Z slice currently displayed,
and paint the intersection as a collection of segments.

I also took the opportunity to refactor a bit the SpotOverlay.

Right now this works but is not optimal:
1/ There are weird stuff happening at the *top* of the mesh: it's
like we miss some part of it.
2/ The slice routine generates a list of disconnected segments. It
does not show when we paint them, but maybe would be nice to
reconstruct the collection of contours resulting from the intersection
of a mesh with a plane.
3/ We could optimize the slice() routinemaybe  by having an index
that sorts triangles by their minZ value, and another index that
sorts them by their maxZ value. This way we could quickly retrieve
the triangles to sort by two binary-search and one set intersection.

While we try to make better slices.

It is working for simple meshes but the ones we have have too
many border cases and make it fail.

Not good enough yet.

At least on star-convex objects, but does not assume they are.
Still very tiny final border cases, where the iteration stops
early at the poles of an object, but it's nothing unsurmontable.
Tomorrow.

Without using the mesh actually, we use the bitmask provided.

With this simple change we get intensity measurements in 3D in a
mesh for free.

So that we can have reading from an input stream.

The meshes are saved in a ZIP file next to the TrackMate XML file.
If the TrackMate file is called: trackmate-file.xml, then the file
that stores the meshes for the model are in a zip file called
trackmate-file.xml.meshes

This zip file just contains the meshes as PLY files, named with the
spots ID. If a spot has an ID equal to 1234, then the PLY file that
stores its mesh is named 1234.ply in the zip file. If the zip file
does not contain such a file then it means that this spot does not
have a mesh. If there is not .meshes file, it means that no spot
have a mesh.

Possible improvement: read all meshes at once, instead of opening and
closing the zip file for every spot.

They are not saved not retrieved by the PLY file reader. Should they?

Try to build actual contours across Z sections of the object,
reusing the ray casting things we have for the iteration.
Very preliminary and has cases where it does not work.
Also has a lot of room for optimization and refactoring.

When everything is bugged, they are important.

Not important, will go away.

Use the contours we got from the ZSlicer. Perform ray cast along
the X axis. Count how many intersection we crosses to determine
whether we are inside or outside.
Works when the slice has several disjoint contours and when some
contours are surrounding the exterior of the mesh (holes inside
the slice).

Relatively optimized:
- Once per spot: get all the Z slices. Involves iterating once through
all the triangles, sorting 2 arrays and a few binary search.
- Once per X line: compute intersections of a ray along the X axis
with all the contours.
- Once per pixel: binary search against intersection to know how
many of them we crossed.

They and translated on the fly when iterating over pixels,
saving and diplaying.

A small routine builds a view of the input (that should be a mask)
where all pixels greater than 0 are set to 1 and to 0 otherwise.
In the case of meshes, this allows using the marching cube algorithm
on real type, interpolating at 0.5 between 0 and 1, and having
smoother meshes than when using the marching cube on boolean types.

Holes in slices are properly handled.
But only in the case of contours generated by meshes that are
manifold and two-manifold.

We don't want to recompute them every time we have to paint the
spot-meshes, or iterate through their pixel. And we have an
optimized version of the ZSlicer that computes Z-slices in batch
with several Zs. This makes the display and iteration in the
TrackMate app much much faster for large meshes.

The difficulty is that we need to specify a scale in XY and in
Z (to simplify the  contours, and compute the Z positions of
the intersections with the image stack slices). But we don't
want to store these scales - which are the pixel size typically -
in the model, that should be independent of a reference to an image.

The solution in this commit consists in receiving these
scales when we require the precomputed Z-slices: the cache is
then recomputed if needed, and we have these scales in the code
when we require the Z-slices

Not sure it is useful, but we can do it for normal spots, rois
and now meshes.

That is: we do not rely on connected components to separate mesh,
but instead simply use the ImgLib2 regions.