2012/5/11 Gabriel Landini <[email protected]>: > 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 _______________________________________________ ImageJ-devel mailing list [email protected] http://imagej.net/mailman/listinfo/imagej-devel
