Add `Tracks` conversion

[gselzer]

Napari has a Tracks layer that cannot currently be converted into something usable by ImageJ. This would be a problem save for the fact that nothing in PyImageJ really uses tracks/tracking data.

While there is certainly tracking functionality in the ImageJ ecosystem e.g. Trackmate, Mastodon, that functionality is not available without Fiji; we don't expose Fiji in this plugin. Furthermore, there is no abstract tracking data structure in Imglib/Scijava, which would be the prerequisite for conversion.

@tinevez, @ctrueden and I decided to postpone this conversion until we have a use case and available SciJava/Imglib data structures.

[ctrueden]

we don't expose Fiji in this plugin.

We will. This plugin will need to let users configure their Java-side dependencies (i.e. customize the argument to imagej.init). And that can include passing sc.fiji:fiji, and hence having access to TrackMate.

there is no abstract tracking data structure in Imglib/Scijava, which would be the prerequisite for conversion.

Are the TrackMate and Mastodon data structures not interface-driven enough? Or flexible enough?

[gselzer]

We will. This plugin will need to let users configure their Java-side dependencies (i.e. customize the argument to imagej.init). And that can include passing sc.fiji:fiji, and hence having access to TrackMate.

I'd much rather create a napari-trackmate plugin or so instead of trying to shoehorn that functionality into this plugin. I'd rather not write functionality into napari-imagej that may or may not throw exceptions depending on your classpath. Of course, running both of those plugins would require work towards solving napari/npe2#136

Are the TrackMate and Mastodon data structures not interface-driven enough? Or flexible enough?

I'd defer to @tinevez here, but my impression from our discussion on Gitter was that they were not. fiji/trackmate-core was an attempt to do so, but it is not used in trackmate 😕

[ctrueden]

I'd much rather create a napari-trackmate plugin or so instead of trying to shoehorn that functionality into this plugin.

That is fair, and I think I agree. But I do think you should be able to, with napari-imagej and no other napari plugins installed, initialize your ImageJ2 with whatever init string you want (including a locally wrapped ImageJ2 installation if desired). That way, people can invoke Fiji plugins with the search bar, for example—they just won't magically gain additional data structure conversions beyond those fundamentally supported. But for the vast majority of such plugins, they won't need anything extra.

[gselzer]

I'd much rather create a napari-trackmate plugin or so instead of trying to shoehorn that functionality into this plugin.

That is fair, and I think I agree. But I do think you should be able to, with napari-imagej and no other napari plugins installed, initialize your ImageJ2 with whatever init string you want (including a locally wrapped ImageJ2 installation if desired). That way, people can invoke Fiji plugins with the search bar, for example—they just won't magically gain additional data structure conversions beyond those fundamentally supported. But for the vast majority of such plugins, they won't need anything extra.

Yes, I can see that being useful. See #16

[gselzer]

I am going to close this issue; it should be reopened if there is ever a use case for a Tracks layer conversion.