[ome-devel] OMERO.features: Development of a new API for storing image features

[Lee Kamentsky]

Hi Simon, all,
Just some quick answers to some parts:

On Thu, Aug 1, 2013 at 1:42 PM, Simon Li <s.p.li at dundee.ac.uk> wrote:

>  Hi all
>
>
> 2. Feature calculation
>
>  Coming up with a way to record a whole workflow to support reproducible
> research is going to be a very big undertaking, though a standardised ROI
> and feature storage specification will be a big step. Is there any way, at
> least in the short term, we could take advantage of say some of the
> components in CellProfiler or KNIME to record our analysis pipeline?
>

For reproducibility in CellProfiler, you'd need to save the pipeline file
(which controls the analysis) and a GIT hash for CellProfiler itself. I
think that's a good first cut. CellProfiler outputs its own GIT hash as an
analysis-wide feature.

>
>
> 3. Feature retrieval
>
>  Chris' suggestion of requesting features in the form of ([feature
> names], [object ids]) looks sensible. Vebjorn brings up a very good point
> about retrieving both row and column slices efficiently. When I spoke with
> Lee a few months ago in Dundee he said features sets are often frozen after
> calculation, so one option would be to have a post-feature-calculation task
> to optimise the storage format, if necessary duplicating the data so both
> row an column operations are fast. Effectively we'd have multiple
> implementations of the same API, transparent to the client.
>
> Thanks Simon - good idea.

>
>  In the interests of getting things moving I think concentrating on
> feature storage/retrieval first might be better than trying to do
> everything at once.
>

Again good, looking forward to it.

--Lee

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openmicroscopy.org.uk/pipermail/ome-devel/attachments/20130801/b9379761/attachment.html>