Login  Register

Re: a tutorial on a custom image format file reader / writer

Posted by ctrueden on Apr 16, 2008; 9:24pm
URL: http://imagej.273.s1.nabble.com/a-tutorial-on-a-custom-image-format-file-reader-writer-tp3696492p3696507.html

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 +44-141-330-6598
> >> Glasgow, G12 8QQ, Scotland.   |  Fax +44-141-330-4612
> >>
> >
> >
>