[ome-devel] ome-devel Digest, Vol 63, Issue 4 - message 1 : ROI's-> give them a LABEL?

[josh.moore at gmx.de]

Ghislain Bonamy writes:
...
 > Actually I was referring to the OME storage standard for ROI. I have
 > been in touch with Curtis Rueden who suggested I discuss this with the
 > OME-developers. More precisely, the XML schema used for current ROI
 > storage (cf. attached XML file from Curtis) would need to be amended to
 > provide a way to store storage ROI as chain code. 

Right. The current SVG elements supported can be seen here:
http://www.ome-xml.org/browser/Schemas/OME/2008-09/ome.xsd#L1521

We'd need to add either a "Path" shape or a "ChainCode" shape for
supporting what you were mentioning, Ghislain.

 > I see your point about using labels for complex objects. In fact, I
 > already had considered to map objects to their parents (ie, nucleus to
 > cell body) via the cell features. I suppose I can extend this model to
 > ROI, where you have complex forms.
 > 
 > I think you lost me at the Euler number part though. Do you mean that
 > for each objects we would add an extra index, corresponding to the
 > different objects parts? I think this is also a good idea, but would
 > also require to edit the ROI object model. Another thing which should be
 > added to the OME ROI model, would be an object group (ie, an image
 > usually has several different nuclei/cells...) an in addition to this,
 > you may want to save the object organization (ie. a cell, may have
 > several nuclei...), so adding a parentType and a parentID would be
 > useful (the parent type of every objects is obviously "Image")

My opinion would be that the Euler number and similar information stay
external to the ROI model itself. Otherwise, every new technique would
lead to an expanding of the model. Instead, we need to decide how to
handle analysis results in general.

For the most recent discussion, see the "Day 2" notes from the Paris Users' meeting:

  https://www.openmicroscopy.org/site/community/minutes/meetings/may-2009-ome-european-users-meeting

At the moment, you'd be limited to attaching such extra indices to the
ROI either individually via a StructuredAnnotation (which I wouldn't
suggest for performance reasons), or as a larger XML or tabular blob.

 > I have attached an example of single cells features and associated ROI.
 > As you can see in the feature list (.feat), each objects is linked to a
 > parent object. The objects ROI and features can be linked using the
 > "TimePoint, StackNum, FieldNum, ObjectType, ObjectID".
 > 
 > Finally for the Acapella code to make the polygons/chain codes? I would
 > like to share it, but need to ask our lawyers for permission first. We
 > can take this off-line. Also, I have also have some java code for it,
 > which I was planning to put into bioformats, to convert turn a bunch of
 > points into a polygon/chaincode. This only works if the object does not
 > have non adjacent parts (if you have one multipart object only the top
 > left object is returned as an ROI), and for objects with holes, only the
 > outer shell is returned as a polygon. Hopefully, this could be worked on
 > a little more by the community, to provide support for more complex
 > objects! 

Sounds brilliant, Ghislain. Looking forward to it!

Best wishes,
~Josh.

 > 
 > -----Original Message-----
 > From: ome-devel-bounces at lists.openmicroscopy.org.uk
 > [mailto:ome-devel-bounces at lists.openmicroscopy.org.uk] On Behalf Of
 > Cornelissen, Frans [PRDBE]
 > Sent: Wednesday, June 10, 2009 5:40 AM
 > To: ome-devel at lists.openmicroscopy.org.uk
 > Subject: Re: [ome-devel] ome-devel Digest, Vol 63,Issue 4 - message 1 :
 > ROI's-> give them a LABEL?
 > 
 > Ghislain,
 > 
 > I suppose you are referring to OMERO (and not the old OME)?
 > Chain codes ar indeed the best way to store ROI's efficiently
 > 
 > My 2 cents: For the ROI's I would suggest adding an information
 > item: a "LABEL" This would make it easy to make ROI from output
 > from image analysis packages that "call" or identify the object by
 > its label number All ROI's with the same LABEL, even when complex
 > have to be described with holes etc. would then belong to each
 > other (to the same "outer" object) One could even add an Euler-like
 > number to describe the "phase", e.g.  Outer object, A hole = ;
 > object in a hole, etc.
 > 
 > See
 > http://www.mathworks.com/access/helpdesk_r13/help/toolbox/images/morph20
 > .html
 > 
 > PS: would you like to share the acapella code to make the polygons/chain
 > codes?
 > 
 > Cheers, frans
 > 
 > -----Original Message-----
 > From: ome-devel-bounces at lists.openmicroscopy.org.uk
 > [mailto:ome-devel-bounces at lists.openmicroscopy.org.uk] On Behalf Of
 > ome-devel-request at lists.openmicroscopy.org.uk
 > Sent: Wednesday, 10 June 2009 1:00 PM
 > To: ome-devel at lists.openmicroscopy.org.uk
 > Subject: ome-devel Digest, Vol 63, Issue 4
 > 
...
 > 
 > Today's Topics:
 > 
 >    1. ROI storage with OME (Ghislain Bonamy)
 > 
 > 
 > ----------------------------------------------------------------------
 > 
 > Message: 1
 > Date: Tue, 9 Jun 2009 21:49:29 -0700
 > From: "Ghislain Bonamy" <GBonamy at gnf.org>
 > Subject: [ome-devel] ROI storage with OME
 > To: <ome-devel at lists.openmicroscopy.org.uk>
 > Message-ID:
 > 	<F5A26DAD36F60843830631774C95CAE205D12A1D at EXCH2.rec.gnf.org>
 > Content-Type: text/plain;	charset="iso-8859-1"
 > 
 > Dear all,
 > 
 > I have programmed a tool allowing me to save objects calculated from
 > Acapella into a Polygonal ROI format, which works great for shapes
 > without holes (ex nuclei, cell borders etc).
 > 
 > While playing with different storage format, it became evident that
 > storing the polygon as a chain code (along with the coordinate of the
 > first point) was extremely space efficient and probably just as
 > computing intensive to draw back the current system to store polygons.
 > Using the chain code vs. set of point is about 3-4 times more efficient.
 > 
 > Because the volume of ROI outputted by High content imaging will become
 > extremely voluminous, I was thinking that perhaps adding to OME an ROI
 > model that stores polygon/polyline as a chain code would be very useful.
 > 
 > Finally for more complex shapes, perhaps a "Group of Point" model could
 > also be implemented. This would be useful for complex shape that can not
 > readily be turned into a vector (such as a donut, or other objects with
 > a hole in them).
 > 
 > 
 > Looking forward to hearing your thoughts,