<div dir="ltr">Hi Simon, just a short comment - how does it scale with the number of ROIs per image? It looks like the initial use case is one ROI / image - what about 1000?</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 7, 2014 at 12:18 PM, Simon Li <span dir="ltr"><<a href="mailto:s.p.li@dundee.ac.uk" target="_blank">s.p.li@dundee.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div>Hi all</div>
<div><br>
</div>
<div>It’s taken a bit longer than anticipated, but here’s a first implementation for the features API:</div>
<div><a href="https://github.com/ome/omero-features" target="_blank">https://github.com/ome/omero-features</a></div>
<div><br>
</div>
<div>It’s more or less what I’ve described in my last email, to start with I recommend looking at the README and example.py in the repository root to see how it all works. The key features are:</div>
<ul>
<li>Store and retrieve features using an Image-ID or Roi-ID.</li><li>Each feature set consists of a number of named features and is per-user-per-group to avoid permissions problems.</li><li>The underlying storage format is OMERO.tables which has some limitations, but one of the aims of this work is to figure out exactly what we want to replace it with.</li></ul>
<div>As an example of using it I’ve created a new branch of OMERO.wndcharm:</div>
<div><a href="https://github.com/manics/omero-wndcharm/tree/omero-features" target="_blank">https://github.com/manics/omero-wndcharm/tree/omero-features</a></div>
<div>Note only the original WND-CHARM image features are stored using the features API, other information such as classification labels, results, and feature weights can’t be stored at present. They would require additional columns to store row metadata, this
 is an obvious next step.</div>
<div><br>
</div>
<div>There’s obviously a lot more that could be handled by the API, but this is the sort of thing that really needs input from potential users so take a look and let me know what you think, either on this list, as a GitHub issue, or on the Wiki.</div>
<div><br>
</div>
<div>Cheers</div>
<div><br>
</div>
<div>Simon</div>
<div><br>
</div>
<span>
<div style="font-family:Calibri;font-size:11pt;text-align:left;color:black;BORDER-BOTTOM:medium none;BORDER-LEFT:medium none;PADDING-BOTTOM:0in;PADDING-LEFT:0in;PADDING-RIGHT:0in;BORDER-TOP:#b5c4df 1pt solid;BORDER-RIGHT:medium none;PADDING-TOP:3pt">
<span style="font-weight:bold">From: </span>Simon Li <<a href="mailto:s.p.li@dundee.ac.uk" target="_blank">s.p.li@dundee.ac.uk</a>><br>
<span style="font-weight:bold">Date: </span>Wednesday, 27 August 2014 15:50<br>
<span style="font-weight:bold">To: </span>Lee Kamentsky <<a href="mailto:leek@broadinstitute.org" target="_blank">leek@broadinstitute.org</a>>, "Coletta, Christopher (NIH/NIA/IRP) [E]" <<a href="mailto:christopher.coletta@nih.gov" target="_blank">christopher.coletta@nih.gov</a>>, "Ivan E.
 Cao-Berg" <<a href="mailto:icaoberg@andrew.cmu.edu" target="_blank">icaoberg@andrew.cmu.edu</a>>, Joaquin Correa <<a href="mailto:joaquincorrea@lbl.gov" target="_blank">joaquincorrea@lbl.gov</a>><br>
<span style="font-weight:bold">Cc: </span>OME Development <<a href="mailto:ome-devel@lists.openmicroscopy.org.uk" target="_blank">ome-devel@lists.openmicroscopy.org.uk</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [ome-devel] OMERO.features API development<br>
</div>
<div><br>
</div>
<div>
<div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div>
<div>Hi all</div>
<div><br>
</div>
<div>I had a discussion with Jason and Jean-Marie in Dundee a couple of weeks ago on how to make progress with the OMERO.features API. The problem of properly storing all the metadata we require is obviously extremely important, but it's going to take a while
 to figure out.</div>
<div><br>
</div>
<div>So, to begin with we came up with the idea of a simplified API that would work as a client-side Python library and should be relatively simple to implement. I've described it on the OMERO.features wiki:
<a href="https://github.com/ome/omero-features/wiki/API-Outline-V1" target="_blank">https://github.com/ome/omero-features/wiki/API-Outline-V1</a></div>
<div><br>
</div>
<div>The key points are:</div>
<div><br>
</div>
<div>* Store the Image and/or ROI ID (which allows us to specify planes/channels/tiles without needing to add columns to the table), and feature names/values, using OMERO.tables.</div>
<div>* Provide methods to store a feature row, retrieve a feature row by Image/ROI ID, and to select rows by querying feature values (simple comparison operators), ideally with a simple to understand syntax.</div>
<div>* Implement as a client-side Python library.</div>
<div><br>
</div>
<div>This means the more complicated requirements such as linking objects other than images/ROIs, more complicated feature metadata, and supporting both efficient bulk and random access will be left for the next iteration. As always comments are welcome- if
 you think this is too simple to be useful don't be afraid to say so.</div>
<div><br>
</div>
<div>Cheers</div>
<div><br>
</div>
<div>Simon</div>
</div>
<div><br>
</div>
<div><br>
</div>
<span>
<div>
<div>On 08/05/2014 15:20, "Lee Kamentsky" <<a href="mailto:leek@broadinstitute.org" target="_blank">leek@broadinstitute.org</a>> wrote:</div>
</div>
<div><br>
</div>
<blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5">
<div>
<div>
<div dir="ltr">Hi all,
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Thu, May 8, 2014 at 9:40 AM, Simon Li <span dir="ltr">
<<a href="mailto:s.p.li@dundee.ac.uk" target="_blank">s.p.li@dundee.ac.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div>
<div>Hi all</div>
<div><br>
</div>
<div>I've started a Github repository for trying out some OMERO.features ideas based on what I mentioned in the last email:</div>
<div><a href="https://github.com/manics/omero-features" target="_blank">https://github.com/manics/omero-features</a></div>
<div><br>
</div>
<div>There's not a great deal in there at the moment. It's just saving features into a local HDF5 file using Pytables, and example.py creates a table similar to that used by Pyslid (OMERO.searcher). timings.txt shows some rough run-times. Key-value row pairs
 are mapped to table columns, however this means each row has to have the same keys. There's no simple way to have a key-value map per column, for now I'm just storing multiple features in one column.</div>
<div><br>
</div>
<div>This is easily convertible to OMERO.tables, columns could be labelled using OMERO annotations (in 5.1 there's a new MapAnnotation), though it effectively means each group of features is stored separately and thus would need to be queried separately. Alternatively
 an auxiliary table could be used to store the per-column key-value pairs, similar to how column descriptions are currently stored in OMERO.tables.</div>
<div><br>
</div>
<div>A major limitation is that database joins between OMERO and a feature-table aren't practical. For example, if each feature row is labelled with an image ID, and you want to select a subset of rows using an OMERO query, you have to pass a list of image
 IDs to the Pytables query function which from my initial testing is very limited in the number of parameters it'll handle (I get a stack overflow if too many image IDs are passed).</div>
<div><br>
</div>
<div>In practice this means you'd either need the feature table to contain any metadata necessary for selecting rows (e.g. dataset ID, experiment parameters, annotations) even if this means duplicating information held in OMERO, or split the query up (very
 inefficient). This is probably fine for people dealing with features in bulk where you might download all features for a screen for offline processing, not so good for real-time searching such as OMERO.searcher where you'd either need to store everything you
 need for pre-filtering search results in the table, or read all features and do the filtering afterwards.</div>
<div><br>
</div>
<div>Probably OK as far as developing the API is concerned, but longer term it suggests we need some other storage mechanism. Some of you will remember Joaquin Correa from Paris last year. He's currently working on his own feature storage implementation at
 LBL, so potentially this is something we could look at for OMERO, and of course there are many other possibilities.</div>
<div><br>
</div>
</div>
</div>
</blockquote>
<div>People in other groups here (Broad Institute) are looking at MongoDB as an alternative to HDF5 - we are all sort of struggling with the same types of problems and I don't think anyone has found a solution. In CellProfiler, for HDF5, we maintain a dataset
 of per-image indexing information into the HDF5 datasets and perhaps that's an appropriate hybrid approach for OMERO - the join returns the slicing information needed for pulling the data out of the datasets and you then retrieve the data from HDF5. We store
 ~1K values per image per feature (one value per cell or other segmented object), so for us, each round-trip down the HDF5 stack deals with a reasonable amount of data. HDF5 slicing isn't as flexible as Numpy - you can ask for ranges, but not a list of individual
 dimension coordinates which would be what you'd want if you were returning data for a large number of rows. Fetching individual values from HDF5 is painfully slow for our scale of experiments, no really good solution, maybe all I have to contribute on the
 topic is "I feel your pain" :-(</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div>
<div></div>
<div>Simon</div>
</div>
<div><br>
</div>
<div><br>
</div>
<br>
<div>
<div>On 24 Apr 2014, at 12:57, Lee Kamentsky <<a href="mailto:leek@broadinstitute.org" target="_blank">leek@broadinstitute.org</a>> wrote:</div>
<br>
<blockquote type="cite">
<div dir="ltr">Hi all,<br>
<div class="gmail_extra">Just chiming in, since we were mentioned...<br>
<br>
<div class="gmail_quote">On Wed, Apr 23, 2014 at 5:10 PM, Simon Li <span dir="ltr">
<<a href="mailto:s.p.li@dundee.ac.uk" target="_blank">s.p.li@dundee.ac.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hi all<br>
<br>
Now that OMERO 5.0 is out of the way, and OMERO.searcher and WND-CHRM are either released or very close to release, I think it's time to restart our OMERO.features discussions.<br>
<br>
We got as far as the idea of a 2D table with any number of key-value pairs on each column and row, so for example each row could be as simple as (OmeroType: Image, OmeroId: 123), or in the case of features which are a function of multiple images or channels
 (OmeroType: Image, OmeroId: 123, Channel1: 0, Channel2: 3), etc. Columns could for example be (FeatureFamily: WndCharm, Feature: Zernike). Each table cell could either be a scalar or array. Retrieving features could be done by providing key-value pairs to
 be matched.<br>
<br>
All of this is still up for discussion, especially since the implementation of this interface could be challenging and there's some redundancy/ambiguity. Just to be clear, the above is a conceptual description of how the API would appear to users, the actual
 back-end could be completely different.<br>
<br>
Lee Kamentsky gave us a use case just before Christmas [1], Chris Coletta and Ivan Cao-berg are planning to summarise how they see WND-CHARM and OMERO.searcher fitting in. I know a few other people are interested in this discussion, so feel free to respond
 here or in the forums.<br>
</blockquote>
<div><br>
</div>
<div>For us, it's important to link features to regions of interest, specifically segmentations of whole cells and cellular compartments. The other issues have to do with scalability and the efficiency of retrieving large data sets either by selecting a few
 features for a large number of images (e.g. up to on the order of 1,000,000 images and 1,000 entries per feature per image) or by selecting many or all features associated with a subset of the regions of interest.</div>
<div><br>
</div>
<div>We are also interested in recording tracking data. What's needed here is the ability to record a link between the region of interest in one frame of a time-series stack with a region of interest in a later frame and you need the flexibility of a many-many
 relationship to represent cell division and potentially merging. I'm fairly confident that you could encode that sort of thing in a 2-D table which had columns referencing both ROIs.</div>
<div><br>
</div>
<div>Finally, we try to capture enough information about the analysis to make it reproducible - things like the pipeline used for the analysis, the GIT hash of the software used to run the analysis and of each image analyzed. I think all of that is easily captured,
 though, in the tables and I doubt we need any explicit functionality devoted to that. It might be nice to be able to annotate the table itself with attributes in order to document the linking of the analysis results to the experimental protocol, but the linking
 could be documented using columns in an experiment-wide table.</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
A few of us are planning to meet up at the OME Paris meeting- if you're interested drop me an email.<br>
<br>
Thanks<br>
<br>
Simon<br>
<br>
[1] <a href="http://lists.openmicroscopy.org.uk/pipermail/ome-devel/2013-November/002573.html" target="_blank">
http://lists.openmicroscopy.org.uk/pipermail/ome-devel/2013-November/002573.html</a><br>
<br>
<br>
On 7 Nov 2013, at 14:20, Simon Li <<a href="mailto:s.p.li@dundee.ac.uk" target="_blank">s.p.li@dundee.ac.uk</a>> wrote:<br>
<br>
> Some notes from our meeting yesterday:<br>
> <a href="http://www.openmicroscopy.org/site/community/minutes/minigroup/omero-features-meetings/2013-11-06-omero-features-google-hangout" target="_blank">
http://www.openmicroscopy.org/site/community/minutes/minigroup/omero-features-meetings/2013-11-06-omero-features-google-hangout</a><br>
><br>
> Summary:<br>
> We're thinking of representing features as a 2D array, with metadata stored as key-value maps attached to the array, or individual columns or rows. These keys could describe things such as the feature name (column), sample metadata (row), algorithm parameters,
 calculation pipelines, etc.<br>
><br>
> This should work as an OMERO API- in order to retrieve features you'd pass in a set of key-value pairs, for instance to specify which features you want and which images/ROIs etc, and OMERO would handle the logic and return the feature table(s) matching those
 parameters. Since everyone has different requirements the keys could be anything, however we're trying to define a small set of standard keys- any suggestions are very welcome.<br>
><br>
> Outside of OMERO we still need a format for transporting features, so we're thinking some form of HDF5.<br>
><br>
> Simon<br>
><br>
><br>
> The University of Dundee is a registered Scottish Charity, No: SC015096<br>
> _______________________________________________<br>
> ome-devel mailing list<br>
> <a href="mailto:ome-devel@lists.openmicroscopy.org.uk" target="_blank">ome-devel@lists.openmicroscopy.org.uk</a><br>
> <a href="http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel" target="_blank">
http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel</a><br>
<br>
<br>
The University of Dundee is a registered Scottish Charity, No: SC015096<br>
_______________________________________________<br>
ome-devel mailing list<br>
<a href="mailto:ome-devel@lists.openmicroscopy.org.uk" target="_blank">ome-devel@lists.openmicroscopy.org.uk</a><br>
<a href="http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel" target="_blank">http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div>
<br>
<br>
<span style="font-size:10pt">The University of Dundee is a registered Scottish Charity, No: SC015096</span></div>
<br>
_______________________________________________<br>
ome-devel mailing list<br>
<a href="mailto:ome-devel@lists.openmicroscopy.org.uk" target="_blank">ome-devel@lists.openmicroscopy.org.uk</a><br>
<a href="http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel" target="_blank">http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</blockquote>
</span><br>
<span style="font-size:10pt">The University of Dundee is a registered Scottish Charity, No: SC015096</span></div>
</div>
</span><br>
<span style="font-size:10pt">The University of Dundee is a registered Scottish Charity, No: SC015096</span>
</div>

</blockquote></div><br></div>