[OpenSPIM] ome-tiff output

Fri Nov 10 04:05:05 CST 2017

Dear Stephan and OpenSpim users,

thanks for pointing me to the autoloader. I tested it on our data and 
technically it works! It seems tiles and angles are still mistaken, but 
this seems to be a problem of the wrong meta data... I now work on 
automating the MVR process for our setup.

Also, we found a way to truncate the containing ome-xml data, to make 
each output files 'stand-alone' for specific cases. Yet, the autoloader 
is my preferred solution.

Thanks to all for your help!

Cheers,

Chris

Am 11/7/2017 um 8:17 PM schrieb Stephan.Preibisch at mdc-berlin.de:
> Hi, did you try using the Autoloader of the MVR/BigStitcher (it’s 
> basically the same now) for import? Activate the BigStitcher update 
> site first to get the newest code. It should handle OME-TIff ... if 
> not, send us a small example and we’ll fix it.
>
> Cheers,
> Stephan
>
> Sent from my iPhone
>
> On Nov 7, 2017, at 16:17, Christoph Sommer <christoph.sommer at ist.ac.at 
> <mailto:christoph.sommer at ist.ac.at>> wrote:
>
>> Dear HongKee,
>>
>> thank so much for your recommendation and code. When I understand 
>> correctly, it would require the deployment of this VirtualStack class 
>> to all ImageJ instances of potential users. I was hoping for a 
>> solution, which does not need adaptions of ImageJ.
>>
>> Alternatively, we could create a different output format in the 
>> acquisition (no multi-file OMETiff). I saw that there's already a 
>> "IndividualImagesHandler" or an HDF5 handler in "spim.io 
>> <http://spim.io>". Does someone have experience with alternative 
>> output formats?
>>
>> Cheers,
>> Chris
>>
>>
>>> We have also faced those problems because the default image opener 
>>> is trying to get the metadata for every file.
>>> I really recommend you to make own ImageStack class for reading the 
>>> metadata just once for your whole series.
>>>
>>> We had to create our version of VirtualStack class based on 
>>> https://imagej.nih.gov/ij/plugins/virtual-opener.html 
>>> <https://imagej.nih.gov/ij/plugins/virtual-opener.html> to avoid 
>>> redundant metadata reading. The below code is not a perfect version, 
>>> please, use it as a reference.
>>>
>>> Hopefully, it will help you.
>>>
>>> Cheers,
>>> HongKee
>>>
>>> ———————————————————
>>>
>>> import ij.ImageStack;
>>> import ij.process.ByteProcessor;
>>> import ij.process.ImageProcessor;
>>> import loci.formats.FormatException;
>>> import loci.formats.ImageReader;
>>> import loci.plugins.util.ImageProcessorReader;
>>>
>>> import loci.common.services.DependencyException;
>>> import loci.common.services.ServiceException;
>>> import loci.common.services.ServiceFactory;
>>> import loci.formats.FormatException;
>>> import loci.formats.ImageReader;
>>> import loci.formats.meta.IMetadata;
>>> import loci.formats.services.OMEXMLService;
>>>
>>> public class MyImageStack extends ImageStack
>>> {
>>> private int bitDepth;
>>> private int width, height;
>>> ImageProcessorReader imageProcessorReader;
>>> private int zSize = 1, tSize = 1, cSize = 1;
>>> private int cEffectiveSize = 1;
>>>
>>> public void addSlice( String path )
>>> {
>>> if(path != null)
>>> {
>>> if(width == 0)
>>> {
>>> // create format reader
>>> ImageReader reader = getImageReader( path );
>>>
>>> // output dimensional information
>>> int sizeX = reader.getSizeX();
>>> this.width = sizeX;
>>>
>>> int sizeY = reader.getSizeY();
>>> this.height = sizeY;
>>>
>>> // System.out.println("Effective C" + reader.getEffectiveSizeC());
>>> setcEffectiveSize( reader.getEffectiveSizeC() );
>>>
>>> int sizeC = reader.getSizeC();
>>> int sizeZ = reader.getSizeZ();
>>> int sizeT = reader.getSizeT();
>>>
>>> // System.out.println( "C=" + sizeC + " Z=" + sizeZ + " T=" + sizeT );
>>>
>>> setcSize( sizeC );
>>> setzSize( sizeZ );
>>> settSize( sizeT );
>>>
>>> this.bitDepth = reader.getBitsPerPixel();
>>> this.imageProcessorReader = new ImageProcessorReader( reader );
>>> }
>>> }
>>> }
>>>
>>> public ImageProcessor getProcessor(int n)
>>> {
>>> // properly implement to get ImageProcessor based on n
>>> }
>>>
>>> public static ImageReader getImageReader( String path )
>>> {
>>> ImageReader reader = null;
>>>
>>> try
>>> {
>>> ServiceFactory factory = new ServiceFactory();
>>> OMEXMLService service = factory.getInstance(OMEXMLService.class);
>>> IMetadata meta = service.createOMEXMLMetadata();
>>>
>>> // create format reader
>>> reader = new ImageReader();
>>> reader.setMetadataStore(meta);
>>>
>>> // initialize file
>>> //System.out.println(path);
>>> reader.setId( path );
>>> }
>>> catch ( DependencyException e )
>>> {
>>> e.printStackTrace();
>>> }
>>> catch ( ServiceException e )
>>> {
>>> e.printStackTrace();
>>> }
>>> catch ( IOException e )
>>> {
>>> e.printStackTrace();
>>> }
>>> catch ( FormatException e )
>>> {
>>> e.printStackTrace();
>>> }
>>>
>>> return reader;
>>> }
>>> }
>>>
>>> ———————————————
>>>
>>>
>>>> On Nov 6, 2017, at 10:43 AM, Christoph Sommer 
>>>> <christoph.sommer at ist.ac.at <mailto:christoph.sommer at ist.ac.at>> wrote:
>>>>
>>>> Dear OpenSpim folks,
>>>>
>>>> thanks for creating such a great resource!
>>>>
>>>> We are currently using an OpenSpim setup and the created output is 
>>>> a multi-file ome-tiff. For many applications (e.g. the MVR from 
>>>> Stephan Preibisch et al.) we need to convert the ome-tiff to normal 
>>>> tiff.
>>>>
>>>> Unfortunately, for long time-lapse the conversion takes forever, 
>>>> since for each conversion step all meta-data is parsed from each 
>>>> single time point. My script uses the Bioformats ImporterOptions 
>>>> class, but I can't see how I can bypass the meta-data parsing. I 
>>>> also tried the 'bvconvert' command line script but also got issues 
>>>> there. Also reading from Python (e.g. with the module 'tifffile' 
>>>> only return always the first angle image-stack...)
>>>>
>>>> Would you have any idea?
>>>>
>>>> Cheers,
>>>>
>>>> Chris
>>>>
>>>>
>>>> _______________________________________________
>>>> OpenSPIM mailing list
>>>> OpenSPIM at openspim.org <mailto:OpenSPIM at openspim.org>
>>>> http://openspim.org/mailman/listinfo/openspim
>>>
>>>
>>> --
>>> HongKee Moon
>>> Scientific Software Engineer
>>> Scientific Computing Facility
>>>
>>> Max Planck Institute of Molecular Cell Biology and Genetics
>>> Pfotenhauerstr. 108
>>> 01307 Dresden
>>> Germany
>>>
>>> fon: +49 351 210 1923
>>> fax: +49 351 210 1907
>>> www.mpi-cbg.de <http://www.mpi-cbg.de>
>>>
>>
>> _______________________________________________
>> OpenSPIM mailing list
>> OpenSPIM at openspim.org <mailto:OpenSPIM at openspim.org>
>> http://openspim.org/mailman/listinfo/openspim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openspim.org/pipermail/openspim/attachments/20171110/d400b7fc/attachment-0001.html>