[OpenSPIM] Why do SPIM and Micro-Manager use different TIFF packages?

[Bill Whitney]

I have discovered that if I image a Z-stack using Micro-Manager's multi-D
acquisition, the TIFF file generated differs from what I get if I image the
Z-stack using SPIMAcquisition.

Here is what I have discovered so far:

   - MM's Multi-D acquisition uses a micro-manager package,
   namely org.micromanager.acquisition.TaggedImageStorageMultipageTiff, which
   implements the interface org.micromanager.api.TaggedImageStorage
   - OpenSPIM uses packages from OME (Open Microscopy Environment),
   including loci.formats.IFormatWriter,  loci.formats.ImageWriter,
    loci.common.services.ServiceFactory,  loci.formats.MetadataTools,  etc.
   - The two packages write metadata to the TIFF file differently. The main
   difference that is impacting me right now is the metadata for the physical
   space separation between Z slices. Both packages arguably write "CORRECT"
   metadata to the TIFF file, but in different ways. When I read the file  in
   later using ImageJ, or the ImageJ plugin BigDataViewer, the z-spacing info
   is read correctly for the MM Multi-D file. However, when I try to read in a
   file created using SPIMAcquisition, ImageJ always thinks the z-spacing is 1
   cm (when typically it is 3-5 micrometers).
   - The two packages also behave differently for LARGE files. The
   definition of the TIFF file format limits files to no more than 4GB. When
   MM's Multi-D code encounters a file that would be over the 4GB limit, it
   breaks it up into multiple files, each less than 4GB. SPIMAcquisition does
   not do anything different for files over the 4GB limit, which results in an
   error from the OME package. The OME package does support large files via
   switching from TIFF format to BIGTIFF format, but the calling code has to
    specify that. I was able to customize the SPIM code to do this, but the
   resulting BIGTIFF file proved to be unusable in ImageJ.

In both of these cases, the MM Multi-D behavior matches my needs, whereas
the SPIMAcquisition behavior is causing me problems that I have to fix, or
workaround in some way. I have been using the SPIM because we have a SPIM
microscope, and we need support for a stage that can rotate in Theta, as
well as move in X, Y, and Z.

I am posting this first to the SPIM group, although I know this issue
involves interfaces between several groups: SPIM, Micro-manager, OME,
ImageJ, etc.

I would like to ask the SPIM people if there was a reason for using the OME
package for writing TIFF files rather than the MM package?
Because -- I am thinking of customizing my version of the SPIM code to use
the MM package instead.

I appreciate thoughts on the reasonableness of doing this customization to
the TIFF writing code in SPIM.
I also appreciate any other suggestions people have about better ways to
move forward.

I am using the following versions at the moment:
 - Micro-Manager: 1.4.23 20151021
 - ImageJ: 1.50b
 - OpenSPIM: Not sure how to determine this. We originally downloaded the
OpenSPIM/Fiji package. I just checked the OpenSPIM downloads page, and it
is still listing a download dated 4/26/2015, so that must be the one we
used.

Thanks,
Bill Whitney
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openspim.org/pipermail/openspim/attachments/20160112/9fb4d819/attachment-0002.html>