Region Properties Performance Overhaul - Part 5: Perimeter and Euler Characteristic

[grlee77]

Please review #843 first as that explains the general approach in more detail.

Overview

This MR implements the final few region properties supported by regionprops_table

• perimeter
• perimeter_crofton
• euler_number

The batch implementation here is not applicable to tightly packed regions (i.e. when regions share a border with other regions). The default robust_perimeter=True will maintain accuracy by computing the values for individual regions in isolation at cost of performance.

If accurate perimeter values are not required, but only relative perimeter size, then "num_perimeter_pixels" as implemented in #843 just counts the number of pixels/voxels on the object perimeter is much faster to compute. That number of pixels measurement does not suffer from this region adjacency issue and can always safely be applied even to tightly packed regions.

Benchmarks

Performance vs. Image Size (with # regions fixed)

The following show performance for a small fixed number of label regions at different spatial scale in both 2D and 3D

In 2D, there are 16 labeled regions for shapes ranging from (64, 64) up to (8192, 8192)

In 3D, there are 8 labeled regions for shapes ranging from (32, 32) up to (512, 512, 512)

Performance vs. Region Size (with image shape fixed)

Here a single large 2D image (7680, 4320) is used, but with varying numbers of labeled regions within it. The total % of foreground vs. background voxels remains similar (i.e. regions are larger when there are fewer of them). The number of regions range from 4 up through 16,384.

Here a single large 3D image (384, 384, 384) is used, but with varying numbers of labeled regions within it. The number of regions range from 8 up through 1,728.

Benchmark conclusions

Note: We can see that performance improves as a function of image size (top 2 figures) and remains good across many labeled region sizes (lower 2 figures).

CAVEAT:: The benchmarks shown above are for the case with robust_perimeter=False set. In this case the perimeter will not be accurate when labeled regions are immediately adjacent to each other (share a border with spacing of <= 1 background voxel). When robust_perimeter=True, performance will highly depend on how many labeled regions are within 1 pixel proximity of another label. Any such detected labels have to be processed in isolation to give accurate results and this will slow down the algorithm as we have to launch multiple CUDA kernels per each such labeled region.

If accurate perimeter values are not required, but only relative perimeter size, then "num_perimeter_pixels" which just counts the number of pixels/voxels on the object perimeter will be much faster to compute and does not suffer from this region adjacency issue.