[ImageJ-devel] ROI -> Overlay bug

Stephan Saalfeld saalfeld at mpi-cbg.de
Fri May 11 14:32:55 CDT 2012

On Fri, 2012-05-11 at 14:18 -0400, Lee Kamentsky wrote: 
> On 5/11/2012 2:10 PM, Albert Cardona wrote:
> > 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 ...
> >> 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.
> Brave man - I think that's how I interpreted it when I wrote the imglib 
> ROIs. If you are to count pixels, it's by whole numbers and the 
> criterion is whether the integer coordinate falls inside the region of 
> interest, not how it's drawn. Area is a different measure and might very 
> well be different than pixel count. Unfortunate as it is, maybe the 
> visual representation is just illustrative, not normative.

I concur.  All we do in ImgLib2 and the mpicbg transformations that
spread throughout TrakEM2 and the various registration libraries in Fiji
we consider pixel coordinates at a pixel's center which is in perfect
agreement when working with microscopic images (particularly confocal
scanners where the coordinate really is a point sample (with some
hopefully symmetric  centered at the stored location).

I had some hard time recently bringing that model into agreement with
image rendering in TrakEM2 since AWT follows the concurrent model that
pixel coordinates are at the top left corner of a pixel.  Being aware of
that will save your day, being not makes all the headache.  ImageJ
currently mixes the two models at various places as noted by Gabriel.
One just has to know where it does what.

Best regards,

> > Albert
> >
> > _______________________________________________
> > ImageJ-devel mailing list
> > ImageJ-devel at imagej.net
> > http://imagej.net/mailman/listinfo/imagej-devel
> _______________________________________________
> ImageJ-devel mailing list
> ImageJ-devel at imagej.net
> http://imagej.net/mailman/listinfo/imagej-devel

More information about the ImageJ-devel mailing list