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

[Feinstein, Timothy N]

Hi Bill,

Is that necessary?  We use Multi-D Acquisition because our SPIM has two lasers, and in my experience the mult-stage position mode handles sample rotation well.  Maybe I am missing something in your plan.

Best,


Tim

Timothy Feinstein, Ph.D.
Research Scientist
University of Pittsburgh Department of Developmental Biology


From: <openspim-bounces at openspim.org<mailto:openspim-bounces at openspim.org>> on behalf of Bill Whitney <whitnewn at clarkson.edu<mailto:whitnewn at clarkson.edu>>
Date: Tuesday, January 12, 2016 at 1:03 PM
To: "openspim at openspim.org<mailto:openspim at openspim.org>" <openspim at openspim.org<mailto:openspim at openspim.org>>
Subject: [OpenSPIM] Why do SPIM and Micro-Manager use different TIFF packages?

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/d7c33973/attachment-0002.html>