[ome-devel] ROI storage with OME

[josh.moore at gmx.de]

Hi Ghislain,

the data structure planned for Rois moving forward is based closely on
SVG, as pointed out by Melissa in her recent email. As you probably
know, SVG supports a generalized "path" concept:

  http://www.w3.org/TR/SVGTiny12/single-page.html#paths-PathData

Looking briefly, there is some literature comparing the two. For
example in:

  http://svg.dmi.unict.it/iplab/administrator/users/spie2005_2.pdf

        
CC4:  2 2 4 2 4 4 4 2 4 6 0 6 6 0 0 0 0 6 
<path d=$,1r}(BM x y h 2 v 1 h 1 v 3 h1 v 1 h -1 v -1 h -2 v -4  z$,1r}(B style=$,1r}(B...$,1r}(B /> 
        
CC8: 2 2 3 4 4 3 4 6 7 6 0 0 0 7 
<path d=$,1r}(BM x y h 2 l 1 1 v 2 l 1 1 v 1 h -1 l -1 -1 h -1 v -4 z $,1r|(Bstyle=$,1r}(B...$,1r}(B /> 
        

The SVG representation is certainly bit more verbose, but that was for
a shape without curves. Representations using bezier curves could
presumably be more compact (though less exact at the pixel level).

It would be interesting to hear if you think that SVG paths would
support your current work.

As for the "group of points" model, you may have to fill me in more on
exactly what you need. With paths, there's the possibility of
representing doughnuts. For example,

M 69.09375 0 C 30.946591 -4.7369516e-015 2.0995637e-013 20.013396 0
44.65625 C 0 69.299106 30.946591 89.281253 69.09375 89.28125 C
107.24091 89.28125 138.21874 69.299107 138.21875 44.65625 C 138.21875
20.013394 107.24091 3.6849557e-013 69.09375 0 z M 60.90625 31.78125 C
83.8734 31.781251 102.5 39.856781 102.5 49.8125 C 102.5 59.768218
83.873401 67.84375 60.90625 67.84375 C 37.939097 67.843748 19.28125
59.768219 19.28125 49.8125 C 19.281251 39.85678 37.939099 31.78125
60.90625 31.78125 z 

is the doughnut available at:

  http://upload.wikimedia.org/wikipedia/en/1/1e/Purple_donut.svg

but I'm not sure that's what you're going for.

Cheers,
~Josh.

Ghislain Bonamy writes:
 > ...
 > 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,
 >  
 > Ghislain Bonamy, PhD