[ImageJ-devel] ROI presentation powerpoint

[Gabriel Landini]

On Tuesday 24 May 2011 13:24:33 Lee Kamentsky wrote:
> Gabriel, by boundaries, do you mean the perimeter pixels? I think I
> could put that interface in.

Hi Lee:
Excellent.
 
> Under the covers, the abstract ROI classes ask for rasters - runs of
> pixels at constant Y and incremental X. That's pretty much the same
> thing as finding two of the perimeter pixels, so we could add an
> interface to iterate through the perimeter pixels. You wouldn't get them
> in the right order though, not clockwise or counterclockwise along the
> boundary. I'm not sure how to handle topologically complex objects where
> iterating clockwise doesn't make sense (objects with holes, objects that
> are disjoint).

I seem to remember somebody encoding holes ROIs in the opposite 
direction of the boundary ROIs. I am not sure what advantage this has. 

In some imaging packages I worked with before (notably Optimas, now defunct) 
there were 2 different resolutions for the positioning, one for addressing the 
image and one for ROIs. The ROIs were located (by default) on the centre of 
the "pixels". I know that pixels are really points, but if you enlarge the 
image, they look like squares, so it would be useful to really have an 
intuitive positioning of the ROI nodes on the image.

There are at least 8 different ways to encode a blob, depending whether the 
ROI centres on the pixels belonging to the object boundary, on the background 
bounday pixel centres or to the boundaries of the underlying grid, and whether 
4 or 8 connected.

As far as I know, IJ uses the top left corner to position the polygon, but 
then this creates an un-intuitive situation of the ROI not reaching the point 
the it will paint if you fill the ROI.
ImageJ's polygon length computation is somewhat difficult to grasp. It does 
not return the same length as the standard Freeman's algorithm (the difference 
is not too large, but it is different). This needs to be investigated a bit, I 
think.

There used to be a problem (not sure if this is still there) that if you 
filled ROI then get the ROI again the wand, then drew the 
outline, it would be bigger by 1 pixel again to the right and down. Somehow 
this does not seem to be the ideal. An ROI should define a blob, that when 
filled and detected again with the want, the same boundary is detected.
Although I eventually became used to to live with it, I think it would be 
better to avoid this in future.

I contacted Curtis so he has my skype id and hope to join to -at least to 
listen- about the progress tomorrow.

Regards

Gabriel