[ImageJ-devel] ROI presentation powerpoint

[Lee Kamentsky]

Lots of good stuff in your email, Gabriel. Just to respond to one point, 
the "all-connected-components" segmentation algorithm I did in imglib 
lets you specify the connectedness using a structuring element. You can 
do 4 or 8 connectedness and it does segment in N dimensions... you can 
specify the connectedness there too. You can even increase the 
connectedness to encompass pixels that are 2 or more away to get a 
dilation effect, although that might be computationally expensive for 
large dilations.

--Lee

On 5/24/2011 10:27 AM, Gabriel Landini wrote:
> 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
>
>
>
> _______________________________________________
> ImageJ-devel mailing list
> ImageJ-devel at imagejdev.org
> http://imagejdev.org/mailman/listinfo/imagej-devel