Fiji, the nrrd file format, and HandleExtraFileTypes
47 views
Skip to first unread message
J Collin Poczatek
Apr 10, 2013, 12:45:40 PM4/10/13
to fi...@fiji.sc, ImageJ Interest Group
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.
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.
Curtis Rueden
Apr 18, 2013, 5:34:38 PM4/18/13
to J Collin Poczatek, Fiji Developers, ImageJ Interest Group, Johannes Schindelin
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:
> 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
--
--
Please avoid top-posting, and please make sure to reply-to-all!
Mailing list web interface: 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.
For more options, visit https://groups.google.com/groups/opt_out.
Johannes Schindelin
Apr 18, 2013, 9:09:44 PM4/18/13
to Curtis Rueden, J Collin Poczatek, Fiji Developers, ImageJ Interest Group
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
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.
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
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.
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).
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!
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
Curtis Rueden
Apr 19, 2013, 12:09:21 AM4/19/13
to Johannes Schindelin, J Collin Poczatek, Fiji Developers, ImageJ Interest Group
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:
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
Johannes Schindelin
Apr 19, 2013, 4:42:41 PM4/19/13
to Curtis Rueden, J Collin Poczatek, Fiji Developers, ImageJ Interest Group
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
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."
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.
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.
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
Gregory Jefferis
Apr 20, 2013, 3:49:14 AM4/20/13
to Johannes Schindelin, Curtis Rueden, J Collin Poczatek, Fiji Developers, ImageJ Interest Group
On 19 Apr 2013, at 02:09, Johannes Schindelin wrote:
>> 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
https://github.com/fiji/fiji/blob/master/src-plugins/IO_/src/main/java/io/Nrrd_Reader.java
or receive test images that currently cause trouble.
best wishes,
Greg.
--
Gregory Jefferis, PhD
Division of Neurobiology
MRC Laboratory of Molecular Biology
Francis Crick Avenue
Cambridge Biomedical Campus
Cambridge, CB2 OQH, UK
http://www2.mrc-lmb.cam.ac.uk/group-leaders/h-to-m/g-jefferis
http://www.neuroscience.cam.ac.uk/directory/profile.php?gsxej2
http://flybrain.stanford.edu
Reply all
Reply to author
Forward
0 new messages