[ImageJ-devel] ROI -> Overlay bug

[Albert Cardona]

2012/5/11 Gabriel Landini <G.Landini at bham.ac.uk>:
> On Thursday 10 May 2012 18:38:58 Senseney, Justin  [E] wrote:
>> Gabriel’s nice points brought up  the issue of bias in counting pixels (a
>> common problem in image processing applications is that when turning a
>> shape with curves into pixels, the pixels are under-counted on the LHS and
>> over-counted on the RHS, IJ2’s bug appears to be have a top/down
>> orientation).  This problem is present in IJ2, but has been solved in IJ1
>> (I think was maybe even solved not too long ago in IJ1).  Here is an
>> example:
>
> I do not think this is "solved" in IJ1. This issue arises when you zoom in and
> use the Draw command.
>
> Long ago I mentioned (and several times in the IJ list) that problem of ROI
> anchoring. For some reason, most (but not all!) the ROIs anchor on the top
> left corner of the pixel representation on screen.
> This makes it look like the ROIs is out of place in the top left compared to
> the bottom right quadrants of the ROIs. That is fine with me because I got
> used to it, but it is not intuitive.
>
> The worst situation is a rectangle: the last row and column inside the
> rectangle, appear outside (!) the rectangle when you apply Draw. But if you
> have a binary rectangle and apply the magic wand, now the ROI "encloses" the
> rectangle.
> This mismatch of where the boundary of objects is and where with respect of
> the ROI shown when zoomed is a source of headaches.
>
> This can be solved completely by anchoring the ROI on a subgrid (when zooming
> in) that is centred on the pixel. Then you have a single boundary whose pixels
> are always in the object that the ROI defines. It also forces one into
> thinking that the image is just an array of points, not squares.
>
> In addition to resolving this problem in a standard way, it would make
> understanding small regions geometry better (for instance, 0-area ROIs, the
> fact that area of a ROI and pixel counts in a ROI are differnt things, and the
> fact that pixel is a point and not an area) and ties nicely with the
> algorithms encoding regions (like Freeman's chain code).
>
> I would be prepare to explain this in more detail (if there is interest) over
> skype or discuss it at the Luxembourg conference).


I second Gabriel's views, a pixel is a point and considering it so
solves a lot of issues. If that's a break from IJ1, that's ok: it's
for the better.

Albert