PERF: Parallelize ContourExtractor2DImageFilter

[Leengit]

This pull request addresses the same issue as Pull Request #2371 of @dzenanz but I am submitting this new pull request because I am cautious about submitting to his pull request, I've rebased to merged master-branch commits in the same code, and I have built on his code to a fair degree. It is probably best to not merge both that pull request and this pull request.

Much of this code is co-authored with @dzenanz.

PR Checklist

• No API changes were made (or the changes have been approved)
• No major design changes were made (or the changes have been approved)
• Added test (or behavior not changed)
• Updated API documentation (or API not changed)
• Added license to new files (if any)
• Added Python wrapping to new files (if any) as described in ITK Software Guide Section 9.5
• Added ITK examples for all new major features (if any)

[Leengit]

Unfortunately, ShapedImageNeighborhoodRange with ConstantBoundaryImageNeighborhoodPixelAccessPolicy is like ConstShapedNeighborhoodIterator with ConstantBoundaryCondition. In both cases, the default “outside” pixel value is used when the pixel falls outside the image, but we want it to be used when the pixel falls outside the region.

[dzenanz]

Maybe @N-Dekker is willing to extend ShapedImageNeighborhoodRange for this use case?

[N-Dekker]

@Leengit @dzenanz Do I understand correctly that you want any pixel value outside the requested region to be treated as constant value zero, while iterating over the neighborhood of a pixel at the border of the region? Even when the requested region is in the middle of the image?

[Leengit]

@Leengit @dzenanz Do I understand correctly that you want any pixel value outside the requested region to be treated as constant value zero, while iterating over the neighborhood of a pixel at the border of the region? Even when the requested region is in the middle of the image?

Yes, exactly, except for the zero part. I need to be able to set what value is returned when a pixel is outside of the region.

[Leengit]

FWIW, there may be more than one region in play. There's the region #1 that we've been discussing that determines when a pixel value should be ignored and instead the set constant is returned. But, I also have a shaped iterator or range that is traversing a slightly different region #2. Because of its radius and other parameters the region #2 exploration may end up requesting values for individual pixels outside of region #1, and it is those pixels that I want to get the set constant for.

Also, in some cases the pixels outside of region #1 might also be outside of the image. I'd like to get the set constant in those cases too, rather than an exception or error.

[N-Dekker]

Yes, exactly, except for the zero part. I need to be able to set what value is returned when a pixel is outside of the region.

Honestly I was not aware of this use case, during the initial development of ShapedImageNeighborhoodRange. But I think it is quite well possible to add a new "pixel access policy", which takes the requested region into account.

By default, ShapedImageNeighborhoodRange does not pass the requested region to the pixel access policy. Simply because it was never needed. But I think a new pixel access policy could have the region included as "pixel access parameter".

As far as I can see, ShapedImageNeighborhoodRange does not need to be adjusted. We just need a new policy! Working title: RegionalConstantBoundaryImageNeighborhoodPixelAccessPolicy 😄

If the value for a pixel outside the region shouldn't always be zero, is the value still known at compile-time? If not, how or when is the value estimated?

[Leengit]

I like your analysis ... all we need is a new policy!

If the value for a pixel outside the region shouldn't always be zero, is the value still known at compile-time? If not, how or when is the value estimated?

Runtime. This is being used by a superpixel calculating routine and this step starts with a region of labels. The user can use uchar, int32_t, or float, etc. as labels. Each time there is a clump of pixels with the same value, I want to draw a contour around the entirity of it. I set the border-pixel value to be a value not used as a label by the user, so that border region is always recognized as "other". (In particular, If the the label type is char and the user uses all 256 possible values as labels, the user gets an exception!)

[N-Dekker]

@Leengit Still under construction, but please have a look:
https://github.com/N-Dekker/ITK/tree/RegionalConstantBoundaryImageNeighborhoodPixelAccessPolicy

The idea is that itk::RegionalConstantBoundaryImageNeighborhoodPixelAccessPolicy<ImageType> can be specified as template argument TImageNeighborhoodPixelAccessPolicy of the ShapedImageNeighborhoodRange. A range variable can then be declared as follows:

itk::ShapedImageNeighborhoodRange<ImageType,
                                  itk::RegionalConstantBoundaryImageNeighborhoodPixelAccessPolicy<ImageType>>
  neighborhoodRange{ *image, location, offsets, { regionIndex, regionSize, constantValue } };

If you're in a hurry, you may just copy https://github.com/N-Dekker/ITK/blob/RegionalConstantBoundaryImageNeighborhoodPixelAccessPolicy/Modules/Core/Common/include/itkRegionalConstantBoundaryImageNeighborhoodPixelAccessPolicy.h and adjust it to your needs.

[Leengit]

Thanks @N-Dekker. I have to work on something else now, so I will probably just wait until your code is merged.

On a related note, if the ShapedImageNeighborhoodRange code is similar to the ConstShapedNeighborhoodIterator code then Issue #2387 could apply. Hopefully not, but it might be worth adding a test for.

[Leengit]

This is now ready for review. By using (Shaped)RegionRange objects instead of (Shaped)RegionIterator objects we're using better code, and we bypass Issue #2387.

[dzenanz]

This could be merged as-is. Alternatively, the last two commits could be squashed into the other commits.

[Leengit]

This could be merged as-is. Alternatively, the last two commits could be squashed into the other commits.

I squashed them.

[Leengit]

I rebased to the current upstream/master, 38dec0a.