-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add napari reader that uses SciJava/SCIFIO under the hood #287
Comments
I agree, this would be super slick.
I haven't tried it yet - here are the obstacles I know of:
|
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). |
My thoughts exactly - let's get it done! |
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. |
The TrackMate XML reader is super slick. Why can't we also do one that uses the
IOService
? Looking at thetrackMate_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 theIOService
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!The text was updated successfully, but these errors were encountered: