http://imagej.273.s1.nabble.com/a-tutorial-on-a-custom-image-format-file-reader-writer-tp3696492p3696496.html
and drop. Then I could, for example, drag a .lsm file onto the "ImageJ"
> Hi,
>
> I am very interested in helping to improve the ImageJ I/O API. It
> would be
> nice if ImageJ's file format I/O could -- at some level -- harness the
> general framework we have created for Bio-Formats. Even though the
> Bio-Formats project itself is geared toward life sciences file formats,
> there is nothing in the framework that fundamentally limits it that
> way.
>
> As I alluded to earlier, I think it would be really cool to expand
> ImageJ's
> I/O architecture a bit to more explicitly identify which plugins
> fulfill an
> "input reader" or "output writer" role. That way, ImageJ could include
> an
> interface specifically for toggling and/or reordering which
> readers/writers
> get called in which order for various file formats.
>
> Obviously, in developing Bio-Formats I have given these issues a lot of
> thought, and Bio-Formats has significant chunks of logic for file type
> identification and modular extraction of pixels and metadata. It is not
> perfect, but maybe we can apply some portion of the BF solution to
> ImageJ.
>
> My basic suggestion would be to have a Java interface, a subinterface
> of
> PlugIn, that represents an image format reader. When ImageJ scans for
> plugins, it could note which ones implement this interface, and
> automatically register them with its File/Open command, reducing or
> eliminating the need for a manually edited HandleExtraFileTypes. You
> could
> do something similar, but simpler, for writers, by having a PlugIn
> subinterface for image format writers.
>
> The hard part is deciding whether a given file is of a particular
> format.
> For many formats you can just use the file extension, but for some
> formats
> it is insufficient. In Bio-Formats we have two levels of detection: a
> "fast"
> way from just the filename, and a "slow" way that opens up the file for
> random access and scans it. The logic is pretty smart and only uses
> the slow
> way 1) if the fast way fails, and 2) if we are in a situation where it
> is
> allowed and appropriate.
>
> If we did this, then we could have a GUI for toggling and reordering
> which
> formats are called in which order. I have created something like this
> for
> Bio-Formats -- allowing toggling of each reader individually -- as
> part of a
> "Bio-Formats Configuration" dialog, that will be present in the next
> release, and can be seen in its current form using the prerelease
> build at <
>
http://skyking.microscopy.wisc.edu/curtis/jar/loci_tools.jar>. (I am
> also
> planning to add an upgrade feature similar to ImageJ's that allows you
> to
> upgrade BF to the latest release or daily build.)
>
> Even if we do not end up doing anything like I've described here, with
> this
> format toggling feature we could now move Bio-Formats up in the
> priority
> list in HandleExtraFileTypes. This solves the problem of having
> multiple
> plugins installed for handling the same file format -- e.g., you can
> have
> both Bio-Formats and the LSM_Reader, and just toggle Bio-Formats's LSM
> support in order to test files one way or the other.
>
> This is probably the kind of thing that would be easier to hash out by
> getting interested parties together for a phone chat or even in person
> meeting. I am insanely busy through Friday (apologies to Wayne,
> Patrick and
> others for being slow in responding to issues), but could invest some
> time
> next week to discuss all of this further, if there is any interest.
>
> -Curtis