# Custom border extrapolation of ShapedImageNeighborhoodRange by ImageNeighborhoodPixelAccessPolicy

**URL:** <https://discourse.itk.org/t/custom-border-extrapolation-of-shapedimageneighborhoodrange-by-imageneighborhoodpixelaccesspolicy/879>\
**Category:** Engineering\
**Created:** [April 30, 2018, 6:02pm UTC](https://discourse.itk.org/t/custom-border-extrapolation-of-shapedimageneighborhoodrange-by-imageneighborhoodpixelaccesspolicy/879 "2018-04-30T18:02:39Z")\
**Posts on this page:** 14\
**Page:** 2

<div class="post-metadata">

**Author:** ![Niels\_Dekker](https://discourse.itk.org/letter_avatar_proxy/v4/letter/n/9d8465/32.png) [@Niels\_Dekker](https://discourse.itk.org/u/Niels_Dekker)\
**Post date:** [July 23, 2018, 3:45pm UTC](https://discourse.itk.org/t/custom-border-extrapolation-of-shapedimageneighborhoodrange-by-imageneighborhoodpixelaccesspolicy/879/21 "2018-07-23T15:45:49Z")

</div>

> [@phcerdan](#):
>
> That’s super nice! 😁

Thanks 😀

In the mean time I did figure out, roughly, how any number of run-time arguments could be supported for those pixel access policies that might need them, without any run-time penalty for those that don’t need them. By defining the range class as a _variadic template class_:

```
ShapedImageNeighborhoodRange<TImage, TPixelAccessPolicy, TPixelAccessParameters...>

```

An ITK user could then pass run-time arguments for those pixel access parameters to the constructor of the range. For example:

```
// For example: 1 run-time parameter, type = int, value = 255.
using RangeType = ShapedImageNeighborhoodRange<ImageType, PixelAccessPolicy, int>;
RangeType range { *image, location, offsets, 255 };

```

Internally, I think these optional pixel access parameters should then be wrapped in an `std::tuple<TPixelAccessParameters...>`. This tuple should then be stored as a private data member of the iterator object. Whenever a pixel is accessed, the iterator should pass the tuple to the pixel proxy, which should unwrap it again, and pass the arguments to the policy. Unwrapping/unrolling a tuple isn’t entirely trivial in C++11. It’s slightly easier in C++14 (using `std::index_sequence`), and possibly still easier in C++17. Anyway, here’s a link that I found helpful: [c++ - How to store variadic template arguments? - Stack Overflow](https://stackoverflow.com/questions/16868129/how-to-store-variadic-template-arguments)

---

<div class="post-metadata">

**Author:** ![Niels\_Dekker](https://discourse.itk.org/letter_avatar_proxy/v4/letter/n/9d8465/32.png) [@Niels\_Dekker](https://discourse.itk.org/u/Niels_Dekker)\
**Post date:** [October 9, 2018, 10:37pm UTC](https://discourse.itk.org/t/custom-border-extrapolation-of-shapedimageneighborhoodrange-by-imageneighborhoodpixelaccesspolicy/879/22 "2018-10-09T22:37:21Z")

</div>

@phcerdan I just posted a possible implementation of `ConstantBoundaryImageNeighborhoodPixelAccessPolicy`, which has the same functionality of the policy classes we have been discussing here in July… but this one does allow specifying the _constant value_ at run-time: [WIP: Added policy for constant NeighborhoodRange values outside image](http://review.source.kitware.com/#/c/23795/)

While I think it’s fully functional already, I just marked it _WIP_, because I don’t know if it has priority for the release of ITK 5.0. What do you think?

Eventually it could replace existing use cases of the old `itk::ConstantBoundaryCondition`, and possibly yield a performance improvement…

---

<div class="post-metadata">

**Author:** ![phcerdan](https://discourse.itk.org/user_avatar/discourse.itk.org/phcerdan/32/286_2.png) [@phcerdan](https://discourse.itk.org/u/phcerdan)\
**Post date:** [October 9, 2018, 10:57pm UTC](https://discourse.itk.org/t/custom-border-extrapolation-of-shapedimageneighborhoodrange-by-imageneighborhoodpixelaccesspolicy/879/23 "2018-10-09T22:57:35Z")

</div>

Hey Niels, great, good stuff ✨ I have an itch though, why does the Range class has to have a new template parameter for this? Didn’t you explore the options you mentioned in the past:

> [@Niels\_Dekker](#):
>
> **`TStaticValueClass` :** Allowing the policy to retrieve the constant value by `TStaticValueClass::Value()` .
> 
> Actually there’s a third possibility which I find quite reasonable, and quite appealing:
> 
> **`TValueConvertible` :** Allowing the policy to retrieve the constant value, just by `TValueConvertible{}` . (Without the extra parentheses needed for `TFunctor{}()` ). `TValueConvertible{}` should then be convertible to the pixel value.

What problems did you find with those approaches? It seems to me they would generate a cleaner interface. Basically the user would only need to provide a template with the policy to the Range. Right know the Range class has to provide an optional parameter that would only be used for the case of the ConstantPolicy.

---

<div class="post-metadata">

**Author:** ![Niels\_Dekker](https://discourse.itk.org/letter_avatar_proxy/v4/letter/n/9d8465/32.png) [@Niels\_Dekker](https://discourse.itk.org/u/Niels_Dekker)\
**Post date:** [October 10, 2018, 8:59pm UTC](https://discourse.itk.org/t/custom-border-extrapolation-of-shapedimageneighborhoodrange-by-imageneighborhoodpixelaccesspolicy/879/24 "2018-10-10T20:59:52Z")

</div>

Thank you, @phcerdan, for having looked at [WIP: Added policy for constant NeighborhoodRange values outside image](http://review.source.kitware.com/#/c/23795). I hope I can clarify this patch a little more.

First of all, the patch still fully supports the original NeighborhoodRange interface: With the patch, it is still _not required_ to specify a _‘pixel access parameter’_. When you don’t specify the ‘pixel access parameter’, it is just set to a `nullptr` by default (and then it is simply ignored).

The policy introduced with the patch (`ConstantBoundaryImageNeighborhoodPixelAccessPolicy`) allows specifying the `'padding value'` at run-time, through this pixel access parameter. My idea is that it would thereby have the same flexibility as the old `itk::ConstantBoundaryCondition` (as used in combination with the old `itk::ConstNeighborhoodIterator`).

Example use case:

```
// Retrieve padding-value at run-time, from user input: 
std::cout << "Please enter 'paddingValue':" << std::endl;
PixelType paddingValue;
std::cin >> paddingValue;

// Using the old itk::ConstNeighborhoodIterator
itk::ConstantBoundaryCondition<ImageType> boundaryCondition;
boundaryCondition.SetConstant(paddingValue);
constNeighborhoodIterator.SetBoundaryCondition(boundaryCondition);

// The equivalent in ITK 5.0 + this patch.
// Using itk::Experimental::ShapedImageNeighborhoodRange:
using RangeType = ShapedImageNeighborhoodRange<ImageType,
  ConstantBoundaryImageNeighborhoodPixelAccessPolicy<ImageType>, PixelType>;
RangeType range{ *image, location, offsets, paddingValue };

```

The approaches we discussed in July did not support such a use case. They would just support specifying the padding value at compile-time. That’s why I still wanted to figure out how support for an _optional_ run-time pixel access parameter could be added, without significant extra overhead for the non-parametric use cases!

Did I make myself more clear? 😀

---

<div class="post-metadata">

**Author:** ![phcerdan](https://discourse.itk.org/user_avatar/discourse.itk.org/phcerdan/32/286_2.png) [@phcerdan](https://discourse.itk.org/u/phcerdan)\
**Post date:** [October 10, 2018, 9:41pm UTC](https://discourse.itk.org/t/custom-border-extrapolation-of-shapedimageneighborhoodrange-by-imageneighborhoodpixelaccesspolicy/879/25 "2018-10-10T21:41:44Z")

</div>

Thanks Niels, crystal clear, I think I understood correctly the first time, but always appreciate the extra examples! 😊

So, better than talking, going directly for the code (simplified):

```cpp
template <typename TImage>
class ConstantBoundaryImageNeighborhoodPixelAccessPolicy final
{
//......... Appending to all the good stuff already there ...... //
public:
  void SetConstant(const PixelType & inputValue) {m_Constant = inputValue; }
}

```

No new template parameter in Range:

```cpp
template<typename TImage, typename TImageNeighborhoodPixelAccessPolicy >
class ShapedImageNeighborhoodRange final:
{
// ........ Appending .... //
TImageNeighborhoodPixelAccessPolicy & GetReferencePixelAccessPolicy() { return m_PixelAccessPolicy;}
}

```

The usage:

```cpp
// The equivalent in ITK 5.0 + this patch + this
// Using itk::Experimental::ShapedImageNeighborhoodRange:
using RangeType = ShapedImageNeighborhoodRange< ImageType,
ConstantBoundaryImageNeighborhoodPixelAccessPolicy<ImageType> >;

RangeType range{ *image, location, offsets}; // same constructor as before
range->GetReferencePixelAccessPolicy()->SetConstant(paddingValue); // we set the value at run time on the policy

```

Let me know what you think,  
Cheers

---

<div class="post-metadata">

**Author:** ![Niels\_Dekker](https://discourse.itk.org/letter_avatar_proxy/v4/letter/n/9d8465/32.png) [@Niels\_Dekker](https://discourse.itk.org/u/Niels_Dekker)\
**Post date:** [October 11, 2018, 10:18am UTC](https://discourse.itk.org/t/custom-border-extrapolation-of-shapedimageneighborhoodrange-by-imageneighborhoodpixelaccesspolicy/879/26 "2018-10-11T10:18:17Z")

</div>

Hi Pablo!

I’m glad you appreciate the extra examples. I did test them, actually 😀 Did you also test the (simplified) code from your repy? If not, I think it would be helpful if you would just try to make it work.

The current `ShapedImageNeighborhoodRange` class does _not_ have a `m_PixelAccessPolicy` data member. Only the `PixelProxy` (which is returned when the user does `*it` on a Range iterator `it`) has a `m_PixelAccessPolicy`.

I fear an extra performance penalty when a PixelAccessPolicy data member would be added to the Range class. But please feel free to give it a try, if you want to!

**P.S.** In the meantime, I did replace `std::nullptr_t` by an empty struct, `EmptyPixelAccessParameter`, as a way to indicate that there is _no_ pixel access parameter specified: [Patch Set 4](http://review.source.kitware.com/#/c/23795/4) Hope you like that better!

---

<div class="post-metadata">

**Author:** ![Niels\_Dekker](https://discourse.itk.org/letter_avatar_proxy/v4/letter/n/9d8465/32.png) [@Niels\_Dekker](https://discourse.itk.org/u/Niels_Dekker)\
**Post date:** [October 20, 2018, 9:58pm UTC](https://discourse.itk.org/t/custom-border-extrapolation-of-shapedimageneighborhoodrange-by-imageneighborhoodpixelaccesspolicy/879/27 "2018-10-20T21:58:08Z")

</div>

@matt.mccormick, @phcerdan I just did a performance comparison between “old-school” and new range-based neighborhood iteration, both doing zero-padding (constant boundary). Using Visual C++ 2017 64-bit Release, I observed that the range-based neighborhood iteration implemented by [http://review.source.kitware.com/#/c/23795/7](http://review.source.kitware.com/#/c/23795/7) can be more than twice as fast as the “old-school” iteration 😀

The new range-based neighborhood iteration was tested by the following function. It calculates a number, `sumOfNeighbors`, just so that the optimizer cannot eliminate all the work.

```
unsigned TestRangeBasedIteration(const ImageType& image, const SizeType& radius)
{
  using namespace itk::Experimental;
  using RangeType = ShapedImageNeighborhoodRange<const ImageType,
    ConstantBoundaryImageNeighborhoodPixelAccessPolicy<ImageType>>;

  const auto region = image.GetBufferedRegion();
  const auto imageSize = region.GetSize();
  const auto offsets = GenerateRectangularImageNeighborhoodOffsets(radius);

  RangeType range{ image, IndexType{}, offsets };
  IndexType index{};
  unsigned sumOfNeighbors = 0;

  for (auto i = region.GetNumberOfPixels(); i > 0; --i)
  {
    range.SetLocation(index);

    for (const PixelType neighbor : range)
    {
      sumOfNeighbors += neighbor;
    }
    GoToNextPixelIndex(index, imageSize);
  }
  return sumOfNeighbors;
}

```

And the old-school neighborhood iteration was tested by the following function:

```
unsigned TestOldSchoolIteration(const ImageType& image, const SizeType& radius)
{
  using NeighborhoodIteratorType = itk::ConstNeighborhoodIterator<ImageType,
    itk::ConstantBoundaryCondition<ImageType>>;

  const auto region = image.GetBufferedRegion();
  const auto imageSize = region.GetSize();

  NeighborhoodIteratorType neighborhoodIterator(radius, &image, region);
  const auto numberOfNeigbors = neighborhoodIterator.Size();
  unsigned sumOfNeighbors = 0;

  while (!neighborhoodIterator.IsAtEnd())
  {
    for (itk::SizeValueType i = 0; i < numberOfNeigbors; ++i)
    {
      sumOfNeighbors += neighborhoodIterator.GetPixel(i);
    }
    ++neighborhoodIterator;
  }
  return sumOfNeighbors;
}

```

The full test is at [https://gist.github.com/N-Dekker/eb94ba817b2a16e75d5e7c3fe54ec66f](https://gist.github.com/N-Dekker/eb94ba817b2a16e75d5e7c3fe54ec66f)

Please check if you find it a fair comparison!

---

<div class="post-metadata">

**Author:** ![Niels\_Dekker](https://discourse.itk.org/letter_avatar_proxy/v4/letter/n/9d8465/32.png) [@Niels\_Dekker](https://discourse.itk.org/u/Niels_Dekker)\
**Post date:** [October 22, 2018, 4:48pm UTC](https://discourse.itk.org/t/custom-border-extrapolation-of-shapedimageneighborhoodrange-by-imageneighborhoodpixelaccesspolicy/879/28 "2018-10-22T16:48:47Z")

</div>

> [@Niels\_Dekker](#):
>
> Using Visual C++ 2017 64-bit Release, I observed that the range-based neighborhood iteration implemented by [http://review.source.kitware.com/#/c/23795/7](http://review.source.kitware.com/#/c/23795/7) can be more than twice as fast as the “old-school” iteration 😀

For the record, it was only **_after_** I wrote those words, that I found a way to significantly improve the performance of the “old-school” iteration (using Visual C++ 2017 Release): [PERF: Made ConstNeighborhoodIterator::GetPixel(i) much faster](http://review.source.kitware.com/#/c/23813/)

---

<div class="post-metadata">

**Author:** ![matt.mccormick](https://discourse.itk.org/user_avatar/discourse.itk.org/matt.mccormick/32/7_2.png) [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)\
**Post date:** [November 7, 2018, 6:31pm UTC](https://discourse.itk.org/t/custom-border-extrapolation-of-shapedimageneighborhoodrange-by-imageneighborhoodpixelaccesspolicy/879/29 "2018-11-07T18:31:11Z")

</div>

> [@Niels\_Dekker](#):
>
> > Using Visual C++ 2017 64-bit Release, I observed that the range-based neighborhood iteration implemented by [http://review.source.kitware.com/#/c/23795/7](http://review.source.kitware.com/#/c/23795/7) can be more than twice as fast as the “old-school” iteration 😀
> 
> For the record, it was only _ **after** _ I wrote those words, that I found a way to significantly improve the performance of the “old-school” iteration (using Visual C++ 2017 Release): [PERF: Made ConstNeighborhoodIterator::GetPixel(i) much faster](http://review.source.kitware.com/#/c/23813/)

@Niels_Dekker Well done! 👏 ✨ To add more data 🖖 to the Visual C++ 2017 Release results, here are some metrics created on Linux with GCC 7.3.0 and ICC (the Intel Compiler) 19.0.0.120. These results are created for this [ultrasound application](https://github.com/KitwareMedical/ITKUltrasound/pull/98) and [your Gist](https://gist.github.com/N-Dekker/eb94ba817b2a16e75d5e7c3fe54ec66f).

 ![ITKUltrasound%20Xcorr](https://discourse.itk.org/uploads/default/original/1X/37e4e192b056aec75a411cfb58b08bce48d1db1d.png)

They are very interesting! All we can conclude is that neither implementation is consistently faster across compilers! 😲

That said, the potential of these new image range classes to be used with STL algorithms is quite compelling because of potential future benefits:

- [C++17 Parallel STL execution policies](https://en.cppreference.com/w/cpp/experimental/parallelism)
- [Intel `parallelstl` TBB-backed implementation of the above](https://github.com/intel/parallelstl)
- [OpenCL / SYCL GPU / FPGA](https://www.khronos.org/sycl/) implementation of parallel STL via [ComputeCPP](https://www.codeplay.com/products/computesuite/computecpp) or [triSYCL](https://github.com/Xilinx/triSYCL)
- [AMD support](https://github.com/parmance/par_offload)
- [Potential NVidia support](https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-Interest-Parallel-Algos)

Granted that we would have to figure out a good way to control data synchronization in the GPU case.

> [@phcerdan](#):
>
> The usage:
> 
> ```auto
> // The equivalent in ITK 5.0 + this patch + this
> // Using itk::Experimental::ShapedImageNeighborhoodRange:
> using RangeType = ShapedImageNeighborhoodRange< ImageType,
> ConstantBoundaryImageNeighborhoodPixelAccessPolicy<ImageType> >;
> 
> RangeType range{ *image, location, offsets}; // same constructor as before
> range->GetReferencePixelAccessPolicy()->SetConstant(paddingValue); // we set the value at run time on the policy
> 
> ```

+1 to this API – setting the constant value separately from the range initialization is easier to follow, in my opinion. That said, this is not implemented, and maybe we could implement it in the future if it is really compelling. As an `itk::Experimental` namespaced feature, we should keep experimenting with nice things!

Let’s merge [the patch](https://github.com/InsightSoftwareConsortium/ITK/pull/105), which @hjmjohnson has kindly migrated to GitHub! 🐙

---

<div class="post-metadata">

**Author:** ![Niels\_Dekker](https://discourse.itk.org/letter_avatar_proxy/v4/letter/n/9d8465/32.png) [@Niels\_Dekker](https://discourse.itk.org/u/Niels_Dekker)\
**Post date:** [November 8, 2018, 11:27am UTC](https://discourse.itk.org/t/custom-border-extrapolation-of-shapedimageneighborhoodrange-by-imageneighborhoodpixelaccesspolicy/879/30 "2018-11-08T11:27:24Z")

</div>

@matt.mccormick Thanks for your extensive performance tests! Very interesting! Clearly the new range-based iterators aren’t _always_ faster (anymore) than the “old-school” NeighborhoodIterator classes, especially now that the old iterator classes have received some major PERF updates. 🤔 However, the new iterators will potentially be much faster than the old ones when the neighborhood location has to be reset frequently (for example, by means of `SetLocation`). As I observed with `GaussianDerivativeImageFunction`. Also I believe that the new range-based iterators could be significantly faster than the old ones on arbitrary neighborhood shapes (rather than just rectangular shapes). 😀

> [@matt.mccormick](#):
>
> +1 to this API – setting the constant value separately from the range initialization is easier to follow, in my opinion.

Sorry but I’m not really convinced. Allowing to modify the constant padding value _after_ range initialization might make things _harder_ to follow, in my opinion. Especially when the padding value is modified _after_ retrieving iterators from the range (using `begin()` and `end()`). It would yield the question whether such a modification would still affect these iterators. It seems clearer to me to specify the constant padding value as part of the range initialization so that it would then clearly remain constant.

(There’s also the design issue that current `ShapedImageNeighborhoodRange` class does _not_ have a policy data member, as I explained at [Custom border extrapolation of ShapedImageNeighborhoodRange by ImageNeighborhoodPixelAccessPolicy - #25 by phcerdan](https://discourse.itk.org/t/custom-border-extrapolation-of-shapedimageneighborhoodrange-by-imageneighborhoodpixelaccesspolicy/879/25))

Anyway, please go ahead if you would like to merge [ENH: Added policy for constant NeighborhoodRange values outside image by hjmjohnson · Pull Request #105 · InsightSoftwareConsortium/ITK · GitHub](https://github.com/InsightSoftwareConsortium/ITK/pull/105) I haven’t yet got the GitHub/ITK entirely up and running but if @hjmjohnson would like to do the merge, please do!

---

<div class="post-metadata">

**Author:** ![phcerdan](https://discourse.itk.org/user_avatar/discourse.itk.org/phcerdan/32/286_2.png) [@phcerdan](https://discourse.itk.org/u/phcerdan)\
**Post date:** [November 9, 2018, 12:37am UTC](https://discourse.itk.org/t/custom-border-extrapolation-of-shapedimageneighborhoodrange-by-imageneighborhoodpixelaccesspolicy/879/31 "2018-11-09T00:37:55Z")

</div>

> [@Niels\_Dekker](#):
>
> Sorry but I’m not really convinced. Allowing to modify the constant padding value _after_ range initialization might make things _harder_ to follow, in my opinion. Especially when the padding value is modified _after_ retrieving iterators from the range (using `begin()` and `end()` ). It would yield the question whether such a modification would still affect these iterators. It seems clearer to me to specify the constant padding value as part of the range initialization so that it would then clearly remain constant.

The issue I see with the current API is that the optional parameter of a particular policy should be encoded in that policy, not in the Range that can use any policy. Right now `Range<TPolicy, TOptionalParameterForConstantPolicy>`

What would happen if another policy comes by with another parameter type, we will need to modify `Range` template parameter?

What do you think about this? Do you think another API would be possible?

I suggested the Policy as data member because it solves this mangling, it would be less clean to use, we will have to first construct the range and then modify the policy, but I don’t see where the performance will be reduced (there is only one way to know though).

In any case, this is good stuff! 🎩

---

<div class="post-metadata">

**Author:** ![Niels\_Dekker](https://discourse.itk.org/letter_avatar_proxy/v4/letter/n/9d8465/32.png) [@Niels\_Dekker](https://discourse.itk.org/u/Niels_Dekker)\
**Post date:** [November 9, 2018, 10:45am UTC](https://discourse.itk.org/t/custom-border-extrapolation-of-shapedimageneighborhoodrange-by-imageneighborhoodpixelaccesspolicy/879/32 "2018-11-09T10:45:19Z")

</div>

@matt.mccormick Is [your ultrasound application](https://github.com/KitwareMedical/ITKUltrasound/pull/98) just zero-padding outside the image borders, or does it use some specific (non-zero) constant value?

If it is just zero-padding, you could possibly use some `ZeroBoundaryImageNeighborhoodPixelAccessPolicy` (to be implemented), instead of the `ConstantBoundaryImageNeighborhoodPixelAccessPolicy` class that I’m proposing at [PR 105](https://github.com/InsightSoftwareConsortium/ITK/pull/105).

Such a `ZeroBoundaryImageNeighborhoodPixelAccessPolicy` would _not_ need the optional extra `TOptionalPixelAccessParameter` parameter from the NeighborhoodRange, so it could work independently of the NeighborhoodRange code changes from [PR 105](https://github.com/InsightSoftwareConsortium/ITK/pull/105).

I’m saying this also because @phcerdan and I are still in discussion about the design of [PR 105](https://github.com/InsightSoftwareConsortium/ITK/pull/105). A `ZeroBoundaryImageNeighborhoodPixelAccessPolicy` class could still be implemented based on the currently merged version of the NeighborhoodRange.

---

<div class="post-metadata">

**Author:** ![matt.mccormick](https://discourse.itk.org/user_avatar/discourse.itk.org/matt.mccormick/32/7_2.png) [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)\
**Post date:** [November 9, 2018, 10:10pm UTC](https://discourse.itk.org/t/custom-border-extrapolation-of-shapedimageneighborhoodrange-by-imageneighborhoodpixelaccesspolicy/879/33 "2018-11-09T22:10:28Z")

</div>

> [@Niels\_Dekker](#):
>
> @matt.mccormick Is [your ultrasound application](https://github.com/KitwareMedical/ITKUltrasound/pull/98) just zero-padding outside the image borders, or does it use some specific (non-zero) constant value?

Yes, it is zero in this case.

> [@Niels\_Dekker](#):
>
> If it is just zero-padding, you could possibly use some `ZeroBoundaryImageNeighborhoodPixelAccessPolicy` (to be implemented), instead of the `ConstantBoundaryImageNeighborhoodPixelAccessPolicy` class that I’m proposing at [PR 105](https://github.com/InsightSoftwareConsortium/ITK/pull/105).
> 
> Such a `ZeroBoundaryImageNeighborhoodPixelAccessPolicy` would _not_ need the optional extra `TOptionalPixelAccessParameter` parameter from the NeighborhoodRange, so it could work independently of the NeighborhoodRange code changes from [PR 105](https://github.com/InsightSoftwareConsortium/ITK/pull/105).

Very cool! 🆒 Thanks for implementing and contributing this! 👏

In general, if we create these type-based optimized implementations, we are showcasing the power of C++.

---

<div class="post-metadata">

**Author:** ![Niels\_Dekker](https://discourse.itk.org/letter_avatar_proxy/v4/letter/n/9d8465/32.png) [@Niels\_Dekker](https://discourse.itk.org/u/Niels_Dekker)\
**Post date:** [November 9, 2018, 10:28pm UTC](https://discourse.itk.org/t/custom-border-extrapolation-of-shapedimageneighborhoodrange-by-imageneighborhoodpixelaccesspolicy/879/34 "2018-11-09T22:28:50Z")

</div>

> [@matt.mccormick](#):
>
> Thanks for implementing and contributing this!

I did not implement `ZeroBoundaryImageNeighborhoodPixelAccessPolicy`, I only implemented the more general `ConstantBoundaryImageNeighborhoodPixelAccessPolicy`, but that one is still under discussion. If you would like to, you could implement `ZeroBoundaryImageNeighborhoodPixelAccessPolicy` locally within your ultrasound application, by just copying the code from [`itkConstantBoundary*.h`](https://raw.githubusercontent.com/InsightSoftwareConsortium/ITK/578ccbc647fffc3ee5063d652763f5a079382182/Modules/Core/Common/include/itkConstantBoundaryImageNeighborhoodPixelAccessPolicy.h) and simply removing its `m_Constant` data member, replacing it by a hard-code 0 (or Zero), within GetPixelValue. I would be interested to know if hard-coding the zero constant would improve the performance…

[Previous page](https://discourse.itk.org/t/custom-border-extrapolation-of-shapedimageneighborhoodrange-by-imageneighborhoodpixelaccesspolicy/879.md?page=1)