STYLE: Use GetNumberOfPixels() for STAPLE pixel count

[hjmjohnson]

Replaces a per-pixel double accumulator with GetRequestedRegion().GetNumberOfPixels() in STAPLEImageFilter::GenerateData(). No behavior change — cleanup only, closing #6763.

Why this is cleanup and not a bug fix

N was accumulated as N = N + 1.0 inside the scanline loop. double carries a 53-bit mantissa, so the increment stays exact to 2^53 pixels and the counter never actually breaks. Filed and fixed only because it is the same idiom as the float counter in #6759, where it is a live defect (float saturates at 2^24 = 16,777,216, reached easily by a 3D image), so anyone auditing for that pattern lands here and has to re-derive that this instance is benign.

The change also removes one add from the inner loop.

What else in the file was checked and deliberately left alone

• g_t accumulates fractional per-pixel values, not counts — stays double.
• p_num / p_denom / q_num / q_denom accumulate W_i and 1 - W_i over all pixels. Fractional, already double, not counters.
• The initial averaging loop's out.Set(out.Get() + 1.0) is bounded by the input file count, so it carries no precision risk.
• alpha1 / beta1 are per-pixel products, not accumulations.

itkLabelVotingImageFilter was checked separately and already counts votes in unsigned int.

Local verification

ninja ITKImageCompareTestDriver ITKImageCompareGTestDriver   # clean, no warnings
ctest -R STAPLE                                             # 11/11 passed

Includes itkSTAPLEImageFilterTest, which is a baseline image comparison — the filter's output is bit-identical to before.

pre-commit run --all-files exits 0 on this tree.

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)
• Added ITK examples for all new major features (if any)

[greptile-apps]

Greptile Summary

This change replaces the per-pixel floating-point counter in STAPLEImageFilter::GenerateData() with the requested region’s pixel count while retaining double-precision normalization. No correctness issues were identified.

Confidence Score: 5/5

Safe to merge: the normalization denominator remains equivalent to the number of processed pixels while removing unnecessary work from the inner loop.

There are no final findings, so the score is 5.

Files Needing Attention: None.

_{Reviews (1): Last reviewed commit: "STYLE: Use GetNumberOfPixels() for STAPL..." | Re-trigger Greptile}

[N-Dekker]

Thanks Hans!

Minor note: Now that N is only used at line 124, its declaration might be moved to line 123, reducing its scope and visibility. But I leave that up to you. Approved anyway.

---

PS I'm surprised that greptile did not already suggest you to reduce the scope of N. It's a C++ Core Guideline: Keep scopes small. Still approved anyway, just slightly disappointed about greptile!