a tutorial on a custom image format file reader / writer

[Albert Cardona]

For any interested:

I've written a tutorial on how to create your own image file
reader/writer, and nicely integrate them with the rest of ImageJ:

- seamless opening from the "File / Open" by editing the
  HandleExtraFileTypes.java file

- easy writing by placing the plugin under "File / Save As" with a
  plugins.config packed along with a jar file.


http://www.mcdb.ucla.edu/research/hartenstein/acardona/imagej_programming_tutorials.html


Hope that's useful.

Albert
--
Albert Cardona
http://www.mcdb.ucla.edu/Research/Hartenstein/acardona

[ctrueden]

Hi Albert,

Thanks for this guide. I think it is very useful currently, but hopefully in
the future we can improve the ImageJ I/O plugin architecture to reduce the
need for many of these steps. I have some ideas on how to do so, but have
not yet had time to work on them.

LOCI also has a guide to adding new file format readers to Bio-Formats:
https://skyking.microscopy.wisc.edu/svn/java/trunk/loci/formats/doc/reader-guide.txt

The are several advantages to adding a format to Bio-Formats rather than as
a standalone ImageJ plugin:

1) Support for the format in a modularized fashion usable by any software
that uses Bio-Formats (including ImageJ)

2) Ability to extract data plane by plane and in arbitrary order rather than
just sequentially -- for ImageJ this means automatic support for virtual
stacks

3) Standard infrastructure for metadata handling, including adding metadata
mappings from your format to the OME data model

4) No need to edit HandleExtraFileTypes or plugins.config

The main disadvantage is that implementing a Bio-Formats reader is somewhat
more complex than a simple ImageJ reader -- but still less complex than a
complicated ImageJ reader. While there is a learning curve to understanding
the Bio-Formats IFormatReader API, it is not that complicated, and you get
so much out of it -- with an ImageJ reader plugin you must not only code the
pixel extraction, but also manage your own ImagePlus objects, handle your
format's metadata as best you can (if at all), and you don't get any extra
trimmings.

There is no guide to creating format writers yet, but the process is similar
(and it is actually simpler since writers are easier than readers).

-Curtis

On Sat, Apr 12, 2008 at 1:56 PM, Albert Cardona <[hidden email]>
wrote:

> For any interested:
>
> I've written a tutorial on how to create your own image file
> reader/writer, and nicely integrate them with the rest of ImageJ:
>
> - seamless opening from the "File / Open" by editing the
>  HandleExtraFileTypes.java file
>
> - easy writing by placing the plugin under "File / Save As" with a
>  plugins.config packed along with a jar file.
>
>
>
> http://www.mcdb.ucla.edu/research/hartenstein/acardona/imagej_programming_tutorials.html
>
>
> Hope that's useful.
>
> Albert
> --
> Albert Cardona
> http://www.mcdb.ucla.edu/Research/Hartenstein/acardona
>

[Francis Burton]

At 12:16 14/04/08 -0500, "Curtis Rueden" <[hidden email]> wrote:
>Thanks for this guide. I think it is very useful currently, but hopefully in
>the future we can improve the ImageJ I/O plugin architecture to reduce the
>need for many of these steps. I have some ideas on how to do so, but have
>not yet had time to work on them.

Recently I have been playing around with getting ImageJ to do conversions
between file formats via command line invocation and macros. (Many thanks
to Patrick Pirrotte for all his help with reading LSM linescan images with
his useful LSMReader/LSMToolbox.)

One outstanding problem concerns the threaded nature of file reading. In
Patrick's own words:

"The problem is that somehow in macro headless mode (no gui) opening and
saving occur in other threads. This means that the LSM_Reader is not
finished opening the image that the macro already tries to save the files.
The results are sometimes weird."

This has necessitated adding a delay instruction in the macro, to allow
reading to finish before any attempt to write the converted data file.

Obviously this is less than ideal because this delay will vary depending
on the speed of the computer and other running processes. It makes it
impossible to write a portable solution unless one incorporates a long
enough delay to cover all existing computers (in practice that is quite
a few seconds' delay!).

Would the solution be to add another command to ImageJ similar to wait(...)
that waits for all i/o to complete before continuing execution (of the
macro)?

I am not in a position to judge if this is a sensible proposition, but if
it is I would be very pleased if this was incorporated into the program.

Cheers,
Francis

--
Dr Francis L Burton,          |  [hidden email]
West Medical Building,        |
University of Glasgow,        |  Tel [phone]
Glasgow, G12 8QQ, Scotland.   |  Fax [phone]

[Wayne Rasband]

You are probably seeing this problem because you are using the
LSM_Toobox, which opens files in a separate thread. Instead, use the
LSM_Reader plugin, which does not return until it has finished reading
the file. You will need to remove LSM_Toolbox.jar from the plugins
folder since the Handle_Extra_File_Types plugin uses it if it is
present. Or upgrade to the latest version of Handle_Extra_File_Types at
<http://rsb.info.nih.gov/ij/plugins/file-handler.html>, which uses the
LSM_Reader if it is present.

-wayne


On Apr 14, 2008, at 1:52 PM, Francis Burton wrote:

> At 12:16 14/04/08 -0500, "Curtis Rueden" <[hidden email]> wrote:
>> Thanks for this guide. I think it is very useful currently, but
>> hopefully in
>> the future we can improve the ImageJ I/O plugin architecture to
>> reduce the
>> need for many of these steps. I have some ideas on how to do so, but
>> have
>> not yet had time to work on them.
>
> Recently I have been playing around with getting ImageJ to do
> conversions
> between file formats via command line invocation and macros. (Many
> thanks
> to Patrick Pirrotte for all his help with reading LSM linescan images
> with
> his useful LSMReader/LSMToolbox.)
>
> One outstanding problem concerns the threaded nature of file reading.
> In
> Patrick's own words:
>
> "The problem is that somehow in macro headless mode (no gui) opening
> and
> saving occur in other threads. This means that the LSM_Reader is not
> finished opening the image that the macro already tries to save the
> files.
> The results are sometimes weird."
>
> This has necessitated adding a delay instruction in the macro, to allow
> reading to finish before any attempt to write the converted data file.
>
> Obviously this is less than ideal because this delay will vary
> depending
> on the speed of the computer and other running processes. It makes it
> impossible to write a portable solution unless one incorporates a long
> enough delay to cover all existing computers (in practice that is quite
> a few seconds' delay!).
>
> Would the solution be to add another command to ImageJ similar to
> wait(...)
> that waits for all i/o to complete before continuing execution (of the
> macro)?
>
> I am not in a position to judge if this is a sensible proposition, but
> if
> it is I would be very pleased if this was incorporated into the
> program.
>
> Cheers,
> Francis
>
> --
> Dr Francis L Burton,          |  [hidden email]
> West Medical Building,        |
> University of Glasgow,        |  Tel [phone]
> Glasgow, G12 8QQ, Scotland.   |  Fax [phone]
>

[Patrick Pirrotte]

Hi,

I have almost finished updating the LSM_Toolbox to 4.0c, which will accept
CSV files as a list of lsm files to batch process.

The whole batch process will run in the same thread and will not be subject
to race conditions as is the case with the actual verison of the
toolbox/reader.

Furthermore, reading of compressed images has been improved. While 8 bit
compressed images are read correctly since LSM_Toolbox 4.0a, 12 bit
compressed images will work with LSM_Toolbox 4.0c and ImageJ >=v1.40e.

Best regards,

Patrick

-----Original Message-----
From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of Wayne
Rasband
Sent: 14 April 2008 22:34
To: [hidden email]
Subject: Re: a tutorial on a custom image format file reader / writer

You are probably seeing this problem because you are using the LSM_Toobox,
which opens files in a separate thread. Instead, use the LSM_Reader plugin,
which does not return until it has finished reading the file. You will need
to remove LSM_Toolbox.jar from the plugins folder since the
Handle_Extra_File_Types plugin uses it if it is present. Or upgrade to the
latest version of Handle_Extra_File_Types at
<http://rsb.info.nih.gov/ij/plugins/file-handler.html>, which uses the
LSM_Reader if it is present.

-wayne


On Apr 14, 2008, at 1:52 PM, Francis Burton wrote:

> At 12:16 14/04/08 -0500, "Curtis Rueden" <[hidden email]> wrote:
>> Thanks for this guide. I think it is very useful currently, but
>> hopefully in
>> the future we can improve the ImageJ I/O plugin architecture to
>> reduce the
>> need for many of these steps. I have some ideas on how to do so, but
>> have
>> not yet had time to work on them.
>
> Recently I have been playing around with getting ImageJ to do
> conversions
> between file formats via command line invocation and macros. (Many
> thanks
> to Patrick Pirrotte for all his help with reading LSM linescan images
> with
> his useful LSMReader/LSMToolbox.)
>
> One outstanding problem concerns the threaded nature of file reading.
> In
> Patrick's own words:
>
> "The problem is that somehow in macro headless mode (no gui) opening
> and
> saving occur in other threads. This means that the LSM_Reader is not
> finished opening the image that the macro already tries to save the
> files.
> The results are sometimes weird."
>
> This has necessitated adding a delay instruction in the macro, to allow
> reading to finish before any attempt to write the converted data file.
>
> Obviously this is less than ideal because this delay will vary
> depending
> on the speed of the computer and other running processes. It makes it
> impossible to write a portable solution unless one incorporates a long
> enough delay to cover all existing computers (in practice that is quite
> a few seconds' delay!).
>
> Would the solution be to add another command to ImageJ similar to
> wait(...)
> that waits for all i/o to complete before continuing execution (of the
> macro)?
>
> I am not in a position to judge if this is a sensible proposition, but
> if
> it is I would be very pleased if this was incorporated into the
> program.
>
> Cheers,
> Francis
>
> --
> Dr Francis L Burton,          |  [hidden email]
> West Medical Building,        |
> University of Glasgow,        |  Tel [phone]
> Glasgow, G12 8QQ, Scotland.   |  Fax [phone]
>

[Albert Cardona]

Hi Francis,

> "The problem is that somehow in macro headless mode (no gui) opening and
> saving occur in other threads. This means that the LSM_Reader is not
> finished opening the image that the macro already tries to save the files.
> The results are sometimes weird.

I had this problem very often. The core problem is that ImageJ is
multithreaded where you wouldn't want it to be: the I/O routines. Not
only images may be attempted to be written to disk before they have
finished opening, but also the image to save may not be the one you
expect/want, because the writer plugin will take the current image,
which changes as other images are opened.

I have addressed the problem for image writers by adding a static method
to all format writers included within ij.plugin package, which bypasses
the need to instantiate a new PlugIn in a new Thread, and made a
convenient wrapper method within in the ij.io.Writer class. Changes will
be available soon as part of the fiji package -a new ImageJ
distribution, to be released around May 1st.

Albert

--
Albert Cardona
http://www.mcdb.ucla.edu/Research/Hartenstein/acardona

[Albert Cardona]

Curtis Rueden wrote:

> Hi Albert,
>
> Thanks for this guide. I think it is very useful currently, but hopefully in
> the future we can improve the ImageJ I/O plugin architecture to reduce the
> need for many of these steps. I have some ideas on how to do so, but have
> not yet had time to work on them.
>
> LOCI also has a guide to adding new file format readers to Bio-Formats:
> https://skyking.microscopy.wisc.edu/svn/java/trunk/loci/formats/doc/reader-guide.txt
>  

Thanks Curtis, I wasn't aware of LOCI's accessible API for adding new
reader/writer capabilities, and the automatic virtualization (which is
great and very much needed).

We included LOCI into fiji. I will write a reader/writer using LOCI to
test it out, familiarize myself with it and document it.

As for the advantage of avoiding the HandleExtraFileTypes: with LOCI the
problem is transported somewhere else. I agree we need a "drop in"
system, perhaps a folder like the macros folder where file
readers/writers are read from, which implement a specific interface.
Just an idea.

Albert

--
Albert Cardona
http://www.mcdb.ucla.edu/Research/Hartenstein/acardona

[Gabriel Landini]

On Tuesday 15 April 2008 13:01:38 Albert Cardona wrote:

> We included LOCI into fiji

And so the crowd asks: "Where is it?"

For the record, I installed IJ in the Asus eee PC 4GB and it works perfectly
fine.
It is a bit slow with the default xandros kernel (the benchmark is ~8
sec :-/ ).
The xandros default distribution has java jre 1.5.0, not the sdk, so one
cannot compile plugins straight out of the box, but there are many other
linux distributions that can be installed.

Cheers,

Gabriel

[ctrueden]

Hi Francis,

If you want to convert files on the command line, Bio-Formats has a
"bfconvert" tool that allows this. As you would expect, it can read from any
supported input format, and write to any supported output format -- see the
formats table on the web site at <http://www.loci.wisc.edu/ome/formats.html>
for details; blue striped rows are supported output formats (as of this
writing: AVI, EPS, JPEG, OME-TIFF, PNG, MOV and TIFF).

The command has a number of optional parameters to control its behavior; if
what you need isn't there, let me know and perhaps it could be added.

-Curtis

On Mon, Apr 14, 2008 at 12:52 PM, Francis Burton <[hidden email]>
wrote:

> At 12:16 14/04/08 -0500, "Curtis Rueden" <[hidden email]> wrote:
> >Thanks for this guide. I think it is very useful currently, but hopefully
> in
> >the future we can improve the ImageJ I/O plugin architecture to reduce
> the
> >need for many of these steps. I have some ideas on how to do so, but have
> >not yet had time to work on them.
>
> Recently I have been playing around with getting ImageJ to do conversions
> between file formats via command line invocation and macros. (Many thanks
> to Patrick Pirrotte for all his help with reading LSM linescan images with
> his useful LSMReader/LSMToolbox.)
>
> One outstanding problem concerns the threaded nature of file reading. In
> Patrick's own words:
>
> "The problem is that somehow in macro headless mode (no gui) opening and
> saving occur in other threads. This means that the LSM_Reader is not
> finished opening the image that the macro already tries to save the files.
> The results are sometimes weird."
>
> This has necessitated adding a delay instruction in the macro, to allow
> reading to finish before any attempt to write the converted data file.
>
> Obviously this is less than ideal because this delay will vary depending
> on the speed of the computer and other running processes. It makes it
> impossible to write a portable solution unless one incorporates a long
> enough delay to cover all existing computers (in practice that is quite
> a few seconds' delay!).
>
> Would the solution be to add another command to ImageJ similar to
> wait(...)
> that waits for all i/o to complete before continuing execution (of the
> macro)?
>
> I am not in a position to judge if this is a sensible proposition, but if
> it is I would be very pleased if this was incorporated into the program.
>
> Cheers,
> Francis
>
> --
> Dr Francis L Burton,          |  [hidden email]
> West Medical Building,        |
> University of Glasgow,        |  Tel [phone]
> Glasgow, G12 8QQ, Scotland.   |  Fax [phone]
>

[ctrueden]

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

On Mon, Apr 14, 2008 at 3:33 PM, Wayne Rasband <[hidden email]> wrote:

> You are probably seeing this problem because you are using the LSM_Toobox,
> which opens files in a separate thread. Instead, use the LSM_Reader plugin,
> which does not return until it has finished reading the file. You will need
> to remove LSM_Toolbox.jar from the plugins folder since the
> Handle_Extra_File_Types plugin uses it if it is present. Or upgrade to the
> latest version of Handle_Extra_File_Types at <
> http://rsb.info.nih.gov/ij/plugins/file-handler.html>, which uses the
> LSM_Reader if it is present.
>
> -wayne
>
>
>
> On Apr 14, 2008, at 1:52 PM, Francis Burton wrote:
>
>  At 12:16 14/04/08 -0500, "Curtis Rueden" <[hidden email]> wrote:
> >
> > > Thanks for this guide. I think it is very useful currently, but
> > > hopefully in
> > > the future we can improve the ImageJ I/O plugin architecture to reduce
> > > the
> > > need for many of these steps. I have some ideas on how to do so, but
> > > have
> > > not yet had time to work on them.
> > >
> >
> > Recently I have been playing around with getting ImageJ to do
> > conversions
> > between file formats via command line invocation and macros. (Many
> > thanks
> > to Patrick Pirrotte for all his help with reading LSM linescan images
> > with
> > his useful LSMReader/LSMToolbox.)
> >
> > One outstanding problem concerns the threaded nature of file reading. In
> > Patrick's own words:
> >
> > "The problem is that somehow in macro headless mode (no gui) opening and
> > saving occur in other threads. This means that the LSM_Reader is not
> > finished opening the image that the macro already tries to save the
> > files.
> > The results are sometimes weird."
> >
> > This has necessitated adding a delay instruction in the macro, to allow
> > reading to finish before any attempt to write the converted data file.
> >
> > Obviously this is less than ideal because this delay will vary depending
> > on the speed of the computer and other running processes. It makes it
> > impossible to write a portable solution unless one incorporates a long
> > enough delay to cover all existing computers (in practice that is quite
> > a few seconds' delay!).
> >
> > Would the solution be to add another command to ImageJ similar to
> > wait(...)
> > that waits for all i/o to complete before continuing execution (of the
> > macro)?
> >
> > I am not in a position to judge if this is a sensible proposition, but
> > if
> > it is I would be very pleased if this was incorporated into the program.
> >
> > Cheers,
> > Francis
> >
> > --
> > Dr Francis L Burton,          |  [hidden email]
> > West Medical Building,        |
> > University of Glasgow,        |  Tel [phone]
> > Glasgow, G12 8QQ, Scotland.   |  Fax [phone]
> >
> >

[ctrueden]

Hi Albert,

Good point about the HandleExtraFileTypes problem being transported
somewhere else. Right now you either need to edit readers.txt, or have some
static code somewhere that registers your format readers with the
ImageReader class. I agree that inventing some kind of drop-in mechanism
would be superior -- perhaps something like I just described in my previous
email.

Regarding fiji, I'll second Gabriel's comment: where can we find out more?
Is there a web site for it? Is it similar to Tony's MBF ImageJ bundle in
that it comes with a bunch of plugins preinstalled? What is fiji's purpose?

-Curtis

On Tue, Apr 15, 2008 at 7:01 AM, Albert Cardona <[hidden email]>
wrote:

> Curtis Rueden wrote:
>
> > Hi Albert,
> >
> > Thanks for this guide. I think it is very useful currently, but
> > hopefully in
> > the future we can improve the ImageJ I/O plugin architecture to reduce
> > the
> > need for many of these steps. I have some ideas on how to do so, but
> > have
> > not yet had time to work on them.
> >
> > LOCI also has a guide to adding new file format readers to Bio-Formats:
> >
> > https://skyking.microscopy.wisc.edu/svn/java/trunk/loci/formats/doc/reader-guide.txt
> >
> >
>
>
> Thanks Curtis, I wasn't aware of LOCI's accessible API for adding new
> reader/writer capabilities, and the automatic virtualization (which is great
> and very much needed).
>
> We included LOCI into fiji. I will write a reader/writer using LOCI to
> test it out, familiarize myself with it and document it.
>
> As for the advantage of avoiding the HandleExtraFileTypes: with LOCI the
> problem is transported somewhere else. I agree we need a "drop in" system,
> perhaps a folder like the macros folder where file readers/writers are read
> from, which implement a specific interface. Just an idea.
>
>
> Albert
>
> --
> Albert Cardona
> http://www.mcdb.ucla.edu/Research/Hartenstein/acardona
>

[Albert Cardona]

> Regarding fiji, I'll second Gabriel's comment: where can we find out
> more?
> Is there a web site for it? Is it similar to Tony's MBF ImageJ bundle in
> that it comes with a bunch of plugins preinstalled? What is fiji's
> purpose?
>  


Fiji is on its way, but just not public yet. We need 2 weeks.

Fiji is Just ImageJ.

Fiji puts the sources for java, ImageJ and selected plugins under the
same git repository (with submodules).

All OSes supported, one package for each.

Fiji aims at:
- deploying a batteries-included image processing application
- making it very easy to hack code together (python, macros, java plugins)
- fixing longstanding problems in ImageJ, including threading.
- exploring new features for ImageJ, such as new datastructures
(octrees, ...), 3D visualization, collapsable "advanced" tabs in
dialogs, help buttons in dialogs, a command listener interface with
command events, and a lot more.
- a task-oriented manual a la Tony Collins distribution.

More on Fiji by May 1st.

Albert

--
Albert Cardona
http://www.mcdb.ucla.edu/Research/Hartenstein/acardona

[Wayne Rasband]

What I would like to see is a "Bio-Formats" window that supports drag
and drop. Then I could, for example, drag a .lsm file onto the "ImageJ"
window to open it using the LSM_Reader, onto the "LSM Toolbox" window
to open it using the LSM Toolbox, and onto the "Bio-Formats" window to
open it using the Bio-Formats plugin.

-wayne

On Apr 15, 2008, at 2:37 PM, Curtis Rueden wrote:

> 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

[Gabriel Landini]

On Wednesday 16 April 2008 16:06:27 Wayne Rasband wrote:
> What I would like to see is a "Bio-Formats" window that supports drag
> and drop.

Now that you mention... I sometimes lose the ability to drag and drop in the
IJ window. I am afraid that I do not know what triggers this and that is why
I haven't reported it so far.
This has been going on for sometime now (i.e. it is not a new "feature").
Has anybody else seen this? (IJ under linux).

Regards

Gabriel

[Francis Burton]

Hi Curtis,

Thanks for the suggestion. I'm willing to try anything that will get me
more quickly to my destination - which is to read two images, representing
simultaneous linescan recordings at two different wavelengths, from Zeiss
LSM files into a Delphi program I wrote to space- and time-average bands
in a very interactive way. At the moment, my colleagues are still using the
free Zeiss image browsing software manually to open the LSM file and write
out two uncompressed TIFF files which my program can then read. I haven't yet
reinvented the wheel and written my own LSM importing routine, because I
don't particularly want to have to grapple with the business of reading &
interpreting TIFF header fields and doing LZW decompression if someone else
has solved those problems already!

So I tried some of the Bio-Format tools. First, I tried "showinf", and that
displayed sensible-looking info, showing that I had put the files in the
right place at least:

C:\bftools>showinf 07.lsm
Checking file format [Zeiss Laser-Scanning Microscopy]
Initializing reader
        Reading IFDs
        Populating metadata
        Removing thumbnails
Initialization took 1.344s

Reading core metadata
Filename = 07.lsm
Series count = 1
Series #0:
        Image count = 20000
        RGB = true (2)
        Interleaved = false
        Indexed = false
        Width = 512
        Height = 1
        SizeZ = 1
        SizeT = 20000
        SizeC = 2 (effectively 1)
        Thumbnail size = 3 x 128
        Endianness = intel (little)
        Dimension order = XYZCT (certain)
        Pixel type = uint16
        Metadata complete = true
        -----
        Plane #0 <=> Z 0, C 0, T 0
        Plane #9998 <=> Z 0, C 0, T 9998
        Plane #9999 <=> Z 0, C 0, T 9999
        Plane #10000 <=> Z 0, C 0, T 10000
        Plane #10001 <=> Z 0, C 0, T 10001
        Plane #10002 <=> Z 0, C 0, T 10002
        Plane #19999 <=> Z 0, C 0, T 19999

Reading pixel data (0-19999) ..Terminate batch job (Y/N)? y

Then I tried to "bfconvert" and received the following errors:

C:\bftools>bfconvert -debug 07.lsm 07.tiff
Debugging at level 1
07.lsm java.lang.UnsatisfiedLinkError: no LegacyND2Reader in java.library.path
        at java.lang.ClassLoader.loadLibrary(Unknown Source)
        at java.lang.Runtime.loadLibrary0(Unknown Source)
        at java.lang.System.loadLibrary(Unknown Source)
        at loci.formats.in.LegacyND2Reader.<clinit>(LegacyND2Reader.java:59)
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Unknown Source)
        at loci.formats.ClassList.<init>(ClassList.java:90)
        at loci.formats.ImageReader.getDefaultReaderClasses(ImageReader.java:56)

        at loci.formats.ImageReader.<init>(ImageReader.java:90)
        at loci.formats.tools.ImageConverter.testConvert(ImageConverter.java:91)

        at loci.formats.tools.ImageConverter.main(ImageConverter.java:146)

1208362874734: ZeissLSMReader: ZeissLSMReader.initFile(07.lsm)
1208362874734: ZeissLSMReader: BaseTiffReader.initFile(07.lsm)
java.lang.ArithmeticException: / by zero
        at loci.formats.in.ZeissLSMReader.parseOverlays(ZeissLSMReader.java:825)

        at loci.formats.in.ZeissLSMReader.initMetadata(ZeissLSMReader.java:400)
        at loci.formats.in.ZeissLSMReader.initFile(ZeissLSMReader.java:757)
        at loci.formats.FormatReader.setId(FormatReader.java:573)
        at loci.formats.FormatHandler.setId(FormatHandler.java:146)
        at loci.formats.ImageReader.setId(ImageReader.java:565)
        at loci.formats.tools.ImageConverter.testConvert(ImageConverter.java:103
)
        at loci.formats.tools.ImageConverter.main(ImageConverter.java:146)

Terminate batch job (Y/N)? y

Finally, I tried "bfview" and after a few seconds it put up a window with some
sliders labelled N, Z, T & C, and a Progress bar window which is still sitting
at 0% some 20 minutes after I started the batch file. :-/

Any ideas what might be going on (or not going on)?

Cheers!

Francis

At 13:08 15/04/08 -0500, Curtis Rueden <[hidden email]> wrote:

>Hi Francis,
>
>If you want to convert files on the command line, Bio-Formats has a
>"bfconvert" tool that allows this. As you would expect, it can read from any
>supported input format, and write to any supported output format -- see the
>formats table on the web site at <http://www.loci.wisc.edu/ome/formats.html>
>for details; blue striped rows are supported output formats (as of this
>writing: AVI, EPS, JPEG, OME-TIFF, PNG, MOV and TIFF).
>
>The command has a number of optional parameters to control its behavior; if
>what you need isn't there, let me know and perhaps it could be added.
>
>-Curtis
>
>On Mon, Apr 14, 2008 at 12:52 PM, Francis Burton <[hidden email]>
>wrote:
>
>> At 12:16 14/04/08 -0500, "Curtis Rueden" <[hidden email]> wrote:
>> >Thanks for this guide. I think it is very useful currently, but hopefully
>> in
>> >the future we can improve the ImageJ I/O plugin architecture to reduce
>> the
>> >need for many of these steps. I have some ideas on how to do so, but have
>> >not yet had time to work on them.
>>
>> Recently I have been playing around with getting ImageJ to do conversions
>> between file formats via command line invocation and macros. (Many thanks
>> to Patrick Pirrotte for all his help with reading LSM linescan images with
>> his useful LSMReader/LSMToolbox.)
>>
>> One outstanding problem concerns the threaded nature of file reading. In
>> Patrick's own words:
>>
>> "The problem is that somehow in macro headless mode (no gui) opening and
>> saving occur in other threads. This means that the LSM_Reader is not
>> finished opening the image that the macro already tries to save the files.
>> The results are sometimes weird."
>>
>> This has necessitated adding a delay instruction in the macro, to allow
>> reading to finish before any attempt to write the converted data file.
>>
>> Obviously this is less than ideal because this delay will vary depending
>> on the speed of the computer and other running processes. It makes it
>> impossible to write a portable solution unless one incorporates a long
>> enough delay to cover all existing computers (in practice that is quite
>> a few seconds' delay!).
>>
>> Would the solution be to add another command to ImageJ similar to
>> wait(...)
>> that waits for all i/o to complete before continuing execution (of the
>> macro)?
>>
>> I am not in a position to judge if this is a sensible proposition, but if
>> it is I would be very pleased if this was incorporated into the program.
>>
>> Cheers,
>> Francis
>>
>> --
>> Dr Francis L Burton,          |  [hidden email]
>> West Medical Building,        |
>> University of Glasgow,        |  Tel [phone]
>> Glasgow, G12 8QQ, Scotland.   |  Fax [phone]
>>
>
>

[Francis Burton]

At 17:52 16/04/08 +0100, I wrote:
>[...]
>Finally, I tried "bfview" and after a few seconds it put up a window with some
>sliders labelled N, Z, T & C, and a Progress bar window which is still sitting
>at 0% some 20 minutes after I started the batch file. :-/

Update: more than an hour later, the progress bar is at 1 or 2%. Oddly,
it doesn't look like there's a lot of disk thrashing going on, so maybe
it's not a memory limitation issue.

Francis

[ctrueden]

Hi Francis,

Thanks for taking the time to try Bio-Formats, and for the detailed bug
report.

So I tried some of the Bio-Format tools. First, I tried "showinf", and that
> displayed sensible-looking info, showing that I had put the files in the
> right place at least:
>

Output from showinf looks good. Note that you can suppress reading of the
pixels by using:

showinf 07.lsm -nopix

Or you can limit to a smaller subset of image planes with:

showinf 07.lsm -range 0 2

The latter is a good way to quickly test that the pixels are being read
properly, without waiting for 20000 image planes to load. :-)

Then I tried to "bfconvert" and received the following errors:
>

Unfortunate, and almost certainly a bug in the Zeiss LSM reader. First,
please try it again with the latest prerelease code at:
http://skyking.microscopy.wisc.edu/curtis/jar/loci_tools.jar

Alternately, since another Bio-Formats release is imminent (i.e., tonight or
tomorrow morning), you could test with the new release from the web site.

C:\bftools>bfconvert -debug 07.lsm 07.tiff
>

Note that the -debug flag is very verbose in error output, including some
errors that can be safely ignored.


> Debugging at level 1
> 07.lsm java.lang.UnsatisfiedLinkError: no LegacyND2Reader in
> java.library.path
>

This can be ignored -- it just means that Nikon's ND2 plugin wasn't found.


> java.lang.ArithmeticException: / by zero
>

Therein lies the rub. It's a bug in ZeissLSMReader. Hopefully the latest
code will fix it -- if not, let me know and I'll send you our FTP server
information off-list. If you are willing to send me a nonworking file, we'll
get it fixed for you.

Finally, I tried "bfview" and after a few seconds it put up a window with
> some
> sliders labelled N, Z, T & C, and a Progress bar window which is still
> sitting
> at 0% some 20 minutes after I started the batch file. :-/
>

It is likely the same issue manifesting in a different way. Hopefully once
we fix the bug, bfview will load the image planes more quickly. Note that
since you have 20000 image planes, 1% of that progress bar corresponds to
200 image planes, though, so it is going to be pretty slow regardless.

From what you said, I'm confident that the bfconvert tool will help simplify
your TIFF conversion process once we iron out the
ArrayIndexOutOfBoundsException bug. Alternately, you could use a Java-Delphi
bridge to call the Bio-Formats import routine directly from your Delphi
program. Then you could ask for the data plane by plane, ask about
associated metadata, etc., all from within your Delphi app. Here are some
resources for doing that:

1) Article on using JNI for communication between Delphi & Java:
http://www.pacifier.com/~mmead/jni/delphi/informant/di200309kw.htm

2) Delphi-Java Bridge library on SourceForge:
http://sourceforge.net/projects/djbridge/

3) JVMLink library that we developed for communication between Java and
native languages via TCP/IP sockets:
http://www.loci.wisc.edu/ome/jvmlink.html

Or you could just make system calls to showinf from Delphi to extract
metadata parameters from the LSMs and dump the results to text files, which
your program could parse. There are lots of ways to do what you want. Just
let me know if you have any questions, and I'll try to help.

-Curtis

On Wed, Apr 16, 2008 at 11:52 AM, Francis Burton <[hidden email]>
wrote:

> Hi Curtis,
>
> Thanks for the suggestion. I'm willing to try anything that will get me
> more quickly to my destination - which is to read two images, representing
> simultaneous linescan recordings at two different wavelengths, from Zeiss
> LSM files into a Delphi program I wrote to space- and time-average bands
> in a very interactive way. At the moment, my colleagues are still using
> the
> free Zeiss image browsing software manually to open the LSM file and write
> out two uncompressed TIFF files which my program can then read. I haven't
> yet
> reinvented the wheel and written my own LSM importing routine, because I
> don't particularly want to have to grapple with the business of reading &
> interpreting TIFF header fields and doing LZW decompression if someone
> else
> has solved those problems already!
>
> So I tried some of the Bio-Format tools. First, I tried "showinf", and
> that
> displayed sensible-looking info, showing that I had put the files in the
> right place at least:
>
> C:\bftools>showinf 07.lsm
> Checking file format [Zeiss Laser-Scanning Microscopy]
> Initializing reader
>        Reading IFDs
>        Populating metadata
>        Removing thumbnails
> Initialization took 1.344s
>
> Reading core metadata
> Filename = 07.lsm
> Series count = 1
> Series #0:
>        Image count = 20000
>        RGB = true (2)
>        Interleaved = false
>        Indexed = false
>        Width = 512
>        Height = 1
>        SizeZ = 1
>        SizeT = 20000
>        SizeC = 2 (effectively 1)
>        Thumbnail size = 3 x 128
>        Endianness = intel (little)
>        Dimension order = XYZCT (certain)
>        Pixel type = uint16
>        Metadata complete = true
>        -----
>        Plane #0 <=> Z 0, C 0, T 0
>        Plane #9998 <=> Z 0, C 0, T 9998
>        Plane #9999 <=> Z 0, C 0, T 9999
>        Plane #10000 <=> Z 0, C 0, T 10000
>        Plane #10001 <=> Z 0, C 0, T 10001
>        Plane #10002 <=> Z 0, C 0, T 10002
>        Plane #19999 <=> Z 0, C 0, T 19999
>
> Reading pixel data (0-19999) ..Terminate batch job (Y/N)? y
>
> Then I tried to "bfconvert" and received the following errors:
>
> C:\bftools>bfconvert -debug 07.lsm 07.tiff
> Debugging at level 1
> 07.lsm java.lang.UnsatisfiedLinkError: no LegacyND2Reader in
> java.library.path
>        at java.lang.ClassLoader.loadLibrary(Unknown Source)
>        at java.lang.Runtime.loadLibrary0(Unknown Source)
>        at java.lang.System.loadLibrary(Unknown Source)
>        at
> loci.formats.in.LegacyND2Reader.<clinit>(LegacyND2Reader.java:59)
>        at java.lang.Class.forName0(Native Method)
>        at java.lang.Class.forName(Unknown Source)
>        at loci.formats.ClassList.<init>(ClassList.java:90)
>        at
> loci.formats.ImageReader.getDefaultReaderClasses(ImageReader.java:56)
>
>        at loci.formats.ImageReader.<init>(ImageReader.java:90)
>        at
> loci.formats.tools.ImageConverter.testConvert(ImageConverter.java:91)
>
>        at loci.formats.tools.ImageConverter.main(ImageConverter.java:146)
>
> 1208362874734: ZeissLSMReader: ZeissLSMReader.initFile(07.lsm)
> 1208362874734: ZeissLSMReader: BaseTiffReader.initFile(07.lsm)
> java.lang.ArithmeticException: / by zero
>        at
> loci.formats.in.ZeissLSMReader.parseOverlays(ZeissLSMReader.java:825)
>
>        at
> loci.formats.in.ZeissLSMReader.initMetadata(ZeissLSMReader.java:400)
>        at loci.formats.in.ZeissLSMReader.initFile(ZeissLSMReader.java:757)
>        at loci.formats.FormatReader.setId(FormatReader.java:573)
>        at loci.formats.FormatHandler.setId(FormatHandler.java:146)
>        at loci.formats.ImageReader.setId(ImageReader.java:565)
>        at
> loci.formats.tools.ImageConverter.testConvert(ImageConverter.java:103
> )
>        at loci.formats.tools.ImageConverter.main(ImageConverter.java:146)
>
> Terminate batch job (Y/N)? y
>
> Finally, I tried "bfview" and after a few seconds it put up a window with
> some
> sliders labelled N, Z, T & C, and a Progress bar window which is still
> sitting
> at 0% some 20 minutes after I started the batch file. :-/
>
> Any ideas what might be going on (or not going on)?
>
> Cheers!
>
> Francis
>
> At 13:08 15/04/08 -0500, Curtis Rueden <[hidden email]> wrote:
> >Hi Francis,
> >
> >If you want to convert files on the command line, Bio-Formats has a
> >"bfconvert" tool that allows this. As you would expect, it can read from
> any
> >supported input format, and write to any supported output format -- see
> the
> >formats table on the web site at <
> http://www.loci.wisc.edu/ome/formats.html>
> >for details; blue striped rows are supported output formats (as of this
> >writing: AVI, EPS, JPEG, OME-TIFF, PNG, MOV and TIFF).
> >
> >The command has a number of optional parameters to control its behavior;
> if
> >what you need isn't there, let me know and perhaps it could be added.
> >
> >-Curtis
> >
> >On Mon, Apr 14, 2008 at 12:52 PM, Francis Burton <
> [hidden email]>
> >wrote:
> >
> >> At 12:16 14/04/08 -0500, "Curtis Rueden" <[hidden email]> wrote:
> >> >Thanks for this guide. I think it is very useful currently, but
> hopefully
> >> in
> >> >the future we can improve the ImageJ I/O plugin architecture to reduce
> >> the
> >> >need for many of these steps. I have some ideas on how to do so, but
> have
> >> >not yet had time to work on them.
> >>
> >> Recently I have been playing around with getting ImageJ to do
> conversions
> >> between file formats via command line invocation and macros. (Many
> thanks
> >> to Patrick Pirrotte for all his help with reading LSM linescan images
> with
> >> his useful LSMReader/LSMToolbox.)
> >>
> >> One outstanding problem concerns the threaded nature of file reading.
> In
> >> Patrick's own words:
> >>
> >> "The problem is that somehow in macro headless mode (no gui) opening
> and
> >> saving occur in other threads. This means that the LSM_Reader is not
> >> finished opening the image that the macro already tries to save the
> files.
> >> The results are sometimes weird."
> >>
> >> This has necessitated adding a delay instruction in the macro, to allow
> >> reading to finish before any attempt to write the converted data file.
> >>
> >> Obviously this is less than ideal because this delay will vary
> depending
> >> on the speed of the computer and other running processes. It makes it
> >> impossible to write a portable solution unless one incorporates a long
> >> enough delay to cover all existing computers (in practice that is quite
> >> a few seconds' delay!).
> >>
> >> Would the solution be to add another command to ImageJ similar to
> >> wait(...)
> >> that waits for all i/o to complete before continuing execution (of the
> >> macro)?
> >>
> >> I am not in a position to judge if this is a sensible proposition, but
> if
> >> it is I would be very pleased if this was incorporated into the
> program.
> >>
> >> Cheers,
> >> Francis
> >>
> >> --
> >> Dr Francis L Burton,          |  [hidden email]
> >> West Medical Building,        |
> >> University of Glasgow,        |  Tel [phone]
> >> Glasgow, G12 8QQ, Scotland.   |  Fax [phone]
> >>
> >
> >
>

[ctrueden]

Hi Wayne,

Good idea; I will add such a window to the next Bio-Formats release (not
this week's, but next time).

I still think ImageJ would benefit from having specific reader and writer
interfaces, though. It would allow the File/Open and Save As commands to be
more extensible.

-Curtis

On Wed, Apr 16, 2008 at 10:06 AM, Wayne Rasband <[hidden email]> wrote:

> What I would like to see is a "Bio-Formats" window that supports drag and
> drop. Then I could, for example, drag a .lsm file onto the "ImageJ" window
> to open it using the LSM_Reader, onto the "LSM Toolbox" window to open it
> using the LSM Toolbox, and onto the "Bio-Formats" window to open it using
> the Bio-Formats plugin.
>
> -wayne
>
>
> On Apr 15, 2008, at 2:37 PM, Curtis Rueden wrote:
>
>  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
> >
>

[Bertram Manz]

> Now that you mention... I sometimes lose the ability to drag and drop in the
> IJ window. I am afraid that I do not know what triggers this and that is why
> I haven't reported it so far.
> This has been going on for sometime now (i.e. it is not a new "feature").
> Has anybody else seen this? (IJ under linux).
>
Same with me. If I start ImageJ from a console window, I get the following error
messages:
java.lang.NegativeArraySizeException
         at ij.plugin.DicomDecoder.getString(DICOM.java:249)
         at ij.plugin.DicomDecoder.getHeaderInfo(DICOM.java:664)
         at ij.plugin.DicomDecoder.addInfo(DICOM.java:603)
         at ij.plugin.DicomDecoder.getFileInfo(DICOM.java:425)
         at ij.plugin.DICOM.run(DICOM.java:82)
         at ij.IJ.runPlugIn(IJ.java:131)
         at ij.IJ.runPlugIn(IJ.java:113)
         at ij.io.Opener.openImage(Opener.java:199)
         at ij.io.Opener.openImage(Opener.java:249)
         at ij.io.Opener.open(Opener.java:116)
         at ij.io.Opener.openAndAddToRecent(Opener.java:176)
         at ij.plugin.DragAndDrop.openFile(DragAndDrop.java:96)
         at ij.plugin.DragAndDrop.run(DragAndDrop.java:83)
         at java.lang.Thread.run(Unknown Source)

It seems like ImageJ tries to open the file as DICOM?

Cheers,
Bertram

[Francis Burton]

Hi Curtis,

I'm not sure if it is appropriate to continue this exchange on the mailing
list. If not, we can continue in private. Still, this discussion may be of
interest to someone - who knows.

At 16:24 16/04/08 -0500, Curtis Rueden <[hidden email]> wrote:

>Output from showinf looks good. Note that you can suppress reading of the
>pixels by using:
>
>showinf 07.lsm -nopix
>
>Or you can limit to a smaller subset of image planes with:
>
>showinf 07.lsm -range 0 2
>
>The latter is a good way to quickly test that the pixels are being read
>properly, without waiting for 20000 image planes to load. :-)

Ah, this might indicate where part of the problem lies. I am not expecting
to see 20000 image planes in the LSM file. Rather, it contains two 'images'
each comprising 20000 line scans. So the long (20000 pixels) axis represents
time, and the short axis (512 pixels) is space; pixel values are fluorescence
intensities. In practice, this 2d array is treated as a normal image for
display purposes (Syla's recent post "Color profile for calcium waves" has a
link to such an image), though for analysis the axes are of course handled
rather differently.

>Therein lies the rub. It's a bug in ZeissLSMReader. Hopefully the latest
>code will fix it -- if not, let me know and I'll send you our FTP server
>information off-list. If you are willing to send me a nonworking file, we'll
>get it fixed for you.

You are welcome to have a sample file if you don't mind downloading >30Mb!

>From what you said, I'm confident that the bfconvert tool will help simplify
>your TIFF conversion process once we iron out the
>ArrayIndexOutOfBoundsException bug. Alternately, you could use a Java-Delphi
>bridge to call the Bio-Formats import routine directly from your Delphi
>program. Then you could ask for the data plane by plane, ask about
>associated metadata, etc., all from within your Delphi app. Here are some
>resources for doing that:
>
>1) Article on using JNI for communication between Delphi & Java:
>http://www.pacifier.com/~mmead/jni/delphi/informant/di200309kw.htm
>
>2) Delphi-Java Bridge library on SourceForge:
>http://sourceforge.net/projects/djbridge/
>
>3) JVMLink library that we developed for communication between Java and
>native languages via TCP/IP sockets:
>http://www.loci.wisc.edu/ome/jvmlink.html

Thanks for the pointers! This sounds like an efficient (in terms of run time)
solution. I just need to come up to speed with the new technology.

>Or you could just make system calls to showinf from Delphi to extract
>metadata parameters from the LSMs and dump the results to text files, which
>your program could parse. There are lots of ways to do what you want. Just
>let me know if you have any questions, and I'll try to help.

My idea of a simple-to-implement solution was to spawn (ShellExecute in Delphi)
"bfconvert" to read the LSM file and dump out the two TIFF images (one for each
wavelength), and then read the two TIFF files as I am doing now, using existing
code. Creating two new large files will be slower than unpacking the images in
memory, but faster than my colleagues can manually extract the images using the
Zeiss Browser!

Francis

--
Dr Francis L Burton,          |  [hidden email]
West Medical Building,        |
University of Glasgow,        |  Tel [phone]
Glasgow, G12 8QQ, Scotland.   |  Fax [phone]