[ome-users] Minimal HCS OME-XML Spec

[Andrew Patterson]

Hello Matt,

> With the HCS additions to the OME-XML model, I am curious if there is a
> minimal HCS specification available (e.g. SPW)?
There is not one yet but we are working on putting this together along with what we are calling an OME Compliant specification. We hope to have something in place as a discussion document for our Users Meeting in Paris next month.

> A few quick general OME-XML questions:
> - does the model include any portions to describe image analysis results
> (not just to a frame/field and below but also to a plate/well)?  Can
> this be described in a distinct file from the file(s) containing the
> pixels?

You can use the Structured Annotation model to attach information including analysis results at several points in the model. This includes: Image, Pixels, Screen, Plate, Well. We have not tried to model analysis results themselves in our model due to the wide variety of results people can generate.

If you use a multi-part OME-TIFF file (see below) and full LSIDs to identify your Annotations then yes the data could be in a separate file to the pixels. The other option is to use a FileAnnotation to reference an external file.

> - image analysis software can export segmentation data (indication that
> a specific pixel belongs to a certain segmented feature).  Is there a
> portion of the model to handle this?
The ROI (Region Of Interest) model is designed to support this. It allows you to define 2D structures on the z-plane of an image or pseudo-3D regions using a stack of 2D structures across several z-planes.

> - I recall in the past a discussion about referencing pixel data that
> may be contained in another file (TIFF I think).  Can anyone point me in
> the direction of samples of this?
Sure, the sample tubhiswt-2D.zip on the OME-TIFF data page:
http://www.ome-xml.org/wiki/OmeTiffData
This is two files each of which hold one of the two channels in the image.
The key areas to look at in the xml data of each file are:
* In the OME node the UUID attribute identifying the current file
* In each TiffData node the UUID element identifying the source file, which may be the current file or another. An importer is expected to scan for these other files in the current folder. The UUID is definitive and allows the files to survive renaming, the filename is just an optimisation.

> - are there any larger sample OME-XML datasets from HCS imagers (I
> realize it would probably be converted and not native)
With our work on the next release we're moving to a version of Bio-Formats that has interfaces generated directly from the OME Data Model. As part of this work we hope to have a system in place that can convert some of our large datasets into OME-XML. Our plan is to have this available as part of the OMERO 4.2 release.

Hope this helps,

Andrew