Add napari reader that uses SciJava/SCIFIO under the hood

[ctrueden]

The TrackMate XML reader is super slick. Why can't we also do one that uses the IOService? Looking at the trackMate_reader.py code, it looks flexible enough, and on the Java side, we have API for discerning whether a given file path can be opened by the IOService or not. Did you try it, @gselzer? Were there obstacles? If not, it would be so awesome to be able to "just open" so many file types more easily!

[gselzer]

Why can't we also do one that uses the IOService? Looking at the trackMate_reader.py code, it looks flexible enough, and on the Java side, we have API for discerning whether a given file path can be opened by the IOService or not.

I agree, this would be super slick.

Did you try it, @gselzer? Were there obstacles?

I haven't tried it yet - here are the obstacles I know of:

• The npe2 specification requires, in yaml, the filename patterns that the reader supports. I don't know much about SciJava/SCIFIO, but I have enough intuition to this this could be tricky. Of course, we could just accept all filename patterns, but that sounds greedy.
• The actual reader enables runtime evaluation of whether the reader supports a file - see here for how the TrackMate reader works - so I suppose we could boot up the JVM if it hasn't been already and check. I'd hope that the computational footprint of starting up the JVM here wouldn't be too big, I wonder if there is any way to set the priority low such that non-JVM readers could take priority?

[ctrueden]

we could just accept all filename patterns, but that sounds greedy.

I agree it's greedy, but that's what we'll have to do, if we want to implement it correctly. I'm guessing that declaration is just a pre-filter to avoid invoking the plugin reader code at all in some cases? And the fact that the SciJava reader can still return None when it doesn't actually handle that file will cover all the cases properly. So it's just a question of possible performance impact, which we can measure, and if it's noticeably worse file an issue in npe2 with suggestion for improvement (e.g. if it doesn't already have a priority sort, we could score the SciJava reader as very low so it only gets invoked when nothing else would handle it first).

[gselzer]

My thoughts exactly - let's get it done!

[ctrueden]

I suppose we could boot up the JVM if it hasn't been already and check.

Yeah, I'm torn—as a first cut, we might want to just return None if the JVM isn't already running. It sucks that users won't be told to start the JVM or whatnot in that scenario, but I don't know how we could do that in an accurate way in general.