[ome-devel] Re: [ome-users] importing multiples pixel sets ?

[Curtis Rueden]

Hi Zach,

> Is this something that VisBio can help with? Maybe just in terms of  
> opening up all of the individual images and stitching them together  
> into an OME-TIFF or OME-XML file, or even perhaps using VisBio to  
> actually send the data to the OME server?


VisBio is capable of encapsulating an image from a collection of files 
numbered in some coherent fashion. The exact numbering scheme is 
flexible, and VisBio detects possible sets of files pretty robustly.

VisBio's export function currently exports to multi-page TIFF, but not 
OME-TIFF. Switching it to export OME-TIFF is trivial in principle, but I 
wanted to wait until our file format support was properly converting 
metadata from the various formats -- I don't want to release that 
functionality until the convertion of metadata to OME-TIFF is adequate, 
which it currently is not.

As for uploading to the database, unfortunately VisBio uploads a single 
set of pixels as a new image right now. Eventually we hope to expand 
this support to be more flexible, but it sounds like Kris wants multiple 
sets of pixels, which VisBio cannot do directly right now.

> Of course, the custom importer/perl route is best if this needs to be  
> automated, but -- and this is out of my own curiosity -- is all the  
> groundwork there in VisBio to do this sort of task?


Actually, VisBio's OME uploading can be easily automated using the 
"omeul" tool packaged with VisBio. It allows any number of uploads to be 
batched without needing to launch the GUI or provide user interaction. 
However, since the upload functionality isn't sophisticated enough to 
upload multiple pixel sets yet, this is largely a moot point.

I do not know the Java Remote Framework API well enough to comment on 
how difficult it would be to extend VisBio to support multiple pixel sets.

Another possibility might be converting the data to OME-TIFF. If the 
data files are already TIFF, this could be as simple as inserting the 
OME-XML metadata block into each header with the proper TiffData element 
identifying which image planes correspond to which pixel sets (see 
http://www.loci.wisc.edu/ome/ome-tiff-spec.html for full details). In 
theory, it is sound. Unfortunately, again, the OME-TIFF backend importer 
currently supports one Image with one Pixels -- additional pixel sets 
are ignored. But it shouldn't be too hard to extend the OME-TIFF perl 
importer to handle multiple Images with multiple Pixels. If Kris decides 
to go the OME-TIFF route I can work on bringing the importer up to snuff.

-Curtis