-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Region Properties Performance Overhaul - Part 2: Intensity Image Properties #844
Open
grlee77
wants to merge
5
commits into
rapidsai:branch-25.04
Choose a base branch
from
grlee77:regionprops_part2_intensity
base: branch-25.04
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Region Properties Performance Overhaul - Part 2: Intensity Image Properties #844
grlee77
wants to merge
5
commits into
rapidsai:branch-25.04
from
grlee77:regionprops_part2_intensity
+2,745
−12
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The functions introduced here are not being added to the public API. They will be used behind the scenes from `regionprops_table` to enable orders of magnitude faster computation of region properties for all labels in an image. The basic approach here is to compute a property for all labels in an image from a single CUDA kernel call. This is in contrast to the approach from the `RegionProperties` class which first splits the full image into small sub-images corresponding to each region and then loops over these small sub-images, computing the requested property for each small region in turn. That approach is not amenable to good acceleration on the GPU as individual regions are typically small. Provides batch implementation that computes the following properties for all properties in a single kernel call: - bbox - label_filled (creates version of label_image with all holes filled) - num_pixels - num_pixels_filled - num_perimeter_pixels (number of pixels at perimeter of each labeled region) - num_boundary_pixels (number of pixels touching the image boundary for each region) The following properties are simple transformations of the properties above and have negligable additional cost to compute: - area - area_bbox - area_filled - equivalent_diameter_area - equivalent_spherical_perimeter (as in ITK) - extent - perimeter_on_border_ratio (as in ITK) - slice The following split the label image into a list of sub-images or subsets of coordinates where each element in the list corresponds to a label. The background of the label image has value 0 and is not represented in the sequences. Sequence entry `i` corresponds to label `i + 1`. In most cases, these will not be needed as properties are now computed for all regions at once from the labels image, but they are provided for completeness and to match the scikit-image API. - coords - coords_scaled - image (label mask subimages) - image_convex (convex label mask subimages) - image_intensity (intensity_image subimages) - image_filled (subimages of label mask but with holes filled) - label (sequence of integer label ids) Test cases are added that compare the results of these batch computations to results from scikit-image `regionprops_table`.
This function operates similarly to `regionprops_table`. In a future commit, once all properties have been supported, it will be used within the existing regionprops_table function so that it will provide much higher performance.
- intensity_mean - intensity_std - intensity_min - intensity_max Both single and multi-channel intensity images are supported
jameslamb
approved these changes
Mar 3, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
packaging-codeowners
was just added because you changed the codespell
config, approving this on that basis.
Will defer to other reviewers on the substance of this PR.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
improvement
Improves an existing functionality
non-breaking
Introduces a non-breaking change
performance
Performance improvement
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Please review #843 first as that explains the general approach in more detail.
Overview
This MR implements the following intensity-based region properties
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)

Note that "multi-intensity" is the time to compute the following list of region properties rather than just a single property
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: The results for the older GPU-based regionprops from cuCIM are not shown here. However, for many properties that implementation became much slower as the number of regions increased. We can see that for the new implementation proposed here, performance is roughly independent of the number of regions present. As expected, the relative acceleration that can be achieved becomes larger as image sizes increase, eventually starting to plateau at the larger sizes shown.