loci bioformats importer with custom window

[Unruh, Jay-2]

Hi everyone,

This question is mostly for the bioformats team, but I would like to hear others comments as well.  I rely heavily on a custom plotting window format that I have working importers and exporters for.  This custom plotting window, much like the built-in PlotWindow class displays in a subclass of the ImageWindow with custom buttons that allow for data export and display manipulation.  In my current transition to FIJI, I came up against the recently documented issue of the missing "handleextrafiletypes" class.  So I decided to follow the recommended suggestion of implementing my own bioformats importer by extending the FormatReader class.  Immediately, I ran up against the issue that FormatReader wants to display my image for me via the openBytes method (which circumvents the custom window display and the entire reason my plotting window exists).  I would prefer to load my custom window within the initFile method (which works just fine).  If I return a blank array from the openBytes method, everything works fine, but I have a black image that shows up in addition to my plotting window that I have to manually close.  Alternatively, I can return null from this method, but then the user is constantly bugged by null pointer exceptions.

So here are my questions/suggestions:
1.  Is there a way to tell the FormatReader that I want to handle the display on my own?  If not, I think there should be.  I can think of multiple circumstances under which a developer would like to co-opt the display capabilities of ImageJ for specific file types.  The old handleextrafiletypes worked perfectly for this scenario and I see the new mechanism as removing useful features-something that I feel is a bad idea going forward.

2. Alternatively, is there a programmatic way that I can tell bioformats that my file type should be windowless and/or meta-data only.  This would circumvent the above problem in that I could tell the library to only open my metadata and I would "secretly" open the image in the process.  Of course, this would probably be considered a hack and I would still have the annoying task of closing metadata windows for  each loaded file but at least my users wouldn't be baffled by a blank image or an exception.

3.  Is there a mechanism by which I can tell the FIJI file loader to open custom images outside of the bioformats library.  To be completely honest, I don't really understand why handleextrafiletypes was removed from the distribution.  While I realize that handleextrafiletypes was an opening for buggy code, it seems perfectly reasonable to me to leave it blank and instruct users to ignore it unless they know what they are doing.  In that way, I also don't have to instruct them to change the readers.txt inside the bioformats jar file (which seems to take on an ever changing target of names as time goes on).  This mechanism has also allowed me to implement my own readers for certain file types by default when I wasn't happy with the bioformats library performance or idiosyncrasies.  Of course, the bioformats team does an amazing job of improving support over time, but for the short term custom scenarios I'm not sure I see the negative impact of the handleextrafiletypes methodology.

Thanks,
Jay

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

[ctrueden]

Hi Jay,

> In my current transition to FIJI, I came up against the recently
> documented issue of the missing "handleextrafiletypes" class.

Are you referring to this thread?
    https://groups.google.com/d/msg/fiji-devel/8lWH4PWD21Y/uMbsl1F9jw4J

As noted there, HandleExtraFileTypes is not missing, merely embedded in
IO_.jar.

> So I decided to follow the recommended suggestion of implementing my
> own bioformats importer by extending the FormatReader class.

Sure! I am happy to give advice and assistance.

> Immediately, I ran up against the issue that FormatReader wants to
> display my image for me via the openBytes method (which circumvents
> the custom window display and the entire reason my plotting window
> exists).

The FormatReader class does not want to display anything; all openBytes
does is return an array of bytes. The image display happens in the ImageJ
layer, as part of the Bio-Formats Importer plugin, which is what gets
called by HandleExtraFileTypes.

> I would prefer to load my custom window within the initFile method
> (which works just fine).

I strongly suggest you avoid conflating the loading of your data with its
display. None of the various Bio-Formats readers do any such thing, or have
any dependency on ImageJ. Rather, as I mentioned, the display is handled in
a format-agnostic manner at a higher level. Your current approach will
likely be unusable from outside your plugin, and even more so from outside
ImageJ -- for example, reading your data in MATLAB via the bfopen.m script
will likely have problems. And what about virtual stacks, where planes are
read on demand by openBytes via the BFVirtualStack class? There are many
potential issues.

> If I return a blank array from the openBytes method, everything works
> fine, but I have a black image that shows up in addition to my
> plotting window that I have to manually close.

Right, by default, the Bio-Formats Importer is still going to display the
result, regardless of what else you do in your format reader.

> 1.  Is there a way to tell the FormatReader that I want to handle the
> display on my own?  If not, I think there should be.

The most convenient (i.e., high-level) way is the loci.plugins.BF utility
class. See this plugin for an example:


https://github.com/openmicroscopy/bioformats/blob/v4.4.6/components/loci-plugins/utils/Simple_Read.java#L52

This may be close to what you need. However, if I understand correctly, you
want File Open to read in the ImagePlus but not display it as normal, and
instead have your plugin take care of the display using your custom
ImageWindow extension. There is really no facility in ImageJ1 for that; it
is something we are addressing in ImageJ2.

Is using File Open an absolute requirement for you? If you are willing to
have your own plugin for opening files of your format and displaying them
as you wish, it would make your job much simpler: you could simply invoke
BF.openImagePlus to get the ImagePlus objects without displaying them (or
just embed your file reading code directly in that plugin), then pass those
objects to your custom visualization mechanism.

> Alternatively, is there a programmatic way that I can tell bioformats
> that my file type should be windowless and/or meta-data only.

Every reader has a corresponding ImageJ preference key for windowless
operation (e.g., bioformats.windowless.APNG), and there is a similar global
property for the display mode, too. But let's discuss other potential
solutions first, and come back to that later if necessary.

> Is there a mechanism by which I can tell the FIJI file loader to open
> custom images outside of the bioformats library.

You are looking for another way to customize the File Open command besides
HandleExtraFileTypes and Bio-Formats? As discussed in the other thread
linked above, there is no other way. But I really like the idea Johannes
proposed about solving it by making SCIFIO available from ImageJ1. However,
you would still need another extensibility point for custom displays, which
is not something we have discussed tackling in ImageJ1, but rather only in
ImageJ2. Off the top of my head, I am not sure how feasible it would be to
expose an ImageJ2-based solution while Fiji is running in ImageJ1 mode.

> To be completely honest, I don't really understand why
> handleextrafiletypes was removed from the distribution.

I agree that it would be convenient to be able to override the
HandleExtraFileTypes in IO_.jar with a custom one in the plugins folder, to
avoid modifying the JAR file. Johannes, what do you think?

Regards,
Curtis


On Tue, Apr 16, 2013 at 4:16 PM, Unruh, Jay <[hidden email]> wrote:

> Hi everyone,
>
> This question is mostly for the bioformats team, but I would like to hear
> others comments as well.  I rely heavily on a custom plotting window format
> that I have working importers and exporters for.  This custom plotting
> window, much like the built-in PlotWindow class displays in a subclass of
> the ImageWindow with custom buttons that allow for data export and display
> manipulation.  In my current transition to FIJI, I came up against the
> recently documented issue of the missing "handleextrafiletypes" class.  So
> I decided to follow the recommended suggestion of implementing my own
> bioformats importer by extending the FormatReader class.  Immediately, I
> ran up against the issue that FormatReader wants to display my image for me
> via the openBytes method (which circumvents the custom window display and
> the entire reason my plotting window exists).  I would prefer to load my
> custom window within the initFile method (which works just fine).  If I
> return a blank array from the openBytes method, everything works fine, but
> I have a black image that shows up in addition to my plotting window that I
> have to manually close.  Alternatively, I can return null from this method,
> but then the user is constantly bugged by null pointer exceptions.
>
> So here are my questions/suggestions:
> 1.  Is there a way to tell the FormatReader that I want to handle the
> display on my own?  If not, I think there should be.  I can think of
> multiple circumstances under which a developer would like to co-opt the
> display capabilities of ImageJ for specific file types.  The old
> handleextrafiletypes worked perfectly for this scenario and I see the new
> mechanism as removing useful features-something that I feel is a bad idea
> going forward.
>
> 2. Alternatively, is there a programmatic way that I can tell bioformats
> that my file type should be windowless and/or meta-data only.  This would
> circumvent the above problem in that I could tell the library to only open
> my metadata and I would "secretly" open the image in the process.  Of
> course, this would probably be considered a hack and I would still have the
> annoying task of closing metadata windows for  each loaded file but at
> least my users wouldn't be baffled by a blank image or an exception.
>
> 3.  Is there a mechanism by which I can tell the FIJI file loader to open
> custom images outside of the bioformats library.  To be completely honest,
> I don't really understand why handleextrafiletypes was removed from the
> distribution.  While I realize that handleextrafiletypes was an opening for
> buggy code, it seems perfectly reasonable to me to leave it blank and
> instruct users to ignore it unless they know what they are doing.  In that
> way, I also don't have to instruct them to change the readers.txt inside
> the bioformats jar file (which seems to take on an ever changing target of
> names as time goes on).  This mechanism has also allowed me to implement my
> own readers for certain file types by default when I wasn't happy with the
> bioformats library performance or idiosyncrasies.  Of course, the
> bioformats team does an amazing job of improving support over time, but for
> the short term custom scenarios I'm not sure I see the negative impact of
> the handleextrafiletypes methodology.
>
> Thanks,
> Jay
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

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

[Unruh, Jay-2]

Hi Curtis,

Unfortunately, until ImageJ2, I have no choice but to link my data import to the display--ImageJ doesn't currently have plotting or histogramming facilities that can be easily manipulated by the user.  Without this, I might as well just save an image of the plot as a jpg.  Given that this is a stackless format intended only for ImageJ, the virtual stacking and matlab issues are mostly irrelevant.

I do rely heavily on the open facilities because of drag and drop, but I am now implementing a shortcut drop window like the one that bioformats uses and it seems to provide the facilities I need for everything but macro recording which I can handle manually.

As you mentioned, it would still be nice to have HandleExtraFileTypes outside of the jar.  If it is only intended for personal customization, there is no reason it needs to be part of the update process at all.  Everything else can take place inside the jar as is.  This would essentially require creation of a secondary HandleExtraFileTypes class, but I'm not sure that's such a big deal.  I am essentially doing that with my shortcut window--calling a different HandleExtraFileTypes class to circumvent the default processing.

I also think that there should be some programmatic mechanism to specify windowless and no display options via the bioformats library.  I understand why you don't want to encourage linked data displays, but that is ultimately up to each developer given that they can always create a workaround like I did with my shortcut window.  In some ways, it encourages developers to not utilize the bioformats extensions because of inflexibility.

Jay

-----Original Message-----
From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of Curtis Rueden
Sent: Thursday, April 18, 2013 10:55 PM
To: [hidden email]
Subject: Re: loci bioformats importer with custom window

Hi Jay,

> In my current transition to FIJI, I came up against the recently
> documented issue of the missing "handleextrafiletypes" class.

Are you referring to this thread?
    https://groups.google.com/d/msg/fiji-devel/8lWH4PWD21Y/uMbsl1F9jw4J

As noted there, HandleExtraFileTypes is not missing, merely embedded in IO_.jar.

> So I decided to follow the recommended suggestion of implementing my
> own bioformats importer by extending the FormatReader class.

Sure! I am happy to give advice and assistance.

> Immediately, I ran up against the issue that FormatReader wants to
> display my image for me via the openBytes method (which circumvents
> the custom window display and the entire reason my plotting window
> exists).

The FormatReader class does not want to display anything; all openBytes does is return an array of bytes. The image display happens in the ImageJ layer, as part of the Bio-Formats Importer plugin, which is what gets called by HandleExtraFileTypes.

> I would prefer to load my custom window within the initFile method
> (which works just fine).

I strongly suggest you avoid conflating the loading of your data with its display. None of the various Bio-Formats readers do any such thing, or have any dependency on ImageJ. Rather, as I mentioned, the display is handled in a format-agnostic manner at a higher level. Your current approach will likely be unusable from outside your plugin, and even more so from outside ImageJ -- for example, reading your data in MATLAB via the bfopen.m script will likely have problems. And what about virtual stacks, where planes are read on demand by openBytes via the BFVirtualStack class? There are many potential issues.

> If I return a blank array from the openBytes method, everything works
> fine, but I have a black image that shows up in addition to my
> plotting window that I have to manually close.

Right, by default, the Bio-Formats Importer is still going to display the result, regardless of what else you do in your format reader.

> 1.  Is there a way to tell the FormatReader that I want to handle the
> display on my own?  If not, I think there should be.

The most convenient (i.e., high-level) way is the loci.plugins.BF utility class. See this plugin for an example:


https://github.com/openmicroscopy/bioformats/blob/v4.4.6/components/loci-plugins/utils/Simple_Read.java#L52

This may be close to what you need. However, if I understand correctly, you want File Open to read in the ImagePlus but not display it as normal, and instead have your plugin take care of the display using your custom ImageWindow extension. There is really no facility in ImageJ1 for that; it is something we are addressing in ImageJ2.

Is using File Open an absolute requirement for you? If you are willing to have your own plugin for opening files of your format and displaying them as you wish, it would make your job much simpler: you could simply invoke BF.openImagePlus to get the ImagePlus objects without displaying them (or just embed your file reading code directly in that plugin), then pass those objects to your custom visualization mechanism.

> Alternatively, is there a programmatic way that I can tell bioformats
> that my file type should be windowless and/or meta-data only.

Every reader has a corresponding ImageJ preference key for windowless operation (e.g., bioformats.windowless.APNG), and there is a similar global property for the display mode, too. But let's discuss other potential solutions first, and come back to that later if necessary.

> Is there a mechanism by which I can tell the FIJI file loader to open
> custom images outside of the bioformats library.

You are looking for another way to customize the File Open command besides HandleExtraFileTypes and Bio-Formats? As discussed in the other thread linked above, there is no other way. But I really like the idea Johannes proposed about solving it by making SCIFIO available from ImageJ1. However, you would still need another extensibility point for custom displays, which is not something we have discussed tackling in ImageJ1, but rather only in ImageJ2. Off the top of my head, I am not sure how feasible it would be to expose an ImageJ2-based solution while Fiji is running in ImageJ1 mode.

> To be completely honest, I don't really understand why
> handleextrafiletypes was removed from the distribution.

I agree that it would be convenient to be able to override the HandleExtraFileTypes in IO_.jar with a custom one in the plugins folder, to avoid modifying the JAR file. Johannes, what do you think?

Regards,
Curtis


On Tue, Apr 16, 2013 at 4:16 PM, Unruh, Jay <[hidden email]> wrote:

> Hi everyone,
>
> This question is mostly for the bioformats team, but I would like to
> hear others comments as well.  I rely heavily on a custom plotting
> window format that I have working importers and exporters for.  This
> custom plotting window, much like the built-in PlotWindow class
> displays in a subclass of the ImageWindow with custom buttons that
> allow for data export and display manipulation.  In my current
> transition to FIJI, I came up against the recently documented issue of
> the missing "handleextrafiletypes" class.  So I decided to follow the
> recommended suggestion of implementing my own bioformats importer by
> extending the FormatReader class.  Immediately, I ran up against the
> issue that FormatReader wants to display my image for me via the
> openBytes method (which circumvents the custom window display and the
> entire reason my plotting window exists).  I would prefer to load my
> custom window within the initFile method (which works just fine).  If
> I return a blank array from the openBytes method, everything works
> fine, but I have a black image that shows up in addition to my
> plotting window that I have to manually close.  Alternatively, I can return null from this method, but then the user is constantly bugged by null pointer exceptions.
>
> So here are my questions/suggestions:
> 1.  Is there a way to tell the FormatReader that I want to handle the
> display on my own?  If not, I think there should be.  I can think of
> multiple circumstances under which a developer would like to co-opt
> the display capabilities of ImageJ for specific file types.  The old
> handleextrafiletypes worked perfectly for this scenario and I see the
> new mechanism as removing useful features-something that I feel is a
> bad idea going forward.
>
> 2. Alternatively, is there a programmatic way that I can tell
> bioformats that my file type should be windowless and/or meta-data
> only.  This would circumvent the above problem in that I could tell
> the library to only open my metadata and I would "secretly" open the
> image in the process.  Of course, this would probably be considered a
> hack and I would still have the annoying task of closing metadata
> windows for  each loaded file but at least my users wouldn't be baffled by a blank image or an exception.
>
> 3.  Is there a mechanism by which I can tell the FIJI file loader to
> open custom images outside of the bioformats library.  To be
> completely honest, I don't really understand why handleextrafiletypes
> was removed from the distribution.  While I realize that
> handleextrafiletypes was an opening for buggy code, it seems perfectly
> reasonable to me to leave it blank and instruct users to ignore it
> unless they know what they are doing.  In that way, I also don't have
> to instruct them to change the readers.txt inside the bioformats jar
> file (which seems to take on an ever changing target of names as time
> goes on).  This mechanism has also allowed me to implement my own
> readers for certain file types by default when I wasn't happy with the
> bioformats library performance or idiosyncrasies.  Of course, the
> bioformats team does an amazing job of improving support over time,
> but for the short term custom scenarios I'm not sure I see the negative impact of the handleextrafiletypes methodology.
>
> Thanks,
> Jay
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

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

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

[ctrueden]

Hi Jay,

> I also think that there should be some programmatic mechanism to
> specify windowless and no display options via the bioformats library.

Understood. As I said, there are API calls for doing everything
programmatically, just not via File Open.

I briefly explored a one hack workaround for you, using the ImageJ
preference keys I mentioned before:

    windowless = call("ij.Prefs.get", "bioformats.windowless", "false");
    stackFormat = call("ij.Prefs.get", "bioformats.stackFormat",
"Hyperstack");
    // override the settings of the Bio-Formats Importer
    call("ij.Prefs.set", "bioformats.windowless", "true");
    call("ij.Prefs.set", "bioformats.stackFormat", "Metadata only");
    // open the file
    file = "/Users/curtis/data/image.zvi";
    open(file);
    // put the settings back the way they were before
    call("ij.Prefs.set", "bioformats.windowless", windowless);
    call("ij.Prefs.set", "bioformats.stackFormat", stackFormat);

Worked in my tests to suppress the Bio-Formats Import Options dialog as
well as the image window popping up (and actually, for reasons unknown, no
metadata window appears either). Perhaps this will be enough to keep you
going for the time being?

Otherwise, given your background as a developer, and the fact that you are
trying to do something rather unusual and currently unsupported, I cannot
afford to invest much more time to help. However, I will list a couple of
other avenues you could pursue if you want to:

- Use Javassist to manipulate behavior of core ImageJ1. We do this to
facilitate compatibility between IJ2 and IJ1. This is also how Fiji makes
its changes to the core behavior, such as the title bar saying "(Fiji Is
Just) ImageJ".

- Submit a patch (pull request for fiji/fiji on GitHub) for
HandleExtraFileTypes that enables your use case somehow. Potentially adding
support for the "secondary HEFT" as you mention, or similar.

- Submit a patch (pull request for openmicroscopy/bioformats on GitHub) for
the Bio-Formats Importer that enables your use case somehow. Probably
adding more configurability via either ImageJ preferences or system
properties, since there would be no way to pass explicit additional
arguments to ImageJ's open command. E.g., you could add a new stackFormat
"Nothing" that really pops up *no* windows (not even metadata).

Again, sorry that I can't spend more time to help you in the short term.
The only consolation I can offer is that we are thinking about these sorts
of things for ImageJ2 and it has many more "seams" for extensibility and
injecting your own behavior at many different levels.

Regards,
Curtis



On Fri, Apr 19, 2013 at 1:14 PM, Unruh, Jay <[hidden email]> wrote:

> Hi Curtis,
>
> Unfortunately, until ImageJ2, I have no choice but to link my data import
> to the display--ImageJ doesn't currently have plotting or histogramming
> facilities that can be easily manipulated by the user.  Without this, I
> might as well just save an image of the plot as a jpg.  Given that this is
> a stackless format intended only for ImageJ, the virtual stacking and
> matlab issues are mostly irrelevant.
>
> I do rely heavily on the open facilities because of drag and drop, but I
> am now implementing a shortcut drop window like the one that bioformats
> uses and it seems to provide the facilities I need for everything but macro
> recording which I can handle manually.
>
> As you mentioned, it would still be nice to have HandleExtraFileTypes
> outside of the jar.  If it is only intended for personal customization,
> there is no reason it needs to be part of the update process at all.
>  Everything else can take place inside the jar as is.  This would
> essentially require creation of a secondary HandleExtraFileTypes class, but
> I'm not sure that's such a big deal.  I am essentially doing that with my
> shortcut window--calling a different HandleExtraFileTypes class to
> circumvent the default processing.
>
> I also think that there should be some programmatic mechanism to specify
> windowless and no display options via the bioformats library.  I understand
> why you don't want to encourage linked data displays, but that is
> ultimately up to each developer given that they can always create a
> workaround like I did with my shortcut window.  In some ways, it encourages
> developers to not utilize the bioformats extensions because of
> inflexibility.
>
> Jay
>
> -----Original Message-----
> From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of
> Curtis Rueden
> Sent: Thursday, April 18, 2013 10:55 PM
> To: [hidden email]
> Subject: Re: loci bioformats importer with custom window
>
> Hi Jay,
>
> > In my current transition to FIJI, I came up against the recently
> > documented issue of the missing "handleextrafiletypes" class.
>
> Are you referring to this thread?
>     https://groups.google.com/d/msg/fiji-devel/8lWH4PWD21Y/uMbsl1F9jw4J
>
> As noted there, HandleExtraFileTypes is not missing, merely embedded in
> IO_.jar.
>
> > So I decided to follow the recommended suggestion of implementing my
> > own bioformats importer by extending the FormatReader class.
>
> Sure! I am happy to give advice and assistance.
>
> > Immediately, I ran up against the issue that FormatReader wants to
> > display my image for me via the openBytes method (which circumvents
> > the custom window display and the entire reason my plotting window
> > exists).
>
> The FormatReader class does not want to display anything; all openBytes
> does is return an array of bytes. The image display happens in the ImageJ
> layer, as part of the Bio-Formats Importer plugin, which is what gets
> called by HandleExtraFileTypes.
>
> > I would prefer to load my custom window within the initFile method
> > (which works just fine).
>
> I strongly suggest you avoid conflating the loading of your data with its
> display. None of the various Bio-Formats readers do any such thing, or have
> any dependency on ImageJ. Rather, as I mentioned, the display is handled in
> a format-agnostic manner at a higher level. Your current approach will
> likely be unusable from outside your plugin, and even more so from outside
> ImageJ -- for example, reading your data in MATLAB via the bfopen.m script
> will likely have problems. And what about virtual stacks, where planes are
> read on demand by openBytes via the BFVirtualStack class? There are many
> potential issues.
>
> > If I return a blank array from the openBytes method, everything works
> > fine, but I have a black image that shows up in addition to my
> > plotting window that I have to manually close.
>
> Right, by default, the Bio-Formats Importer is still going to display the
> result, regardless of what else you do in your format reader.
>
> > 1.  Is there a way to tell the FormatReader that I want to handle the
> > display on my own?  If not, I think there should be.
>
> The most convenient (i.e., high-level) way is the loci.plugins.BF utility
> class. See this plugin for an example:
>
>
>
> https://github.com/openmicroscopy/bioformats/blob/v4.4.6/components/loci-plugins/utils/Simple_Read.java#L52
>
> This may be close to what you need. However, if I understand correctly,
> you want File Open to read in the ImagePlus but not display it as normal,
> and instead have your plugin take care of the display using your custom
> ImageWindow extension. There is really no facility in ImageJ1 for that; it
> is something we are addressing in ImageJ2.
>
> Is using File Open an absolute requirement for you? If you are willing to
> have your own plugin for opening files of your format and displaying them
> as you wish, it would make your job much simpler: you could simply invoke
> BF.openImagePlus to get the ImagePlus objects without displaying them (or
> just embed your file reading code directly in that plugin), then pass those
> objects to your custom visualization mechanism.
>
> > Alternatively, is there a programmatic way that I can tell bioformats
> > that my file type should be windowless and/or meta-data only.
>
> Every reader has a corresponding ImageJ preference key for windowless
> operation (e.g., bioformats.windowless.APNG), and there is a similar global
> property for the display mode, too. But let's discuss other potential
> solutions first, and come back to that later if necessary.
>
> > Is there a mechanism by which I can tell the FIJI file loader to open
> > custom images outside of the bioformats library.
>
> You are looking for another way to customize the File Open command besides
> HandleExtraFileTypes and Bio-Formats? As discussed in the other thread
> linked above, there is no other way. But I really like the idea Johannes
> proposed about solving it by making SCIFIO available from ImageJ1. However,
> you would still need another extensibility point for custom displays, which
> is not something we have discussed tackling in ImageJ1, but rather only in
> ImageJ2. Off the top of my head, I am not sure how feasible it would be to
> expose an ImageJ2-based solution while Fiji is running in ImageJ1 mode.
>
> > To be completely honest, I don't really understand why
> > handleextrafiletypes was removed from the distribution.
>
> I agree that it would be convenient to be able to override the
> HandleExtraFileTypes in IO_.jar with a custom one in the plugins folder, to
> avoid modifying the JAR file. Johannes, what do you think?
>
> Regards,
> Curtis
>
>
> On Tue, Apr 16, 2013 at 4:16 PM, Unruh, Jay <[hidden email]> wrote:
>
> > Hi everyone,
> >
> > This question is mostly for the bioformats team, but I would like to
> > hear others comments as well.  I rely heavily on a custom plotting
> > window format that I have working importers and exporters for.  This
> > custom plotting window, much like the built-in PlotWindow class
> > displays in a subclass of the ImageWindow with custom buttons that
> > allow for data export and display manipulation.  In my current
> > transition to FIJI, I came up against the recently documented issue of
> > the missing "handleextrafiletypes" class.  So I decided to follow the
> > recommended suggestion of implementing my own bioformats importer by
> > extending the FormatReader class.  Immediately, I ran up against the
> > issue that FormatReader wants to display my image for me via the
> > openBytes method (which circumvents the custom window display and the
> > entire reason my plotting window exists).  I would prefer to load my
> > custom window within the initFile method (which works just fine).  If
> > I return a blank array from the openBytes method, everything works
> > fine, but I have a black image that shows up in addition to my
> > plotting window that I have to manually close.  Alternatively, I can
> return null from this method, but then the user is constantly bugged by
> null pointer exceptions.
> >
> > So here are my questions/suggestions:
> > 1.  Is there a way to tell the FormatReader that I want to handle the
> > display on my own?  If not, I think there should be.  I can think of
> > multiple circumstances under which a developer would like to co-opt
> > the display capabilities of ImageJ for specific file types.  The old
> > handleextrafiletypes worked perfectly for this scenario and I see the
> > new mechanism as removing useful features-something that I feel is a
> > bad idea going forward.
> >
> > 2. Alternatively, is there a programmatic way that I can tell
> > bioformats that my file type should be windowless and/or meta-data
> > only.  This would circumvent the above problem in that I could tell
> > the library to only open my metadata and I would "secretly" open the
> > image in the process.  Of course, this would probably be considered a
> > hack and I would still have the annoying task of closing metadata
> > windows for  each loaded file but at least my users wouldn't be baffled
> by a blank image or an exception.
> >
> > 3.  Is there a mechanism by which I can tell the FIJI file loader to
> > open custom images outside of the bioformats library.  To be
> > completely honest, I don't really understand why handleextrafiletypes
> > was removed from the distribution.  While I realize that
> > handleextrafiletypes was an opening for buggy code, it seems perfectly
> > reasonable to me to leave it blank and instruct users to ignore it
> > unless they know what they are doing.  In that way, I also don't have
> > to instruct them to change the readers.txt inside the bioformats jar
> > file (which seems to take on an ever changing target of names as time
> > goes on).  This mechanism has also allowed me to implement my own
> > readers for certain file types by default when I wasn't happy with the
> > bioformats library performance or idiosyncrasies.  Of course, the
> > bioformats team does an amazing job of improving support over time,
> > but for the short term custom scenarios I'm not sure I see the negative
> impact of the handleextrafiletypes methodology.
> >
> > Thanks,
> > Jay
>

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

[dscho]

Hi Curtis,

On Thu, 18 Apr 2013, Curtis Rueden wrote:

> > To be completely honest, I don't really understand why
> > handleextrafiletypes was removed from the distribution.
>
> I agree that it would be convenient to be able to override the
> HandleExtraFileTypes in IO_.jar with a custom one in the plugins folder,
> to avoid modifying the JAR file. Johannes, what do you think?

First of all, it was never removed. Instead, it was put into to most
logical place: IO_.jar (I might have mentioned that before... :-)

And then: sure, we could special-case the file
plugins/HandleExtraFileTypes.class and put it first in the classpath so
that it certainly overrides IO_.jar's.

But at what price?

- All the updates in IO_.jar -- including the upcoming SCIFIO one -- would
  be lost, leading to bug reports *I* have to deal with.

- It still would not be customizable, except if there is a .java file,
  too.

- Compiling said .java requires javac to be available, which is not
  generally the case.

- When the classpath is discovered, the .java might be there, but not the
  .class, excluding it from the classpath.

- Since HandleExtraFileTypes.java is not a plugin, it would not be handled
  by Refresh_Javas.jar, so it would not automatically be recompiled when
  the .java file is newer, again resulting in bug reports *I* have to deal
  with.

- In reality, only very few people would need that feature to begin with.
  The vast majority of users do not even want to *know* about that class,
  let alone how to modify Java code.

Ciao,
Johannes

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

[dscho]

Hi Curtis,

On Fri, 19 Apr 2013, Johannes Schindelin wrote:

> On Thu, 18 Apr 2013, Curtis Rueden wrote:
>
> > > To be completely honest, I don't really understand why
> > > handleextrafiletypes was removed from the distribution.
> >
> > I agree that it would be convenient to be able to override the
> > HandleExtraFileTypes in IO_.jar with a custom one in the plugins
> > folder, to avoid modifying the JAR file. Johannes, what do you think?
>
> First of all, it was never removed. Instead, it was put into to most
> logical place: IO_.jar (I might have mentioned that before... :-)
>
> And then: sure, we could special-case the file
> plugins/HandleExtraFileTypes.class and put it first in the classpath so
> that it certainly overrides IO_.jar's.
>
> But at what price?
>
> - All the updates in IO_.jar -- including the upcoming SCIFIO one -- would
>   be lost, leading to bug reports *I* have to deal with.
>
> - It still would not be customizable, except if there is a .java file,
>   too.
>
> - Compiling said .java requires javac to be available, which is not
>   generally the case.
>
> - When the classpath is discovered, the .java might be there, but not the
>   .class, excluding it from the classpath.
>
> - Since HandleExtraFileTypes.java is not a plugin, it would not be handled
>   by Refresh_Javas.jar, so it would not automatically be recompiled when
>   the .java file is newer, again resulting in bug reports *I* have to deal
>   with.
>
> - In reality, only very few people would need that feature to begin with.
>   The vast majority of users do not even want to *know* about that class,
>   let alone how to modify Java code.

To clarify: I really think it would be a much better idea to work on that
SCIFIO integration, rather than spending dozens of hours on
above-mentioned idea (and it would take that much time if I'd have to
implement it because of testing to make sure that nothing breaks that
works currently) only to revert the whole shebang when we have a
SCIFIO-based HandleExtraFileTypes.

Ciao,
Dscho

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

[ctrueden]

Hi Dscho,

> I really think it would be a much better idea to work on that SCIFIO
> integration

As long as we can cover use cases like Jay's, I agree. That is, it should
be possible to customize not only the image I/O, but the display of the
resulting ImagePlus object. My concern with the SCIFIO idea is that SCIFIO
is really an extensibility point for I/O, not image display. How would you
propose Jay solve his specific use case in your proposed scenario?

Thanks,
Curtis


On Sun, Apr 21, 2013 at 6:40 PM, Johannes Schindelin <
[hidden email]> wrote:

> Hi Curtis,
>
> On Fri, 19 Apr 2013, Johannes Schindelin wrote:
>
> > On Thu, 18 Apr 2013, Curtis Rueden wrote:
> >
> > > > To be completely honest, I don't really understand why
> > > > handleextrafiletypes was removed from the distribution.
> > >
> > > I agree that it would be convenient to be able to override the
> > > HandleExtraFileTypes in IO_.jar with a custom one in the plugins
> > > folder, to avoid modifying the JAR file. Johannes, what do you think?
> >
> > First of all, it was never removed. Instead, it was put into to most
> > logical place: IO_.jar (I might have mentioned that before... :-)
> >
> > And then: sure, we could special-case the file
> > plugins/HandleExtraFileTypes.class and put it first in the classpath so
> > that it certainly overrides IO_.jar's.
> >
> > But at what price?
> >
> > - All the updates in IO_.jar -- including the upcoming SCIFIO one --
> would
> >   be lost, leading to bug reports *I* have to deal with.
> >
> > - It still would not be customizable, except if there is a .java file,
> >   too.
> >
> > - Compiling said .java requires javac to be available, which is not
> >   generally the case.
> >
> > - When the classpath is discovered, the .java might be there, but not the
> >   .class, excluding it from the classpath.
> >
> > - Since HandleExtraFileTypes.java is not a plugin, it would not be
> handled
> >   by Refresh_Javas.jar, so it would not automatically be recompiled when
> >   the .java file is newer, again resulting in bug reports *I* have to
> deal
> >   with.
> >
> > - In reality, only very few people would need that feature to begin with.
> >   The vast majority of users do not even want to *know* about that class,
> >   let alone how to modify Java code.
>
> To clarify: I really think it would be a much better idea to work on that
> SCIFIO integration, rather than spending dozens of hours on
> above-mentioned idea (and it would take that much time if I'd have to
> implement it because of testing to make sure that nothing breaks that
> works currently) only to revert the whole shebang when we have a
> SCIFIO-based HandleExtraFileTypes.
>
> Ciao,
> Dscho
>

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

[dscho]

Hi Curtis,

On Mon, 22 Apr 2013, Curtis Rueden wrote:

> > I really think it would be a much better idea to work on that SCIFIO
> > integration
>
> As long as we can cover use cases like Jay's, I agree. That is, it
> should be possible to customize not only the image I/O, but the display
> of the resulting ImagePlus object. My concern with the SCIFIO idea is
> that SCIFIO is really an extensibility point for I/O, not image display.
> How would you propose Jay solve his specific use case in your proposed
> scenario?

It is very easy to obtain an ImagePlus instance by calling IJ.openImage()
from a custom plugin and do with that ImagePlus whatever you want,
including displaying in a non-standard way.

The only problem is that readers are in general written using only the
contract of PlugIn, but not the obscure and little-known convention for
readers. The ImageJ API never enforced readers to adhere to the convention
that the passed argument should be interpreted as a file path, and that
the plugin should extend (and populate) ImagePlus.

Readers not heeding that convention might still be called by
HandleExtraFileTypes, but they will always display the files themselves
and then HandleExtraFileTypes returns null.

The essence of the involved call stack:

https://github.com/fiji/imagej1/blob/master/ij/IJ.java#L1557
https://github.com/fiji/imagej1/blob/master/ij/io/Opener.java#L306
https://github.com/fiji/imagej1/blob/master/ij/io/Opener.java#L434
https://github.com/fiji/fiji/blob/master/src-plugins/IO_/src/main/java/HandleExtraFileTypes.java#L396
https://github.com/fiji/fiji/blob/master/src-plugins/IO_/src/main/java/HandleExtraFileTypes.java#L433

However, with the HandleExtraFileTypes/SCIFIO interaction we can adhere to
that reader convention.

The only problem with that convention is that it is limited to a single
ImagePlus, so if you want to support a file format that encodes more than
a single image, or images with more than the five hard-coded dimensions X,
Y, Z, channel, time, you simply cannot return it for use with
IJ.openImage. You *have* to display it in the ImageJ 1.x plugin.

But in the case of such images, you most likely are limited by other
places in ImageJ 1.x, or worse, by plugins using the previous convention
that ImageStacks are limited to representing X, Y, Z stacks. Therefore, I
would highly recommend to go ImageJ2 in such a case anyway.

Ciao,
Dscho

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

[Unruh, Jay-2]

Curtis and Johannes,

Firstly, I am more than happy with the workaround Curtis proposed that involves programmatic bioformats preferences manipulation and subsequent opening of the image via initFile.  Given that my use case is fairly unique, I'm not sure we need to extend things beyond that at this point.  For that matter, my workaround of a drag-n-drop window also suffices.

As for the issue of custom display, I'm not entirely sure I understand what Johannes is proposing.  A call to IJ.openImage() would fail in my circumstance unless I modify handleextrafiletypes, because my image format is not a tif or any other recognized format.  Alternatively, my openBytes could display an empty ImagePlus which I could then draw my plot and buttons on.  This would require me to instantiate my plot window in initFile and then call back to it from openBytes, sending it the displayed ImagePlus.  Actually, this would be problematic given that the ImagePlus is not yet displayed when openBytes returns and there is no reference to it yet.  Is there some sort of notification I can implement that would tell my code when the ImagePlus is displayed and provide a reference to it so I can modify it?  I know the ImagePlus reader has status listeners, but I'm not sure how to gain access to those via the FormatReader.

I like the idea of an ImageJ2 implementation, though I'm not quite familiar enough with the data service to know how to write one tailored to my data type (multiple xy data vectors of varying length).  My plan  was to wait until the examples were relatively well fleshed out or until the histogram was implemented.  I feel that I am a relatively decent java programmer but the flexibility which with ImageJ2 (necessarily) handles data types and object references makes it difficult for me to utilize these tools without a fairly complete example.

Thanks,
Jay

-----Original Message-----
From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of Johannes Schindelin
Sent: Monday, April 22, 2013 5:46 PM
To: [hidden email]
Subject: Re: loci bioformats importer with custom window

Hi Curtis,

On Mon, 22 Apr 2013, Curtis Rueden wrote:

> > I really think it would be a much better idea to work on that SCIFIO
> > integration
>
> As long as we can cover use cases like Jay's, I agree. That is, it
> should be possible to customize not only the image I/O, but the
> display of the resulting ImagePlus object. My concern with the SCIFIO
> idea is that SCIFIO is really an extensibility point for I/O, not image display.
> How would you propose Jay solve his specific use case in your proposed
> scenario?

It is very easy to obtain an ImagePlus instance by calling IJ.openImage() from a custom plugin and do with that ImagePlus whatever you want, including displaying in a non-standard way.

The only problem is that readers are in general written using only the contract of PlugIn, but not the obscure and little-known convention for readers. The ImageJ API never enforced readers to adhere to the convention that the passed argument should be interpreted as a file path, and that the plugin should extend (and populate) ImagePlus.

Readers not heeding that convention might still be called by HandleExtraFileTypes, but they will always display the files themselves and then HandleExtraFileTypes returns null.

The essence of the involved call stack:

https://github.com/fiji/imagej1/blob/master/ij/IJ.java#L1557
https://github.com/fiji/imagej1/blob/master/ij/io/Opener.java#L306
https://github.com/fiji/imagej1/blob/master/ij/io/Opener.java#L434
https://github.com/fiji/fiji/blob/master/src-plugins/IO_/src/main/java/HandleExtraFileTypes.java#L396
https://github.com/fiji/fiji/blob/master/src-plugins/IO_/src/main/java/HandleExtraFileTypes.java#L433

However, with the HandleExtraFileTypes/SCIFIO interaction we can adhere to that reader convention.

The only problem with that convention is that it is limited to a single ImagePlus, so if you want to support a file format that encodes more than a single image, or images with more than the five hard-coded dimensions X, Y, Z, channel, time, you simply cannot return it for use with IJ.openImage. You *have* to display it in the ImageJ 1.x plugin.

But in the case of such images, you most likely are limited by other places in ImageJ 1.x, or worse, by plugins using the previous convention that ImageStacks are limited to representing X, Y, Z stacks. Therefore, I would highly recommend to go ImageJ2 in such a case anyway.

Ciao,
Dscho

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

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

[Unruh, Jay-2]

Hi Everyone,

Wayne's solution coupled with my interpretation of Johannes suggestion seems to work quite well.  I'll describe it briefly here (in case someone is crazy enough to want to do this too) and make it available via my website tomorrow.  I had to make a little modification to my plot window so that it could be instantiated from an existing ImagePlus--no big deal there.  In short, my new plugin that extends the FormatReader also implements the ImageListener.  It keeps track of the full path starting with the initFile method.  When the image listener detects an opened image with the exact path that was saved in initFile, it sends the new ImagePlus to the plot window constructor and destroys the imagelistener.  A little convoluted but it works.

One more question for Curtis--is there a mechanism to add to the readers.txt within loci_tools.jar (perhaps similar to the IJ prefs keys you mentioned)?

Jay
________________________________________
From: ImageJ Interest Group [[hidden email]] on behalf of Unruh, Jay
Sent: Tuesday, April 23, 2013 2:12 PM
To: [hidden email]
Subject: Re: loci bioformats importer with custom window

Curtis and Johannes,

Firstly, I am more than happy with the workaround Curtis proposed that involves programmatic bioformats preferences manipulation and subsequent opening of the image via initFile.  Given that my use case is fairly unique, I'm not sure we need to extend things beyond that at this point.  For that matter, my workaround of a drag-n-drop window also suffices.

As for the issue of custom display, I'm not entirely sure I understand what Johannes is proposing.  A call to IJ.openImage() would fail in my circumstance unless I modify handleextrafiletypes, because my image format is not a tif or any other recognized format.  Alternatively, my openBytes could display an empty ImagePlus which I could then draw my plot and buttons on.  This would require me to instantiate my plot window in initFile and then call back to it from openBytes, sending it the displayed ImagePlus.  Actually, this would be problematic given that the ImagePlus is not yet displayed when openBytes returns and there is no reference to it yet.  Is there some sort of notification I can implement that would tell my code when the ImagePlus is displayed and provide a reference to it so I can modify it?  I know the ImagePlus reader has status listeners, but I'm not sure how to gain access to those via the FormatReader.

I like the idea of an ImageJ2 implementation, though I'm not quite familiar enough with the data service to know how to write one tailored to my data type (multiple xy data vectors of varying length).  My plan  was to wait until the examples were relatively well fleshed out or until the histogram was implemented.  I feel that I am a relatively decent java programmer but the flexibility which with ImageJ2 (necessarily) handles data types and object references makes it difficult for me to utilize these tools without a fairly complete example.

Thanks,
Jay

-----Original Message-----
From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of Johannes Schindelin
Sent: Monday, April 22, 2013 5:46 PM
To: [hidden email]
Subject: Re: loci bioformats importer with custom window

Hi Curtis,

On Mon, 22 Apr 2013, Curtis Rueden wrote:

> > I really think it would be a much better idea to work on that SCIFIO
> > integration
>
> As long as we can cover use cases like Jay's, I agree. That is, it
> should be possible to customize not only the image I/O, but the
> display of the resulting ImagePlus object. My concern with the SCIFIO
> idea is that SCIFIO is really an extensibility point for I/O, not image display.
> How would you propose Jay solve his specific use case in your proposed
> scenario?

It is very easy to obtain an ImagePlus instance by calling IJ.openImage() from a custom plugin and do with that ImagePlus whatever you want, including displaying in a non-standard way.

The only problem is that readers are in general written using only the contract of PlugIn, but not the obscure and little-known convention for readers. The ImageJ API never enforced readers to adhere to the convention that the passed argument should be interpreted as a file path, and that the plugin should extend (and populate) ImagePlus.

Readers not heeding that convention might still be called by HandleExtraFileTypes, but they will always display the files themselves and then HandleExtraFileTypes returns null.

The essence of the involved call stack:

https://github.com/fiji/imagej1/blob/master/ij/IJ.java#L1557
https://github.com/fiji/imagej1/blob/master/ij/io/Opener.java#L306
https://github.com/fiji/imagej1/blob/master/ij/io/Opener.java#L434
https://github.com/fiji/fiji/blob/master/src-plugins/IO_/src/main/java/HandleExtraFileTypes.java#L396
https://github.com/fiji/fiji/blob/master/src-plugins/IO_/src/main/java/HandleExtraFileTypes.java#L433

However, with the HandleExtraFileTypes/SCIFIO interaction we can adhere to that reader convention.

The only problem with that convention is that it is limited to a single ImagePlus, so if you want to support a file format that encodes more than a single image, or images with more than the five hard-coded dimensions X, Y, Z, channel, time, you simply cannot return it for use with IJ.openImage. You *have* to display it in the ImageJ 1.x plugin.

But in the case of such images, you most likely are limited by other places in ImageJ 1.x, or worse, by plugins using the previous convention that ImageStacks are limited to representing X, Y, Z stacks. Therefore, I would highly recommend to go ImageJ2 in such a case anyway.

Ciao,
Dscho

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

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

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

[ctrueden]

Hi Jay,

Sorry for the delay in reply.

> One more question for Curtis--is there a mechanism to add to the
> readers.txt within loci_tools.jar (perhaps similar to the IJ prefs
> keys you mentioned)?

The following code will add your reader to the list for the current JVM:

    ImageReader.getDefaultReaderClasses().addClass(MyReader.class);

However, there is a chicken-and-egg problem: the code above needs to be
called only once, but before the user attempts to open any data via File >
Open or drag-and-drop. One solution is to create a small plugin
"Register_My_Reader" or some such, which you execute in ImageJ's startup
macros.

Fortunately, as of last month, Fiji's startup macros got smarter, such that
you can serve an addition to the startup macros via an update site. See
this link for details:

    https://github.com/fiji/fiji/commit/371d3786

Regards,
Curtis


On Tue, Apr 23, 2013 at 10:31 PM, Unruh, Jay <[hidden email]> wrote:

> Hi Everyone,
>
> Wayne's solution coupled with my interpretation of Johannes suggestion
> seems to work quite well.  I'll describe it briefly here (in case someone
> is crazy enough to want to do this too) and make it available via my
> website tomorrow.  I had to make a little modification to my plot window so
> that it could be instantiated from an existing ImagePlus--no big deal
> there.  In short, my new plugin that extends the FormatReader also
> implements the ImageListener.  It keeps track of the full path starting
> with the initFile method.  When the image listener detects an opened image
> with the exact path that was saved in initFile, it sends the new ImagePlus
> to the plot window constructor and destroys the imagelistener.  A little
> convoluted but it works.
>
> One more question for Curtis--is there a mechanism to add to the
> readers.txt within loci_tools.jar (perhaps similar to the IJ prefs keys you
> mentioned)?
>
> Jay
> ________________________________________
> From: ImageJ Interest Group [[hidden email]] on behalf of Unruh, Jay
> Sent: Tuesday, April 23, 2013 2:12 PM
> To: [hidden email]
> Subject: Re: loci bioformats importer with custom window
>
> Curtis and Johannes,
>
> Firstly, I am more than happy with the workaround Curtis proposed that
> involves programmatic bioformats preferences manipulation and subsequent
> opening of the image via initFile.  Given that my use case is fairly
> unique, I'm not sure we need to extend things beyond that at this point.
>  For that matter, my workaround of a drag-n-drop window also suffices.
>
> As for the issue of custom display, I'm not entirely sure I understand
> what Johannes is proposing.  A call to IJ.openImage() would fail in my
> circumstance unless I modify handleextrafiletypes, because my image format
> is not a tif or any other recognized format.  Alternatively, my openBytes
> could display an empty ImagePlus which I could then draw my plot and
> buttons on.  This would require me to instantiate my plot window in
> initFile and then call back to it from openBytes, sending it the displayed
> ImagePlus.  Actually, this would be problematic given that the ImagePlus is
> not yet displayed when openBytes returns and there is no reference to it
> yet.  Is there some sort of notification I can implement that would tell my
> code when the ImagePlus is displayed and provide a reference to it so I can
> modify it?  I know the ImagePlus reader has status listeners, but I'm not
> sure how to gain access to those via the FormatReader.
>
> I like the idea of an ImageJ2 implementation, though I'm not quite
> familiar enough with the data service to know how to write one tailored to
> my data type (multiple xy data vectors of varying length).  My plan  was to
> wait until the examples were relatively well fleshed out or until the
> histogram was implemented.  I feel that I am a relatively decent java
> programmer but the flexibility which with ImageJ2 (necessarily) handles
> data types and object references makes it difficult for me to utilize these
> tools without a fairly complete example.
>
> Thanks,
> Jay
>
> -----Original Message-----
> From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of
> Johannes Schindelin
> Sent: Monday, April 22, 2013 5:46 PM
> To: [hidden email]
> Subject: Re: loci bioformats importer with custom window
>
> Hi Curtis,
>
> On Mon, 22 Apr 2013, Curtis Rueden wrote:
>
> > > I really think it would be a much better idea to work on that SCIFIO
> > > integration
> >
> > As long as we can cover use cases like Jay's, I agree. That is, it
> > should be possible to customize not only the image I/O, but the
> > display of the resulting ImagePlus object. My concern with the SCIFIO
> > idea is that SCIFIO is really an extensibility point for I/O, not image
> display.
> > How would you propose Jay solve his specific use case in your proposed
> > scenario?
>
> It is very easy to obtain an ImagePlus instance by calling IJ.openImage()
> from a custom plugin and do with that ImagePlus whatever you want,
> including displaying in a non-standard way.
>
> The only problem is that readers are in general written using only the
> contract of PlugIn, but not the obscure and little-known convention for
> readers. The ImageJ API never enforced readers to adhere to the convention
> that the passed argument should be interpreted as a file path, and that the
> plugin should extend (and populate) ImagePlus.
>
> Readers not heeding that convention might still be called by
> HandleExtraFileTypes, but they will always display the files themselves and
> then HandleExtraFileTypes returns null.
>
> The essence of the involved call stack:
>
> https://github.com/fiji/imagej1/blob/master/ij/IJ.java#L1557
> https://github.com/fiji/imagej1/blob/master/ij/io/Opener.java#L306
> https://github.com/fiji/imagej1/blob/master/ij/io/Opener.java#L434
>
> https://github.com/fiji/fiji/blob/master/src-plugins/IO_/src/main/java/HandleExtraFileTypes.java#L396
>
> https://github.com/fiji/fiji/blob/master/src-plugins/IO_/src/main/java/HandleExtraFileTypes.java#L433
>
> However, with the HandleExtraFileTypes/SCIFIO interaction we can adhere to
> that reader convention.
>
> The only problem with that convention is that it is limited to a single
> ImagePlus, so if you want to support a file format that encodes more than a
> single image, or images with more than the five hard-coded dimensions X, Y,
> Z, channel, time, you simply cannot return it for use with IJ.openImage.
> You *have* to display it in the ImageJ 1.x plugin.
>
> But in the case of such images, you most likely are limited by other
> places in ImageJ 1.x, or worse, by plugins using the previous convention
> that ImageStacks are limited to representing X, Y, Z stacks. Therefore, I
> would highly recommend to go ImageJ2 in such a case anyway.
>
> Ciao,
> Dscho
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

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

[Unruh, Jay-2]

Awesome!  This works quite well and seems to represent a semi-permanent solution.

Jay

-----Original Message-----
From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of Curtis Rueden
Sent: Tuesday, April 30, 2013 9:13 AM
To: [hidden email]
Subject: Re: loci bioformats importer with custom window

Hi Jay,

Sorry for the delay in reply.

> One more question for Curtis--is there a mechanism to add to the
> readers.txt within loci_tools.jar (perhaps similar to the IJ prefs
> keys you mentioned)?

The following code will add your reader to the list for the current JVM:

    ImageReader.getDefaultReaderClasses().addClass(MyReader.class);

However, there is a chicken-and-egg problem: the code above needs to be called only once, but before the user attempts to open any data via File > Open or drag-and-drop. One solution is to create a small plugin "Register_My_Reader" or some such, which you execute in ImageJ's startup macros.

Fortunately, as of last month, Fiji's startup macros got smarter, such that you can serve an addition to the startup macros via an update site. See this link for details:

    https://github.com/fiji/fiji/commit/371d3786

Regards,
Curtis


On Tue, Apr 23, 2013 at 10:31 PM, Unruh, Jay <[hidden email]> wrote:

> Hi Everyone,
>
> Wayne's solution coupled with my interpretation of Johannes suggestion
> seems to work quite well.  I'll describe it briefly here (in case
> someone is crazy enough to want to do this too) and make it available
> via my website tomorrow.  I had to make a little modification to my
> plot window so that it could be instantiated from an existing
> ImagePlus--no big deal there.  In short, my new plugin that extends
> the FormatReader also implements the ImageListener.  It keeps track of
> the full path starting with the initFile method.  When the image
> listener detects an opened image with the exact path that was saved in
> initFile, it sends the new ImagePlus to the plot window constructor
> and destroys the imagelistener.  A little convoluted but it works.
>
> One more question for Curtis--is there a mechanism to add to the
> readers.txt within loci_tools.jar (perhaps similar to the IJ prefs
> keys you mentioned)?
>
> Jay
> ________________________________________
> From: ImageJ Interest Group [[hidden email]] on behalf of Unruh,
> Jay
> Sent: Tuesday, April 23, 2013 2:12 PM
> To: [hidden email]
> Subject: Re: loci bioformats importer with custom window
>
> Curtis and Johannes,
>
> Firstly, I am more than happy with the workaround Curtis proposed that
> involves programmatic bioformats preferences manipulation and
> subsequent opening of the image via initFile.  Given that my use case
> is fairly unique, I'm not sure we need to extend things beyond that at this point.
>  For that matter, my workaround of a drag-n-drop window also suffices.
>
> As for the issue of custom display, I'm not entirely sure I understand
> what Johannes is proposing.  A call to IJ.openImage() would fail in my
> circumstance unless I modify handleextrafiletypes, because my image
> format is not a tif or any other recognized format.  Alternatively, my
> openBytes could display an empty ImagePlus which I could then draw my
> plot and buttons on.  This would require me to instantiate my plot
> window in initFile and then call back to it from openBytes, sending it
> the displayed ImagePlus.  Actually, this would be problematic given
> that the ImagePlus is not yet displayed when openBytes returns and
> there is no reference to it yet.  Is there some sort of notification I
> can implement that would tell my code when the ImagePlus is displayed
> and provide a reference to it so I can modify it?  I know the
> ImagePlus reader has status listeners, but I'm not sure how to gain access to those via the FormatReader.
>
> I like the idea of an ImageJ2 implementation, though I'm not quite
> familiar enough with the data service to know how to write one
> tailored to my data type (multiple xy data vectors of varying length).  
> My plan  was to wait until the examples were relatively well fleshed
> out or until the histogram was implemented.  I feel that I am a
> relatively decent java programmer but the flexibility which with
> ImageJ2 (necessarily) handles data types and object references makes
> it difficult for me to utilize these tools without a fairly complete example.
>
> Thanks,
> Jay
>
> -----Original Message-----
> From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of
> Johannes Schindelin
> Sent: Monday, April 22, 2013 5:46 PM
> To: [hidden email]
> Subject: Re: loci bioformats importer with custom window
>
> Hi Curtis,
>
> On Mon, 22 Apr 2013, Curtis Rueden wrote:
>
> > > I really think it would be a much better idea to work on that
> > > SCIFIO integration
> >
> > As long as we can cover use cases like Jay's, I agree. That is, it
> > should be possible to customize not only the image I/O, but the
> > display of the resulting ImagePlus object. My concern with the
> > SCIFIO idea is that SCIFIO is really an extensibility point for I/O,
> > not image
> display.
> > How would you propose Jay solve his specific use case in your
> > proposed scenario?
>
> It is very easy to obtain an ImagePlus instance by calling
> IJ.openImage() from a custom plugin and do with that ImagePlus
> whatever you want, including displaying in a non-standard way.
>
> The only problem is that readers are in general written using only the
> contract of PlugIn, but not the obscure and little-known convention
> for readers. The ImageJ API never enforced readers to adhere to the
> convention that the passed argument should be interpreted as a file
> path, and that the plugin should extend (and populate) ImagePlus.
>
> Readers not heeding that convention might still be called by
> HandleExtraFileTypes, but they will always display the files
> themselves and then HandleExtraFileTypes returns null.
>
> The essence of the involved call stack:
>
> https://github.com/fiji/imagej1/blob/master/ij/IJ.java#L1557
> https://github.com/fiji/imagej1/blob/master/ij/io/Opener.java#L306
> https://github.com/fiji/imagej1/blob/master/ij/io/Opener.java#L434
>
> https://github.com/fiji/fiji/blob/master/src-plugins/IO_/src/main/java
> /HandleExtraFileTypes.java#L396
>
> https://github.com/fiji/fiji/blob/master/src-plugins/IO_/src/main/java
> /HandleExtraFileTypes.java#L433
>
> However, with the HandleExtraFileTypes/SCIFIO interaction we can
> adhere to that reader convention.
>
> The only problem with that convention is that it is limited to a
> single ImagePlus, so if you want to support a file format that encodes
> more than a single image, or images with more than the five hard-coded
> dimensions X, Y, Z, channel, time, you simply cannot return it for use with IJ.openImage.
> You *have* to display it in the ImageJ 1.x plugin.
>
> But in the case of such images, you most likely are limited by other
> places in ImageJ 1.x, or worse, by plugins using the previous
> convention that ImageStacks are limited to representing X, Y, Z
> stacks. Therefore, I would highly recommend to go ImageJ2 in such a case anyway.
>
> Ciao,
> Dscho
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

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

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