Replace buffered region iteration with FillBuffer in FastMarching filters

[N-Dekker]

Removed manual iterations over buffered regions that just set all elements to the same value, in FastMarching filters. Added equivalent (but more efficient) calls to FillBuffer.

[N-Dekker]

This pull request would also merge the two consecutive if (m_GenerateGradientImage) statements:

ITK/Modules/Filtering/FastMarching/include/itkFastMarchingUpwindGradientImageFilter.hxx

Lines 87 to 95 in 643cafb

	if (m_GenerateGradientImage)
	{
	m_GradientImage->CopyInformation(this->GetInput());
	m_GradientImage->SetBufferedRegion(output->GetBufferedRegion());
	m_GradientImage->Allocate();
	}
	// set all gradient vectors to zero
	if (m_GenerateGradientImage)

[N-Dekker]

/azp run ITK.Linux

[greptile-apps]

Greptile Summary

This PR simplifies initialization logic in three FastMarching filter implementation files by replacing verbose manual ImageRegionIterator loops (that simply fill a buffer with a single value) with equivalent FillBuffer() calls. The change is purely a code-quality and minor performance improvement — FillBuffer can use memset-style bulk operations under the hood, while the iterator loops required per-pixel method calls and iterator overhead.

Key changes:

• itkFastMarchingImageFilter.hxx: Two manual loops (filling output pixels with m_LargeValue and filling m_LabelImage with LabelEnum::FarPoint) replaced by output->FillBuffer(m_LargeValue) and m_LabelImage->FillBuffer(LabelEnum::FarPoint). Three unnecessary outputPixel temporary variables are also eliminated.
• itkFastMarchingUpwindGradientImageFilter.hxx: Two separate if (m_GenerateGradientImage) blocks merged into one; the gradient-zeroing loop replaced with m_GradientImage->FillBuffer(GradientPixelType{}).
• itkFastMarchingUpwindGradientImageFilterBase.hxx: A 13-line while loop zeroing gradient vectors replaced with GradientImage->FillBuffer(GradientPixelType{}), consistent with the itkFastMarchingImageFilterBase.hxx base class which already used this pattern.
• All three test files correctly add an explicit #include "itkImageRegionIterator.h" since they use ImageRegionIterator directly and were previously relying on its transitive inclusion through the filter headers — good include hygiene.

The FillBuffer pattern for this type of bulk initialization is already established in itkFastMarchingImageFilterBase.hxx (lines 400 and 430), so these changes bring the older filter variants into alignment with the modern base class convention.

Confidence Score: 5/5

• This PR is safe to merge — all changes are semantically equivalent refactors with no behavioral differences.
• Every FillBuffer replacement is a direct semantic equivalent of the manual iterator loop it replaces. The GradientPixelType{} value-initialization correctly produces a zero-filled vector (the same pattern is already proven correct in itkFastMarchingImageFilterBase.hxx). The include changes in the three test files are accurate — each test file directly uses ImageRegionIterator and needed the explicit include after the transitive dependency was removed. No logic is altered, no new code paths are introduced, and the existing test suite exercises all affected initialization paths.
• No files require special attention.

Important Files Changed

Filename	Overview
Modules/Filtering/FastMarching/include/itkFastMarchingImageFilter.hxx	Replaces two manual ImageRegionIterator loops with FillBuffer calls and removes three unnecessary outputPixel temporaries; semantically equivalent and cleaner.
Modules/Filtering/FastMarching/include/itkFastMarchingUpwindGradientImageFilter.hxx	Merges two if (m_GenerateGradientImage) blocks into one and replaces the manual gradient-zeroing loop with FillBuffer(GradientPixelType{}), matching the pattern already established in the base class.
Modules/Filtering/FastMarching/include/itkFastMarchingUpwindGradientImageFilterBase.hxx	Removes a manual 13-line while loop that zeroed gradient vectors and replaces it with a single FillBuffer(GradientPixelType{}) call; straightforward and correct.
Modules/Filtering/FastMarching/test/itkFastMarchingTest.cxx	Adds an explicit #include "itkImageRegionIterator.h" that was previously satisfied transitively through the filter header; the test uses ImageRegionIterator at line 198, so the include is necessary.
Modules/Filtering/FastMarching/test/itkFastMarchingTest2.cxx	Adds an explicit #include "itkImageRegionIterator.h" needed by the ImageRegionIterator usage at line 171; the pre-existing itkImageRegionIteratorWithIndex.h include does not cover ImageRegionIterator.
Modules/Filtering/FastMarching/test/itkFastMarchingUpwindGradientTest.cxx	Adds an explicit #include "itkImageRegionIterator.h" for the ImageRegionIterator usage at line 178; correct hygiene fix after removing the transitive include from the filter header.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[FastMarchingImageFilter::Initialize] --> B[output->Allocate]
    B --> C["output->FillBuffer(m_LargeValue)\n(was: ImageRegionIterator loop)"]
    C --> D["m_LabelImage->FillBuffer(LabelEnum::FarPoint)\n(was: ImageRegionIterator loop)"]
    D --> E[Process AlivePoints / OutsidePoints / TrialPoints]

    F[FastMarchingUpwindGradientImageFilter::Initialize] --> G[Superclass::Initialize]
    G --> C
    F --> H{m_GenerateGradientImage?}
    H -- Yes --> I[m_GradientImage->Allocate]
    I --> J["m_GradientImage->FillBuffer(GradientPixelType{})\n(was: ImageRegionIterator loop)"]
    H -- No --> K[Skip]

    L[FastMarchingUpwindGradientImageFilterBase::InitializeOutput] --> M[Superclass::InitializeOutput]
    M --> N["oImage->FillBuffer(m_LargeValue)"]
    L --> O[GradientImage->Allocate]
    O --> P["GradientImage->FillBuffer(GradientPixelType{})\n(was: while loop)"]

Loading

_{Last reviewed commit: "PERF: Use FillBuffer..."}

[N-Dekker]

greptile-apps says at #5970 (comment)

Three unnecessary outputPixel temporary variables are also eliminated.

But it's really just one variable! So AI is inaccurate (or maybe I should say incorrect) this time.