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

Fri Jan 15 07:23:20 CST 2016

Indeed it looks like the updated OpenSPIM writes files bigger than 4GB,  
the metadata also looks correct for me.

Regards,
Monika

W dniu .01.2016 o 12:18 HongKee Moon <moon at mpi-cbg.de> pisze:

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

-- 
Dr Monika Pawłowska
Nencki Institute
02-093 Warsaw
Pasteura 3
Poland
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openspim.org/pipermail/openspim/attachments/20160115/01bdbecd/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 25136 bytes
Desc: not available
URL: <http://openspim.org/pipermail/openspim/attachments/20160115/01bdbecd/attachment-0002.png>