[ome-devel] ROI storage with OME

[josh.moore at gmx.de]

Ooops, that's what I get for copy-n-pasting from a PDF. The SVG path
elements should have looked like this:

<path d="M x y h 2 l 1 1 v 2 l 1 1 v 1 h -1 l -1 -1 h -1 v -4 z" "style="..." /> 
<path d="M x y h 2 v 1 h 1 v 3 h1 v 1 h -1 v -1 h -2 v -4  z"    "style="..." /> 

All the crazy signs were just fancy quotes. My apologies,
~Josh.


josh.moore at gmx.de writes:
 > 
 > 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