BUG: Findings collected while porting ~60 filters — reported together in one issue

[physwkim]

Following up on #6569: while porting SimpleITK's filter surface to another language, I kept a ledger of everything in the ITK sources that looked wrong or surprising. It has grown to 92 suspected bugs and 118 quirks (originally 30 and 24; follow-up batches B31–B92 and Q25–Q118) — too many to file individually without flooding the tracker, so I am reporting them together here for triage. The quirks now live in #6684; this issue tracks the 92 suspected bugs only. Happy to split any subset into standalone issues if that is more useful; I am not planning PRs for all of these, so please treat this as raw material.

Status at a glance (maintainer triage — updated 2026-07-26 by @hjmjohnson)

Bucket	Count
✅ Bugs fixed and merged	88 of 92
❌ Bugs withdrawn — investigated, not defects	4
Quirks (moved to #6684)	16 of 118 dispositioned (all merged)

The bug ledger is complete: all 92 items are resolved — 88 fixed and merged, 4 withdrawn after investigation. The final six landed the week of 2026-07-21: #6681 (B63/Q82), #6682 (B91), #6683 (B52), and the MetaIO vendor update #6692 (B64/B65/B66 via Kitware/MetaIO#141 and #142). Remaining lower-priority quirks are tracked in #6684.

✅ Outstanding work — none

Final six items (now merged)

#	Site	One-line symptom
✅ B52	niftilib nifti_read_buffer (vendored)	maps every non-finite float/double/complex component to 0 on read wherever isfinite is a macro — always, since it is a C99 <math.h> macro everywhere — so NaN/±Inf pixels are silently destroyed; confirmed empirically (1.5 nan inf -inf 2.5 reads back 1.5 0 0 0 2.5) — fix: #6683 (merged), via ISC/nifti_clib f24a6078 + UpdateFromUpstream.sh
✅ B91	vnl vnl_matlab_readhdr::read_hdr (vendored)	The no-swap switch lists 7 of the 8 legal type_t encodings — 1010 (big-endian, column-wise, single-precision), which vnl's own writer emits on a big-endian host, is byte-swapped as though foreign — fix: #6682 (merged), vendored-only by maintainer decision
✅ B63	NrrdImageIO::Write metadata dispatch	NRRD_-prefixed keys are matched by strncmp of the candidate's length — NRRD_space directions is swallowed by the space handler, and unmatched NRRD_ keys (including the reader's own NRRD_pixel_original_axis) are silently dropped — fix: #6681 (merged)
✅ B64	MetaIO ElementDataFile = LIST (vendored)	out-of-range file dimension (LIST -1 indexes m_DimSize[-1]/m_SubQuantity[-1]; LIST NDims reads nothing) and a short slice list both report success — fix: Kitware/MetaIO#141 (merged), vendored via #6692
✅ B65	MetaIO M_ReadElements (vendored)	a compressed image whose header omits CompressedDataSize measures from the start of the file, so a LOCAL image inflates its own ASCII header — fix: Kitware/MetaIO#142 (merged), vendored via #6692
✅ B66	MetaIO MET_PerformUncompression (vendored)	unconditionally return true; also its dest_pos accounting skipped the final inflate call, so no byte-count check was possible — both fixed, and both call sites now honour the result — fix: Kitware/MetaIO#142 (merged), vendored via #6692

Quirks — moved to #6684

All 118 quirks were split into #6684 so this issue can be driven to completion. They are lower priority and deliberately deferred until the bug ledger closes. Of them, 16 are dispositioned and merged (Q25–Q38 via #6671, Q82 via #6681, Q84 via #6674); the remaining 102 are untriaged and tracked there.

✅ Completed — 88 merged bug fixes (table)

#	Site	One-line symptom
✅ B1	ProjectionImageFilter	Collapsed-axis origin shift uses the axis index, unsigned; axis 0 wraps to a ~2³¹·spacing shift — fix: #6594 (merged)
✅ B2	N4BiasFieldCorrectionImageFilter::SharpenImage	Degenerate bin range → 0.0/0.0 = NaN → NaN→int cast (UB) → unchecked histogram index — fix: #6589 (merged)
✅ B3	SLICImageFilter	Empty cluster → 0/0 NaN centroid → NaN→integer index cast (UB) — fix: #6589 (merged)
✅ B4	WienerDeconvolutionImageFilter	Pf == Pn → complex division by zero → NaN output (guard passes on inf) — fix: #6589 (merged)
✅ B6	GridImageSource	Kernel loop walks only the first line per axis; origin cancels out of the pattern — fix: #6600 (merged)
✅ B7	MinMaxCurvatureFlowFunction (3-D)	acos taken on a gradient rescaled to length r, not 1 — wrong polar angle for radius ≥ 2 — fixed: #6603 (merged)
✅ B8	MinMaxCurvatureFlowFunction	Neighborhood scales divide by the stencil radius but only ±1 neighbors are sampled — update r² too small — fix: #6604 (merged)
✅ B9	AdaptiveHistogramEqualization	Constant input → iscale == 0 → NaN everywhere — fix: #6589 (merged)
✅ B10	MultiLabelSTAPLEImageFilter	Confusion-matrix increment walks into the next row on any voting tie — fix: #6579 (merged)
✅ B11	STAPLEImageFilter	All-background inputs → p_denom == 0 → NaN, unguarded — fix: #6589 (merged)
✅ B12	LabelOverlapMeasuresImageFilter	false_positive_error guard tests the wrong quantity — NaN reachable — fix: #6589 (merged)
✅ B13	ThresholdMaximumConnectedComponentsImageFilter	Initial bisection midpoint is (upper−lower)/2; unsigned wrap when it lands below lower — fixed: #6595 (merged)
✅ B14	ScalarImageKmeansImageFilter	UseNonContiguousLabels interval underflows to 0xFFFFFFFF for > 255 classes — fix: #6596 (merged)
✅ B15	LabelVotingImageFilter	Undecided label max_label+1 wraps to 0 for a UInt8 image using all 256 labels — fix: #6597 (merged)
✅ B16	MaskedFFTNormalizedCorrelationImageFilter	Pixel squaring runs in the input integer type — int32 overflow before the cast to real — fix: #6598 (merged)
✅ B17	IterativeDeconvolutionImageFilter	Output regions clobbered before PadInput/CropOutput read them — OutputRegionMode silently ignored — fixed: #6599 (merged)
✅ B18	FastApproximateRankImageFilter::SetRank	Rank forwarded to only the first Dim−1 per-axis filters — last axis always median — fix: #6580 (merged)
✅ B19	AttributeMorphologyBaseImageFilter	stable_sort end iterator off by one — last raster pixel never sorted — fix: #6581 (merged)
✅ B20	BoxSigmaImageFilter	Radius 0 → 0.0/0.0 → NaN for every pixel — fix: #6589 (merged)
✅ B21	LevelSetNeighborhoodExtractor	Strict sign tests: a pixel exactly on the contour neutralizes its neighborhood; grid-aligned contour starves the outward march — fixed: #6601 (merged)
✅ B22	StructureTensorImageFilter (AnisotropicDiffusionLBR)	Tensor smoothing K_ρ applied along axis 0 only (single-direction filter, SetDirection never called) — fix: #6602 (merged)
✅ B23	CoherenceEnhancingDiffusionImageFilter	Constant input → ∞ rescale → NaN tensors → negative step count via UB cast → zero iterations by accident — fix: #6589 (merged)
✅ B24	FastMarchingUpwindGradientImageFilter	AllTargets stop condition counts arrival events, not distinct targets — a duplicated target point ends the march early — fix: #6658 (merged)
✅ B25	Transform::ApplyToImageMetadata	Null GetInverseTransform() (singular or non-linear transform) dereferenced without a check — fix: #6583 (merged)
✅ B26	PatchBasedDenoisingImageFilter (POISSON)	static_cast<PixelValueType>(0.99999) is 0 for integer types — step size collapses to 1e-5 always — fix: #6633 (merged)
✅ B27	PatchBasedDenoisingImageFilter	Update write-back casts an unclamped negative float to an unsigned pixel type — UB — fix: #6589 (merged)
✅ B28	UniformRandomSpatialNeighborSubsampler	Search loops forever when the search box is exactly the query point (kernel-bandwidth path) — fix: #6605 (merged)
✅ B29	GaussianRandomSpatialNeighborSubsampler	Negative Gaussian variate cast to unsigned int — UB; rejection loop relies on the wrap — fix: #6589 (merged)
✅ B30	RegionBasedLevelSetFunction	Reinitialization smoothing term silently degenerates to a bare Laplacian when CurvatureWeight == 0 — fix: #6606 (merged)
✅ B31	IterativeInverseDisplacementFieldImageFilter	smallestError carries over from the previous pixel when the mapped point starts outside the buffer — output depends on raster order — fix: #6576 (merged)
✅ B32	InverseDisplacementFieldImageFilter	the field-subsampling resampler never gets the input's direction — with non-identity direction cosines the spline landmarks are not on the input lattice at all — fix: #6577 (merged)
✅ B33	VectorConfidenceConnectedImageFilter	a re-estimation pass that visits zero pixels produces NaN statistics, which invert the Mahalanobis guard — the next flood includes every pixel in the image — fix: #6578 (merged)
✅ B34	WarpImageFilter	the same-information fast-path test omits size, so a valid larger-output configuration dies in an iterator containment check instead of taking the general path — fix: #6672 (merged)
✅ B35	ExponentialDisplacementFieldImageFilter	the field is divided by 1 << numiter — UB when numiter >= 31; unreachable by default (cap 20, clamped), but an explicit SetMaximumNumberOfIterations(>= 31) makes it live — fix: #6673 (merged)
✅ B36	FastMarchingImageFilterBase::UpdateNeighbors	the neighbor loop gates on the center being strictly interior, so a border seed never propagates along the boundary-normal axis — a face seed confines the march to that face, a corner seed marches nowhere — fixed: #6613 (merged)
✅ B37	FastMarchingImageFilterBase (NoHandles)	marched-alive voxels never receive a connected-component label, so the facing-neighbor label test always passes and NoHandles degenerates to Strict — fixed: #6613 (merged)
✅ B38	FastMarchingImageFilterBase::Solve	the zero-speed guard substitutes a finite coefficient, giving zero-speed pixels an arrival time ≈ 2⁵² instead of the old filter's ∞ — speed barriers leak — fixed: #6613 (merged)
✅ B39	ScalarToRGBColormapImageFilter / ColormapFunction	NumericTraits<float/double>::min() (smallest positive) used as a "most negative" seed in two places — wrong rescale for non-positive float images, and a ≈FLT_MAX default input range — fixed: #6615 (merged)
✅ B40	MergeLabelMapFilter (KEEP)	the deferred-collision deque is never cleared between inputs — with ≥ 3 inputs one LabelObject ends up aliased under two label keys — fix: #6590 (merged)
✅ B41	LabelMapContourOverlayImageFilter (SLICE_CONTOUR)	the slice-radius loop tests the write cursor against m_SliceDimension where it means the read index — SliceDimension == 0 draws no contour at all — fix: #6590 (merged)
✅ B42	LabelMapMaskImageFilter (Crop)	an empty/zero-line object set leaves the bounding-box seeds untouched — signed overflow (UB), then a 2×2 region at index 2⁶³−1 — fix: #6590 (merged)
✅ B43	AttributeUniqueLabelMapFilter	the "remove objects without lines" pass is while (it.IsAtEnd()) — inverted, never executes — fix: #6590 (merged)
✅ B44	LabelMap::PushLabelObject	on a completely full label range the gap scan finds nothing, skips SetLabel, and silently overwrites the entry at the object's own label instead of throwing "map is full" — fix: #6590 (merged)
✅ B45	StatisticsLabelMapFilter	weighted elongation/flatness: no eigenvalue clamp, one shared guard, no ratio > 0 check — an indefinite weighted covariance yields NaN where ShapeLabelMapFilter yields 0 — fix: #6590 (merged)
✅ B46	NormalizedCorrelationImageFilter	both divisions unguarded — a constant template or a locally-constant neighborhood produces NaN — fixed: #6612 (merged)
✅ B47	TransformIOBaseTemplate::CorrectTransformPrecisionType	find("float") result used unchecked — a transform-type string naming neither precision throws std::out_of_range past every ITK handler — fixed: #6608 (merged)
✅ B48	NiftiImageIO::Read	rescale cast buffer sized per voxel, consumed per component — heap over-read for any multi-component image with scl_slope/scl_inter — fix: #6625 (merged)
✅ B49	NiftiImageIO::Read	RescaleFunction is given the voxel count — only the first numElts of a multi-component/complex buffer are rescaled — fix: #6625 (merged)
✅ B50	NiftiImageIO::Read	RAS↔LPS conversion never checks the 3-component requirement its own exception text names — 2/4-component vectors get a stride-3 sign flip across voxel boundaries — fix: #6625 (merged)
✅ B52	niftilib nifti_read_buffer (vendored)	non-finite float/double/complex components zeroed on read (isfinite macro path) — NaN/±Inf pixels silently destroyed — fix: #6683 (merged), via ISC/nifti_clib f24a6078; opt-in fix_floats keeps the old default for other consumers
✅ B53	GiplImageIO::Write	INT/UINT images throw "Pixel Type Unknown" only after the target file has been truncated and the header written — destroys existing data, leaves a 256-byte stub — fixed: #6611 (merged)
✅ B54	GiplImageIO::Read	success test is !bad(); a short pixel block sets failbit/eofbit, never badbit — truncated file reads as success over an uninitialized tail — fixed: #6611 (merged)
✅ B55	GiplImageIO::Read (compressed)	success flag is p != nullptr on the caller's always-non-null output buffer — gzread's byte count is never inspected — fixed: #6611 (merged)
✅ B56	GiplImageIO::Write	header image_type is derived from the component type alone while the byte count multiplies by components — a vector image writes a scalar header plus N× the bytes, reading back as garbage — fixed: #6611 (merged)
✅ B57	VTKImageIO::Read	ReadBufferAsBinary's bool (false on short read) is discarded — truncated BINARY file reads as success — fixed: #6610 (merged)
✅ B58	VTKImageIO::InternalReadImageInformation	every sscanf return is discarded over uninitialized locals — an under-filled DIMENSIONS/SPACING/ORIGIN line sizes the image from indeterminate values (UB) — fixed: #6610 (merged)
✅ B59	VTKImageIO::InternalReadImageInformation	attribute dispatch is an ordered substring test — SCALARS vector_field float matches the vector arm and is misparsed as a 3-component VECTORS line — fixed: #6610 (merged)
✅ B60	VTKImageIO ASCII write	precision(16) is set on a throwaway header stream; pixel data is emitted through a second stream at the default 6 significant digits — silent precision loss — fixed: #6610 (merged)
✅ B61	ImageIOBase::ReadBuffer (ASCII)	extraction variable declared outside the loop, stream state never checked — one bad/overflowing field latches into every later component (5 99999 7 8 as short reads [5, 32767, 32767, 32767]) — fixed: #6609 (merged)
✅ B62	VTKImageIO::CanReadFile	four GetNextLine calls outside the try block — a .vtk shorter than four lines throws "Premature EOF" through the factory instead of returning false — fixed: #6610 (merged)
✅ B63	NrrdImageIO::Write metadata dispatch	NRRD_-prefixed keys matched by strncmp of the candidate's length — NRRD_space directions swallowed by the space handler; unmatched NRRD_ keys silently dropped — fix: #6681 (merged)
✅ B64	MetaIO ElementDataFile = LIST (vendored)	out-of-range file dimension and a short slice list both report success — fix: Kitware/MetaIO#141, vendored via #6692 (merged)
✅ B65	MetaIO M_ReadElements (vendored)	compressed image without CompressedDataSize measures from the start of the file — a LOCAL image inflates its own ASCII header — fix: Kitware/MetaIO#142, vendored via #6692 (merged)
✅ B66	MetaIO MET_PerformUncompression (vendored)	unconditionally return true; dest_pos accounting skipped the final inflate — both fixed, call sites honour the result — fix: Kitware/MetaIO#142, vendored via #6692 (merged)
✅ B67	NrrdIO per-axis field parsers (vendored)	sizes/spacings/thicknesses/axis mins/axis maxs parse dim + 1 values into a NRRD_DIM_MAX(16)-element stack array — a 16-D header with a 17th token is a stack buffer overflow — fixed: #6674 (merged), upstream teem branch bug-nrrd-parse-axis-overflow on sourceforge
✅ B68	NrrdIO nrrdOriginCalculate (vendored)	the gotMin loop tests axis[0]->min for every axis (literal 0, not the loop variable) — origins computed from NaN mins, or usable mins ignored — fixed: #6674 (merged), upstream teem branch bug-nrrd-origin-calculate on sourceforge
✅ B69	NrrdIO rnParse_kinds (vendored)	the none token arm assigns the axis's centering, not its kind — kinds: none … clobbers a previously parsed centers: value — fixed: #6674 (merged), upstream teem branch bug-nrrd-kinds-none-centering on sourceforge
✅ B70	PNGImageIO::WriteSlice	the file is opened "wb" — truncating it — before the component-type switch whose default: throws; writing an int16 image destroys any existing .png and leaves it zero-byte — fixed: #6614 (merged)
✅ B72	PNGImageIO::WriteSlice	any component count > 4 declares 4 channels (PNG_COLOR_TYPE_RGB_ALPHA) while row pointers advance by the actual count — each row's trailing components are silently dropped — fixed: #6614 (merged)
✅ B73	HDF5ImageIO::WriteImageInformation	the C-string meta-data branch calls constCstringObj->GetMetaDataObjectValue() under a guard that admits constCstringObj == nullptr — null dereference for a MetaDataObject<char *> — fix: #6626 (merged)
✅ B74	HDF5ImageIO::ReadImageInformation	every geometry dataset's length is taken on trust — spacing[i] / Dims[i] are indexed to numDims regardless of the file's actual dataset length, reading past the end of a heap vector before any pixel is touched — fix: #6626 (merged)
✅ B76	JPEGImageIO::WriteSlice	the "prefer centimetres" density branch tags the JFIF header density_unit = 0 ("aspect ratio only") while storing real dots-per-cm values — the reader's own density_unit > 0 guard then discards them, so the spacing is lost on a round-trip through ITK — fix: #6627 (merged)
✅ B77	JPEGImageIO::Read	the CMYK→RGB conversion assumes all four channels are inverted; that holds for plain CMYK, but for a YCCK source libjpeg un-inverts C/M/Y and passes K through — a white YCCK pixel decodes to black — fix: #6627 (merged)
✅ B78	TIFFImageIO::ReadVolume	each kept page is written at its raw directory index while the volume depth is sized from m_SubFiles — one ignored or untagged page before a SUBFILETYPE == 0 page and the last slice is written past the end of the buffer — fix: #6636 (merged)
✅ B79	TIFFImageIO::ReadGenericImage	the scanline buffer is sized from the current directory, but width/SamplesPerPixel/BitsPerSample stay pinned to directory 0 — a multi-page file whose later pages are narrower over-reads the buffer — fix: #6636 (merged)
✅ B80	TIFFImageIO::ReadImageInformation	the 32-bit arm of the component-type ladder has no default:, and CanRead never constrains SampleFormat — a 32-bit SAMPLEFORMAT_VOID page is read as whatever m_ComponentType already held — fix: #6636 (merged)
✅ B81	TIFFImageIO::ReadGenericImage	PHOTOMETRIC_MINISWHITE is read out un-inverted — the // check inverted comment above the plain-copy grayscale arm never grew a body — fix: #6636 (merged)
✅ B82	TIFFImageIO::GetFormat	MINISBLACK/MINISWHITE map to GRAYSCALE regardless of SamplesPerPixel, so a 2-sample grey+alpha page is declared 1-component and each row keeps only its first half — fix: #6636 (merged)
✅ B83	TIFFImageIO::InternalWrite	PHOTOMETRIC_RGB is written for every component count other than 1 — a 2-component image becomes an RGB-tagged file with SamplesPerPixel = 2 and no EXTRASAMPLES — fix: #6636 (merged)
✅ B84	MultiLabelSTAPLEImageFilter	label loop counters are typed InputPixelType but bounded by m_TotalLabelCount — a uint8 input using all 256 labels wraps the counter 255 → 0 and InitializePriorProbabilities() never terminates (reproduced as a live hang, not source analysis) — fix: #6607 (merged)
✅ B85	MultiLabelSTAPLEImageFilter::InitializeConfusionMatrixArrayFromVoting	the internal seeding LabelVotingImageFilter never receives the outer filter's SetLabelForUndecidedPixels(), so the seed pass always uses automatic label selection regardless of the caller's setting — fix: #6607 (merged)
✅ B86	GiplImageIO::ReadImageInformation / CanReadFile	the 256-byte header is consumed as 15 separate gzread/istream::read pairs, none of whose byte counts is checked — a truncated or non-GIPL file populates dimensions, spacing and origin from uninitialized locals (same shape as B54/B55, but no success flag is computed at all) — fix: #6628 (merged)
✅ B87	TileImageFilter	A 0 in any non-last Layout axis is never validated: with a non-zero last axis it indexes an empty std::vector and runs a ~2³² iteration loop; with a zero last axis (the constructor default) it divides by zero — fix: #6630 (merged)
✅ B88	GDCMImageIO::Read (SINGLEBIT)	The 1-bit expansion walks the buffer as an unpadded bitstream, but GDCM pads each row to a byte boundary — every row after the first is decoded from the wrong bits when the width is not a multiple of 8 — fix: #6639 (merged), replacing the reverted #6629
✅ B89	GDCMImageIO::InternalReadImageInformation (ultrasound/hardcopy arm)	A single-valued (0028,0030) leaves the second Element slot never written — axis-0 spacing is read from indeterminate heap memory; the assert(GetLength() == 2) guard is vacuous and cannot fire even in a Debug build — fix: #6639 (merged), replacing the reverted #6629
✅ B90	LabelSetErodeImageFilter / LabelSetDilateImageFilter	GenerateData only calls AllocateOutputs() and every write is gated on m_Scale[d] > 0; under UseImageSpacing a zero radius on the last axis skips erosion's only output-writing pass — the filter returns uninitialized memory — fix: #6631 (merged)
✅ B91	vnl vnl_matlab_readhdr::read_hdr (vendored)	the no-swap switch lists 7 of the 8 legal type_t encodings — native big-endian single-precision 1010 byte-swapped as though foreign — fix: #6682 (merged)
✅ B92	ImageSeriesReader::GenerateOutputInformation	An ITK_ImageOrigin override array shorter than the output dimension is silently shrunk by Array::operator=, and the next loop still indexes to ImageDimension - 1 — unchecked out-of-bounds read. No in-tree ImageIO writes that key, so it is live only for an out-of-tree/custom ImageIO — fix: #6632 (merged)

✅ Completed — PR-by-PR triage record (55 settled rows)

#6629 (B88/B89, GDCM) was reverted by #6638 — its single-bit decode assumed row-padded 1-bit Pixel Data, but DICOM PS3.5 packs contiguously — and is now replaced by #6639, which decodes contiguously (verified pixel-for-pixel against pydicom on a real 13×12×8 highdicom SEG file) and validates PixelSpacing multiplicity via gdcm::VM::GetNumberOfElementsFromArray.

Every @physwkim PR carries a single commit; each regression test was verified locally to fail on the pre-fix code and pass on the fix.

Ledger item	PR	Author	State
B10 (MultiLabelSTAPLE tie increment)	#6579	@physwkim	Merged
B24 (FastMarchingUpwindGradient AllTargets duplicates)	#6658	@hjmjohnson	Merged
B67–B69, Q84 (vendored NrrdIO via ISC teem fork snapshot)	#6674	@hjmjohnson	Merged
B52 (niftilib non-finite pixel zeroing)	#6683	@hjmjohnson	Merged — fixed in ISC/nifti_clib (f24a6078, both nifti1 and nifti2), imported via UpdateFromUpstream.sh; opt-in fix_floats keeps the old default for other consumers; 49/49 NIfTI tests
B63, Q82 (NrrdImageIO, non-vendored)	#6681	@hjmjohnson	Merged — exact-match reserved-key dispatch; ITK-side regression GTests for B67–B69; Q82 verbatim-space warning
B64, B65, B66 (vendored MetaIO snapshot 8c41a1d9)	#6692	@hjmjohnson	Merged — upstream Kitware/MetaIO#141 (B64) and #142 (B65/B66), each with a regression test vendored in (testMeta13ImageList, testMeta14ImageCompressed); 83/83 Meta tests
B91 (vnl matlab reader native 1010 code)	#6682	@hjmjohnson	Merged — endian-agnostic fail-before/pass-after GTests; vendored-only fix, no upstream vxl submission planned
B18 (FastApproximateRank last axis)	#6580	@physwkim	Merged
B19 (AttributeMorphologyBase sort range)	#6581	@physwkim	Merged
B25 (ApplyToImageMetadata null inverse)	#6583	@dzenanz	Merged
B31 (IterativeInverseDisplacementField stale error bar)	#6576	@physwkim	Merged
B32 (InverseDisplacementField subsampler direction)	#6577	@physwkim	Merged; adjacent geometry gaps split to #6582, closed by #6588
B32 follow-up (lattice centering, output-direction API, subsampling guards)	#6588	@hjmjohnson	Merged — closed #6582
B2, B3, B4, B9, B11, B12, B20, B23, B27, B29 (NaN / UB-cast guards)	#6589	@hjmjohnson	Merged
B40–B45 (LabelMap / label-statistics correctness)	#6590	@hjmjohnson	Merged
B1 (ProjectionImageFilter collapsed-axis origin)	#6594	@physwkim	Merged — baselines uploaded
B13 (ThresholdMaximumConnectedComponents bisection seed)	#6595	@physwkim	Merged
B14 (ScalarImageKmeans non-contiguous label interval)	#6596	@physwkim	Merged
B15 (LabelVoting / MultiLabelSTAPLE undecided-label wrap)	#6597	@physwkim	Merged
B16 (MaskedFFTNormalizedCorrelation integer squaring)	#6598	@physwkim	Merged
B17 (IterativeDeconvolution ignores OutputRegionMode)	#6599	@physwkim	Merged
B6 (GridImageSource ignores the image origin)	#6600	@physwkim	Merged
B7 (MinMaxCurvatureFlow 3-D polar angle)	#6603	@physwkim	Merged
B8 (CurvatureFlowFunction derivative scale vs radius)	#6604	@physwkim	Merged
B21 (LevelSetNeighborhoodExtractor zero contour)	#6601	@physwkim	Merged
B22 (StructureTensor single-axis smoothing)	#6602	@physwkim	Merged — the 16 AnisotropicDiffusionLBR baselines were regenerated and uploaded
B28 (UniformRandomSpatialNeighborSubsampler infinite Search)	#6605	@physwkim	Merged
B30 (RegionBasedLevelSetFunction reinitialization term)	#6606	@physwkim	Merged
B36, B37, B38 (FastMarchingImageFilterBase boundary / topology / zero speed)	#6613	@physwkim	Merged
B39 (colormap NumericTraits::min as a most-negative seed)	#6615	@physwkim	Merged
B46 (NormalizedCorrelationImageFilter unguarded divisions)	#6612	@physwkim	Merged
B47 (TransformIOBase CorrectTransformPrecisionType)	#6608	@physwkim	Merged
B53–B56 (GiplImageIO write truncation, short-read detection, vector header)	#6611	@physwkim	Merged
B57–B60, B62 (VTKImageIO short read, sscanf, attribute dispatch, ASCII precision, CanReadFile)	#6610	@physwkim	Merged
B61 (ImageIOBase::ReadBuffer ASCII stream state)	#6609	@physwkim	Merged
B70, B72 (PNGImageIO truncates the file before validating)	#6614	@physwkim	Merged
B71 (PNGImageIO writes only the first slice)	—	@physwkim	Withdrawn — not a defect, the contract is documented and tested
B84, B85 (MultiLabelSTAPLE counter wrap, undecided label not propagated)	#6607	@physwkim	Merged
B48–B50 (NIfTI multi-component rescale over-read)	#6625	@physwkim	Merged
B73, B74 (HDF5 null metadata cast, unchecked geometry lengths)	#6626	@physwkim	Merged
B76, B77 (JPEG centimetre density tag, YCCK conversion)	#6627	@physwkim	Merged
B86 (GIPL header read in one checked call)	#6628	@physwkim	Merged
B88, B89 (GDCM single-bit packing, single-valued PixelSpacing)	#6629 (reverted by #6638), replaced by #6639	@physwkim, @hjmjohnson	Merged — #6639 decodes 1-bit Pixel Data contiguously per PS3.5 (including the trailing partial byte, which the pre-#6629 code dropped) and counts PixelSpacing values with GDCM's own multiplicity counter, closing the trailing-backslash gap. Verified against pydicom on a real multi-frame SEG file.
B87 (TileImageFilter zero Layout axis)	#6630	@physwkim	Merged
B90 (LabelSet erode/dilate uninitialized output)	#6631	@physwkim	Merged
B92 (ImageSeriesReader origin-override out-of-bounds)	#6632	@physwkim	Merged
B26 (PatchBasedDenoising POISSON step collapse)	#6633	@physwkim	Merged
B78–B83 (TIFF volume packing, per-page geometry, SampleFormat, MINISWHITE, grey+alpha, 2-component write)	#6636	@physwkim	Merged
B39 family (NumericTraits::min as a most-negative seed, 5 further sites)	#6634	@physwkim	Merged
B39 family (entropy threshold calculators)	#6635	@physwkim	Merged — expected constants and baselines updated
B51 (NIfTI 2-D vector rank), B71 (PNG first slice), B75 (HDF5 memory type)	—	@physwkim	Withdrawn — not defects, see the bug table
B5 (CannySegmentationLevelSetFunction speed image)	—	@physwkim	Withdrawn — not a defect, see comment below
B33 (ConfidenceConnected empty re-estimation)	#6578	@physwkim	Merged
Precursors	#6569 (JHMI marginals + derivative)	@physwkim	Merged
	#6572 (ScaleLogarithmicTransform Jacobian)	@physwkim	Merged

❌ Withdrawn — 4 items investigated and found not to be defects (table)

#	Site	One-line symptom
❌ B5	CannySegmentationLevelSetFunction	Propagation weight 0 → advection generated from a never-allocated speed image — not a defect; withdrawn (UpdateOutputInformation resets the empty requested region)
❌ B51	NiftiImageIO	spatial-dimension inference for intent-vector images never consults dim[1] — a 2-D vector image one row tall reads back as 1-D — not a defect; withdrawn: the write side collapses trailing degenerate dimensions too, so a 2-D 5x1 vector image and a 1-D 5 vector image produce byte-identical dim[]; the rank is lost at write time and no read-side change can recover it
❌ B71	PNGImageIO::WriteSlice	height comes from GetDimensions(1) alone, no axis beyond it is consulted — a 3-D image writes only its first slice, with no error — not a defect; withdrawn: writing the first slice of an image of 3 or more dimensions is the documented, tested contract (Modules/IO/PNG/test/itkPNGImageIOTest.cxx:152-160)
❌ B75	HDF5ImageIO::Read	the file datatype is passed as H5Dread's memory type, making the conversion the identity — a VoxelData stored STD_I16BE is copied without a byte swap and read back byte-swapped, silently — not a defect; withdrawn: ReadImageInformation() requires an exact H5Tequal match against a NATIVE_* predtype and throws otherwise, and it is what populates m_VoxelDataSet — so Read() is unreachable with a foreign-endian on-disk type (verified: writing STD_I16BE throws during ReadImageInformation())

How these were found, and what was checked before filing

Each filter was reimplemented from the .hxx sources and the two implementations compared on synthetic inputs; every divergence was traced back to the ITK code path that caused it. Before filing, every item was re-checked against main at e46eb723a5: the cited lines re-read in context, declared types and constructor defaults verified, and each claimed consequence re-derived from the quoted code. Items whose original analysis did not survive that re-check were corrected or dropped — some of my own earlier conclusions turned out to be wrong, so I would not be surprised if a few of the remaining ones are too. Corrections welcome.

One item is flagged inline as source-analysis only (B28: non-termination identified from the loop structure, not run to a live hang).

AI assistance

• Tool: Claude Code (claude-opus-4-8)
• Role: found the defects while cross-checking an independent reimplementation of these filters against this source; performed the pre-filing re-verification pass (re-reading every cited line on main at e46eb723a5, checking declared types and constructor defaults, re-deriving each consequence)
• Contribution: the inventory above
• Testing: source-level verification against e46eb723a5; behavioral claims cross-checked against the independent reimplementation's pinned tests. B28 is source analysis only (not run to a live hang) and is labeled as such inline.
• Items whose original analysis did not survive re-verification were corrected or dropped before filing.

[github-actions]

Thank you for contributing an issue! 🙏

Welcome to the ITK community! 🤗👋☀️

We are glad you are here and appreciate your contribution. Please keep in mind our community participation guidelines. 📜
Also, please check existing open issues and consider discussion on the ITK Discourse. 📖

This is an automatic message. Allow for time for the ITK community to be able to read the issue and comment on it.

[physwkim]

Following up on this issue: continuing the porting work, I have a second batch of findings, all in the displacement-field / warp / vector-filter area. Same methodology and caveats as the original report — source-level reading against master e46eb723a5, independently re-verified before posting, no runtime reproduction. Numbering continues from the original lists (B31–B34, Q25–Q29).

Bugs

#	Filter / site	Finding
B31	IterativeInverseDisplacementFieldImageFilter	smallestError carries over from the previous pixel when the mapped point starts outside the buffer — output depends on raster order
B32	InverseDisplacementFieldImageFilter	the field-subsampling resampler never gets the input's direction — with non-identity direction cosines the spline landmarks are not on the input lattice at all
B33	VectorConfidenceConnectedImageFilter	a re-estimation pass that visits zero pixels produces NaN statistics, which invert the Mahalanobis guard — the next flood includes every pixel in the image
B34	WarpImageFilter	the same-information fast-path test omits size, so a valid larger-output configuration dies in an iterator containment check instead of taking the general path

Quirks / doc

#	Site	Finding
Q25	IterativeInverseDisplacementFieldImageFilter	the coordinate-descent probe step is axis 0's spacing on every axis
Q26	DisplacementFieldJacobianDeterminantFilter	SetDerivativeWeights silently flips UseImageSpacing off — precedence between the two is last-writer-wins, while the class doc describes only one ordering
Q27	WarpImageFilter	m_OutputSize[0] == 0 alone keys "size unset"; output-grid defaults are unit/zero/identity from neither input; the field is sampled with edge replication, never out-of-domain
Q28	VectorConnectedComponentImageFilter	zero vectors join anything under the default threshold (no special case); concept macro name typo InputValyeTypeIsFloatingCheck
Q29	MahalanobisDistanceMembershipFunction	the det < 0 exception branch is unreachable; GetCovariance() never reflects the singular-case substitute

Details below.

B31 — IterativeInverseDisplacementField: stale smallestError makes output raster-order dependent

itkIterativeInverseDisplacementFieldImageFilter.hxx:96 declares the residual bar outside the per-pixel loop:

double smallestError = 0;
InputIt.GoToBegin();
OutputIt.GoToBegin();
while (!OutputIt.IsAtEnd())

and it is (re)assigned only inside the inside-buffer branch (:122-132):

if (inputFieldInterpolator->IsInsideBuffer(mappedPoint))
{
  ...
  smallestError = 0;
  ...
  smallestError = std::sqrt(smallestError);
}

Nothing at the top of the pixel iteration resets it. For a pixel whose initial mapped point falls outside the buffer, the branch is skipped and smallestError still holds the previous pixel's residual. The coordinate-descent probes are individually buffer-guarded (:147, :167), so a probe that lands inside the buffer is compared against that stale bar (:156 if (tmp < smallestError)) and accepted or rejected based on how well the previous pixel converged — the inverse field's values at such pixels depend on raster order.

B32 — InverseDisplacementField: subsampling resampler never gets the input's direction

itkInverseDisplacementFieldImageFilter.hxx, PrepareKernelBaseSpline configures the field-subsampling resampler at :119-141:

resampler->SetInput(inputImage);
resampler->SetOutputOrigin(inputImage->GetOrigin());
...
resampler->SetSize(size);
resampler->SetOutputStartIndex(subsampledRegion.GetIndex());
resampler->SetOutputSpacing(spacing);

SetOutputDirection is never called, and ResampleImageFilter's constructor leaves it identity (itkResampleImageFilter.hxx:51 m_OutputDirection.SetIdentity();; no reference image is set, so nothing overrides it). For an input field with non-identity direction cosines two things go wrong at once:

1. the resampler samples along an axis-aligned physical grid; interior sample points can fall outside the input buffer and silently take the default pixel value (zero, :65, applied at :411);
2. the landmark read-back at :168 (sampledInput->TransformIndexToPhysicalPoint(ot.GetIndex(), targetPoint)) uses the subsampled image's (identity) direction, so the target landmarks handed to the kernel transform are those axis-aligned points — not a subset of the input field's lattice.

The kernel-spline inverse is then anchored on landmarks that don't correspond to the field being inverted.

B33 — VectorConfidenceConnected: empty re-estimation pass floods the whole image via NaN statistics

itkVectorConfidenceConnectedImageFilter.hxx: the re-estimation loop recomputes mean/covariance from the previous segmentation with no guard on the visited-pixel count (SizeValueType num{}; at :264):

mean[ii] /= static_cast<double>(num);              // :289
covariance[ii][jj] /= static_cast<double>(num);    // :292

(The initial statistics do guard the equivalent case at :179-184; the loop has no such guard.) The empty case is reachable: the threshold is fixed before the loop (SetThreshold(m_Multiplier), :198/:226; the seed-inclusion boost :209-222 runs pre-loop only), while mean and covariance are recomputed each round (:304-305) — the acceptance interval moves, so a round can exclude even the seeds; the flood loop then simply never executes (:319-323 over an all-background image filled at :314) and the next pass has num == 0.

With num == 0, mean and covariance are 0.0/0.0 = NaN. In MahalanobisDistanceThresholdImageFunction the NaN squared distance then fails the guard at itkMahalanobisDistanceThresholdImageFunction.hxx:113:

const double mahalanobisDistance = (mahalanobisDistanceSquared > 0.0) ? std::sqrt(...) : 0.0;

so the distance clamps to 0.0, and 0.0 <= m_Threshold (:87) is true for any positive threshold — the next flood accepts every pixel in the image. (Mechanism note: the NaN reaches the distance chiefly through the NaN mean — a NaN determinant fails det > singularThreshold in itkMahalanobisDistanceMembershipFunction.hxx:107 and routes to the singular branch, which substitutes a finite inverse; the measurement − NaN-mean differences carry the NaN regardless.)

B34 — WarpImageFilter: same-information fast-path test omits size, so a valid configuration throws

itkWarpImageFilter.hxx:387-391:

this->m_DefFieldSameInformation =
  (outputPtr->GetOrigin()   ... is_equal(fieldPtr->GetOrigin(),   ...)) &&
  (outputPtr->GetSpacing()  ... is_equal(fieldPtr->GetSpacing(),  ...)) &&
  (outputPtr->GetDirection()... is_equal(fieldPtr->GetDirection(), ...));

Size is not part of the test, but the fast path iterates the field over the output's thread region (:294 ImageRegionConstIterator fieldIt(fieldPtr, outputRegionForThread);). The output can legitimately be larger than the field — :428-438 takes the output region from the user's SetOutputSize/SetOutputStartIndex when set — and GenerateInputRequestedRegion explicitly anticipates the mismatch by falling back to the field's largest possible region (:407-410), which silences the pipeline's requested-region check.

What happens then is not a buffer over-read — the iterator's own containment assert catches it (itkImageConstIterator.h:207-212, itkAssertOrThrowMacro(bufferedRegion.IsInside(m_Region)), which throws in release builds and aborts in debug). But the user-visible result is that a configuration the general path handles fine (it clamps field sampling to the field domain, :200-216) instead dies with an internal iterator error ("Region ... is outside of buffered region") whenever the output grid shares origin/spacing/direction with a smaller field. Adding a size/region comparison to the fast-path test would route this case to the general path.

Q25 — IterativeInverseDisplacementField: probe step is axis 0's spacing on every axis

itkIterativeInverseDisplacementFieldImageFilter.hxx:89 is the only per-axis spacing read in GenerateData:

const double spacing = inputPtr->GetSpacing()[0];

and the coordinate-descent loop applies it along every physical axis (:144-146 mappedPoint[k] += step;, :166, :186). For anisotropic fields every axis but the first is probed with the wrong step size.

Q26 — DisplacementFieldJacobianDeterminant: SetDerivativeWeights silently flips UseImageSpacing off

itkDisplacementFieldJacobianDeterminantFilter.hxx:55: SetDerivativeWeights begins with m_UseImageSpacing = false; (unconditionally, not via SetUseImageSpacing). The effective precedence between the two parameters is therefore last-writer-wins: SetUseImageSpacing(true) after SetDerivativeWeights re-derives weights from spacing at update time (:155-168), while the reverse order keeps the explicit weights and drops the spacing request. The class doc (.h:78-82) describes only the first ordering ("if UseImageSpacing is set to TRUE (ON), then these weights will be overridden by weights derived from the image spacing when the filter is updated").

Downstream note: SimpleITK's generated wrapper sets members in yaml order — UseImageSpacing before DerivativeWeights — so a SimpleITK user who sets both gets the UseImageSpacing(true) request silently dropped.

Q27 — WarpImageFilter parameter quirks

Three small ones, all in itkWarpImageFilter.hxx:

1. :428 — if (this->m_OutputSize[0] == 0 && fieldPtr != nullptr) keys "size unset" on element 0 alone; an explicit SetOutputSize({0, 5, 5}) silently discards the 5s and inherits the field's region.
2. :43-48 — constructor defaults are unit spacing, zero origin, identity direction, zero size: borrowed from neither the input image nor the field (asymmetric with ResampleImageFilter's reference-image convention).
3. :200-216 — displacement-field sampling clamps baseIndex/neighIndex into [m_StartIndex, m_EndIndex], i.e. edge-replicates, and never goes out-of-domain; only the input-image probe (m_Interpolator->IsInsideBuffer, :312/:342) can send a pixel to EdgePaddingValue. Worth a doc note since the two lookups follow different out-of-domain policies.

Q28 — VectorConnectedComponent: zero vectors, and a concept-macro typo

itkVectorConnectedComponentImageFilter.h:77-87: the functor is an unnormalized dot product (documented — "Assumes that vectors are normalized", and Math::Absolute deliberately makes antiparallel vectors similar per .h:100-101). A zero vector, however, has no documented story: it yields dotProduct = 0 against anything, so 1 - |0| = 1, and with the wrapped default DistanceThreshold = 1 it joins any neighbor — zero-padding or masked-out regions merge with whatever they touch.

Trivial: .h:145 — itkConceptMacro(InputValyeTypeIsFloatingCheck, ...) misspells "Value" as "Valye".

Q29 — MahalanobisDistanceMembershipFunction: dead det check; GetCovariance hides the substitute

itkMahalanobisDistanceMembershipFunction.hxx:

1. :98-103 — const double det = inv_cov.determinant_magnitude(); followed by if (det < 0.) { itkExceptionStringMacro(...) }. determinant_magnitude() is a product of SVD singular values, hence non-negative; the branch is unreachable (a NaN det also fails < 0.).
2. :92 caches the raw covariance; the singular-case substitution (:114-124) replaces only m_InverseCovariance with aLargeDouble·I. GetCovariance() (a GetConstReferenceMacro) therefore always reports the literal input matrix, with no indication the function is actually operating with the substituted inverse.

(Same AI-assistance disclosure as the issue body applies to this comment.)

[physwkim]

A third batch from the continuing port, this time in the demons-registration / displacement-field-exponential area. Same methodology and caveats as before — source-level reading against master e46eb723a5, independently re-verified before posting, no runtime reproduction. Numbering continues (B35, Q30–Q37).

Bug (latent, explicit-configuration-only)

#	Filter / site	Finding
B35	ExponentialDisplacementFieldImageFilter	the field is divided by 1 << numiter — UB when numiter >= 31; unreachable by default (cap 20, clamped), but an explicit SetMaximumNumberOfIterations(>= 31) makes it live

Quirks / doc

#	Site	Finding
Q30	FastSymmetricForcesDemonsRegistrationFilter	its difference function is ESMDemonsRegistrationFunction; the identically-named FastSymmetricForcesDemonsRegistrationFunction class is orphaned from its own filter
Q31	ExponentialDisplacementFieldImageFilter	"take the ceil" comment vs + 1.0-then-truncate code (integral values overshoot by 1); a zero field still runs one squaring iteration
Q32	WarpVectorImageFilter (as wired by DiffeomorphicDemonsRegistrationFilter)	under the nearest-neighbor-extrapolating interpolator, IsInsideBuffer is always true and m_EdgePaddingValue is dead code
Q33	ESMDemonsRegistrationFunction	the WarpedMoving and MappedMoving gradient options coincide exactly at a zero displacement field (interior pixels, default linear interpolation, coincident grids)
Q34	LevelSetMotionRegistrationFilter/Function	dt = 1/maxL1 makes the applied step at the governing pixel exactly Alpha-independent; thresholded pixels count toward the metric while out-of-buffer pixels don't; Halt adds an RMS==0 clause the base can never fire
Q35	LevelSetMotionRegistrationFunction	one-sided difference steps add index-axis spacing to a physical coordinate — wrong direction and step under non-identity direction cosines
Q36	demons family	zero-iteration runs report GetRMSChange() == 0 but GetMetric() == NumericTraits<double>::max() in the two filters that don't override GetRMSChange
Q37	LevelSetMotionRegistrationFunction smoothing	the smoothed moving image is re-quantized to the moving image's own pixel type (u8 in → u8 smoothed) before the gradient; and any axis shorter than 4 pixels is a hard error for this family member only

Details below.

B35 — ExponentialDisplacementField: signed shift UB behind SetMaximumNumberOfIterations ≥ 31

itkExponentialDisplacementFieldImageFilter.hxx:160 (and the inverse at :164):

m_Divider->SetInput2(static_cast<InputPixelRealValueType>(1 << numiter));

numiter itself is unsigned int (:70); the UB kernel is the signed literal 1 — the shift's result type is int, so 1 << 31 is undefined. To be clear about reachability: this is not hittable by default. The constructor caps m_MaximumNumberOfIterations at 20 (:32), and the automatic count is hard-clamped:

numiter = std::min(static_cast<unsigned int>(numiterfloat + 1.0), m_MaximumNumberOfIterations);  // :112

so no input field, however extreme, raises it past the cap. It becomes live only when a user explicitly calls SetMaximumNumberOfIterations with ≥ 31 (clamp target in automatic mode; taken verbatim in non-automatic mode, :121). 1u << numiter or computing the power in floating point would close it.

Q30 — FastSymmetricForcesDemonsRegistrationFunction is orphaned from its own filter

itkFastSymmetricForcesDemonsRegistrationFilter.h:120-121:

using DemonsRegistrationFunctionType =
  ESMDemonsRegistrationFunction<FixedImageType, MovingImageType, DisplacementFieldType>;

with the in-source comment at :117: FIXME: Why is this the only permissible function ?. Meanwhile the identically-named FastSymmetricForcesDemonsRegistrationFunction (itkFastSymmetricForcesDemonsRegistrationFunction.h:47) is a complete, instantiable class that its own filter never uses. It is not the default force function of any filter either (CurvatureRegistrationFilter defaults to MeanSquareRegistrationFunction, itkCurvatureRegistrationFilter.h:96-99); its only uses anywhere in the tree are as an explicit CurvatureRegistrationFilter template argument in two tests (itkCurvatureRegistrationFilterTest.cxx:114, RegistrationITKv3/DeformableRegistration10.cxx:60). Worth either wiring it back to its filter, documenting the ESM substitution, or deprecating the orphan.

Q31 — ExponentialDisplacementField iteration count: not-quite-ceil, and the zero-field case

itkExponentialDisplacementFieldImageFilter.hxx:111-112:

// take the ceil and threshold
numiter = std::min(static_cast<unsigned int>(numiterfloat + 1.0), m_MaximumNumberOfIterations);

For an exactly-integral numiterfloat == 2.0 this yields 3 where ceil would give 2 — a harmless extra squaring, but not what the comment says.

Zero displacement field: maxnorm2 == 0, so the ternary at :106-107 assigns numiterfloat = NumericTraits<...>::min() (the smallest positive normal), which passes numiterfloat >= 0.0 (:109) and truncates to numiter = 1 — the identity field is still divided by 2, squared once, and composed. Correct result, one wasted composition pass.

Q32 — WarpVectorImageFilter: EdgePaddingValue is dead under the extrapolating interpolator

All three IsInsideBuffer overloads of VectorLinearInterpolateNearestNeighborExtrapolateImageFunction return true unconditionally (.h:99-118), and EvaluateAtContinuousIndex clamps the base index and zeroes the out-of-range fractional distance (.hxx:51-67) — out-of-buffer points extrapolate the nearest pixel. WarpVectorImageFilter's per-pixel test (itkWarpVectorImageFilter.hxx:171-186):

if (m_Interpolator->IsInsideBuffer(point)) { ... } else { outputIt.Set(m_EdgePaddingValue); }

is then always-true, and the m_EdgePaddingValue branch is unreachable. The plain filter's default interpolator (VectorLinearInterpolateImageFunction, .h:141) does real bounds checks, so this is configuration-dependent — but DiffeomorphicDemonsRegistrationFilter installs exactly the extrapolating one (itkDiffeomorphicDemonsRegistrationFilter.h:196-199, ctor wiring .hxx:38-39), so for the demons field warper the edge-padding parameter silently does nothing.

Q33 — ESMDemonsRegistrationFunction: WarpedMoving and MappedMoving gradients coincide at a zero field

WarpedMoving hand-computes an index-space central difference over the warped moving image (itkESMDemonsRegistrationFunction.hxx:294-296 — deliberately not via CentralDifferenceImageFunction, per the comment at :206-207), while MappedMoving calls CentralDifferenceImageFunction::Evaluate, which samples the interpolant at p ± 0.5·spacing in physical space (itkCentralDifferenceImageFunction.hxx:264-300). Under linear interpolation, M(p + 0.5s) − M(p − 0.5s) = ½(m[i+1] − m[i−1]) at a pixel centre, so divided by s the two are exactly equal at a zero displacement field — for interior pixels, default linear interpolation on both paths, and coincident fixed/moving grids (the boundary rules and spacing divisors differ). Users choosing between the two enum options may expect a difference the defaults don't deliver; a doc note would cover it.

Q34 — LevelSetMotion: time-step consequences the docs don't state

The only family member whose global time step is data-dependent: dt = 1/m_MaxL1Norm (itkLevelSetMotionRegistrationFunction.hxx:352-367; the other four functions all return a constant m_TimeStep = 1.0). Three consequences:

1. Per-pixel update is speed * gradient[j] / (gradientMagnitude + m_Alpha) (:330) and the L1 norm feeds m_MaxL1Norm (:339, :345-348). At the pixel that attains the max, with one dominant gradient direction, dt · update[k] = ±mSpacing[k] — the (|g| + Alpha) factor cancels exactly, so at the governing pixel the applied displacement is independent of Alpha (other pixels carry the ratio (|g_max|+α)/(|g_p|+α), so it is approximate field-wide). The Alpha doc ("small positive constant to avoid division by zero") does not mention that the global step rescales its attenuation back out.
2. A thresholded pixel still increments SumOfSquaredDifference/NumberOfPixelsProcessed (:313-325 — counted before the guards zero the update), while an out-of-buffer pixel returns before counting (:220-228) — the reported metric mixes the two exclusion policies.
3. LevelSetMotionRegistrationFilter::Halt (.hxx:76-89) adds m_RMSChange == 0.0 && GetElapsedIterations() != 0; the base's convergence test is strictly GetMaximumRMSError() > m_RMSChange (itkFiniteDifferenceImageFilter.hxx:225), which at the default MaximumRMSError == 0.0 can never fire on 0.0 > 0.0 — so this subclass converges on an exactly-zero iteration where every sibling keeps iterating to the count limit.

Q35 — LevelSetMotion: one-sided differences step a physical coordinate by index-axis spacing

itkLevelSetMotionRegistrationFunction.hxx:253 (loop :251-277):

PointType mPoint(mappedPoint);          // physical point
...
mPoint[j] += mSpacing[j];               // index-axis j's spacing added to physical coordinate j

mappedPoint comes from TransformIndexToPhysicalPoint plus the displacement (:213), and mSpacing is the moving image's spacing (:240-245). With a non-identity direction matrix, physical axis j is not index axis j — the probe walks the wrong direction by the wrong step. (Same borrowed-axis pattern as CentralDifferenceImageFunction::Evaluate's point[dim] ± 0.5 * spacing[dim], so it may be a known family-wide convention — flagging it because here it also interacts with UseImageSpacing, which selects both this step and the L1-norm divisor of the time step, :339. The demons/ESM functions have no such toggle; they fold spacing in unconditionally via m_Normalizer, itkDemonsRegistrationFunction.hxx:122-127.)

Q36 — Demons family: zero-iteration metric reporting is inconsistent

SymmetricForcesDemonsRegistrationFilter (.h:118), FastSymmetricForcesDemonsRegistrationFilter (.h:113), and DiffeomorphicDemonsRegistrationFilter (.h:125) override GetRMSChange() to forward to the function; DemonsRegistrationFilter and LevelSetMotionRegistrationFilter do not. For the latter two, a run with zero elapsed iterations reports the base's value-initialized m_RMSChange == 0.0 (itkFiniteDifferenceImageFilter.h:361) — "converged" — while GetMetric() forwards (itkLevelSetMotionRegistrationFilter.hxx:91-103) to the function's constructor sentinel m_Metric = NumericTraits<double>::max() (itkLevelSetMotionRegistrationFunction.hxx:50). Two query methods on the same freshly-run filter thus disagree about whether anything happened.

Q37 — LevelSetMotion smoothing: re-quantization, and a 4-pixel minimum unique in the family

itkLevelSetMotionRegistrationFunction.h:116 instantiates the smoother with one template argument:

using MovingImageSmoothingFilterType = SmoothingRecursiveGaussianImageFilter<MovingImageType>;

so TOutputImage = TInputImage (itkSmoothingRecursiveGaussianImageFilter.h:50): the filter computes internally in a real-typed image but casts back (CastingFilterType, .h:91) — a u8 moving image is smoothed and then re-quantized to u8 before the gradient interpolator reads it (.hxx:181, :185). And through RecursiveSeparableImageFilter it inherits the hard error on any filtered axis shorter than 4 pixels (itkRecursiveSeparableImageFilter.hxx:193-201, in BeforeThreadedGenerateData) — a 3-pixel-thick volume is a throw for LevelSetMotionRegistrationFilter and for no other member of the family (the others take gradients via CentralDifferenceImageFunction, no minimum size).

(Same AI-assistance disclosure as the issue body applies to this comment.)

[physwkim]

A fourth batch from the continuing port, covering the fast-marching, colormap, label-map / label-statistics, and registration-support areas. Same methodology and caveats as before — source-level reading, each item independently re-verified with a refutation-oriented pass before posting (this batch against current main at 812d7a89f3), no runtime reproduction. Numbering continues (B36–B46, Q38–Q59).

Bugs

#	Filter / site	Finding
B36	FastMarchingImageFilterBase::UpdateNeighbors	the neighbor loop gates on the center being strictly interior, so a border seed never propagates along the boundary-normal axis — a face seed confines the march to that face, a corner seed marches nowhere
B37	FastMarchingImageFilterBase (NoHandles)	marched-alive voxels never receive a connected-component label, so the facing-neighbor label test always passes and NoHandles degenerates to Strict
B38	FastMarchingImageFilterBase::Solve	the zero-speed guard substitutes a finite coefficient, giving zero-speed pixels an arrival time ≈ 2⁵² instead of the old filter's ∞ — speed barriers leak
B39	ScalarToRGBColormapImageFilter / ColormapFunction	NumericTraits<float/double>::min() (smallest positive) used as a "most negative" seed in two places — wrong rescale for non-positive float images, and a ≈FLT_MAX default input range
B40	MergeLabelMapFilter (KEEP)	the deferred-collision deque is never cleared between inputs — with ≥ 3 inputs one LabelObject ends up aliased under two label keys
B41	LabelMapContourOverlayImageFilter (SLICE_CONTOUR)	the slice-radius loop tests the write cursor against m_SliceDimension where it means the read index — SliceDimension == 0 draws no contour at all
B42	LabelMapMaskImageFilter (Crop)	an empty/zero-line object set leaves the bounding-box seeds untouched — signed overflow (UB), then a 2×2 region at index 2⁶³−1
B43	AttributeUniqueLabelMapFilter	the "remove objects without lines" pass is while (it.IsAtEnd()) — inverted, never executes
B44	LabelMap::PushLabelObject	on a completely full label range the gap scan finds nothing, skips SetLabel, and silently overwrites the entry at the object's own label instead of throwing "map is full"
B45	StatisticsLabelMapFilter	weighted elongation/flatness: no eigenvalue clamp, one shared guard, no ratio > 0 check — an indefinite weighted covariance yields NaN where ShapeLabelMapFilter yields 0
B46	NormalizedCorrelationImageFilter	both divisions unguarded — a constant template or a locally-constant neighborhood produces NaN

B36 — FastMarchingImageFilterBase::UpdateNeighbors: border seeds never propagate along the boundary-normal axis

itkFastMarchingImageFilterBase.hxx:152-158:

for (int s = -1; s < 2; s += 2)
{
  if ((v > start) && (v < last))
  {
    neighIndex[j] = v + s;
  }
  const unsigned char label = m_LabelImage->GetPixel(neighIndex);

The guard tests the center coordinate v, and is false for both values of s when v sits on either end of axis j — so neighIndex stays at the center, whose label was just set to Alive by the caller (itkFastMarchingBase.hxx:163, immediately before the UpdateNeighbors call at :166), the label != Alive test fails, and nothing along that axis is updated. A trial seed on a face therefore confines the entire march to that face; a corner seed marches nowhere.

Contrast GetInternalNodesUsed in the same file (:212-218, per-side bounds check) and the old FastMarchingImageFilter::UpdateNeighbors (itkFastMarchingImageFilter.hxx:311-336, separate guards per direction) — the interior-only gating looks like a defect, not a design choice. SimpleITK's own regression test uses interior seeds ({70,70}, {200,180}), which is why it goes unnoticed.

B37 — FastMarchingImageFilterBase: NoHandles topology mode degenerates to Strict

The NoHandles machinery seeds m_ConnectedComponentImage only from the user-supplied alive points (itkFastMarchingImageFilterBase.hxx:449-452); voxels accepted during the march are made Alive (itkFastMarchingBase.hxx:163) but never receive a component label. doesChangeCreateHandle then compares facing-neighbor component labels:

if (ItC.GetNext(d) == ItC.GetPrevious(d))   // :352
{
  doesChangeCreateHandle = true;

Both marched-alive neighbors read 0, so the labels always compare equal, the handle test is effectively always true, and the component-merge code at :371-380 is unreachable. Net effect: NoHandles produces output identical to Strict. (When no alive points are set at all — e.g. through SimpleITK, which exposes only trial points — the component image is all-zero from the start.)

B38 — FastMarchingImageFilterBase::Solve: zero-speed pixels get a finite arrival time — speed barriers leak

itkFastMarchingImageFilterBase.hxx:262-269:

if (itk::Math::FloatAlmostEqual<double>(cc, 0.0))
{
  cc = -1.0 * itk::Math::sqr(1.0 / (cc + itk::Math::eps));
}
else
{
  cc = -1.0 * itk::Math::sqr(1.0 / cc);
}

The old FastMarchingImageFilter has no zero guard (itkFastMarchingImageFilter.hxx:406): cc = -sqr(1/0) = -inf, the discriminant becomes +inf, the candidate solution is ∞ ≥ LargeValue, and the pixel is never accepted — a zero-speed region is an impenetrable wall. The new base instead substitutes cc = -(1/eps)² = -(2⁵²)², which yields a finite candidate ≈ 2⁵² that is written and made Alive — the front passes through the barrier with a huge-but-finite time. Two smaller divergences in the same function: the discriminant guard throws on discrim < itk::Math::eps (:287) where the old filter tested < 0.0 (:428), so an underflowed-to-zero discriminant now throws; and SetSpeedConstant is inert in the base (m_InverseSpeed is initialized to −1 at itkFastMarchingBase.hxx:32 and never recomputed), though that path is shadowed whenever an input image is set.

B39 — ScalarToRGBColormap / ColormapFunction: NumericTraits::min() used as a "most negative" seed for float pixels

Shared root cause in two places — NumericTraits<float/double>::min() is the smallest positive normalized value, not the most negative:

1. itkScalarToRGBColormapImageFilter.hxx:74-75 seeds the extrema scan with maximumValue = NumericTraits<InputImagePixelType>::min(), so with UseInputImageExtremaForScaling (the default) an all-non-positive float image never updates the maximum: [-10, -5, -1] rescales -1.0 to ≈ 0.9 instead of 1.0.
2. With the flag off, itkColormapFunction.h:78-80 defaults m_MinimumInputValue to min() and m_MaximumInputValue to max(), giving RescaleInputValue (:96-99) a ≈ FLT_MAX denominator that collapses realistic-magnitude float pixels to color 0.

Integer pixel types are unaffected (min() is the most negative there), which is presumably how the pattern survived.

B40 — MergeLabelMapFilter (KEEP): collision-deferred objects are pushed again on the next input, aliasing one object under two labels

itkMergeLabelMapFilter.hxx:73-110: VectorType labelObjects; (a std::deque) is declared outside the per-input loop (:74), while the drain loop that empties it sits inside (:104-109) and never clears it. With three or more inputs, an object deferred on a label collision while merging input 1 is pushed a second time while merging input 2: PushLabelObject calls SetLabel(L2) on the object already stored at key L1 and inserts the same LabelObject* at key L2 (itkLabelMap.hxx:373 is an unconditional container[label] = obj). The container then holds two keys aliasing one object; GetNumberOfLabelObjects() counts both, and LabelMapToLabelImageFilter paints the object twice — at L2 each time — so L1 never appears in the output image.

B41 — LabelMapContourOverlayImageFilter: SLICE_CONTOUR slice-radius loop tests the wrong variable — SliceDimension 0 draws nothing

itkLabelMapContourOverlayImageFilter.hxx:155-163:

RadiusType srad{};
for (unsigned int i = 0, j = 0; i < ImageDimension; ++i)
{
  if (j != static_cast<unsigned int>(m_SliceDimension) && (j < (ImageDimension - 1)))
  {
    srad[j] = m_ContourThickness[i];
    ++j;
  }
}

The guard tests the write cursor j against m_SliceDimension where it means the read index i. For m_SliceDimension == 0 the condition is false on the first iteration, j never advances, and srad stays all-zero — the Ball(0) erosion is the identity and the dilate − erode subtraction yields an empty contour: nothing is drawn at all. For m_SliceDimension == 1 in 3-D the radius comes out (thickness[0], 0) instead of (thickness[0], thickness[2]). Only ITK's own default m_SliceDimension == ImageDimension − 1 is correct, by coincidence of j == i until the last axis.

B42 — LabelMapMaskImageFilter: empty object set under Crop builds a garbage image (UB)

The crop bounding-box loops seed mins with NumericTraits<IndexValueType>::max() and maxs with NonpositiveMin() (itkLabelMapMaskImageFilter.hxx:108-109 / :169-170) and never guard a zero-line object set, in which case the loop body never runs and:

regionSize[i] = maxs[i] - mins[i] + 1;   // NonpositiveMin - max + 1: signed overflow (UB), in practice 2

ImageRegion::Crop then finds no intersection and returns false without touching the region, and the filter allocates a 2×2 image at index 2⁶³−1 with a nonsense origin. Reachable two ways: an empty map with Negated && label == background, and a zero-line object with !Negated && label != background — the latter is exactly what AttributeUniqueLabelMapFilter produces via B43.

B43 — AttributeUniqueLabelMapFilter: the "remove objects without lines" pass never executes

itkAttributeUniqueLabelMapFilter.hxx:237-239:

// remove objects without lines
typename ImageType::Iterator it(this->GetLabelMap());
while (it.IsAtEnd())

The condition is inverted (IsAtEnd() where it means !IsAtEnd()), so the loop body never runs and an object whose every pixel was claimed by a higher-priority object survives in the map with zero lines, inflating GetNumberOfLabelObjects() — and feeding the B42 crop path. LabelUniqueLabelMapFilter inherits this GenerateData.

B44 — LabelMap::PushLabelObject: full label range silently overwrites instead of throwing

itkLabelMap.hxx:414-433 (the last-resort gap scan):

LabelType label = firstLabel;
for (it = begin(); it != end(); ++it, ++label)
{
  if (label == m_BackgroundValue) ++label;
  if (label != it->first) { labelObject->SetLabel(label); break; }
}
if (label == lastLabel)
  itkExceptionStringMacro("Can't push the label object: the label map is full.");

On a contiguous, completely full label range label != it->first never fires, so SetLabel is skipped — and the loop leaves label == lastLabel + 1, so the label == lastLabel "map full" test is false too. AddLabelObject then does container[label] = obj at the object's existing label, silently overwriting that entry instead of throwing. Reachability is narrow (the whole label type range must be in use — practical for 8-bit label types), but the intended exception is unreachable exactly when it is needed.

B45 — StatisticsLabelMapFilter: weighted elongation/flatness NaN on an indefinite weighted covariance

itkStatisticsLabelMapFilter.hxx:233-237, 261-267 diverges from ShapeLabelMapFilter in three ways:

for (unsigned int i = 0; i < ImageDimension; ++i)
  principalMoments[i] = pm(i);            // no std::max(pm(i), 0.0) clamp (Shape has it, :315)
...
else if (Math::NotAlmostEquals(principalMoments[0], VectorType::ValueType{}))  // one guard for both ratios
{
  elongation = std::sqrt(principalMoments[ImageDimension - 1] / principalMoments[ImageDimension - 2]);
  flatness   = std::sqrt(principalMoments[1] / principalMoments[0]);   // no if (ratio > 0) (Shape: :348/:357)
}

The weighted central moments are normalized by the intensity sum, so a signed/float feature image can make the weighted covariance indefinite — a negative eigenvalue then reaches std::sqrt (NaN) or sits unguarded in the elongation denominator, where ShapeLabelMapFilter's clamp + per-ratio guards return 0.

B46 — NormalizedCorrelationImageFilter: unguarded divisions → NaN for constant templates and flat neighborhoods

itkNormalizedCorrelationImageFilter.hxx never guards either division:

const double k = std * std::sqrt(num - 1.0);   // :122 — exactly 0 for a constant template
...
*ntIt = (*tIt - mean) / k;                     // :130 — 0.0/0.0 = NaN in every coefficient
...
OutputPixelRealType denominator = std::sqrt(sumOfSquares - (sum * sum / realTemplateSize));  // :190
it.Value() = numerator / denominator;          // :192 (and :226-228 for the boundary faces)

A constant-valued TemplateImage makes k exactly 0.0, so every normalized template coefficient is NaN and the NaN propagates to the whole output. A locally-constant image neighborhood makes the per-pixel denominator exactly 0.0 too — and since the mean-centered template coefficients sum to exactly 0.0 by construction, the numerator there is also ≈ 0.0, so the quotient is NaN rather than ±∞.

Quirks / doc

#	Site	Finding
Q38	FastMarchingImageFilterBase::IsChangeWellComposed3D	builds its neighborhood iterator over GetRequestedRegion() (empty, never set) where the 2-D sibling and the strict-topology check use GetBufferedRegion() — harmless (only SetLocation+GetPixel are used) but inconsistent (.hxx:779 vs :583/:619)
Q39	LabelToRGBImageFilter	background is always fixed black (m_BackgroundColor zero-filled at construction); the functor comment promising a "gray pixel matching the background intensity" describes LabelOverlayFunctor, not this class (itkLabelToRGBFunctor.h:93-98)
Q40	LabelToRGB/LabelOverlay palette	the 0–255 palette constants are rescaled by NumericTraits<output RGB component>::max() rather than a fixed 255 (itkLabelToRGBFunctor.h:110-117) — a double RGB output scales the palette into [0, ≈1.8e308]
Q41	HessianToObjectnessMeasureImageFilter	eigenvalues are sorted by |λ| with unstable std::sort (equal-magnitude order unspecified, .hxx:78-79); alpha == 0 skips only the R_A factor while beta == 0 (or a zero denominator) zeroes the whole measure (.hxx:111-151) — asymmetric parameter semantics
Q42	ComplexToModulusImageFilter	computes sqrt(re*re + im*im) in the component type (.h:46-50): ComplexFloat32 overflows to inf above |component| ≈ 1.8e19 and flushes to 0 near denormals, where std::hypot would not
Q43	RelabelLabelMapFilter	class doc says objects are reassigned via PushLabelObject; the inherited implementation uses SetLabel + AddLabelObject against a counter from 0 (itkAttributeRelabelLabelMapFilter.hxx:64-79)
Q44	LabelMap::HasLabel	doc says the background label also returns true; the implementation is a plain find(label) != end(), which returns false for background (.hxx:151-153)
Q45	StatisticsLabelMapFilter weighted moments	adds spacing²/12 (the pixel's own second moment) to every central-moment diagonal (.hxx:224-228) while ShapeLabelMapFilter does not — WeightedPrincipalMoments exceed PrincipalMoments by 1/12 per eigenvalue even on a constant feature image
Q46	StatisticsLabelMapFilter extremum indices	min/max index updates are non-strict (v <= min, v >= max, .hxx:118-127) — on ties the recorded index is the last tie in raster order
Q47	itk::Statistics::Histogram::Initialize	computes the bin interval and every non-final bin bound in float (itkHistogram.hxx:225-236) — a Histogram<double> gets float-quantized bin edges, which StatisticsLabelMapFilter's Median inherits
Q48	ImageBase::IsCongruentImageGeometry	scales the coordinate tolerance by this->GetSpacing()[0] only (itkImageBase.hxx:400-405) — the predicate is asymmetric when the two images differ in axis-0 spacing, and axes 1+ are judged against axis 0's scale
Q49	DivideImageFilter::Div	a near-zero divisor returns NumericTraits<TOutput>::max() regardless of the numerator's sign or magnitude (itkArithmeticOpsFunctors.h:142-151); through NormalizeToConstantImageFilter a zero-sum input sends the entire output to the type maximum
Q50	VotingBinaryHoleFillingImageFilter	the else-branch stamps it.Set(foregroundValue) for any center value other than backgroundValue (.hxx:138-141) — a third pixel value is silently promoted to foreground without counting toward GetNumberOfPixelsChanged(); the iterative sibling inherits this
Q51	ExtractImageFilter	the output origin ignores a collapsed axis's start index (and the collapsed↔retained direction coupling), so extracting slice k of an oblique volume reports slice 0's origin (.hxx:74-85, :162-179)
Q52	CenteredVersorTransformInitializer::ComputeRotation	uses R = M·Fᵀ (.hxx:47), which does not satisfy the covariance-aligning identity R·Cov_f·Rᵀ = Cov_m (that requires Mᵀ·F); with per-image independent eigenvector sign canonicalization the initializer can 180°-flip an axis
Q53	CompositeTransform	Get/SetParameters, Get/SetFixedParameters, and UpdateTransformParameters all flatten sub-transforms in reverse queue order (last-added first, .hxx:613,665-687,703,734,847) while GetNthTransform(n) indexes forward — two orderings in one class
Q54	FFTPadImageFilter	SizeGreatestPrimeFactor == 1 pads each axis to an even size (.hxx:64-68) while the class doc says "1 or less … disable the extra padding" (.h:90) — only 0 disables
Q55	MaskedFFTNormalizedCorrelationImageFilter	pads FFT sizes using only factors 2/3/5 (.hxx:528-545) while FFTConvolutionImageFilter uses the backend's greatest prime factor (11 under PocketFFT) — identical inputs get different padded sizes across the two FFT-based filters
Q56	RegistrationParameterScalesFromIndexShift	the step scale is computed in continuous-index (voxel) units while MaximumStepSizeInPhysicalUnits defaults to the minimum virtual spacing (mm) — the gradient-descent learning rate divides mm by voxels, dimensionally mixed on anisotropic spacing (.hxx:66-79; itkGradientDescentOptimizerv4.hxx:272)
Q57	RegistrationParameterScalesEstimator CentralRegionRadius	consulted only by CentralRegionSampling, which is selected only for displacement-field/B-spline transforms (.hxx:346-367, :203-211); linear/affine transforms take Corner/Random sampling and never read it, and for displacement fields the scales estimate is radius-independent
Q58	ObjectToObjectOptimizerBase weights	optimizer weights within 1e-4 of 1.0 are flagged identity and never multiplied into the gradient (strict >, so exactly 1e-4 is also discarded, itkObjectToObjectOptimizerBase.cxx:154-164); the sibling scales-identity test uses a 100× looser 0.01
Q59	v4 optimizer weights application	every v4 optimizer validates the weights-array length in the base StartOptimization, but the vnl-based LBFGS/LBFGSB and Amoeba optimizers then apply only scales and silently ignore well-sized weights (itkSingleValuedNonLinearVnlOptimizerv4.cxx:53-58); LBFGS2Optimizerv4, by contrast, does apply them

(Same AI-assistance disclosure as the issue body applies to this comment; this batch was re-verified against main at 812d7a89f3.)

[physwkim]

A fifth batch, from porting the image/transform IO layer (NIfTI, GIPL, VTK, MetaIO, NrrdIO, legacy-txt/HDF5 transform IO). Same methodology and caveats — source-level reading, each item independently re-verified with a refutation-oriented pass against current main at 812d7a89f3, no runtime reproduction. Numbering continues (B47–B69, Q60–Q89).

Several items live in vendored third-party code (Modules/ThirdParty/{MetaIO,NrrdIO,NIFTI}) — marked (vendored) below. They are reported here because ITK ships and executes this code; happy to forward them to the respective upstreams instead if that is preferred.

A recurring theme worth calling out: four of the five readers report success on truncated pixel data (B54/B55 GIPL, B57 VTK, B64 MetaIO-LIST, B65/B66 MetaIO-compressed), each through a different mechanism, and each leaves ITK's freshly-allocated pixel buffer partly uninitialized — an indeterminate-value read (UB) presented as a successful load.

Bugs

#	Site	Finding
B47	TransformIOBaseTemplate::CorrectTransformPrecisionType	find("float") result used unchecked — a transform-type string naming neither precision throws std::out_of_range past every ITK handler
B48	NiftiImageIO::Read	rescale cast buffer sized per voxel, consumed per component — heap over-read for any multi-component image with scl_slope/scl_inter
B49	NiftiImageIO::Read	RescaleFunction is given the voxel count — only the first numElts of a multi-component/complex buffer are rescaled
B50	NiftiImageIO::Read	RAS↔LPS conversion never checks the 3-component requirement its own exception text names — 2/4-component vectors get a stride-3 sign flip across voxel boundaries
B51	NiftiImageIO	spatial-dimension inference for intent-vector images never consults dim[1] — a 2-D vector image one row tall reads back as 1-D
B52	niftilib nifti_read_buffer (vendored)	maps every non-finite float/double/complex component to 0 on read wherever isfinite is a macro (glibc: always) — NaN/±Inf pixels silently destroyed
B53	GiplImageIO::Write	INT/UINT images throw "Pixel Type Unknown" only after the target file has been truncated and the header written — destroys existing data, leaves a 256-byte stub
B54	GiplImageIO::Read	success test is !bad(); a short pixel block sets failbit/eofbit, never badbit — truncated file reads as success over an uninitialized tail
B55	GiplImageIO::Read (compressed)	success flag is p != nullptr on the caller's always-non-null output buffer — gzread's byte count is never inspected
B56	GiplImageIO::Write	header image_type is derived from the component type alone while the byte count multiplies by components — a vector image writes a scalar header plus N× the bytes, reading back as garbage
B57	VTKImageIO::Read	ReadBufferAsBinary's bool (false on short read) is discarded — truncated BINARY file reads as success
B58	VTKImageIO::InternalReadImageInformation	every sscanf return is discarded over uninitialized locals — an under-filled DIMENSIONS/SPACING/ORIGIN line sizes the image from indeterminate values (UB)
B59	VTKImageIO::InternalReadImageInformation	attribute dispatch is an ordered substring test — SCALARS vector_field float matches the vector arm and is misparsed as a 3-component VECTORS line
B60	VTKImageIO ASCII write	precision(16) is set on a throwaway header stream; pixel data is emitted through a second stream at the default 6 significant digits — silent precision loss
B61	ImageIOBase::ReadBuffer (ASCII)	extraction variable declared outside the loop, stream state never checked — one bad/overflowing field latches into every later component (5 99999 7 8 as short reads [5, 32767, 32767, 32767])
B62	VTKImageIO::CanReadFile	four GetNextLine calls outside the try block — a .vtk shorter than four lines throws "Premature EOF" through the factory instead of returning false
B63	NrrdImageIO::Write metadata dispatch	NRRD_-prefixed keys are matched by strncmp of the candidate's length — NRRD_space directions is swallowed by the space handler, and unmatched NRRD_ keys (including the reader's own NRRD_pixel_original_axis) are silently dropped
B64	MetaIO ElementDataFile = LIST (vendored)	three unguarded paths: short slice list → success with uninitialized tail; negative file dimension → m_DimSize[-1]/m_SubQuantity[-1] OOB reads; == NDims → zero-length slice reads, still success
B65	MetaIO M_ReadElements (vendored)	a LOCAL compressed header without CompressedDataSize seeks to file start and inflates its own header text over the uninitialized pixel buffer — success, garbage pixels
B66	MetaIO MET_PerformUncompression (vendored)	unconditionally return true — truncated/corrupt/wrong-container streams and short output all report success
B67	NrrdIO per-axis field parsers (vendored)	sizes/spacings/thicknesses/axis mins/axis maxs parse dim + 1 values into a NRRD_DIM_MAX(16)-element stack array — a 16-D header with a 17th token is a stack buffer overflow
B68	NrrdIO nrrdOriginCalculate (vendored)	the gotMin loop tests axis[0]->min for every axis (literal 0, not the loop variable) — origins computed from NaN mins, or usable mins ignored
B69	NrrdIO rnParse_kinds (vendored)	the none token arm assigns the axis's centering, not its kind — kinds: none … clobbers a previously parsed centers: value

B47 — TransformIOBaseTemplate::CorrectTransformPrecisionType: unchecked find() → std::out_of_range escapes the reader

itkTransformIOBase.h:199-207 (the double specialization; the float one at :187-195 is symmetric):

inline void
TransformIOBaseTemplate<double>::CorrectTransformPrecisionType(std::string & inputTransformName)
{
  if (inputTransformName.find("double") == std::string::npos)
  {
    const std::string::size_type begin = inputTransformName.find("float");
    inputTransformName.replace(begin, 5, "double");
  }
}

begin is never checked against npos. An #Insight Transform File whose Transform: line names neither precision — e.g. the ITKv3-era TranslationTransform_2_2 — reaches std::string::replace(npos, 5, …), which throws std::out_of_range out of TxtTransformIO::Read (itkTxtTransformIO.cxx:171). That is a std:: exception, not an itk::ExceptionObject, so it sails past every ITK exception handler. The two-branch structure shows the missing-double case was considered; the case where the name also lacks float was not.

B48 — NiftiImageIO::Read: rescale cast buffer sized per voxel, consumed per component (heap over-read)

itkNiftiImageIO.cxx:382,386:

pixelSize = static_cast<unsigned int>(this->GetNumberOfComponents()) * static_cast<unsigned int>(sizeof(float));
auto * _data = static_cast<float *>(malloc(numElts * sizeof(float)));

numElts is the voxel count (product of the spatial IO-region sizes), but the de-interleave/copy below (:442-443, :489-495) consumes pixelSize = numComponents · sizeof(float) bytes per voxel out of that buffer. ReadImageInformation promotes any integer on-disk type to FLOAT whenever MustRescale() holds (:1007-1016), so for any multi-component image with a non-trivial scl_slope/scl_inter — RGB24, RGBA32, integer NIFTI_INTENT_VECTOR/DISPVECT — the copy reads numComponents× past the allocation. The CastCopy above it also converted only the first numElts values, so even the in-bounds prefix is component-major garbage. C++ heap over-read, reachable from any such file.

B49 — NiftiImageIO::Read: RescaleFunction is given the voxel count, not the component count

itkNiftiImageIO.cxx:514-561 — every arm of the switch passes numElts:

case IOComponentEnum::FLOAT:
  RescaleFunction(static_cast<float *>(buffer), this->m_RescaleSlope, this->m_RescaleIntercept, numElts);

numElts is the product of the spatial sizes, so for any image with more than one component per voxel — including COMPLEX64, whose buffer holds 2·numElts floats — only the first numElts values are rescaled and the tail keeps its raw on-disk values. Memory-safe, silently wrong.

B50 — NiftiImageIO::Read: RAS↔LPS conversion never checks the component count its own exception names

itkNiftiImageIO.cxx:566-574:

if (this->GetPixelType() != IOPixelEnum::VECTOR && this->GetPixelType() != IOPixelEnum::POINT)
{
  itkExceptionMacro("RAS conversion requires pixel to be 3-component vector or point. ...");
}
    ConvertRASToFromLPS_CXYZT(static_cast<float *>(buffer), numElts * numComponents);

The guard tests only the pixel type, never numComponents == 3. ConvertRASToFromLPS_CXYZT (:265-274) walks size / 3 strides of 3 over the component-interleaved buffer, so a 2- or 4-component NIFTI_INTENT_VECTOR/DISPVECT image (with SetConvertRASVectors enabled) has the sign pattern applied across voxel boundaries — in-bounds (the stride count truncates), silently wrong.

B51 — NiftiImageIO: vector-image dimension inference never consults dim[1]

itkNiftiImageIO.cxx:789-804 (intent-vector branch):

if (m_Holder->ptr->dim[4] > 1)      { this->SetNumberOfDimensions(4); }
else if (m_Holder->ptr->dim[3] > 1) { this->SetNumberOfDimensions(3); }
else if (m_Holder->ptr->dim[2] > 1) { this->SetNumberOfDimensions(2); }
else                                { this->SetNumberOfDimensions(1); }

dim[0]/dim[1] are never read, so a 2-D vector image one row tall (nx = 4, ny = 1) reads back as 1-D — wrong dimensionality and geometry. The scalar path beside it (:820-824, marked HACK ALERT KW) trims trailing size-1 axes only while realdim > 3, so a 4-D scalar with nt == 1 collapses to 3-D but a 3-D volume with nz == 1 stays 3-D — asymmetric, but at least in-bounds; the vector branch's dim[1] omission is the outright defect.

B52 — niftilib (vendored): non-finite pixels silently zeroed on read wherever isfinite is a macro

Modules/ThirdParty/NIFTI/src/nifti/niftilib/nifti1_io.c:5036-5072, in nifti_read_buffer:

#ifdef isfinite
...
case NIFTI_TYPE_FLOAT32:
case NIFTI_TYPE_COMPLEX64:{
    float *far = (float *)dataptr ; size_t jj,nj ;
    nj = ntot / sizeof(float) ;
    for( jj=0 ; jj < nj ; jj++ )
       if( !IS_GOOD_FLOAT(far[jj]) ){
          far[jj] = 0 ;
          fix_count++ ;

IS_GOOD_FLOAT(x) is isfinite(x) whenever isfinite is defined as a macro (nifti1_io.h:560-568) — which glibc's <math.h> always does — so on Linux every NaN/±Inf FLOAT32/FLOAT64/COMPLEX64/COMPLEX128 component is replaced by 0 during Read, with no error and no metadata trace. Platform-dependent silent data corruption: the same file preserves its NaNs on a platform where isfinite is only a function.

B53 — GiplImageIO::Write: int32 images throw only after the target file has been destroyed

SwapBytesIfNecessary (itkGiplImageIO.cxx:590-652) has arms for SCHAR/UCHAR/SHORT/USHORT/FLOAT/DOUBLE; INT and UINT hit the default: that throws "Pixel Type Unknown" (:648-651). Write reaches it (:1024, the byte-order default is BigEndian, set in the constructor at :78) after OpenFileForWriting has truncated the target and the 256-byte header is on disk. The read-side type table (:348-353) maps GIPL_INT/GIPL_U_INT to exactly those two component types, so the format claims a type the class cannot move in either direction. Net effect: WriteImage(int32Image, "x.gipl") destroys any existing x.gipl and leaves a 256-byte stub.

B54 — GiplImageIO::Read: short pixel read reported as success (uninitialized buffer tail)

itkGiplImageIO.cxx:214-227:

m_Ifstream.read(p, static_cast<std::streamsize>(this->GetImageSizeInBytes()));
...
success = !m_Ifstream.bad();

A pixel block shorter than GetImageSizeInBytes() sets failbit and eofbit, never badbit, so Read returns normally and the untouched tail of ITK's freshly-allocated buffer is handed to the caller — an indeterminate-value read (UB).

B55 — GiplImageIO::Read (compressed): the success check tests the output pointer, not the byte count

itkGiplImageIO.cxx:210-223:

gzread(m_Internal->m_GzFile, p, static_cast<unsigned int>(this->GetImageSizeInBytes()));
...
if (m_IsCompressed)
{
  success = p != nullptr;
}

p is the caller-supplied output buffer, which ImageFileReader always allocates non-null — the check is vacuously true and gzread's return value is never inspected. A truncated .gipl.gz (short decompressed stream) and a corrupt one (gzread fails outright) both report success over the untouched buffer tail — worse than the uncompressed arm, which at least tests badbit.

B56 — GiplImageIO::Write: multi-component images write a scalar header plus N× the bytes

The header image_type switch keys only on m_ComponentType (itkGiplImageIO.cxx:732-761) and never encodes m_NumberOfComponents, while the pixel stream writes GetImageSizeInBytes() (:1002), which does multiply by the component count. CanWriteFile (:177-196) only checks the extension, so a 3-component VectorUInt8 image is accepted, written as a GIPL_U_CHAR scalar header followed by 3× the header-implied bytes, and reads back as a scalar image holding the first numPixels components with the rest silently dropped.

B57 — VTKImageIO::Read: ReadBufferAsBinary's result discarded — truncated BINARY file reads as success

itkVTKImageIO.cxx:598:

this->ReadBufferAsBinary(file, buffer, this->GetImageSizeInBytes());

ReadBufferAsBinary returns false when it read fewer bytes than asked (itkStreamingImageIOBase.cxx:125-130, gcount() != bytesToRead), but the call is not inside any check and the next statement byte-swaps. A truncated BINARY structured-points file therefore reads as success with an uninitialized buffer tail.

B58 — VTKImageIO::InternalReadImageInformation: sscanf returns discarded over uninitialized locals (UB)

itkVTKImageIO.cxx:208-210:

unsigned int dims[3];
sscanf(text.c_str(), "%*s %u %u %u", dims, dims + 1, dims + 2);
if (dims[1] <= 1 && dims[2] <= 1)

A DIMENSIONS 4 line fills only dims[0]; dims[1]/dims[2] are then read indeterminate and used to size the image. The SPACING (:238-247) and ORIGIN (:252-261) scans have the same shape over uninitialized double spacing[3] / double origin[3] locals, so an under-filled SPACING 2.0 line stores indeterminate values via SetSpacing as well.

B59 — VTKImageIO: attribute dispatch by ordered substring test misparses array names

itkVTKImageIO.cxx:236-352 — the header loop lowercases each line and dispatches with ordered find() substring tests, vector (:264) before scalars (:311):

else if (text.find("vector") < text.length())
...
else if (text.find("scalars") < text.length())

A legal line SCALARS vector_field float contains vector, so it takes the VECTORS arm: 3 components, the type token read from the wrong field, no LOOKUP_TABLE handling. The array name — free-form per the VTK legacy format — silently changes how the file parses. (color_scalars is tested before scalars for the same containment reason and happens to be ordered correctly.)

B60 — VTKImageIO: ASCII pixel data written at default 6-digit precision

WriteImageInformation sets file.precision(16) on its local header stream (itkVTKImageIO.cxx:641-668), which is destroyed at scope end. Write then opens a fresh stream (:996-1014), seeks past the header, and calls WriteBufferAsASCII with no precision() call — so float/double ASCII pixels are written at the ostream default of 6 significant digits. Round-tripping an ASCII .vtk silently loses up to 10 significant digits of double data.

B61 — ImageIOBase::ReadBuffer (ASCII): one bad field latches into every later component

itkImageIOBase.cxx:804-811:

using PrintType = typename itk::NumericTraits<TComponent>::PrintType;
PrintType    temp;
TComponent * ptr = buffer;
for (ImageIOBase::SizeType i = 0; i < num; i++, ptr++)
{
  is >> temp;
  *ptr = static_cast<TComponent>(temp);
}

temp outlives the loop and the stream state is never checked. Reading 5 99999 7 8 into short stores 5, then the overflowing extraction sets temp = SHRT_MAX and failbit; every subsequent is >> temp is a no-op on the failed stream, so the loop stores 32767 into every remaining component: [5, 32767, 32767, 32767], reported as success. A short/absent ASCII block zero-fills the same way. The caller (VTKImageIO::Read, :587) never inspects the stream either.

B62 — VTKImageIO::CanReadFile throws instead of returning false on short files

itkVTKImageIO.cxx:84-104: the try block wraps only OpenFileForReading; the four GetNextLine calls after it (:93-97) are unprotected, and GetNextLine throws "Premature EOF" (:55) when the file ends. ImageIOFactory::CreateImageIO calls CanReadFile with no try (itkImageIOFactory.cxx:84, :102), so probing a .vtk file shorter than four lines throws out of the factory instead of the reader reporting "could not create IO object". (Also: fname is overwritten by each call, so only the fourth line is actually validated.)

B63 — NrrdImageIO::Write: NRRD_ metadata keys dispatched by prefix strncmp — mis-routed or silently dropped

itkNrrdImageIO.cxx:296-298:

const char * const name = airEnumStr(nrrdField, rf.fieldEnum);
const std::size_t  nameLen = std::strlen(name);
if (std::strncmp(keyField, name, nameLen) != 0)

The comparison uses the candidate field name's length, i.e. a prefix test: the dictionary key NRRD_space directions matches the space handler ("space" is a prefix of "space directions") and is consumed as a scalar space field. And the Write loop (:1378-1383) routes every NRRD_-prefixed key into this dispatcher and ignores its boolean result, so an NRRD_ key that matches nothing — including NRRD_pixel_original_axis, which ITK's own reader emits (:1004) — is silently dropped on a read→write round trip rather than being written back or preserved as a key/value pair.

B64 — MetaIO (vendored): ElementDataFile = LIST — three unguarded failure paths, all reported as success

metaImage.cxx:1318-1388 reads totalFiles slice names and copies each slice into m_ElementData. Three defects:

1. The loop condition is i < totalFiles && !_stream->eof() (:1349): a header listing fewer slice names than totalFiles exits the loop and returns success, leaving the tail of the freshly new-ed pixel buffer uninitialized.
2. The optional file dimension is guarded only by if ((fileImageDim == 0) || (fileImageDim > m_NDims)) (:1333). A negative value passes; for (i = m_NDims; i > fileImageDim; i--) totalFiles *= m_DimSize[i - 1]; (:1345) then reads m_DimSize[-1], and the slice copy indexes m_SubQuantity[-1] (:1376-1377) — out-of-bounds reads.
3. fileImageDim == m_NDims also passes and indexes m_SubQuantity[m_NDims], which InitializeEssential never fills (:522-528 fills 0..m_NDims-1 of a std::streamoff[10]) — 0 on a fresh object, or a stale count from a previous higher-dimensional read on a reused IO; each slice then reads that many elements and the buffer is left wholly or partly uninitialized, still returning success.

B65 — MetaIO (vendored): LOCAL compressed header without CompressedDataSize inflates its own header text over the pixel buffer

metaImage.cxx:2616-2621:

if (m_CompressedDataSize == 0)
{
  compressedDataDeterminedFromFile = true;
  _fstream->seekg(0, std::ios::end);
  m_CompressedDataSize = _fstream->tellg();
  _fstream->seekg(0, std::ios::beg);
}

For a detached .zraw the whole-file guess is right. For a LOCAL .mha the stream is the header file, so the seek rewinds past the header just parsed, M_ReadElementData swallows filesize bytes of "ObjectType = Image\n…", and MET_PerformUncompression (B66) reports success without writing a byte of the destination — which MetaImage::Read handed it straight from new char[m_Quantity]. The caller then reads uninitialized heap as pixels. The writer has the same asymmetry: CompressedDataSize is emitted only when > 0 (metaObject.cxx:1427-1430), which is false exactly for the %d slice-template form — MetaIO can write the very header it cannot read. (Secondary: the field is declared MET_ULONG_LONG but stored through a double[] field record (metaObject.cxx:1250, :1602), so sizes above 2⁵³ do not round-trip.)

B66 — MetaIO (vendored): MET_PerformUncompression returns true on every inflate failure

metaUtils.cxx:879-892:

err = inflate(&d_stream, Z_NO_FLUSH);
if (err == Z_STREAM_END || err < 0)
{
  if (err != Z_STREAM_END && err != Z_BUF_ERROR)
  {
    std::cerr << "Uncompress failed" << '\n';
  }
  break;
}
...
inflateEnd(&d_stream);
return true;

inflate's return code decides only whether to print to std::cerr and break; the function then unconditionally returns true. A truncated, corrupt, or wrong-container stream leaves the caller's buffer partly or wholly unwritten while every caller (metaImage.cxx:2632 and siblings) treats the read as successful. Short output is equally silent — the loop exits on Z_STREAM_END without checking that the destination was filled.

B67 — NrrdIO (vendored): per-axis field parsers overflow a 16-element stack array at dim == 16

rnParse_sizes, rnParse_spacings, rnParse_thicknesses, rnParse_axis_mins, and rnParse_axis_maxs (parseNrrd.c:267-393) each declare a NRRD_DIM_MAX-long stack array (NRRD_DIM_MAX == 16, NrrdIO.h:636) and then parse nrrd->dim + 1 values into it — purely to detect "too many values" by testing whether the (dim+1)-th parse succeeded:

size_t val[NRRD_DIM_MAX];
...
if (nrrd->dim + 1 == airParseStrZ(val, info, nrrd__FieldSep, nrrd->dim + 1)) {

airParseStr* writes out[i] for every i < n (parseAir.c:186-193), and dim == 16 is accepted (AIR_IN_CL(1, dim, NRRD_DIM_MAX), closed interval, simple.c:968) — so a 16-dimensional NRRD whose sizes: line supplies a 17th token writes one element past the array. Stack buffer overflow, reachable from any untrusted .nrrd/.nhdr; the parser's own return count is what gets compared, so the overflowing write is not even needed for the check.

B68 — NrrdIO (vendored): nrrdOriginCalculate tests axis 0's min for every axis

simple.c:272-274:

gotMin = AIR_TRUE;
for (ai = 0; ai < axisIdxNum; ai++) {
  gotMin &= AIR_EXISTS(axis[0]->min);

The subscript is the literal 0, not the loop variable — the sibling gotMaxOrSpacing loop immediately below correctly uses axis[ai]. A header whose first axis has an axis min while later axes do not still reports nrrdOriginStatusOkay and computes the origin from NaN mins on those axes; conversely axis mins: nan 0 0 reports NoMin and ITK silently leaves the origin at zero despite usable mins on axes 1–2. Reached only when the header has no space/space directions (itkNrrdImageIO.cxx:902).

B69 — NrrdIO (vendored): `kinds: none` writes the axis's centering, not its kind

parseNrrd.c:621-623, in rnParse_kinds:

if (!strcmp(tok, NRRD_NONE)) {
  nrrd->axis[ai].center = nrrdKindUnknown;
  continue;

The none arm assigns .center (with a kind-enum constant, both enums' unknown being 0) instead of .kind — an apparent copy-paste from rnParse_centers (:571-573, where the same line is correct). The axis's kind is left at whatever it already held, and a centering previously parsed from a centers: line is clobbered back to unknown: centers: cell cell followed by kinds: none domain loses axis 0's cell centering.

Quirks / doc

#	Site	Finding
Q60	NiftiImageIO	ITK_InputFilterName is encapsulated (:1102) and then wiped six lines later by SetImageIOMetadataFromNIfTI, whose first act is thisDic.Clear() (:630)
Q61	NiftiImageIO	the "original file was non-orthogonal" warning is dead: stored under ITK_sform_corrected (:632), looked up under nifti_sform_corrected (:2038)
Q62	NiftiImageIO	getQFormCodeFromDictionary/getSFormCodeFromDictionary results are unconditionally overwritten with NIFTI_XFORM_SCANNER_ANAT (:2077-2078) — yet their StringToInt32 still throws on a non-numeric dictionary value that would have been discarded anyway
Q63	NiftiImageIO	IMG.NII passes CanWriteFile (extension check lowercases) but WriteImageInformation compares the raw uppercase extension against lowercase spellings only and throws "Bad Nifti file name" (:1173-1202)
Q64	niftilib (vendored)	a magic-less (Analyze-7.5) header in a single .nii reports nifti_type == 1: convert_nhdr2nim sets ANALYZE, then nifti_set_type_from_names forces NIFTI1_1 whenever fname == iname — true for every single-file case (nifti1_io.c:3730, :3453-3454)
Q65	GiplImageIO	the magic number is validated only in CanReadFile; ReadImageInformation re-reads the same 4 bytes and discards them, so a file supplied via SetImageIO gets no magic check (:566-584)
Q66	GiplImageIO	NDims is a population count of non-trivial dims — a 2-D image round-trips as 3-D [nx, ny, 1], and malformed dims like [4, 0, 5, 1] give NDims == 2 with the 5 silently dropped (:294-312)
Q67	GiplImageIO	image_type is byte-swapped only in the BigEndian arm and min/max are never swapped — unobservable, since the constructor pins BigEndian and all these header fields are read then discarded (:78, :325-328, :443-461)
Q68	GiplImageIO	registers no read/write extensions (constructor omits AddSupported*Extension) and its real gate is a case-sensitive suffix test — IMAGE.GIPL is not recognized (:1079-1090)
Q69	GiplImageIO	the compressed path uses gzopen/gzread throughout, which transparently pass through a non-gzip stream — a .gipl.gz containing a plain GIPL file is accepted and read verbatim
Q70	VTKImageIO::GetNextLine	tolerates 5 consecutive empty lines and throws on the 6th, while its message says "consecutive 5 empty lines" — off by one from its own text (:44-46)
Q71	VTKImageIO::GetNextLine	tests eof() before using the line, so a header whose final line lacks a trailing newline throws "Premature EOF" even though getline delivered the content (:50-56)
Q72	VTKImageIO	the 2-D/3-D test is written twice and the first copy is dead — the surviving rule is "2-D iff dims[2] <= 1", so DIMENSIONS 4 1 3 is a one-row-tall 3-D volume (:210-221)
Q73	VTKImageIO	a round-trip collapses ComplexFloat32 to a 2-component VectorFloat32, and a 1-component vector image to a scalar — the legacy format cannot express either distinction (:701-709, :311-329)
Q74	VTKImageIO	the component count is never range-checked on either side (writer carries a // todo this should be asserted, :705) — COLOR_SCALARS c 7 reads as a 7-component VectorUInt8
Q75	ImageIOBase ASCII read	is >> temp with an integer PrintType: a negative literal for an unsigned pixel type wraps rather than failing, and out-of-range 8-bit values narrow silently (−1 → 255, 300 → 44) (itkImageIOBase.cxx:804-811)
Q76	MetaImageIO	complex pixels cannot round-trip: ElementNumberOfChannels == 2 is indistinguishable from a 2-vector, and the reader forces VECTOR for any channels > 1 (itkMetaImageIO.cxx:241-244, in-source // BUG: 8732)
Q77	MetaIO (vendored)	MetaImage::CanRead re-tests the suffix case-sensitively against .mha/.mhd while the ITK factory and CanWriteFile match case-insensitively — IMG.MHA is writable but not readable (metaImage.cxx:1184-1199)
Q78	MetaIO (vendored)	booleans test only value[0] == 'T'|'t'|'1' — trash parses as true, yes as false (metaObject.cxx:1605-1642)
Q79	MetaIO (vendored)	header-alias precedence is M_Read's apply order, not file order: Origin > Position > Offset, TransformMatrix > Rotation > Orientation, BinaryDataByteOrderMSB > ElementByteOrderMSB — a trailing ElementByteOrderMSB = False loses to an earlier BinaryDataByteOrderMSB = True (metaObject.cxx:1618-1707)
Q80	MetaIO (vendored)	writes a zlib (RFC-1950) stream but reads zlib or gzip (inflateInit2(…, 47)) — the reader accepts a superset of what the writer produces (metaUtils.cxx:808, :862)
Q81	vendored gzip readers	NrrdIO's gzio and zlib's gz_look fall back to a byte-for-byte copy when the gzip magic is absent, while niftilib's nifti_is_gzfile is a pure name test — a genuine gzip stream named .nii is never inflated, and a .nii.gz holding raw bytes reads via the copy fallback (gzio.c:501-519; nifti1_io.c:2656-2668)
Q82	NrrdImageIO	only RAS/LAS/LPS are converted to LPS; every other space value (scanner-xyz, right-up, …) has its geometry used verbatim through an empty default: with no warning (itkNrrdImageIO.cxx:766-786)
Q83	NrrdIO (vendored)	data file: LIST reads filenames until EOF, so a blank line becomes an empty filename that later fails fopen("") — there is no in-band list terminator (parseNrrd.c:1347-1400)
Q84	NrrdIO (vendored)	formatNRRD_write emits comments and key/value pairs after the data file: field, defeating the writer's own "data file must be last" ordering — latent header corruption for LIST-form writes with comments (formatNRRD.c:783-857; cf. write.c:724-728)
Q85	TxtTransformIO	Parameters: lines are parsed by vnl read_ascii, which stops at the first unparseable token and reports success — Parameters: 1 2 oops 4 silently yields [1, 2] (itkTxtTransformIO.cxx:183-186)
Q86	TxtTransformIO	one transform local is reassigned per Transform: line and buffered parameters apply only once both Parameters and FixedParameters have been seen — unpaired lines bind one transform's parameters to a different transform, silently (:168-232)
Q87	TxtTransformIO	the #Insight Transform File V1.0 header is swallowed by the #-comment skip and never validated; CanReadFile checks only the .txt/.tfm extension (:148, :39-46)
Q88	TxtTransformIO	an empty FixedParameters vector writes the line FixedParameters: with a trailing space (:238-250, :303-305)
Q89	HDF5TransformIO	CanWriteFile claims .hdf/.h4/.hdf4/.he4 — HDF4 container names — though Write always creates an HDF5 file, and the lowercase extension table rejects .H5/.HDF5 (itkHDF5TransformIO.cxx:83-84, :424)

(Same AI-assistance disclosure as the issue body applies to this comment; this batch was re-verified against main at 812d7a89f3.)

[physwkim]

A sixth and final batch, closing out the IO layer: PNG, HDF5 image IO, and HDF5 transform IO. Same methodology and caveats as before — source-level reading, each item independently re-verified with a refutation-oriented pass against current main at 812d7a89f3, no runtime reproduction. Numbering continues (B70–B75, Q90–Q103).

Two of the six bugs are silent partial writes in PNGImageIO::WriteSlice (B71, B72), and two are memory-safety defects in HDF5ImageIO reachable from a hand-crafted .h5 (B73, B74).

Bugs

#	Site	Finding
B70	PNGImageIO::WriteSlice	the file is opened "wb" — truncating it — before the component-type switch whose default: throws; writing an int16 image destroys any existing .png and leaves it zero-byte
B71	PNGImageIO::WriteSlice	height comes from GetDimensions(1) alone, no axis beyond it is consulted — a 3-D image writes only its first slice, with no error
B72	PNGImageIO::WriteSlice	any component count > 4 declares 4 channels (PNG_COLOR_TYPE_RGB_ALPHA) while row pointers advance by the actual count — each row's trailing components are silently dropped
B73	HDF5ImageIO::WriteImageInformation	the C-string meta-data branch calls constCstringObj->GetMetaDataObjectValue() under a guard that admits constCstringObj == nullptr — null dereference for a MetaDataObject<char *>
B74	HDF5ImageIO::ReadImageInformation	every geometry dataset's length is taken on trust — spacing[i] / Dims[i] are indexed to numDims regardless of the file's actual dataset length, reading past the end of a heap vector before any pixel is touched
B75	HDF5ImageIO::Read	the file datatype is passed as H5Dread's memory type, making the conversion the identity — a VoxelData stored STD_I16BE is copied without a byte swap and read back byte-swapped, silently

B70 — PNGImageIO::WriteSlice: an unwritable component type throws only after the file has been truncated

itkPNGImageIO.cxx:511-515 opens the target first:

void
PNGImageIO::WriteSlice(const std::string & fileName, const void * const buffer)
{
  // use this class so return will call close
  const PNGFileWrapper pngfp(fileName.c_str(), "wb");

PNGFileWrapper's constructor is fopen(fname, "wb"), which truncates immediately. Only afterward, at :531-552, does the component-type switch run:

  switch (this->GetComponentType())
  {
    case IOComponentEnum::UCHAR:  bitDepth = 8;  break;
    case IOComponentEnum::USHORT: bitDepth = 16; break;
    default:
    {
      itk::ExceptionObject excp(__FILE__, __LINE__, "PNG supports unsigned char and unsigned short", ITK_LOCATION);
      throw excp;
    }

WriteImageInformation is empty (:501-502), so nothing checks earlier. WriteImage(int16Image, "x.png") therefore destroys an existing x.png and leaves it empty, then throws. The component type is known before a single byte is needed; the check belongs above the fopen — which is exactly where the sibling JPEGImageIO::Write puts its own (itkJPEGImageIO.cxx:459-467, both a dimension and a component-type gate, before WriteSlice opens anything).

B71 — PNGImageIO::WriteSlice: a 3-D source writes only its first slice

itkPNGImageIO.cxx:605:

  const png_uint_32 height = (m_NumberOfDimensions > 1) ? this->GetDimensions(1) : 1;

No axis beyond dim[1] is ever consulted. png_set_IHDR declares width × height, and the row-pointer loop (:686-692) builds exactly height pointers:

    const int                      rowInc = width * numComp * bitDepth / 8;
    const volatile unsigned char * outPtr = (static_cast<const unsigned char *>(buffer));
    for (unsigned int ui = 0; ui < height; ++ui)
    {
      row_pointers[ui] = const_cast<png_byte *>(outPtr);
      outPtr = const_cast<unsigned char *>(outPtr) + rowInc;
    }

png_write_image then emits the first slice's rows and stops. Every later slice in the buffer is unaddressed. No error, no warning — a 5-slice volume written to PNG silently becomes one slice. Compare JPEGImageIO::Write (itkJPEGImageIO.cxx:459-462), which rejects the same input outright:

  if (this->GetNumberOfDimensions() != 2)
  {
    itkExceptionStringMacro("JPEG Writer can only write 2-dimensional images");
  }

B72 — PNGImageIO::WriteSlice: a >4-component write drops each row's trailing components

itkPNGImageIO.cxx:597-599 — the colorType switch has arms for 1, 2 and 3 components and a default: that always picks 4:

    default:
      colorType = PNG_COLOR_TYPE_RGB_ALPHA;
      break;

So a 7-component image writes an IHDR declaring 4 channels. But the row pointers are spaced by the image's actual component count (:686):

    const int rowInc = width * numComp * bitDepth / 8;

Each row therefore starts at the correct offset, and png_write_image reads width * 4 * bitDepth / 8 bytes from it — the first four components of every pixel in the row, with the remaining numComp − 4 components' worth of bytes never written. The output is a valid RGBA PNG whose pixels are the wrong ones, produced without an error. Both numComp and the declared channel count are known at :579; a bounds check there would cost nothing.

B73 — HDF5ImageIO::WriteImageInformation: null dereference in the C-string meta-data branch

itkHDF5ImageIO.cxx:1328-1336:

        auto * cstringObj = dynamic_cast<MetaDataObject<char *> *>(metaObj);
        auto * constCstringObj = dynamic_cast<MetaDataObject<const char *> *>(metaObj);
        if (cstringObj != nullptr || constCstringObj != nullptr)
        {
          const char * val = constCstringObj->GetMetaDataObjectValue();
          if (cstringObj != nullptr)
          {
            val = cstringObj->GetMetaDataObjectValue();
          }

The guard is a disjunction, so it admits cstringObj != nullptr && constCstringObj == nullptr — a dictionary holding a MetaDataObject<char *>, which is what EncapsulateMetaData<char *>(dict, key, p) produces. The very next statement calls a member function through the null constCstringObj. That the result is overwritten two lines later does not help: the dereference has already happened. The two lines want to be swapped, or the const char * read moved into an else.

B74 — HDF5ImageIO::ReadImageInformation: geometry dataset lengths are taken on trust (out-of-bounds read)

itkHDF5ImageIO.cxx:711-744. numDims is fixed by the Directions dataset, and every later geometry vector is then indexed to that bound regardless of its own length:

    std::vector<std::vector<double>> directions = this->ReadDirections(DirectionsName);
    auto numDims = static_cast<int>(directions.size());
    this->SetNumberOfDimensions(numDims);
    ...
    this->m_Origin = this->ReadVector<double>(OriginName);
    for (int i = 0; i < numDims; ++i)
    {
      this->SetDirection(i, directions[i]);
    }
    ...
    std::vector<double> spacing = this->ReadVector<double>(SpacingName);
    for (int i = 0; i < numDims; ++i)
    {
      this->SetSpacing(i, spacing[i]);
    }
    ...
      std::vector<ImageIOBase::SizeValueType> Dims = this->ReadVector<ImageIOBase::SizeValueType>(DimensionsName);
      for (int i = 0; i < numDims; ++i)
      {
        this->SetDimensions(i, Dims[i]);
      }

ReadVector sizes its result from the dataset alone — vec.resize(dim[0]) (:482) — with no cross-check against numDims. A .h5 whose Spacing or Dimension dataset is shorter than its Directions dataset's second extent makes spacing[i] / Dims[i] index past the end of a std::vector through the unchecked operator[] — C++ UB, before any pixel is read. Two further shapes of the same omission: a non-square Directions hands SetDirection(i, …) a row of the wrong length, and m_Origin is replaced outright by whatever length the file declared, so a later GetOrigin(i) can index past its end.

B75 — HDF5ImageIO::Read: a big-endian VoxelData is copied without a byte swap

itkHDF5ImageIO.cxx:1006-1011:

  const H5::DataType voxelType = m_VoxelDataSet->getDataType();
  H5::DataSpace      imageSpace = m_VoxelDataSet->getSpace();

  H5::DataSpace dspace;
  this->SetupStreaming(&imageSpace, &dspace);
  m_VoxelDataSet->read(buffer, voxelType, dspace, imageSpace);

getDataType() returns the dataset's file datatype, and it is then handed to H5Dread as the memory datatype. Source and destination types are the same object, so the conversion is the identity and no endian conversion is performed. ITK's own writer always stores NATIVE_*, so on a little-endian host the defect is invisible for ITK-written files. A .h5 written by any other tool with STD_I16BE voxels — entirely legal HDF5, and what h5py produces on request — loads byte-swapped, silently, with no diagnostic. Contrast ReadDirections/ReadVector, which read through NATIVE_DOUBLE/GetType<TScalar>() and therefore are converted. The fix is to pass the native predtype for m_ComponentType, as the metadata readers already do.

Quirks (surprising or inconsistent, but arguably intended — recorded for completeness, not as bug reports)

#	Finding
Q90	PNGImageIO::ReadImageInformation is a bare return; on a wrong PNG signature (:334-338) where Read throws "File is not png type: …" for the identical png_sig_cmp (:139-143) — a caller reaching it via SetImageIO (bypassing CanReadFile) gets a fabricated success with m_Dimensions unset. A missing file pointer returns silently the same way (:321-324)
Q91	PNGImageIO::CanWriteFile passes ignoreCase = false to HasSupportedWriteExtension (:497), unlike the trait's own case-insensitive default; .png and .PNG are both registered (:281-287), so foo.PNG is claimed but foo.PnG is not
Q92	m_ExpandRGBPalette's in-class initializer is false (itkImageIOBase.h:853) but ImageIOBase's constructor calls Reset(false), which unconditionally sets it true (itkImageIOBase.cxx:28,45) — PNGImageIO never touches the flag, so the header default is dead and every instance starts with palette expansion on
Q93	HDF5TransformIO's ReadParameters/ReadFixedParameters emit "Wrong data type for " << DataSetName << "in HDF5 File" — no space before in, so the dataset name runs into the word (itkHDF5TransformIO.cxx:171, :217)
Q94	the rank-1 check in both of those readers raises "Wrong # of dims for TransformType in HDF5 File" (:176, :222) — TransformType is the one dataset the check never covers
Q95	HDF5TransformIO::Read loops i < transformGroup.getNumObjs() and then openGroup(GetTransformName(i)) (:297-302); getNumObjs counts every link, so one stray dataset beside the 0, 1, … subgroups makes the loop ask for a group N that was never written and the read dies inside libhdf5 rather than reporting an extra object
Q96	HDF5TransformIO::CanReadFile is h5file.exists("/TransformGroup") (:59-66), i.e. H5Lexists — a dataset of that name passes, the factory hands the file over, and Read's openGroup (:295) throws an H5::Exception instead of the factory's clean "could not create Transform IO object"
Q97	HDF5ImageIO stores three axis conventions in one group: Dimension/Origin/Spacing in ITK order, fastest-moving first (:1151-1161); only VoxelData's dataspace is reversed (:1170-1182); and Directions writes m_Direction[i] as its row i (:490-510) while that is column i of the direction matrix — so a 4×3 2-D image writes Dimension = [4, 3] and a VoxelData of shape [3, 4], and the Directions dataset is the matrix transpose
Q98	HDF5ImageIO's ReadScalar (:410) and ReadVector (:479) both raise "Wrong # of dims for TransformType in HDF5 File" — the transform IO's message (Q94), verbatim, in a file that holds no transform. ReadDirections (:521) at least names the image directions
Q99	VoxelType is written on every Write (:1163-1166) and read on no Read: m_ComponentType is derived from imageSet.getDataType() (:752-753). A file whose VoxelType reads FLOAT over int16 voxels loads as Int16; a file with no VoxelType at all loads fine. The class comment (itkHDF5ImageIO.h:68-71) says it exists to make the file "user friendly with respect to HDF5 viewers", so this is by design — worth stating, since it looks authoritative
Q100	HDF5ImageIO::CanReadFile is h5file.exists("/ITKImage") (:647-654) — same H5Lexists shape as Q96, so a dataset named /ITKImage is claimed and ReadImageInformation's first openDataSet throws
Q101	three of ReadImageInformation's meta-data branches are unreachable: WriteScalar(unsigned long) stores NATIVE_UINT tagged isUnsignedLong (:322-342), so no ITK-written dataset is ever NATIVE_INT + isUnsignedLong as :801-805 expects; and on every LP64 platform H5Tequal(NATIVE_LONG, NATIVE_LLONG) and H5Tequal(NATIVE_ULONG, NATIVE_ULLONG) are true, so the arms at :874-897 swallow every 64-bit integer and those at :898-905 never run (the isLLong/isULLong tags inside the surviving arms are what actually distinguish the two)
Q102	a meta-data dataset of rank > 1 is skipped by continue (:785-789), and the if/else if chain over the fourteen NATIVE_* types ends in an else that tests only metaDataType == strType with no else of its own (:914-922) — so a compound, enum, array or variable-length-sequence dataset leaves no dictionary entry and raises nothing. A subgroup under MetaData, by contrast, is fatal: the loop opens every link with openDataSet (:776-782)
Q103	HDF5ImageIO's constructor registers .hdf, .h4, .hdf4, .he4 — HDF4 container names — for both reading and writing alongside the HDF5 ones (:36-43), the same eight-name list already noted on the transform side (Q89). Here CanWriteFile is HasSupportedWriteExtension(name) with ignoreCase = true (itkImageIOBase.h:788), so IMAGE.H5 is claimed for writing where the transform IO's case-sensitive CanWriteFile declines it

(Same AI-assistance disclosure as the issue body applies to this comment; this batch was re-verified against main at 812d7a89f3.)

[physwkim]

A seventh batch, and the last from this pass — JPEGImageIO. Same methodology and caveats: source-level reading, each item independently re-verified with a refutation-oriented pass against current main at 812d7a89f3, no runtime reproduction. Numbering continues (B76–B77, Q104–Q107).

Bugs

#	Site	Finding
B76	JPEGImageIO::WriteSlice	the "prefer centimetres" density branch tags the JFIF header density_unit = 0 ("aspect ratio only") while storing real dots-per-cm values — the reader's own density_unit > 0 guard then discards them, so the spacing is lost on a round-trip through ITK
B77	JPEGImageIO::Read	the CMYK→RGB conversion assumes all four channels are inverted; that holds for plain CMYK, but for a YCCK source libjpeg un-inverts C/M/Y and passes K through — a white YCCK pixel decodes to black

B76 — JPEGImageIO::WriteSlice: the cm density branch writes density_unit = 0, and the reader drops it

itkJPEGImageIO.cxx:553-566 picks whichever unit represents the spacing with less rounding error:

    if (itk::Math::Absolute(25.4 / m_Spacing[0] - densityPerInch[0]) + ... <= ...)
    {
      cinfo.density_unit = 1;
      cinfo.X_density = densityPerInch[0];
      cinfo.Y_density = densityPerInch[1];
    }
    else
    {
      cinfo.density_unit = 0;
      cinfo.X_density = densityPerCm[0];
      cinfo.Y_density = densityPerCm[1];
    }

In JFIF, density_unit is 0 = no units (X/Y are an aspect ratio only), 1 = dots/inch, 2 = dots/cm. The else arm stores genuine dots-per-cm values under the tag that says "these are not physical units". It should be 2.

That this is a defect rather than a deliberate encoding is settled by the class's own reader, :421-432, which handles 2 correctly and rejects 0:

  if (cinfo.density_unit > 0 && cinfo.X_density > 0 && cinfo.Y_density > 0)
  {
    if (cinfo.density_unit == 1) // inches
    { m_Spacing[0] = 25.4 / cinfo.X_density; ... }
    else if (cinfo.density_unit == 2) // cm
    { m_Spacing[0] = 10.0 / cinfo.X_density; ... }
  }

So ITK writes a spacing the cm branch was reached for, and ITK reads it back as the default [1.0, 1.0]. Concretely, a 2.0 mm spacing is exact in dots/cm (5) and inexact in dots/inch (12.7 → 13), so it takes the else arm and does not survive the round-trip. The density_unit == 2 arm of the reader is unreachable for any file ITK itself wrote.

B77 — JPEGImageIO::Read: the CMYK→RGB formula is wrong for YCCK sources

itkJPEGImageIO.cxx:244-251:

          // Gimp approach: the following code assumes inverted CMYK values,
          // even when an APP14 marker doesn't exist. This is the behavior
          // of recent versions of PhotoShop as well.
          const float K = buf1[0][4 * i + 3];
          row_pointers[scanline][3 * i + 0] = static_cast<JSAMPLE>(buf1[0][4 * i + 0] * K / 255.0f);
          row_pointers[scanline][3 * i + 1] = static_cast<JSAMPLE>(buf1[0][4 * i + 1] * K / 255.0f);
          row_pointers[scanline][3 * i + 2] = static_cast<JSAMPLE>(buf1[0][4 * i + 2] * K / 255.0f);

The formula is uniform: it treats all four incoming channels as inverted (Adobe convention), so R = C·K/255. The comment's assumption is right about what the file contains, but wrong about what libjpeg hands back, and the two differ by source colour space:

• jpeg_color_space == JCS_CMYK → null_convert (jdcolor.c:870, :925) copies all four channels through untouched. All four stay inverted; the formula is correct.
• jpeg_color_space == JCS_YCCK → ycck_cmyk_convert (jdcolor.c:544-587) writes range_limit[MAXJSAMPLE - (y + Crrtab[cr])] into C/M/Y (:574-578), i.e. it un-inverts them, while K is copied verbatim (:580). The buffer ITK receives is mixed: C/M/Y non-inverted, K inverted.

jdmaster.c defaults out_color_space to JCS_CMYK for a JCS_YCCK source, so m_IsCMYK is set (:397) and this branch runs for both. Trace a pure-white pixel: as plain CMYK it arrives as C=255, K=255 and yields R = 255·255/255 = 255, white. As YCCK the same pixel arrives as C=0, K=255 and yields R = 0, black. Every YCCK JPEG — the ordinary output of Adobe tools for CMYK images — is decoded inverted.

Distinguishing the two costs one field: cinfo.jpeg_color_space == JCS_YCCK selects the R = (255 − C)·K/255 form. (Alternatively, setting out_color_space = JCS_CMYK does not help — that is the default here; the un-inversion happens inside the YCCK converter.)

Quirks (surprising or inconsistent, but arguably intended — recorded for completeness, not as bug reports)

#	Finding
Q104	JPEGImageIO::Write throws "JPEG Writer can only write 2-dimensional images" before opening anything (:459-462), where PNGImageIO::WriteSlice silently writes only the first slice (B71) — the two sibling IOs disagree on whether a 3-D source is an error
Q105	JPEGImageIO::CanReadFile is markedly stricter than PNG's: case-sensitive extension (:102, ignoreCase = false), then the 0xFFD8 magic (:117-130), then a full jpeg_read_header parse (:152) — where PNGImageIO::CanReadFile stops at the 8-byte signature
Q106	JPEGImageIO::CanWriteFile passes ignoreCase = false (:449) against four registered spellings (:308-314) — .jpg, .JPG, .jpeg, .JPEG are claimed, .Jpg is not. Same shape as PNG's (Q91)
Q107	m_UseCompression is assigned false in the constructor (:299) and never read: jpeg_set_quality is called unconditionally (:537), so only Quality/CompressionLevel has any effect and UseCompressionOn() is silently inert for this IO

(Same AI-assistance disclosure as the issue body applies to this comment; this batch was re-verified against main at 812d7a89f3.)