Login  Register

Re: Ever decreasing circles

Posted by Gabriel Landini on Dec 11, 2016; 6:13pm
URL: http://imagej.273.s1.nabble.com/Ever-decreasing-circles-tp5017755p5017759.html

On Sunday, 11 December 2016 16:41:45 GMT John M Brear wrote:
> A pixel has an area and a perimeter.

Some would disagree, see for example:
http://www.cs.princeton.edu/courses/archive/spr05/cos426/papers/smith95b.pdf

> If it did not, then two pixels would have neither area nor perimeter, and
> three pixels would have neither area nor perimeter...

Well that is exactly how Particles8 and 4 work when considering "area" and the
values they return. That being said, they also compute "pixels" but I think
that circularity and other morphometrical parameter are better constructed
using the concept of area as the space inside the polygon defined by the
perimeter. If the polygon defines no area, then some morphometrical descriptors
cannot not exist (you get division by 0 and so on). That is useful too, e.g.
in mereotopology there are operators for detecting regions with an without
'interior', so no, not everybody believes a single pixel has an area.

Of course one can count the number of pixels a region is made of,  and  assume
that 2 pixels side by side have an area of 2, but this then has other
consequences that need to be considered later (such as that no points or lines
exist in digital images).
According to Freeman's papers, two pixels side by side define a line of length
1, while two pixels joined by their corners define a line of length sqrt(2).

> ...and 122,880 pixels would have neither area nor perimeter.

Not necessarily. It depends on the connectivity considered between samples and
how we define a "region". If they are all disconnected pixels, that is also
correct, you got 122,880 point samples. If they are somehow connected forming
regions (defining "connected" as the property of being able to travel between
any two pixels in that region through a path that is all contained in that
region), then you can have a perimeter and area associated to that region.

The smallest "area" you can detect with Particles8 (which uses 8-connectivity,
hence its name) is defined by 3 pixels (area of 0.5) in an "L" configuration.
Its perimeter is 1+1+sqrt(2).
A 2x2 pixel square blob as an area of 1 and a perimeter of 4.

> But induction apart, IJ demonstrably reports an area of 1 and a perimeter of
> 2.828.. for a feature occupying one pixel.

Yes, in IJ the default Particle Analyzer does things differently and it is
important to be aware of those, that is what I have been trying to explain.

> It also reports a circularity
> of 1, but the value calculated from the reported area and perimeter is
> 1.5713..

Have a look at the documentation in the IJ site. It says in page 137 that
"values may not be valid for very small particles". That is because for very
small particles IJ just outputs "1".  I do not know exactly the reason for
this,  I think this was set long ago. Wayne might clarify it.
In practical terms it is not a good idea to use such small regions for the
analysis of captured images, but sometimes we might want to analyse synthetic
images, where you know that detecting a pixel is relevant.

If you need to know exactly the value of circularity, you can either compute
it separately (from the area (which in IJ is same a number of pixels) and
perimeter columns) or you can try the Particles 8 and compute it from either
pixels or area , and the perimeter (the default circ. is computed form the
"polygonal area").  You will note that since a pixel has no area, it cannot
have a circularity (and hence it returns -1).

> I have thousands of imaged particles with IJ reported areas and
> perimeters giving calculated circularities >1 against the reported values
> of 1.  All I need to do is to discriminate in this area.

Can you post just one of those regions? I would be interested in seeing how a
value >1 is generated. How do you compute that value?

> I don't think we differ at all in our understanding of the issues of
> polygonization; the problem is that IJ prevents those of us who understand
> the issues from accessing and using the real values.

I am sure that you understand all this, but sometimes users are not aware of
how every detail is implemented and the logic behind the choices made in the
programs.
Anyway, I hope I helped a bit in explaining how things some things work in IJ
and why I implemented it differently in my plugins. A few people found the
alternative implementation useful too.

Regards

Gabriel

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html