[OpenSPIM] ome-tiff output

Fri Nov 10 08:56:49 CST 2017

Great to hear! If we can make it even more intuitive or compatible just let us know!

All the best,
Stephan

Sent from my iPhone

On Nov 10, 2017, at 08:10, Christoph Sommer <christoph.sommer at ist.ac.at<mailto:christoph.sommer at ist.ac.at>> wrote:

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

_______________________________________________
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/e4e48e3f/attachment.html>