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

Posted by ctrueden on Apr 15, 2008; 6:08pm
URL: http://imagej.273.s1.nabble.com/a-tutorial-on-a-custom-image-format-file-reader-writer-tp3696492p3696503.html

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]
>