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

[HongKee Moon]

Hi Bill,

I think SPIMAcquistion was intended to be compatible with Fiji seamlessly. That is why it uses OME TIFF package.
Recently, we have updated SPIMAcquisition before Christmas in order to support HDF5 export and fix Anti-Drift.
The update contains the fix for “over 4GB tiffs” too.
Please, update and give it a try.

For the z-space, you can specify z-space and click “stack at this Z plus:”.
Each stack contains the z-space based on what you enter.
The pixel calibration is also crucial for having the correct Metadata which will be read by image readers in Fiji.




Thank you for your comments.
Please, let us know if you have any feature request and/or feedback.

Cheers,
HongKee


> On Jan 12, 2016, at 7:03 PM, Bill Whitney <whitnewn at clarkson.edu> wrote:
> 
> 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
> _______________________________________________
> OpenSPIM mailing list
> OpenSPIM at openspim.org
> http://openspim.org/mailman/listinfo/openspim


--
HongKee Moon
Software Engineer
Scientific Computing Facility

Max Planck Institute of Molecular Cell Biology and Genetics
Pfotenhauerstr. 108
01307 Dresden
Germany

fon: +49 351 210 2740
fax: +49 351 210 1689
www.mpi-cbg.de

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openspim.org/pipermail/openspim/attachments/20160113/571e0cf8/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenSPIM.png
Type: image/png
Size: 25136 bytes
Desc: not available
URL: <http://openspim.org/pipermail/openspim/attachments/20160113/571e0cf8/attachment-0002.png>