# N4BiasFieldCorrection issues when re-run (applied through SliceBySlice filter)

**URL:** <https://discourse.itk.org/t/n4biasfieldcorrection-issues-when-re-run-applied-through-slicebyslice-filter/2897>\
**Category:** Algorithms\
**Created:** [April 3, 2020, 10:37am UTC](https://discourse.itk.org/t/n4biasfieldcorrection-issues-when-re-run-applied-through-slicebyslice-filter/2897 "2020-04-03T10:37:36Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![grothausmann.roman](https://discourse.itk.org/user_avatar/discourse.itk.org/grothausmann.roman/32/582_2.png) [@grothausmann.roman](https://discourse.itk.org/u/grothausmann.roman)\
**Post date:** [April 3, 2020, 10:37am UTC](https://discourse.itk.org/t/n4biasfieldcorrection-issues-when-re-run-applied-through-slicebyslice-filter/2897/1 "2020-04-03T10:37:36Z")

</div>

Hello!

I am wondering what is the current status of streaming when using the SliceBySlice filter to apply another filter slice-wise. I found this [communication](https://insight-developers.itk.narkive.com/fn6ZnXFz/streaming-with-slicebysliceimagefilter) but it is quite old and have trouble to get my [implementation of slice-wise applying N4](https://github.com/romangrothausmann/ITK-CLIs/blob/c32621b05a590e619c39ed109ed6f791423ef729/n4_SBS.cxx#L89-L157) to stream fully. For a 64GB input (with 2796 z-slices) it needs more than 1TB of memory even if I specify to use a 100 stream chunks. I would expect that the number of slices would be the best choice to apply streaming with the SliceBySlice filter, is it necessary to determine this before hand and set that to the `SetNumberOfStreamDivisions` of the writer?  
Is it necessary to set an ImageRegionSplitter for the writer corresponding to the slicing of the SliceBySlice, since the writer drives the streaming?

Many thanks for any help or hints.

---

<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:** [April 3, 2020, 12:40pm UTC](https://discourse.itk.org/t/n4biasfieldcorrection-issues-when-re-run-applied-through-slicebyslice-filter/2897/2 "2020-04-03T12:40:05Z")

</div>

Yes, I believe I got streaming working through the SliceBySliceImageFilter a while a go.

> [@grothausmann.roman](#):
>
> I would expect that the number of slices would be the best choice to apply streaming with the SliceBySlice filter, is it necessary to determine this before hand and set that to the `SetNumberOfStreamDivisions` of the writer?

Yes, number of slices generally works well. Yes, this should be done before hand. The number of slices can easily be obtained before pipeline execution by calling `UpdateOutputInformation` then [getting the image regions](https://github.com/InsightSoftwareConsortium/ITK/blob/master/Examples/IO/ImageReadExtractWrite.cxx#L177). For this case it make the most since to set the number of divisions to the number of slices.

The [PipelineMonitorImageFilter](https://itk.org/Doxygen/html/classitk_1_1PipelineMonitorImageFilter.html) can be very useful for monitoring how the pipeline is streaming the execution.

> [@grothausmann.roman](#):
>
> Is it necessary to set an ImageRegionSplitter for the writer corresponding to the slicing of the SliceBySlice, since the writer drives the streaming?

The `ImageRegionSplitter` is internal to the ImageIO, so you can’t set it. The ImageIO manages the how the image region is split based on what it’s capabilities. If an ImageIO’s doesn’t support streaming then the request will be for the full region. When compression is enabled streaming can be disabled too, as zlib compression does support the needed streaming/concatenation operations.

Alternatively to having the ImageIO you could use the StreamingImageFilter to drive the pipeline.

At a higher level for your problem consider a method to exploit the coherence in the z directions of the image. Perhaps first running BinShrinkImageFilter to reduce the size, then estimate the bias field in 3D at this lower resolution. The lower resolution field could be using at an initial estimate at the full resolution.

---

<div class="post-metadata">

**Author:** ![grothausmann.roman](https://discourse.itk.org/user_avatar/discourse.itk.org/grothausmann.roman/32/582_2.png) [@grothausmann.roman](https://discourse.itk.org/u/grothausmann.roman)\
**Post date:** [April 3, 2020, 1:01pm UTC](https://discourse.itk.org/t/n4biasfieldcorrection-issues-when-re-run-applied-through-slicebyslice-filter/2897/3 "2020-04-03T13:01:18Z")

</div>

Many thanks @blowekamp for your quick and detailed reply. Perhaps I should use the StreamingImageFilter to ensure that the splitter fits the SliceBySlice processing to be independent of the splitting of the ImageIO. So far I am using uncompressed MHAs so streaming should work and I was expecting that the splitter would correspond to SliceBySlice but I should test that.

> At a higher level for your problem consider a method to exploit the coherence in the z directions of the image. Perhaps first running BinShrinkImageFilter to reduce the size, then estimate the bias field in 3D at this lower resolution. The lower resolution field could be using at an initial estimate at the full resolution.

Generally, I fully agree, but in this case the images are acquired slice by slice and the bias field can vary from slice to slice without any correspondence to the third dimension, so to properly account for the “jagged” bias field (if viewed along the z-direction) I would expect that slice-by-slice processing is suited best. Using BinShrinkImageFilter before N4 even for 2D is on the ToDo list.

---

<div class="post-metadata">

**Author:** ![grothausmann.roman](https://discourse.itk.org/user_avatar/discourse.itk.org/grothausmann.roman/32/582_2.png) [@grothausmann.roman](https://discourse.itk.org/u/grothausmann.roman)\
**Post date:** [April 8, 2020, 7:50pm UTC](https://discourse.itk.org/t/n4biasfieldcorrection-issues-when-re-run-applied-through-slicebyslice-filter/2897/4 "2020-04-08T19:50:51Z")

</div>

Oddly, my [n4\_SBS](https://github.com/romangrothausmann/ITK-CLIs/blob/4288430e65db4978f9d1a7d72de50122541d16d8/n4_SBS.cxx#L89-L154) does need much more memory (as if leaking) if employing streaming when the `NumberOfFittingLevels` is larger than 1, e.g. if using `3x3` as last parameter. All seems fine with `NumberOfFittingLevels` equal 1, e.g. if using `3` or `100` as last parameter. In addition the SBS variant needs much more (about a factor of 100) time for processing that the non-SBS variant [n4](https://github.com/romangrothausmann/ITK-CLIs/blob/4288430e65db4978f9d1a7d72de50122541d16d8/n4.cxx#L91-L149).  
Could it be that for some reason N4 (and possibly other iterative filters) are not (well) compatible with SBS?

---

<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:** [April 8, 2020, 8:13pm UTC](https://discourse.itk.org/t/n4biasfieldcorrection-issues-when-re-run-applied-through-slicebyslice-filter/2897/5 "2020-04-08T20:13:00Z")

</div>

There are many possibilities for the source of the problematic execution. For one you have two new things you are adding here.

- Streaming the pipeline
- Using N4 aside the SBB

Try to break it up to figure where the problem is.

- Stream through the SBS with the CastImageFilter as the internal SBS
- Run the SBS with N4 but no streaming.

You are right, that there is likely some subtle problem with the N4 filter and it being executed multiple time in SBS filter.

---

<div class="post-metadata">

**Author:** ![grothausmann.roman](https://discourse.itk.org/user_avatar/discourse.itk.org/grothausmann.roman/32/582_2.png) [@grothausmann.roman](https://discourse.itk.org/u/grothausmann.roman)\
**Post date:** [April 9, 2020, 6:04pm UTC](https://discourse.itk.org/t/n4biasfieldcorrection-issues-when-re-run-applied-through-slicebyslice-filter/2897/6 "2020-04-09T18:04:12Z")

</div>

Yes, true, and “SBS with N4 but no streaming” even does not behave as expected. So far I was only able to get an output for a 2D input image (i.e. expecting N4 line processing just for testing) and only for `NumberOfFittingLevels = 1` (SDI and noSDI do yield the same result though: [https://gitlab.com/romangrothausmann/ITK-CLIs/-/jobs/505584525](https://gitlab.com/romangrothausmann/ITK-CLIs/-/jobs/505584525)). The output looks like a ramp image, basically not containing any info from the input any more. So there is definitely something wrong, but so far I cannot see where that problem may lie.  
Streaming N4 (without SBS) works as expected and testing SBS with another filter and streaming is in progress.

---

<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:** [April 9, 2020, 7:49pm UTC](https://discourse.itk.org/t/n4biasfieldcorrection-issues-when-re-run-applied-through-slicebyslice-filter/2897/7 "2020-04-09T19:49:45Z")

</div>

When run with the SBS, is the first slice OK?

There may be a problem with the N4 filter being run multiple time. May be worth testing independently.

---

<div class="post-metadata">

**Author:** ![grothausmann.roman](https://discourse.itk.org/user_avatar/discourse.itk.org/grothausmann.roman/32/582_2.png) [@grothausmann.roman](https://discourse.itk.org/u/grothausmann.roman)\
**Post date:** [April 9, 2020, 10:13pm UTC](https://discourse.itk.org/t/n4biasfieldcorrection-issues-when-re-run-applied-through-slicebyslice-filter/2897/8 "2020-04-09T22:13:58Z")

</div>

> When run with the SBS, is the first slice OK?

Yes, the first slice seems fine and I figured that the ramp image dominates but the actual image data is still there if using higher bit depths, e.g. 16-bit. Adjusting bc just within a small region leads to this:

 ![screenshot](https://discourse.itk.org/uploads/default/original/2X/c/c706b5ff89c757af0af6cea18a76bc4af0c7fac4.png)

> There may be a problem with the N4 filter being run multiple time. May be worth testing independently.

Is there a way to reset the filter chain applied by the SBS filter? `n4->ReleaseDataFlagOn();` did not seem to have an effect.

---

<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:** [April 10, 2020, 9:01pm UTC](https://discourse.itk.org/t/n4biasfieldcorrection-issues-when-re-run-applied-through-slicebyslice-filter/2897/9 "2020-04-10T21:01:09Z")

</div>

I would try running the N4 outside of this complicated pipeline twice with different inputs to see if the behaves as expected.

---

<div class="post-metadata">

**Author:** ![grothausmann.roman](https://discourse.itk.org/user_avatar/discourse.itk.org/grothausmann.roman/32/582_2.png) [@grothausmann.roman](https://discourse.itk.org/u/grothausmann.roman)\
**Post date:** [April 13, 2020, 12:33pm UTC](https://discourse.itk.org/t/n4biasfieldcorrection-issues-when-re-run-applied-through-slicebyslice-filter/2897/10 "2020-04-13T12:33:41Z")

</div>

> I would try running the N4 outside of this complicated pipeline twice with different inputs to see if the behaves as expected.

True, will try to create a test for the ITK-test suite.  
It seems the number of threads matters concerning the result, e.g. if run on a GL-runner with 24 CPUs the current test succeeds

> **[n4\_SBS (#508514792) · Jobs · Roman Grothausmann / ITK-CLIs · GitLab](https://gitlab.com/romangrothausmann/ITK-CLIs/-/jobs/508514792)**
>
> collection of command-line programs providing access to some ITK-functions

but if run on a standard GL-runner (providing only one CPU) the result differs

> **[n4\_SBS (#508513494) · Jobs · Roman Grothausmann / ITK-CLIs · GitLab](https://gitlab.com/romangrothausmann/ITK-CLIs/-/jobs/508513494)**
>
> collection of command-line programs providing access to some ITK-functions

The other ITK-CLI tests do not depend on a specific runner. I had a similar problem though with elastix.

---

<div class="post-metadata">

**Author:** ![grothausmann.roman](https://discourse.itk.org/user_avatar/discourse.itk.org/grothausmann.roman/32/582_2.png) [@grothausmann.roman](https://discourse.itk.org/u/grothausmann.roman)\
**Post date:** [April 13, 2020, 2:59pm UTC](https://discourse.itk.org/t/n4biasfieldcorrection-issues-when-re-run-applied-through-slicebyslice-filter/2897/11 "2020-04-13T14:59:58Z")

</div>

> [@blowekamp](#):
>
> Perhaps first running BinShrinkImageFilter to reduce the size, then estimate the bias field in 3D at this lower resolution. The lower resolution field could be using at an initial estimate at the full resolution.

This is quite a bit of hassle, because the N4 implementation is not offering a down-sample parameter directly, so the bias field at full res needs to be constructed separately and applied, like in e.g.

> <https://github.com/midas-journal/midas-journal-640/blob/66064fa938920bc3e47e90ad9bffd79be713bbe8/Source/N4.cxx#L388-L486>

However, the API has changed between the original implementation and the one in ITK-5, so the bias field can be generated as such

> <https://github.com/InsightSoftwareConsortium/ITK/blob/60924a512a38c65b2050ad905fd94b11541d0e10/Modules/Filtering/BiasCorrection/test/itkN4BiasFieldCorrectionImageFilterTest.cxx#L312-L322>

Oddly, it seems, the N4 test does not check the final corrected image only the bias field so the test, that was adjusted to the API changes, does not include the application of the up-sampled bias field.

Is there a reason why the N4 implementation does not have an option for a down-sample first, run N4, and apply up-sampled bias field to input image to produce the output?

---

<div class="post-metadata">

**Author:** ![grothausmann.roman](https://discourse.itk.org/user_avatar/discourse.itk.org/grothausmann.roman/32/582_2.png) [@grothausmann.roman](https://discourse.itk.org/u/grothausmann.roman)\
**Post date:** [April 13, 2020, 3:19pm UTC](https://discourse.itk.org/t/n4biasfieldcorrection-issues-when-re-run-applied-through-slicebyslice-filter/2897/12 "2020-04-13T15:19:08Z")

</div>

Not sure if related, but I just noticed that streaming N4 (without SBS) does not work for ITK-4.13.1

> **[n4 (#508759132) · Jobs · Roman Grothausmann / ITK-CLIs](https://gitlab.com/romangrothausmann/ITK-CLIs/-/jobs/508759132)**
>
> collection of command-line programs providing access to some ITK-functions

  
yielding

```auto
Description: Requested region is (at least partially) outside the largest possible region.

```

---

<div class="post-metadata">

**Author:** ![grothausmann.roman](https://discourse.itk.org/user_avatar/discourse.itk.org/grothausmann.roman/32/582_2.png) [@grothausmann.roman](https://discourse.itk.org/u/grothausmann.roman)\
**Post date:** [April 14, 2020, 2:18pm UTC](https://discourse.itk.org/t/n4biasfieldcorrection-issues-when-re-run-applied-through-slicebyslice-filter/2897/13 "2020-04-14T14:18:46Z")

</div>

> Oddly, it seems, the N4 test does not check the final corrected image only the bias field so the test, that was adjusted to the API changes, does not include the application of the up-sampled bias field.

While trying to implement up-sampling making use of the change from

> <https://github.com/InsightSoftwareConsortium/ITK/commit/d6d17b00986043efdd4b450a41a447e11c68b101#diff-4fd7d6e8f77462fbcf32c75bf3bfe9f8>
>
> This enables saving only the BSpline control point "positions",
> and recreating i…t later to apply to the full-resolution image.

I now stumbled upon the same/similar issue as with streaming N4 of ITK-4.13.1:

> **[n4 (#510348390) · Jobs · Roman Grothausmann / ITK-CLIs · GitLab](https://gitlab.com/romangrothausmann/ITK-CLIs/-/jobs/510348390)**
>
> collection of command-line programs providing access to some ITK-functions

yielding

```auto
N4BiasFieldCorrectionImageFilter # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # done. (real= 2.0s, CPUs= 12.7s)
ExpImageFilter progress: 100.0% done. (real= 0.0s, CPUs= 0.1s)

itk::InvalidRequestedRegionError (0x1a2f470)
Location: "unknown" 
File: /ITK/Modules/Core/Common/src/itkDataObject.cxx
Line: 355
Description: Requested region is (at least partially) outside the largest possible region.

```

i.e. failing on

> <https://github.com/romangrothausmann/ITK-CLIs/blob/6de0aba24fee5dee966d6d0e6b4e632a15c1c563/n4.cxx#L148-L159>

apparently `input` and the `biasField` returned by `ReconstructBiasField` are not equal in size/origin.

@dzenanz Did `ReconstructBiasField` for up-sampling work for you when working on

> <https://github.com/InsightSoftwareConsortium/ITK/commit/d6d17b00986043efdd4b450a41a447e11c68b101#diff-4fd7d6e8f77462fbcf32c75bf3bfe9f8>
>
> This enables saving only the BSpline control point "positions",
> and recreating i…t later to apply to the full-resolution image.

---

<div class="post-metadata">

**Author:** ![grothausmann.roman](https://discourse.itk.org/user_avatar/discourse.itk.org/grothausmann.roman/32/582_2.png) [@grothausmann.roman](https://discourse.itk.org/u/grothausmann.roman)\
**Post date:** [April 14, 2020, 2:25pm UTC](https://discourse.itk.org/t/n4biasfieldcorrection-issues-when-re-run-applied-through-slicebyslice-filter/2897/14 "2020-04-14T14:25:13Z")

</div>

Just as a note for others: The error

```auto
error: ?itk::N4BiasFieldCorrectionImageFilter<TInputImage, TMaskImage, TOutputImage>::RealImagePointer itk::N4BiasFieldCorrectionImageFilter<TInputImage, TMaskImage, TOutputImage>::ReconstructBiasField(itk::N4BiasFieldCorrectionImageFilter<TInputImage, TMaskImage, TOutputImage>::BiasFieldControlPointLatticeType*) [with TInputImage = itk::Image<float, 3>; TMaskImage = itk::Image<unsigned char, 3>; TOutputImage = itk::Image<float, 3>; itk::N4BiasFieldCorrectionImageFilter<TInputImage, TMaskImage, TOutputImage>::RealImagePointer = itk::SmartPointer<itk::Image<float, 3> >; itk::N4BiasFieldCorrectionImageFilter<TInputImage, TMaskImage, TOutputImage>::BiasFieldControlPointLatticeType = itk::Image<itk::Vector<float, 1>, 3>]? is private within this context

```

arises if using `ReconstructBiasField` with an ITK version before v5.1rc1, i.e. before

> <https://github.com/InsightSoftwareConsortium/ITK/commit/d6d17b00986043efdd4b450a41a447e11c68b101>

---

<div class="post-metadata">

**Author:** ![dzenanz](https://discourse.itk.org/user_avatar/discourse.itk.org/dzenanz/32/1093_2.png) [@dzenanz](https://discourse.itk.org/u/dzenanz)\
**Post date:** [April 14, 2020, 2:35pm UTC](https://discourse.itk.org/t/n4biasfieldcorrection-issues-when-re-run-applied-through-slicebyslice-filter/2897/15 "2020-04-14T14:35:26Z")

</div>

I was using N4 filter [in this example](https://github.com/InsightSoftwareConsortium/ITKMontage/blob/master/examples/CompleteMontage.cxx). It was working correctly when I committed, and it should still be working.

---

<div class="post-metadata">

**Author:** ![grothausmann.roman](https://discourse.itk.org/user_avatar/discourse.itk.org/grothausmann.roman/32/582_2.png) [@grothausmann.roman](https://discourse.itk.org/u/grothausmann.roman)\
**Post date:** [April 14, 2020, 2:55pm UTC](https://discourse.itk.org/t/n4biasfieldcorrection-issues-when-re-run-applied-through-slicebyslice-filter/2897/16 "2020-04-14T14:55:15Z")

</div>

Wow, that it is an amazing application and a cool example, many thanks for the pointer.  
However, isn’t `ReconstructBiasField` meant to replace

> <https://github.com/InsightSoftwareConsortium/ITKMontage/blob/2e7000149dd615dfb65d0664ec41a4026b95df11/examples/CompleteMontage.cxx#L274-L284>

  
as in  

> <https://github.com/InsightSoftwareConsortium/ITK/blob/d6d17b00986043efdd4b450a41a447e11c68b101/Modules/Filtering/BiasCorrection/test/itkN4BiasFieldCorrectionImageFilterTest.cxx#L312-L319>

---

<div class="post-metadata">

**Author:** ![dzenanz](https://discourse.itk.org/user_avatar/discourse.itk.org/dzenanz/32/1093_2.png) [@dzenanz](https://discourse.itk.org/u/dzenanz)\
**Post date:** [April 14, 2020, 3:46pm UTC](https://discourse.itk.org/t/n4biasfieldcorrection-issues-when-re-run-applied-through-slicebyslice-filter/2897/17 "2020-04-14T15:46:05Z")

</div>

It could be. I don’t remember any more. Maybe I just forgot to update the example once the ITK patch was integrated? You could try replacing it, and if it works correctly make a PR.

---

<div class="post-metadata">

**Author:** ![grothausmann.roman](https://discourse.itk.org/user_avatar/discourse.itk.org/grothausmann.roman/32/582_2.png) [@grothausmann.roman](https://discourse.itk.org/u/grothausmann.roman)\
**Post date:** [April 15, 2020, 4:49pm UTC](https://discourse.itk.org/t/n4biasfieldcorrection-issues-when-re-run-applied-through-slicebyslice-filter/2897/18 "2020-04-15T16:49:50Z")

</div>

Tried the old way

> <https://github.com/romangrothausmann/ITK-CLIs/commit/170a7173e1d113789c2e8611ad1c1b628015ae75#diff-6fb60c4362a73da6e040072bc4bbc90a>

  
which works ([https://gitlab.com/romangrothausmann/ITK-CLIs/-/jobs/510871225](https://gitlab.com/romangrothausmann/ITK-CLIs/-/jobs/510871225)) and replacing it with the new method

> <https://github.com/romangrothausmann/ITK-CLIs/commit/9bce952788a88227d86c1749f75181d2e90ae9f0#diff-6fb60c4362a73da6e040072bc4bbc90a>

  
which then fails ([https://gitlab.com/romangrothausmann/ITK-CLIs/-/jobs/510951570](https://gitlab.com/romangrothausmann/ITK-CLIs/-/jobs/510951570)) with `Description: Requested region is (at least partially) outside the largest possible region`.  
The only difference I see so far is that the former `bspliner->Update();` is basically now replaced by an update to the _output_ of the `reconstructer`

> <https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Filtering/BiasCorrection/include/itkN4BiasFieldCorrectionImageFilter.hxx#L630-L634>

Could that lead to the observed problem?

---

<div class="post-metadata">

**Author:** ![ntustison](https://discourse.itk.org/user_avatar/discourse.itk.org/ntustison/32/462_2.png) [@ntustison](https://discourse.itk.org/u/ntustison)\
**Post date:** [June 7, 2020, 4:33pm UTC](https://discourse.itk.org/t/n4biasfieldcorrection-issues-when-re-run-applied-through-slicebyslice-filter/2897/19 "2020-06-07T16:33:38Z")

</div>

The reason was simply a case of avoiding feature creep. In the original N3 implementation, John Sled/MNI use something akin to the `itkShrinkImageFilter` and that’s what we use in the [ANTs interface](https://github.com/ANTsX/ANTs/blob/master/Examples/N4BiasFieldCorrection.cxx#L358) but there’s no reason why somebody couldn’t use the `itkResampleImageFilter`. But with the latter, one then has to worry about potentially exposing all the associated parameters with that choice. To avoid that choice and the set of unnecessary parameters, as well as the fact that there seems to be a clean conceptual separation between estimating a bias field and applying that correction to an image, there is no downsampling/upsampling in the filter.

---

<div class="post-metadata">

**Author:** ![grothausmann.roman](https://discourse.itk.org/user_avatar/discourse.itk.org/grothausmann.roman/32/582_2.png) [@grothausmann.roman](https://discourse.itk.org/u/grothausmann.roman)\
**Post date:** [June 8, 2020, 9:35am UTC](https://discourse.itk.org/t/n4biasfieldcorrection-issues-when-re-run-applied-through-slicebyslice-filter/2897/20 "2020-06-08T09:35:00Z")

</div>

Many thanks @ntustison for your explanation. I see. What made me wonder is the fact that the filter returns the corrected image in its output

> <https://github.com/InsightSoftwareConsortium/ITK/blob/51cfc2926fe0cf860e2843e0ed51ee2363e20543/Modules/Filtering/BiasCorrection/include/itkN4BiasFieldCorrectionImageFilter.h#L65-L67>

  
not the bias field. So to me it seemed that the main idea of the filter is to yield the corrected image in which case including the down-sampling, up-sampling and applying the bias field would be very helpful, especially since these parts are not so straight forward and only needed in the case of a down-sampling factor \> 1.