# ImageRange - a range of iterators to the pixels of an image

**URL:** <https://discourse.itk.org/t/imagerange-a-range-of-iterators-to-the-pixels-of-an-image/1455>\
**Category:** Engineering\
**Created:** [December 4, 2018, 6:05pm UTC](https://discourse.itk.org/t/imagerange-a-range-of-iterators-to-the-pixels-of-an-image/1455 "2018-12-04T18:05:59Z")\
**Posts on this page:** 20\
**Page:** 1

<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:** [December 4, 2018, 6:05pm UTC](https://discourse.itk.org/t/imagerange-a-range-of-iterators-to-the-pixels-of-an-image/1455/1 "2018-12-04T18:05:59Z")

</div>

Last weekend, @hjmjohnson merged another C++ range class (template) that I proposed into the master branch: `itk::Experimental::ImageRange<TImage>`

> <https://github.com/InsightSoftwareConsortium/ITK/pull/252/commits/89cb360890ed4548ae2431cc26358bb333a9d9be>

Thanks also to @matt.mccormick , @dzenanz, @phcerdan for your help and review.

`ImageRange<TImage>` supports iteration over all pixels of an image buffer by using a C++11 range-based for-loop (`for(auto&& pixel: imageRange) ...`) or by using a Standard C++ Library (STL) algorithm like `std::for_each`. Moreover, it also supports random access (`pixel = imageRange[i]`).

Possible next steps (not necessarily in that order):

- Use `ImageRange` in existing or new ITK filters, whenever it could yield a significant performance improvement. I’m now looking at for-loops like this one in `N4BiasFieldCorrectionImageFilter`, which iterates over the entire buffered region, and appears to do a lot of (avoidable?) index computation, by calling `itk::Image::GetPixel(const itk::Index<N>&)` every time:

> <https://github.com/InsightSoftwareConsortium/ITK/blob/v5.0b01/Modules/Filtering/BiasCorrection/include/itkN4BiasFieldCorrectionImageFilter.hxx#L105>

  
I _think_ the performance of the code above here could be improved by using `ImageRange`.

- Add `begin()`, `end()`, and other range member functions to `itk::Image` and `itk::VectorImage`, which could just call the corresponding `ImageRange` member functions. This would allow having a range-based for-loop directly on an ITK image, which seems more convenient to me: `for(auto&& pixel: image) ...`

- `itk::ImageRegion` support: allow iteration over the pixels of a certain region within the image. @matt.mccormick asked for this feature already. Something like this (I guess):

---

<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:** [December 4, 2018, 6:20pm UTC](https://discourse.itk.org/t/imagerange-a-range-of-iterators-to-the-pixels-of-an-image/1455/2 "2018-12-04T18:20:39Z")

</div>

This is a monumental, awesome contribution, @Niels_Dekker! 🎉 ⛰

---

<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:** [December 10, 2018, 4:29pm UTC](https://discourse.itk.org/t/imagerange-a-range-of-iterators-to-the-pixels-of-an-image/1455/3 "2018-12-10T16:29:01Z")

</div>

In the mean time, I had a look at the performance, using `ImageRange` to copy the pixel data of an `itk::Image`, and compared it with the good old [itk::ImageAlgorithm::Copy](https://itk.org/Doxygen/html/structitk_1_1ImageAlgorithm.html) (using VS2017 Release):

```auto
std::copy(imageRange.cbegin(), imageRange.cend(), std::begin(outputImageRange));

```

Versus:

```auto
itk::ImageAlgorithm::Copy(&inputImage, &outputImage, bufferedRegion, bufferedRegion);

```

Guess what, the old `ImageAlgorithm::Copy` ran _more than 4 times faster_ than the equivalent `std::copy` on the `ImageRange` iterators! 😳

Fortunately, with the pull request that I just submitted, both lines of code will run approximately equally fast, according to my observation 😅

> <https://github.com/InsightSoftwareConsortium/ITK/pull/291>

---

<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:** [December 14, 2018, 9:58am UTC](https://discourse.itk.org/t/imagerange-a-range-of-iterators-to-the-pixels-of-an-image/1455/4 "2018-12-14T09:58:53Z")

</div>

> [@Niels\_Dekker](#):
>
> Possible next steps (not necessarily in that order):
> 
> - Use `ImageRange` in existing or new ITK filters, whenever it could yield a significant performance improvement. I’m now looking at for-loops like this one in `N4BiasFieldCorrectionImageFilter` , which iterates over the entire buffered region, and appears to do a lot of (avoidable?) index computation, by calling `itk::Image::GetPixel(const itk::Index<N>&)` every time

For the record, this is implemented by [pull request 295 - PERF: N4BiasFieldCorrectionImageFilter implementation using ImageRange](https://github.com/InsightSoftwareConsortium/ITK/pull/295). I observed about 10% performance improvement on an `Update()` of this filter.

---

<div class="post-metadata">

**Author:** ![blowekamp](https://discourse.itk.org/user_avatar/discourse.itk.org/blowekamp/32/79_2.png) [@blowekamp](https://discourse.itk.org/u/blowekamp)\
**Post date:** [December 14, 2018, 2:41pm UTC](https://discourse.itk.org/t/imagerange-a-range-of-iterators-to-the-pixels-of-an-image/1455/5 "2018-12-14T14:41:40Z")

</div>

> [@Niels\_Dekker](#):
>
> In the mean time, I had a look at the performance, using `ImageRange` to copy the pixel data of an `itk::Image` , and compared it with the good old [itk::ImageAlgorithm::Copy](https://itk.org/Doxygen/html/structitk_1_1ImageAlgorithm.html) (using VS2017 Release):
> 
> ```auto
> std::copy(imageRange.cbegin(), imageRange.cend(), std::begin(outputImageRange));
> 
> ```
> 
> Versus:
> 
> ```auto
> itk::ImageAlgorithm::Copy(&inputImage, &outputImage, bufferedRegion, bufferedRegion);
> 
> ```
> 
> Guess what, the old `ImageAlgorithm::Copy` ran _more than 4 times faster_ than the equivalent `std::copy` on the `ImageRange` iterators! 😳

The `ImageAlgorithm::Copy` is a good implementation. It was implemented in ITKv4, and it made several filters go nearly 100x faster than the prior implementation. It implements copying arbitrary _regions_ in the images, and takes care to compute the maximum continuous regions between the image, and then calls std::transform or std::copy in a the appropriate chunks. This method was implemented based on the needs and features required for working with `itk::Image`s and their multiple regions (BufferedRegions, RequestedRegion, LargestPossibleRegions). It is used in filters like the PasteImageFilter, SliceBySliceImageFilter, PadImageFilter etc… These filters are in the Grid group, so they move chunks around. Removing most of the features and then making a comparison biases the evaluation.

Are there any problems with the `ImageAlgorithm::Copy` that motivate an update?

---

<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:** [December 14, 2018, 3:04pm UTC](https://discourse.itk.org/t/imagerange-a-range-of-iterators-to-the-pixels-of-an-image/1455/6 "2018-12-14T15:04:46Z")

</div>

> [@blowekamp](#):
>
> Are there any problems with the `ImageAlgorithm::Copy` that motivate an update?

Honestly I’m impressed about `itk::ImageAlgorithm::Copy`. I think it’s a very clever 👍 piece of code! Having seen how well it performs, I’m certainly _not_ suggesting to generally replace existing `ImageAlgorithm::Copy` calls by `std::copy` calls on `ImageRange` iterators.

In general, I would _only_ suggest to convert existing ITK filters to start using `ImageRange`, when that would yield a significant performance gain. Or when it would yield an obvious style improvement. But only if it would perform at least as good as the original code, of course!

---

<div class="post-metadata">

**Author:** ![blowekamp](https://discourse.itk.org/user_avatar/discourse.itk.org/blowekamp/32/79_2.png) [@blowekamp](https://discourse.itk.org/u/blowekamp)\
**Post date:** [December 14, 2018, 3:32pm UTC](https://discourse.itk.org/t/imagerange-a-range-of-iterators-to-the-pixels-of-an-image/1455/7 "2018-12-14T15:32:33Z")

</div>

> [@Niels\_Dekker](#):
>
> In general, I would _only_ suggest to convert existing ITK filters to start using `ImageRange` , when that would yield a significant performance gain. Or when it would yield an obvious style improvement. But only if it would perform at least as good as the original code, of course!

I like the new interface of the `ImageRange` iterator as it behaves as expected like a std C++ iterator. This is a very _good_ 👍 thing and hope to see more of it. However, it became apparent yesterday, during the N4 review, the implications of only iterating over the `BufferedRegion` and how that interacts with the ITK pipeline.

The fact that the pipeline provides no guarantee that the `BufferedRegion`(s) is equal to the `RequestedRegion`(s) for a filter’s inputs is quite significant and needs to be fully considered. The implications are that the iterator is not suitable for operating on the input images, in general, because of the lack of guarantee we don’t know what the `BufferedRegion` is after a parent filter is executed. There are some cases where these _implicit_ assumptions might be appropirate… but that requires further thought.

It would be prudent to add a required argument to the `ImageRange`, the `Region` which it iterates on. This would make the current _implicit_ assumption explicit. The exemplar use case would be to just pass the image’s `BufferedRegion`. Logic should be added so that if the `Region` parameter does not match the `BufferedRegion` than an exception would be thrown. This would simplify the N4 filter, up for review, by removing the checks ( they would be now part for the `ImageRange` constructor), and make the region operated on explicit. For _old school_ ITK developers this is the expected usage, and it makes sense to know the region we are iterating over.

---

<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:** [December 14, 2018, 4:16pm UTC](https://discourse.itk.org/t/imagerange-a-range-of-iterators-to-the-pixels-of-an-image/1455/8 "2018-12-14T16:16:50Z")

</div>

Thanks for your ideas on ImageRange, @blowekamp. However, I’m not yet convinced that there should be such region checking and exception throwing within the `ImageRange(Image&)` constructor. It’s an essential property of `ImageRange` that it iterates over the entire image buffer. (If necessary, we could rename the class to something like “ImageBufferPixelRange” or “BufferedImageRange”.) Note that `ImageRange` may also be used outside of the context of an ITK pipeline. For example, when initializing an `itk::Image`, before its first use.

I’m considering to also add an image region specific class to iterate over pixels. However, such an “ImageRegionRange” would not be as fast as `ImageRange`.

It seems alright to me that a filter itself explicitly checks the regions or sizes of its input images. It does not seem necessary to me to have these precondition checks “hidden” within the `ImageRange` objects used by the filter. Right?

Please reconsider my pull request, [PERF: N4BiasFieldCorrectionImageFilter implementation using ImageRange](https://github.com/InsightSoftwareConsortium/ITK/pull/295). I really think it’s OK now.

---

<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:** [December 17, 2018, 6:59pm UTC](https://discourse.itk.org/t/imagerange-a-range-of-iterators-to-the-pixels-of-an-image/1455/9 "2018-12-17T18:59:19Z")

</div>

The use / assumptions / contract of `itk::Image`'s `RequestedRegion` and `BufferedRegion` are that

1. Once is comes time to process the `RequestedRegion`, it may be smaller than the `BufferedRegion`. This is common when an input image cannot stream or the filter producing an input image needed to extend the input’s `BufferedRegion`.
2. The `BufferedRegion` fully contains the `RequestedRegion`.

As a consequence, the `ImageRange` class or an alternative class should support operating on a `RequestedRegion` that is smaller than the `BufferedRegion`. Also, it is not necessary to check that the `RequestedRegion` is inside the `BufferedRegion` when iterating over it. The filters make sure that this is true, and if an image is constructed outside of a filter, the author is required to ensure this is true, just like they are required to call `Allocate()` if necessary. Excessive checks that hurt performance or make the API more confusing should be avoided.

---

<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:** [December 18, 2018, 1:57pm UTC](https://discourse.itk.org/t/imagerange-a-range-of-iterators-to-the-pixels-of-an-image/1455/10 "2018-12-18T13:57:05Z")

</div>

Thanks for your feedback, @matt.mccormick

I can imagine having two image range types:

- `BufferedImageRange<TImage>`: the fastest way to iterate over the entire buffer of an `itk::Image` (as currently implemented by `Experimental::ImageRange<TImage>`)
- `RequestedImageRange<TImage>`: iterating within the `RequestedRegion` of the specified image.

They could be constructed the same way, just passing an image as parameter:

```
  BufferedImageRange<TImage> bufferedImageRange{*image}; 
  RequestedImageRange<TImage> requestedImageRange{*image}; 

```

Clearly, the `BufferedImageRange` would use the `BufferedRegion`, and the `RequestedImageRange` would use the `RequestedRegion` of the image. Do you agree? Or do you think it would still be useful to add a region parameter? Is it useful to support specifying an arbitrary region, that is not one of these two?

---

<div class="post-metadata">

**Author:** ![blowekamp](https://discourse.itk.org/user_avatar/discourse.itk.org/blowekamp/32/79_2.png) [@blowekamp](https://discourse.itk.org/u/blowekamp)\
**Post date:** [December 18, 2018, 2:43pm UTC](https://discourse.itk.org/t/imagerange-a-range-of-iterators-to-the-pixels-of-an-image/1455/11 "2018-12-18T14:43:05Z")

</div>

> [@](#):
>
> The use / assumptions / contract of `itk::Image` 's `RequestedRegion` and `BufferedRegion` are that
> 
> 1. Once is comes time to process the `RequestedRegion` , it may be smaller than the `BufferedRegion` . This is common when an input image cannot stream or the filter producing an input image needed to extend the input’s `BufferedRegion` .
> 2. The `BufferedRegion` fully contains the `RequestedRegion` .

Well stated.

> [@matt.mccormick](#):
>
> Also, it is not necessary to check that the `RequestedRegion` is inside the `BufferedRegion` when iterating over it.

There is a [check](https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageConstIterator.h#L208-L210) in the base `ImageConstIterator` class that ensures the `region to iterate on` is contained in the `BufferedRegion`. This is a simple check that is usually done once during construction, and not per-pixel, so it has negligible impact on performance. This checks has been very useful which saves time and effort in writing, running and debugging pipelines or filters. The `ImageRange` or `ImageBufferedRegionRange` needs a similar check for the expected region being equal to the buffered.

Unexpected issues happened when there are multiple input and/or image grid and region manipulation explicitly stating the region being iterated on and checking that will occur will benefit both developers of filters and pipelines as well as when the `ImageRange` is use directly. It will help the class be easy to use and have wider adoption, while improving the reliability of the toolkit.

> [@Niels\_Dekker](#):
>
> Clearly, the `BufferedImageRange` would use the `BufferedRegion` , and the `RequestedImageRange` would use the `RequestedRegion` of the image. Do you agree? Or do you think it would still be useful to add a region parameter? Is it useful to support specifying an arbitrary region, that is not one of these two?

Currently, you specify the region an iterator works on with the conventional `ImageRegionIterators`. This works quite well both in the pipeline and outside. Only being able to iterate on requested or buffered regions will not generally work inside the pipelines, and would miss the flexibility needed to be widely used.

I understand that the current `ImageRange` was implemented to be very efficient and it has achieved that goal inpart by only being able to iterated on the `BufferedRegion`. This class needs to be:

- renamed to something like `ImageBufferedRegionRange`
- an argument added to the constructor to ensure the expected region is actually the buffered region being iterated on so that it is safe and clear what is being iterated over.

There is also a need for a general `ImageRegionRange` iterator to operate on an arbitrary region.

---

<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:** [December 21, 2018, 3:21pm UTC](https://discourse.itk.org/t/imagerange-a-range-of-iterators-to-the-pixels-of-an-image/1455/12 "2018-12-21T15:21:02Z")

</div>

Thank you guys, for discussing this issue so extensively.

In my opinion, _this specific range_ should just provide an elegant and generic interface to the pixel buffer as a whole:

- Offering access though the external `PixelType` of the image, rather than the `InternalPixelType`
- Supporting the modern C++ range interface

I think there should be another image range type that specifically iterates within a specified region (working title “ImageRegionRange”). I think I can submit a WIP version quite soon.

And yes, I would like rename this `ImageRange`, to `ImageBufferRange`. Would you like that too?

---

<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:** [December 21, 2018, 3:47pm UTC](https://discourse.itk.org/t/imagerange-a-range-of-iterators-to-the-pixels-of-an-image/1455/13 "2018-12-21T15:47:59Z")

</div>

> [@blowekamp](#):
>
> There is a [check](https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageConstIterator.h#L208-L210) in the base `ImageConstIterator` class that ensures the `region to iterate on` is contained in the `BufferedRegion` . This is a simple check that is usually done once during construction, and not per-pixel, so it has negligible impact on performance.

A internal check that is performed once in the constructor of the range is reasonable.

> [@Niels\_Dekker](#):
>
> In my opinion, _this specific range_ should just provide an elegant and generic interface to the pixel buffer as a whole:
> 
> - Offering access though the external `PixelType` of the image, rather than the `InternalPixelType`
> - Supporting the modern C++ range interface

Yes! And this class is extremely awesome, BTW!

> [@Niels\_Dekker](#):
>
> I think there should be another image range type that specifically iterates within a specified region (working title “ImageRegionRange”). I think I can submit a WIP version quite soon.
> 
> And yes, I would like rename this `ImageRange` , to `ImageBufferRange` . Would you like that too?

👍 Sounds great!

---

<div class="post-metadata">

**Author:** ![blowekamp](https://discourse.itk.org/user_avatar/discourse.itk.org/blowekamp/32/79_2.png) [@blowekamp](https://discourse.itk.org/u/blowekamp)\
**Post date:** [December 21, 2018, 3:59pm UTC](https://discourse.itk.org/t/imagerange-a-range-of-iterators-to-the-pixels-of-an-image/1455/14 "2018-12-21T15:59:37Z")

</div>

Here is sample usage I see:

```auto
const InputImageType * inputImage = this->GetInput();
const MaskImageType *const maskImage = GetMaskImage();

RegionType inputRegion = inputImage->GetBufferedRegion();

const auto imageRange = MakeImageRange(inputImage, inputRegion);
const auto maskImageRange = MakeImageRange(maskImage, inputRegion);

```

When using multiple `ImageRange` is make since to specify what region we are intending to iterate on, and check that they are consistent with the BufferedRegion.

---

<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:** [December 21, 2018, 4:19pm UTC](https://discourse.itk.org/t/imagerange-a-range-of-iterators-to-the-pixels-of-an-image/1455/15 "2018-12-21T16:19:57Z")

</div>

Thanks for your encouraging reply, @matt.mccormick

> [@blowekamp](#):
>
> When using multiple `ImageRange` is make since to specify what region we are intending to iterate on, and check that they are consistent with the BufferedRegion.

Thanks, @blowekamp I understand your intention. Although _personally_ I still think this region checking could be done more explicitly within the filter itself, before creating the ranges. Anyway, it’s clear how you would like to have it.

But then, I would like to support other use cases as well, with just a single image. For example, like this:

```
  for(auto&& pixel: MakeImageBufferRange(this->GetImage()) )
  {
      pixel = 42;
  }

```

For such use cases, I would not want to _require_ an extra `ImageRegion` parameter. Users would then just do:

```
  for(auto&& pixel:
    MakeImageBufferRange(this->GetImage(), this->GetImage()->GetBufferedRegion()) )
    ...

```

Internally, `ImageBufferRange` would then just check if `image->GetBufferedRegion() == image->GetBufferedRegion()`, for one and the same image. That would not make any sense to me.

As a compromise, could it be acceptable to you to have an _optional_ rather than an _obligatory_ `ImageRegion` parameter?

---

<div class="post-metadata">

**Author:** ![blowekamp](https://discourse.itk.org/user_avatar/discourse.itk.org/blowekamp/32/79_2.png) [@blowekamp](https://discourse.itk.org/u/blowekamp)\
**Post date:** [December 22, 2018, 4:53pm UTC](https://discourse.itk.org/t/imagerange-a-range-of-iterators-to-the-pixels-of-an-image/1455/16 "2018-12-22T16:53:08Z")

</div>

> [@Niels\_Dekker](#):
>
> for(auto&& pixel: MakeImageBufferRange(this-\>GetImage(), this-\>GetImage()-\>GetBufferedRegion()) ) …

I would propose the following more compact style:

```auto
auto itkImage = this->GetImage();
for( auto && pixel: MakeImageBufferRange(itkImage, itkImage->GetBufferedRegion()))
...

```

That looks like the right amount of verbosity to me. ITK has traditionally been over verbose or long in the required typedefs, variable names etc. The burden of writing is only once, but it is read likely hundreds of time so a little verbosity to make what the region being operated on clear ( to those who may not have seen this new iterative before) is well worth the effort.

---

<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:** [December 22, 2018, 8:50pm UTC](https://discourse.itk.org/t/imagerange-a-range-of-iterators-to-the-pixels-of-an-image/1455/17 "2018-12-22T20:50:20Z")

</div>

> [@blowekamp](#):
>
> I would propose the following more compact style:
> 
> ```auto
> auto itkImage = this->GetImage();
> for( auto && pixel: MakeImageBufferRange(itkImage, itkImage->GetBufferedRegion()))
> ...
> 
> ```

I’m sorry Bradley, but I’m not convinced. Internally, `MakeImageBufferRange(itkImage, itkImage->GetBufferedRegion())` would just check if `itkImage->GetBufferedRegion()` is equal to itself (!), which looks completely unnecessary to me.

Moreover, it would be a pity to me if `MakeImageBufferRange` would no longer support passing a `nullptr` as Image-pointer argument of `MakeImageBufferRange`. Currently `MakeImageBufferRange` returns an _empty range_, in that case. For example at [itkN4BiasFieldCorrectionImageFilter.hxx#L278](https://github.com/InsightSoftwareConsortium/ITK/blob/3fad901c761bbaff5dcc099c8a4025b1f5b4366d/Modules/Filtering/BiasCorrection/include/itkN4BiasFieldCorrectionImageFilter.hxx#L278):

```auto
const auto maskImageBufferRange = MakeImageBufferRange(this->GetMaskImage());

```

In this case, `this->GetMaskImage()` may return `nullptr`, and if that’s the case, you cannot easily pass `maskImage->GetBufferedRegion()` as second argument.

Would you like it if I rename the current `MakeImageBufferRange(TImage*)` to something like “MakeImageBufferRangeForBufferedRegion(TImage\*)”? Would that make things clearer to you (or anyone else)?

Of course you may still add another (an extra) `Make` function that does perform `BufferedRegion` checking… what do you think?

---

<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:** [January 2, 2019, 8:44pm UTC](https://discourse.itk.org/t/imagerange-a-range-of-iterators-to-the-pixels-of-an-image/1455/18 "2019-01-02T20:44:57Z")

</div>

> [@Niels\_Dekker](#):
>
> `MakeImageBufferRange(itkImage, itkImage->GetBufferedRegion())` would just check if `itkImage->GetBufferedRegion()` is equal to itself (!), which looks completely unnecessary to me.

+1

---

<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 6, 2019, 5:06pm UTC](https://discourse.itk.org/t/imagerange-a-range-of-iterators-to-the-pixels-of-an-image/1455/19 "2019-07-06T17:06:36Z")

</div>

> [@Niels\_Dekker](#):
>
> I think there should be another image range type that specifically iterates within a specified region (working title “ImageRegionRange”).

Update: I have finally finalized my `ImageRegionRange` [pull request](https://github.com/InsightSoftwareConsortium/ITK/pull/1032), and it has just been merged onto the master branch, by @hjmjohnson :

> <https://github.com/InsightSoftwareConsortium/ITK/commit/e164e0c285e4c3c065ca0f9df7bb328986b91d2f>
>
> Added \`ImageRegionRange\<TImage\>\` to the \`itk::Experimental\` namespace,
> supportin…g modern C++ iteration (bidirectional) over a range of pixels
> of an image region.
> 
> Replaced the classic \`ImageRegionConstIterator\<ImageType\>\` by
> \`ImageRegionRange\<const ImageType\>\`, when doing bounding box computation
> in \`ImageMaskSpatialObject\`. A performance improvement of 5 % or more
> was observed.

Thanks for your comments @dzenanz, @blowekamp !

I hope it can be included with ITK 5.1.0!

---

<div class="post-metadata">

**Author:** ![hjmjohnson](https://discourse.itk.org/user_avatar/discourse.itk.org/hjmjohnson/32/23_2.png) [@hjmjohnson](https://discourse.itk.org/u/hjmjohnson)\
**Post date:** [July 6, 2019, 5:10pm UTC](https://discourse.itk.org/t/imagerange-a-range-of-iterators-to-the-pixels-of-an-image/1455/20 "2019-07-06T17:10:02Z")

</div>

@Niels_Dekker Thank you for your contributions! Your careful considerations and extraordinary efforts are very much appreciated.

Please keep up the great work.

Hans

[Next page](https://discourse.itk.org/t/imagerange-a-range-of-iterators-to-the-pixels-of-an-image/1455.md?page=2)