Login  Register

Re: [fiji-devel] Fiji, the nrrd file format, and HandleExtraFileTypes

Posted by ctrueden on Apr 19, 2013; 4:09am
URL: http://imagej.273.s1.nabble.com/Fiji-the-nrrd-file-format-and-HandleExtraFileTypes-tp5002602p5002714.html

Hi Dscho & everyone,

> 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

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
link above tries to load a wiki page with that name and reports "There is
currently no text in this page."

> 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.

Good idea! Doing that had not occurred to me.

> 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).

Indeed. However, as pointed out by Jay Unruh in another thread [1], it
would still not be quite as powerful as HandleExtraFileTypes in that there
is no obvious way to override the display of the image data after it is
loaded. We will need a separate extensibility point for that.

Regards,
Curtis

[1] https://list.nih.gov/cgi-bin/wa.exe?A2=IMAGEJ;dbbddd59.1304


On Thu, Apr 18, 2013 at 8:09 PM, Johannes Schindelin <
[hidden email]> wrote:

> 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
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html