How to replace ImageMaskSpatialObject::GetAxisAlignedBoundingBoxRegion() calls?

Engineering
1

While trying to get the elastix image registration toolbox compatible with ITK5, we encountered compilation errors, because itk::ImageMaskSpatialObject::GetAxisAlignedBoundingBoxRegion() was recently removed:

Do you have a suggestion how to replace calls to GetAxisAlignedBoundingBoxRegion()?

2

This functionality is now available via a standard function call in every SpatialObject.

In particular, the member function GetMyBoundingBoxInObjectSpace() will return the bounding box around the mask (non-zero voxels) in the image. This bounding box will be aligned with the ObjectSpace axis of the image, i.e., the image’s “physical space” that considers its origin, spacing, and directions.

Pro Tip: Make certain you call “Update()” on your SpatialObject before attempting to use its BoundingBox in any space.

If you instead need an itk::Region in IndexSpace, you can use the corners of the ObjectSpace bounding box to compute that region. However, I think ITK has image filters which might do this more quickly. Nevertheless, an example of this conversion to an itk::Region in IndexSpace is given in this test, starting at line 64:
itkImageMaskSpatialObjectTest3.cxx

Hope this helps. Please let me know if I interpreted your question wrong.

Enjoy ITK,
Stephen

3 Likes
3

Thanks @Stephen_Aylward I think your answer should be of help. (I’m still busy.)

I must admit I’m a bit overwhelmed by all compilation errors that we get right now, from using ITK. Did not expect to see such a big change of the interface, after release candidate 1…

Anyway, I’ll try to get things our applications fixed, and I’ll let you know if I have any other question on the spatial object revision!

4

I am slogging through updating multiple projects too. While initially daunting, I do find that it tends to follow an easily resolved pattern.

Additionally, the SpatialObjects in particular had acquired an amazing amount of cruft and logic errors / inconsistencies. While individual spatialObjects would (typically) operate well, the behavior of different objects was amazingly inconsistent for the same API - sometimes operating in ObjectSpace and othertimes operating in WorldSpace, and often making assumptions that were simply wrong. We’re really hoping to lower the bar for adopting ITK - not requiring folks to be C++ developers and having to look at source code to decipher an implementation’s Space are big part’s of lowering that bar.

For example, looking at the test I referenced to you, the logic in that test is weak. It assumes that the min of the bounding box in physical space should map to the region’s index and the max-min of the bounding box should map to the region’s size. This is wrong if the image’s directions are not the identity transform. If the image directions are, for example, inverted, then the max of the bounding box in physical space should map to the region’s index. Similarly, if the image’s directions are not axis aligned, then the physical box’s min and max may not map at all to the index and size of the bounding region in index space. In that case, it is necessary to convert every corner of the physical bounding box into index space, and then take the coordinate-specific mins and maxs of those transformed corners to define the region.

Sorry - long answer, but that test is a valid test for the particular conditions it uses (identity directions) but it does give a general solution. It is another example of how the SpatialObjects have degraded over time.

If you need code to go from a bounding box in physical space to an image region, let me know. I do have it elsewhere.

Good luck with the conversion. It is a pain, but I think your project and all new developers will greatly benefit immediately after the update to ITKv5 (better threading, consistent APIs, …)

Stephen

2 Likes
5

The Spatial Objects refactoring contributed by @Stephen_Aylward is a major improvement that simplifies and improves the Spatial Objects API and all around sets up Spatial Objects and ITK for greater adoption and utility in the future.

There is a nice section on Spatial Objects Refactoring in the ITK 5 Migration Guide. Please use it as a guide and consider contributing amendments if there are uncovered, common patterns encountered during refactoring.

1 Like
6

@Stephen_Aylward Thanks for adding a note about GetAxisAlignedBoundingBoxRegion() at

:smiley:

1 Like
7

Please check if this pull request would correctly restore the old functionality of GetAxisAlignedBoundingBoxRegion():

It is based on code from @Stephen_Aylward at