[ImageJ-devel] ROI presentation powerpoint

[Gabriel Landini]

On Wednesday 25 May 2011 13:34:34 Lee Kamentsky wrote:
> On 5/25/2011 3:35 AM, Johannes Schindelin wrote:
> > On Mon, 23 May 2011, Lee Kamentsky wrote:
> > - When measuring area and circumference, we should definitely realize
> > that
> > 
> >    we're working with sampled data, and consequentially we should always
> >    have some +/- number with the value.
> 
> Maybe we shouldn't call it area. 

Why not? it is the area of the polygon that is defined very precisely. This is 
a geometric feature of the vectorised object. What the connection of the 
vectorised perimeter has to do with reality cannot be built into the measuring 
machinery without any further information and this is most often missing.
Easiest example: think of a fractal outline which has been digitised. All 
correction factors that have been published (there are a few) to estimate the 
"correct" perimeter or line length (and area) fail miserably because they have 
been tested on low dimensional or simple profiles. The assumption that the 
world is smooth at high resolution outside the pixel grid cannot be 
guaranteed.

> There are a lot of circumstances where
> you want to normalize a sum over the pixels in an image by the number of
> pixels, so I've found it handy to keep the number of pixels in a ROI
> cached. So that's the number I'm trying to represent.

Yes, I have taken the same approach in my humble Particles8 and 4 plugins. If 
I need the area I use Freeman's chaincode length which gives the (or "a type 
of") length and area of the polygon. If I need Pixels, they are there too.
Note that just restricting ourselves to using pixels to estimate area gives 
peculiar results. Single pixels and lines will return a non-zero area, but 
these are 0 when using a chaincode. Although this would fail (and give some 
tiny areas in some lines (due to the connectivity issue), it can be 
nevertheless exploited to get an idea that it might be really a linear 
feature. This might not account to much in most cases, but when one starts 
computing shape ratios things start getting very confusing.

> I think it would
> be great to have an algorithm that could come up with an error estimate
> (or competing algorithms, each calculating the error in its own clever
> way, each arriving at a different, but arguably correct estimate).

These error estimates already exist, but this assumes that the geometry of the 
real objects is known and stable, none of which can be assured.

> Gabriel Landini has also asked for the perimeter pixels (and from those,
> you can use a structuring element find the "just inside" and "just
> outside" pixels) so I will add that to the ROI interface sometime in the
> near future. 

Yes he has :-), thanks!

Regards

Gabriel