Posted by
dscho on
Apr 19, 2013; 1:09am
URL: http://imagej.273.s1.nabble.com/Fiji-the-nrrd-file-format-and-HandleExtraFileTypes-tp5002602p5002721.html
Hi Curtis,
thanks for answering this mail. I was meaning to complete the draft I had
in my inbox.
Just a couple of additional comments:
On Thu, 18 Apr 2013, Curtis Rueden wrote:
> > - In Fiji the HandleExtraFileTypes class is inside
> > IO_-2.0.0-SNAPSHOT.jar as opposed to having the .java and .class in
> > plugins/Input-Output/ where you could edit the java.
>
> I can't speak for Johannes, but I think the general idea was to be able
> to version that JAR file so that it could be updated more easily via the
> update mechanism.
It is not only the updating mechanism. Some hardcore hackers might forget
that the majority of users do not have a Java compiler, don't even want
one...
Besides, having the .java instead of the .class would not make things
easier but more complicated: you would have to somehow reconcile all your
local changes with upstream ones. That is definitely not simple. And in
any case not robust.
> > - Also I am most likely blind because I can't find the source for
> > Fiji's HandleExtraFileTypes. It's not in the jar itself and it's not
> > in fiji.git?
>
> It is there. If you go to github.com and press T and type
> "HandleExtraFileTypes" you will find it:
>
>
https://github.com/fiji/fiji/blob/master/src-plugins/IO_/src/main/java/HandleExtraFileTypes.javaIn many cases, the source can be found (as I pointed out in earlier mails)
via
http://fiji.sc/(class-name.java). In this case:
http://fiji.sc/HandleExtraFileTypes.javaYou could also use the Find Jar For Class command to figure out that the
class is in IO_.jar, and then remember that Fiji's sources live in
src-plugins/(jar-name)/src/main/java/ ;-)
> > - This makes me think that editing HandleExtraFileTypes is maybe not
> > the way to go. Is there a better (or any?) way to associate a given
> > file type with a specific plugin? Is there a reason
> > HandleExtraFileTypes is "hidden" in a jar?
>
> The design of ImageJ1 is unfortunately rather limited in this way. There
> are various workarounds, but ultimately the image I/O architecture is
> not extensible. ImageJ2 seeks to address this by making image readers &
> writers into their own type of plugin, which can be assigned a specific
> priority (in other words, there is no more need for
> "HandleExtraFileTypes" in ImageJ2). That said, I realize that doesn't
> help you solve your current problem, today.
I agree that the way to go is ImageJ2 (in conjunction with SCIFIO). With
the work I will complete soon, Fiji will always have an ImageJ2 context
available. After that, we can use ij-io in HandleExtraFileTypes.
That will bring all the benefits of SCIFIO to ImageJ 1.x while avoiding
duplicate work when implementing format readers/writers (no need to
implement things twice, once for ImageJ 1.x and once for all the users of
SCIFIO such as KNIME, Icy, ITK etc).
> So, on to a potential concrete solution:
>
> You could update HandleExtraFileTypes to read some sort of configuration
> file with an explicit mapping of extensions to desired plugins for handling
> such files. Then use that configuration if the given file matches one of
> the config file's known extensions. Submit this change as a Pull Request to
> github.com/fiji/fiji.
>
> After that, all you would need to do is edit the configuration file to
> associate .im and .nrrd files with your plugin, and you are done. The only
> cases where this would be insufficient would be for extensions already
> handled by ImageJ1's built-in I/O (i.e., before HandleExtraFileTypes even
> gets called).
We discussed this several times, including on the Fiji mailing list.
However, in every case we concluded that a proper solution based on
configuration files would be too limiting.
The SCIFIO framework, however, poses a perfect solution. All that is
needed to support a new format is to provide a .jar file. The annotation
(similar to the ImageJ2 commands, in fact, it is the very same technique)
makes it discoverable from SCIFIO without the need to edit a config file,
nor edit HandleExtraFileTypes, nor any other file or configuration.
> Alternately, if your plugin is open source, you could contribute it to
> Fiji, we add it to the official HandleExtraFileTypes, and the problem is
> solved in your particular case!
Of course there is already a Nrrd Reader, provided by Greg Jefferis. I
would rather have its bugs fixed than two incompatible Nrrd Readers with
their respective sets of bugs. After all, we all know who will be stuck
with maintaining the plugin :-D
Ciao,
Dscho
--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html