[ImageJ-devel] ROI -> Overlay bug

Gabriel Landini G.Landini at bham.ac.uk
Fri May 11 04:03:56 CDT 2012

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 
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).


More information about the ImageJ-devel mailing list