http://imagej.273.s1.nabble.com/Fiji-the-nrrd-file-format-and-HandleExtraFileTypes-tp5002602p5002714.html
). In this case:
Thanks for the reminder about this useful feature. However, I fear it may
be broken at the moment due to the recent server migration. Accessing the
> I agree that the way to go is ImageJ2 (in conjunction with SCIFIO).
> context available. After that, we can use ij-io in
> HandleExtraFileTypes.
Good idea! Doing that had not occurred to me.
> the users of SCIFIO such as KNIME, Icy, ITK etc).
Indeed. However, as pointed out by Jay Unruh in another thread [1], it
loaded. We will need a separate extensibility point for that.
> 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.java>
> In 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.java>
> You 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
>