HI noahjp,

I too have been struggling with perimeter in imageJ, but in the context of circularity. Here’s some details about what’s going on.

The TLDR is that the perimeter reported in imageJ is for a different shape and the algorithm used may not be the best.

As @gabriel mentioned, it is difficult to even define a perimeter is for a digitised shape and there are plugins that do a better job.

Cheers,

Chris

### The naive approach

The simplest approach for calculating the perimeter of a traced Roi is to add up the sides of the pixels exposed to outside. This leads to some confusing results.

In mathematical terms, this is because this is equivalent to using the ‘Taxicab distance’ or \ell_1-norm to measure distances.

Using this approach leads to a number of problems. For example, these two shapes both have a perimeter 44.

It also means that the perimeter is not invariant to rotations. In this example a line of length 20 and width 1 is rotated and the \ell_1-perimeter calculated:

### Fixing the issue

Approaches to correct the deficiencies of the \ell_1-perimeter can be seen as building in more common Euclidean or \ell_2-norm. In the case of the diagonal line, using the \ell_2-norm a single pixel would contribute \sqrt{2} to the perimeter rather than 2.

Another way to say this is calculate the perimeter of digitised shapes we need to ‘cut corners’ rather than use the taxi-cab metric which sticks to the pixel grid.

### The approach in imageJ

The code currently calculates the perimeter by first calculating the taxi-cab perimeter, then replacing some of the corner pixels with a diagonal:

Returns the perimeter length of ROIs created using the wand tool

and the particle analyzer. The algorithm counts pixels in straight edges

as 1 and pixels in corners as sqrt(2).It does this by calculating the total length of the ROI boundary and subtracting

2-sqrt(2) for each non-adjacent corner.

It can be thought as doing some thing like the following:

The code itself is more complicated and often the output can’t be interpreted in terms of shapes like above. To visualise what is happening I modified the code to mark which edges get marked as ‘non-adjacent’. In this case it marks 6 edges as ‘non-adjacent’ corners and calculates the perimeter as 6+3\sqrt{2}.

The edges that get marked ‘non-adjacent’ depend on the orientation of the shape and which point it starts at. This leads to some strange results, for example, this shape has a different perimeter depending on the orientation

## Sequence of squares

For the sequence squares the corners cut off can easily visualised. The perimeters are smaller than convex hull because they are for a **different shape**!

Area |
perim |

1 |
2\sqrt{2} |

4 |
4+4\sqrt{2} |

9 |
8+4\sqrt{2} |

16 |
16+4\sqrt{2} |