[ome-devel] .Flex File integration

[josh.moore at gmx.de]

Ghislain Bonamy writes:
 > Thanks josh,

Gladly.

 > For the path: this is what I meant:
 > [FlexReaderServerMaps]
 > CIA-1 = \\\\hostname1\\mount;\\\\archivehost1\\mount;... 
 > >From the description, I was not sure whether the total number of path is limited to 2 or more.

No, not at all. I'll try to make the wiki page clearer.

 > With OMERO.fs in OMERO 4.1, one could simply point to the location
 > of the images, or location of the .mea file, so that the import is
 > done automatically without data duplication. Right?

No. Unfortunately, we were not able to solve the data duplication
issue for 4.1. It is still high on our priority list, but for this
release, files will still be converted to the internal format.

fs (specifically "DropBox") does allow for automatic import of the
files, however.

 > For the ROI, storage, I think the advantage of the chain code is
 > that it is much more concise (so it would use less storage
 > space). The disadvantage is the computing portion of it. Perhaps
 > something we should keep discussing.

Definitely. We will certainly be expanding the server-side ROI support
over the next releases.

 > I am not sure I see how the PyTables and OMERO interact. Can you
 > expect to have these PyTables saved as separate (physical) files,
 > to which OMERO points, or is it an actual table in OMERO (in the
 > PLSQL database)?

They're separate HDF files. There's a secondary python server which
handles all requests for the tabular data. At the moment,
populate_roi.py is creating one file on disk for every analysis run,
the definition of which is file format dependent. In the HDF file,
there is a column referencing the Image id as well as the Roi id along
with the measurements for that region.

Cheers,
~J.

 > Best,
 > 
 > Ghislain Bonamy, PhD
 > __________________________________________
 > Research Investigator
 > 
 > Genomic Institute of the
 > Novartis Research
 > Foundation
 > Department of Informatics, room C117
 > 10675 John Jay Hopkins Drive
 > San Diego CA 92121
 > USA
 > 
 > +1 (858) 812-1534 (W & F)
 > +1 (757) 941-4194 (H)
 > +1 (858) 354-7388 (M)
 > www.gnf.org 
 > 
 > 
 > -----Original Message-----
 > From: josh.moore at gmx.de [mailto:josh.moore at gmx.de] 
 > Sent: Wednesday, October 14, 2009 9:15 AM
 > To: Ghislain Bonamy
 > Cc: josh.moore at gmx.de; Curtis Rueden; OME-devel mailing list; Frick, Manfred; Haque, Nuzrul
 > Subject: Re: [ome-devel] .Flex File integration
 > 
 > Ghislain Bonamy writes:
 >  > Josh, Curtis,
 > 
 > Hi Ghislain,
 > 
 >  > I looked at this page:
 >  > https://trac.openmicroscopy.org.uk/omero/wiki/FlexSupport
 >  > One thing that I wanted to point out is that the Opera supports
 >  > several archiving paths.
 > 
 > Right. Do the semicolon separated values not fulfill this? 
 > 
 >  > Another thing that I was wondering is whether OMERO will start
 >  > federating the results from various analysis tools.
 > 
 > That's certainly what the HCS_PREVIEW is intended to be the beginning
 > of. It's non-trivial, of course, but you can take a look at:
 > 
 >   http://trac.openmicroscopy.org.uk/omero/browser/trunk/components/tools/OmeroPy/src/omero/util/populate_roi.py
 > 
 > for what we're doing at the moment.
 > 
 >  > Finally I see that the "HCS Preview" provide storage support for
 >  > ROI. Acapella does not currently provide support generating
 >  > ROI. Thus, I have developed a library which generates the chain
 >  > code for simple shape (ie. not composite shapes). Any information
 >  > how this data can be formatted into something usable by OMERO would
 >  > be great.
 > 
 > Unfortunately, I don't think it will be possible to visualize anything
 > like your chains in the preview, unless you convert them and store
 > them as bit masks. But it's certainly something we can keep talking
 > about.
 > 
 >  > Regarding single cell data, ROI etc. Am I correct to believe that
 >  > all of this data is stuffed into OMERO? If so is there any plans to
 >  > provide support for file storage rather storage in the database?
 > 
 > It's currently being stored in HDF via PyTables. For more information,
 > see:
 > 
 >   http://trac.openmicroscopy.org.uk/omero/wiki/OmeroTables
 > 
 > 
 > Cheers,
 > ~Josh