Fiji, the nrrd file format, and HandleExtraFileTypes

[Colin Poczatek]

Hi all,

I've been trying to wrap my head around Fiji and I'm a little stuck on
the best way to handle this.  This is my train of thought.

- We have 2 image file formats, .im and .nrrd and a plugin that can open
both.

- At the OS level I'd like to be able to associate these file types with
Fiji to take advantage of consistency across platforms and avoid shell
script / classpath sillyness.

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

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

* Because of the above I'm not exactly sure what class is actually
opening .nrrd files.  In the case of a simple .nrrd (eg blobs.gif saved
as a nrrd, which has a bug I think but that's another email) it looks
like io.Nrrd_Reader.  In the case of one of my nrrds it's passed to loci...

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

Thoughts?

Thanks
Collin


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

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

[ctrueden]

Hi Collin,

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

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

> Because of the above I'm not exactly sure what class is actually
> opening .nrrd files.  In the case of a simple .nrrd (eg blobs.gif
> saved as a nrrd, which has a bug I think but that's another email) it
> looks like io.Nrrd_Reader.  In the case of one of my nrrds it's passed
> to loci...

The general execution path is to try Nrrd_Reader first if present. If it
can't handle it for some reason, the same file will then be passed off to
the next thing down the chain, etc., and ultimately Bio-Formats gets to
take a crack at it if everything else failed.

So, it may be that your nrrd that is gets handled by Bio-Formats couldn't
be opened by Nrrd_Reader for some reason. Did you try opening that file
explicitly with each desired plugin, rather than using the File > Open
command? It might shed some light on things.

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

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

Perhaps someone else has a better idea?

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!

Regards,
Curtis


On Wed, Apr 10, 2013 at 11:45 AM, J Collin Poczatek <
[hidden email]> wrote:

> Hi all,
>
> I've been trying to wrap my head around Fiji and I'm a little stuck on the
> best way to handle this.  This is my train of thought.
>
> - We have 2 image file formats, .im and .nrrd and a plugin that can open
> both.
>
> - At the OS level I'd like to be able to associate these file types with
> Fiji to take advantage of consistency across platforms and avoid shell
> script / classpath sillyness.
>
> - 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.
>
> - 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?
>
> * Because of the above I'm not exactly sure what class is actually opening
> .nrrd files.  In the case of a simple .nrrd (eg blobs.gif saved as a nrrd,
> which has a bug I think but that's another email) it looks like
> io.Nrrd_Reader.  In the case of one of my nrrds it's passed to loci...
>
> - 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?
>
> Thoughts?
>
> Thanks
> Collin
>
>
> The information in this e-mail is intended only for the person to whom it
> is
> addressed. If you believe this e-mail was sent to you in error and the
> e-mail
> contains patient information, please contact the Partners Compliance
> HelpLine at
> http://www.partners.org/**complianceline<http://www.partners.org/complianceline>. If the e-mail was sent to you in error
> but does not contain patient information, please contact the sender and
> properly
> dispose of the e-mail.
>
> --
> --
> Please avoid top-posting, and please make sure to reply-to-all!
>
> Mailing list web interface: http://groups.google.com/**group/fiji-devel<http://groups.google.com/group/fiji-devel>
>
> --- You received this message because you are subscribed to the Google
> Groups "Fiji-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to fiji-devel+unsubscribe@**googlegroups.com<fiji-devel%[hidden email]>
> .
> For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
> .
>
>
>

... [show rest of quote]

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

[dscho]

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

[ctrueden]

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
>

... [show rest of quote]

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

[dscho]

Hi Curtis,

On Thu, 18 Apr 2013, Curtis Rueden wrote:

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

Yes, you're correct. I added a script to fiji.git which lets me check
whenever I have to make updates to fiji.sc's Apache configuration that all
the services work as expected: bin/verify-fiji.sc.sh.

Now, the convenient source code search should work again.

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

Great, I will let you know as soon as I finished that work. FWIW I will
also post updates here: http://trac.imagej.net/ticket/1662

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

Well, HandleExtraFileTypes is the class I would like to use for the ij-io
wrapper. So everything HandleExtraFileTypes can do, we will still be able
to do, just better.

For example, the major idea of ImageJ 1.x plugins implementing image
readers was that they extend ImagePlus. That way, the result could be
intercepted by the batch mode. And likewise, IJ.openImage() would still
return the ImagePlus (actually, the reader plugin instance).

But maybe I misunderstood what you meant by overriding the display?

Ciao,
Dscho

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