http://imagej.273.s1.nabble.com/a-tutorial-on-a-custom-image-format-file-reader-writer-tp3696492p3696507.html
report.
So I tried some of the Bio-Format tools. First, I tried "showinf", and that
Output from showinf looks good. Note that you can suppress reading of the
properly, without waiting for 20000 image planes to load. :-)
Unfortunate, and almost certainly a bug in the Zeiss LSM reader. First,
tomorrow morning), you could test with the new release from the web site.
errors that can be safely ignored.
This can be ignored -- it just means that Nikon's ND2 plugin wasn't found.
Therein lies the rub. It's a bug in ZeissLSMReader. Hopefully the latest
information off-list. If you are willing to send me a nonworking file, we'll
get it fixed for you.
> 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
200 image planes, though, so it is going to be pretty slow regardless.
ArrayIndexOutOfBoundsException bug. Alternately, you could use a Java-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
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.
> 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
> >>
> >
> >
>