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

Posted by Wayne Rasband on Apr 14, 2008; 8:33pm
URL: http://imagej.273.s1.nabble.com/a-tutorial-on-a-custom-image-format-file-reader-writer-tp3696492p3696494.html

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