Possible bug with perimeter calculation on composite selections

[Chris Bradhurst]

Hello All,

I'm getting unexpected results for the perimeter value returned by the
ImageJ measure command (version 1.41o) when applying to composite disjoint
selections.

e.g.:
Just one square selection (20x20 pixels):
Area: 400, Perimeter 80 - as expected.

Hold shift and create an additional non-overlapping 20x20 square:
Area: 800, Perimeter 120 - (should be 160)

Create a third 20x20 non-overlapping square:
Area: 1200, Perimeter 180 - (should be 240)

In each case the area is correct, but the perimeter doesn't seem right when
there is 2 or more squares in the selection.

Any thoughts would be appreciated.

Kind Regards,
-Chris.

[Michael Schmid]

Hi Chris,

partly this has been discussed a while ago in the mailing list, see
   https://list.nih.gov/cgi-bin/wa?A2=ind0803&L=IMAGEJ&P=R2098&I=-3

In your case:

A single square is a square roi.

Two squares cannot be a square roi, so the whole thing is transformed  
into a shape roi. In this case, one can't distinguish between a  
square and a circle with a diameter of 1, so a single pixel gets a  
perimeter of 3 (approximation of Pi) - nothing bad about this.

Also your squares are now considered shapes, so it is not astonishing  
that you get a different value (edges will be considered rounded) -  
but the difference is too much!

E.g., for a 6x6 square measured as a shape roi I get a perimeter of  
18 - less than for a circle with a diameter of 6 (where I get 20).  
Also you get a factor of 3 for the perimeter/side_length ratio.

So it seems that this is a bug - possibly in Java java.awt.geom?
(I use Java 1.5.0_16 on Intel OSX).


Michael
________________________________________________________________

On 23 Jan 2009, at 13:06, Chris Bradhurst wrote:

> Hello All,
>
> I'm getting unexpected results for the perimeter value returned by the
> ImageJ measure command (version 1.41o) when applying to composite  
> disjoint
> selections.
>
> e.g.:
> Just one square selection (20x20 pixels):
> Area: 400, Perimeter 80 - as expected.
>
> Hold shift and create an additional non-overlapping 20x20 square:
> Area: 800, Perimeter 120 - (should be 160)
>
> Create a third 20x20 non-overlapping square:
> Area: 1200, Perimeter 180 - (should be 240)
>
> In each case the area is correct, but the perimeter doesn't seem  
> right when
> there is 2 or more squares in the selection.
>
> Any thoughts would be appreciated.
>
> Kind Regards,
> -Chris.

[Gabriel Landini]

On Friday 23 January 2009 13:51:41 Michael Schmid wrote:
> Hi Chris,
>
> partly this has been discussed a while ago in the mailing list, see
>    https://list.nih.gov/cgi-bin/wa?A2=ind0803&L=IMAGEJ&P=R2098&I=-3

I think that this is a different issue, not the differences due to perimeter
encoding, but some other problem. The difference is massive (50%
underestimation).
As a workaround one could store the ROIs individually and add their perimeters
afterwards.

G.

[Chris Bradhurst]

On Fri, 23 Jan 2009 14:18:16 +0000, Gabriel Landini <[hidden email]>
wrote:

>On Friday 23 January 2009 13:51:41 Michael Schmid wrote:
>> Hi Chris,
>>
>> partly this has been discussed a while ago in the mailing list, see
>>    https://list.nih.gov/cgi-bin/wa?A2=ind0803&L=IMAGEJ&P=R2098&I=-3
>
>I think that this is a different issue, not the differences due to perimeter
>encoding, but some other problem. The difference is massive (50%
>underestimation).
>As a workaround one could store the ROIs individually and add their perimeters
>afterwards.
>
>G.
>=========================================================================

Gabriel and Michael,

Thanks for responding.  It does seem to have the hallmarks of a bug.  I
might put on some gloves and overalls and go digging into the internals of
the source code tomorrow, however it appears quite complex at first appearance.

Another alternative workaround I am thinking of is to create a single pixel
width outline of the roi as a binary image and count the number of
foreground pixels.  This is obviously not terribly accurate, but probably
sufficient for my purposes.

-Chris.

[Gabriel Landini]

On Friday 23 January 2009, Chris Bradhurst wrote:
> Another alternative workaround I am thinking of is to create a single pixel
> width outline of the roi as a binary image and count the number of
> foreground pixels.  This is obviously not terribly accurate, but probably
> sufficient for my purposes.

Better than pixel counting as estimates of perimeters, you could use the
Particles8 plugin which uses Freeman's algorithm to estimate the length of the
perimeter (distance 1 for side-connected and sqrt(2) for corner-connected
pixel boundaries).

Cheers
G.

[Chris Bradhurst]

On Sat, 24 Jan 2009 09:26:37 +0000, Gabriel Landini <[hidden email]>
wrote:

>On Friday 23 January 2009, Chris Bradhurst wrote:
>> Another alternative workaround I am thinking of is to create a single pixel
>> width outline of the roi as a binary image and count the number of
>> foreground pixels.  This is obviously not terribly accurate, but probably
>> sufficient for my purposes.
>
>Better than pixel counting as estimates of perimeters, you could use the
>Particles8 plugin which uses Freeman's algorithm to estimate the length of the
>perimeter (distance 1 for side-connected and sqrt(2) for corner-connected
>pixel boundaries).

The particles8 plugin works very nicely for extracting perimeters.  Thanks
for the tip Gabriel.

[Kenneth Sloan-2]

It's worth noting that "perimeter" is a notoriously difficult concept  
to nail down.
The answer depends on scale, and on what you think a "pixel" is, and  
on precisely
where you think the boundary is.

In my opinion, "perimeter" is nearly useless when used across  
different studies
done by different observers.

see "How long is the coast of England".


On Jan 26, 2009, at 9:52 AM, Chris Bradhurst wrote:

> On Sat, 24 Jan 2009 09:26:37 +0000, Gabriel Landini  
> <[hidden email]>
> wrote:
>
>> On Friday 23 January 2009, Chris Bradhurst wrote:
>>> Another alternative workaround I am thinking of is to create a  
>>> single pixel
>>> width outline of the roi as a binary image and count the number of
>>> foreground pixels.  This is obviously not terribly accurate, but  
>>> probably
>>> sufficient for my purposes.
>>
>> Better than pixel counting as estimates of perimeters, you could  
>> use the
>> Particles8 plugin which uses Freeman's algorithm to estimate the  
>> length of the
>> perimeter (distance 1 for side-connected and sqrt(2) for corner-
>> connected
>> pixel boundaries).
>
> The particles8 plugin works very nicely for extracting perimeters.  
> Thanks
> for the tip Gabriel.

--
Kenneth Sloan
[hidden email]

[Chris Bradhurst]

On Mon, 26 Jan 2009 12:31:48 -0600, Kenneth Sloan <[hidden email]>
wrote:

>It's worth noting that "perimeter" is a notoriously difficult concept
>to nail down.
>The answer depends on scale, and on what you think a "pixel" is, and
>on precisely
>where you think the boundary is.
>
>In my opinion, "perimeter" is nearly useless when used across
>different studies
>done by different observers.

For my application, I would like to compare the average perimeter per object
in one class of images versus the average perimeter per object in another
class.  The actual real-world value of measurement is not important in this
case.  So provided the method of perimeter calculation works consistently, I
think it should be fine.

As far as whether perimeter will actually have any discriminating value
remains to be seen, although I suspect it will likely be ineffective, in
accord with your experience.

[Gabriel Landini]

On Tuesday 27 January 2009 04:28:17 Chris Bradhurst wrote:
> As far as whether perimeter will actually have any discriminating value
> remains to be seen, although I suspect it will likely be ineffective, in
> accord with your experience.

What Kenneth was talking about is a special type of geometrical object where
the perimeter length scales with observational scale (i.e. fractal and
asymptotic fractal boundaries).
Those are very common in nature and so comparing their perimeters is only good
for a single resolution (while is unlikely to be exactly the same across
different setups).
Many traditional shape descriptors use also the perimeter in the calculation
(like circularity, shape factor, etc) so those can be badly affected as well.

For complex/fractal particles with varying sizes, computing their fractal
dimension is much more robust and informative than other shape parameters.

The paper full reference is very much worth reading:

Mandelbrot B. How long is the coast of Britain? Statistical self-similarity
and fractional dimension. Science 1967;156:636-638.

And within the biological context everybody doing microscopy should read these
two (both way ahead of their time):

Paumgartner D, Losa G, Weibel ER. Resolution effect on the stereological
estimation of surface and volume and its interpretation in terms of fractal
dimensions. Journal of Microscopy 1981;121(1):51-63.

Rigaut JP. An empirical formulation relating boundary lengths to resolution in
specimens showing 'non-ideally fractal' dimensions. Journal of Microscopy
1984;133(1):41-54.

Cheers

Gabriel

[karo03]

Interesting discussion.
What I still miss in this thread is the discussion about the objects  
under examination, their variability and overall shape and the  
necessity.

The problem with perimeter occured with groups of disconnected objects  
considered as one object. In this case I think the perimeter is mostly  
useless except the size of the isolated connected objects varies only  
similar or equal to the other object members.

As a recommendation: I would start with simple measures: Area,  
Extension (max object extension (box)), minimal inscribable circle  
(max distance of object). If these are not discriminative enough,  
further, more complicated measures have to be tested, eg P^2/A (to  
avoid size (and pixel scaling) effects) ...

The problem with perimeter of groups of objects is manifest. If the  
perimeter is really necessary there are ways to circumvent the actual  
calculation with other means, eg with the morphology library of Gabriel.

Regards
Karsten

Am 27.01.2009 um 11:51 schrieb Gabriel Landini:

> On Tuesday 27 January 2009 04:28:17 Chris Bradhurst wrote:
>> As far as whether perimeter will actually have any discriminating  
>> value
>> remains to be seen, although I suspect it will likely be  
>> ineffective, in
>> accord with your experience.
>
> What Kenneth was talking about is a special type of geometrical  
> object where
> the perimeter length scales with observational scale (i.e. fractal and
> asymptotic fractal boundaries).
> Those are very common in nature and so comparing their perimeters is  
> only good
> for a single resolution (while is unlikely to be exactly the same  
> across
> different setups).
> Many traditional shape descriptors use also the perimeter in the  
> calculation
> (like circularity, shape factor, etc) so those can be badly affected  
> as well.
>
> For complex/fractal particles with varying sizes, computing their  
> fractal
> dimension is much more robust and informative than other shape  
> parameters.
>
> The paper full reference is very much worth reading:
>
> Mandelbrot B. How long is the coast of Britain? Statistical self-
> similarity
> and fractional dimension. Science 1967;156:636-638.
>
> And within the biological context everybody doing microscopy should  
> read these
> two (both way ahead of their time):
>
> Paumgartner D, Losa G, Weibel ER. Resolution effect on the  
> stereological
> estimation of surface and volume and its interpretation in terms of  
> fractal
> dimensions. Journal of Microscopy 1981;121(1):51-63.
>
> Rigaut JP. An empirical formulation relating boundary lengths to  
> resolution in
> specimens showing 'non-ideally fractal' dimensions. Journal of  
> Microscopy
> 1984;133(1):41-54.
>
> Cheers
>
> Gabriel

Karsten
[hidden email]