Repository navigation
ITK 5.4.8 tag? #6859
Description
Activity
In preparation for 5.4.8, these recent
mainfixes will be tried as backports. Please reply with any that should NOT be attempted before the 5.4.8 tag.Updated after @dzenanz's review: behavior changes are excluded from the patch release.
To be tried for backporting
PR Fix Expected effort Backport #6829 HDF5ImageIO: set VECTOR pixel type when inferring components Library code applies cleanly; GTest needs porting #6866 (merged) #6704 Correct superclass asserted for LabelOverlapMeasuresImageFilter Clean #6869 (draft) #6821 Mangle libpng symbols added since last vendored update Clean #6871 (draft, NEON symbols only) #6822 Pass /Zc:__cplusplusto SWIG wrappers with MSVCOne-line conflict #6864 (merged) #6776 Declare NrrdIO's Threads dependency in exported config Small conflict Not needed: NrrdIO on 5.4 has no Threads dependency (it came with #6695) #6717 Array SetDatainvoked with wrong parameter typesGTest needs porting #6868 (draft) #6682 Recognize native big-endian single-precision MATLAB headers Test CMake conflict #6870 (draft) Not to be backported (behavior changes)
PR Fix Reason #6771 Python: map np.int64toitk.int64_tinstead ofitk.SLBehavior change (@dzenanz) #6783 Python: initialize_c_types_onceordering (UI/UL/ULL/SLL)Depends on #6771 and changes type resolution the same way #6759 MultiLabelSTAPLE: integer counting in prior init Behavior change (@dzenanz) #6633 PatchBasedDenoising: wraparound, NaN, and max-tracker seeding Behavior change (@dzenanz) #6683 NIfTI: preserve non-finite pixel values on read Behavior change (@dzenanz) #6835 MetaIO update (2026-09-04), including memory-safety hardening Behavior change (@dzenanz) Considered but not proposed
- BUG: Fix six read and write defects in TIFFImageIO #6636 (TIFF read/write defects) and Bruker 2dseq reader: ParaVision on-disk format conformance #6761 (Bruker 2dseq): each commit conflicts because the branches have diverged; high effort for a patch release.
- BUG: Reject class counts that overflow non-contiguous labels #6596 (ScalarImageKmeans label overflow): conflicts in 4 files.
- BUG: Locale-independent float parsing and printing in NRRD/DICOM IO #6695 (locale-independent float parsing): removes the public
NumericLocaleAPI, so it is not suitable for 5.4.x. - Remaining
COMP:changes onmaintarget v6 (VtkGlue abi3, Python 3.11 minimum, warning fixes, and pins).
Reacted by Bradley LowekampThe proposal looks good. Just double check the patches on third-party libraries by verifying the vendored version in release matches what was in main brach where the patch was done.
@hjmjohnson @thewtex @dzenanz Any remaining items before the patch tag is made?
Maybe InsightSoftwareConsortium/ITKPythonPackage#309 and/or #6891?
Reacted by Dženan ZukićReacted by Dženan ZukićThe ITKPythonPackaging is hopefully independent of the main ITK repository. #6891 looks like a larger effort needing more time and testing before it'd be ready for back porting to the release-5.4 branch. Hopefully, ITK Python will be able to be packaged the same way as the prior patch release.
I am looking to do a patch release of SimpleITK with changed in the release-5.4 branch.
Reacted by Dženan ZukićYou are absolutely right. I confused 6.0RC1 with 5.4.8 😕
Reacted by Bradley LowekampAn RC is needed too! But for that ensuring python packaging is a requirement. Is there already an issue with a burn down chart/list?
That is complete. I guess all that's left is for someone to go through the release checklist.
Possibly the checklist variant for 5.4 branch.
I have run into a failure in SimpleITK with the release-5.4 branch related to concurrent IO I am investigating this morning. I am suspicious of cf983db, but was not easily able to reproduce locally as easily as it started to fail in GHA.
Reacted by Matt McCormickIn SimpleITK/SimpleITK#2292 there is a nice request for back port of #5357.
There has been some isolation of this behavior through ITK versions (documented in the linked issue), there is a needed decision with of a trade off between "correct" behavior and stable incorrect behavior that needs to be made.
EDIT: corrected ITK PR number.
Reacted by Dženan ZukićAre you sure you meant 2292? It is about updating KWSys.
Reacted by Bradley LowekampHi @blowekamp and @dzenanz,
Following up on SimpleITK/SimpleITK#2292 (comment), here is our request for this release discussion.
@dzenanz, the bug report is SimpleITK/SimpleITK#2292 and the merged ITK fix is #5357. Bradley's comment now also has the corrected PR number.
In our synthetic axial reproduction, read in the default
GetGDCMSeriesFileNamesorder, negative SpacingBetweenSlices (0018,0088) leaves the voxel planes in ascending ImagePositionPatient order but gives direction[2,2] = -1: reported physical z positions decrease while the IPP values increase. SimpleITK 2.5.6 (ITK 5.4) produces this result; SimpleITK 2.3.1 (ITK 5.3) and development build 3.0.0b1.post230 (ITK 6.0) give +1. The full tested-version matrix is at SimpleITK/SimpleITK#2292 (comment). We tested SimpleITK builds, not ITK directly; we have not built or tested ITKrelease-5.4with #5357 applied.As checked on 2026-10-03 at 16:37 UTC,
release-5.4(b3abd15) lacks the direction-sign correction initkImageSeriesReader.hxx. We found no backport PR or 5.4.8 tag; PyPI's latest stable SimpleITK is still 2.5.6.We understand the decision to exclude behavior changes from 5.4.8. For consideration: with
ForceOrthogonalDirectionenabled, #5357 flips the slice-axis direction column only when its dot product with the first-to-last slice position vector is negative. The new code leaves an already consistent direction column unchanged. For our affected axial input, the corrected development-build result matches the ITK 5.3-based SimpleITK build; we are not attributing the 5.3/5.4 difference to a regression initkImageSeriesReader.hxx. Code compensating for the existing 5.4 result could be affected, so the backport decision remains yours.The library-code change is confined to
ImageSeriesReader::GenerateOutputInformation(). Its new GTests would need integration or adaptation: the currentrelease-5.4GDCM test CMake file has no GoogleTest driver.If a backport is inappropriate, a known-issue note in the ITK 5.4.8 and/or SimpleITK 2.5.x release notes would help.
ForceOrthogonalDirectionOff()corrects our axial case in SimpleITK 2.5.6; we have not validated it for other orientations. We would be glad to run the synthetic reproduction against a backport build:
https://gist.github.com/zhurong2020/563f974baaf33c30f910f98c4d06ebadThank you.
Hello,
Could we get a 5.4.8 release tag in the coming weeks?
I am looking to do a patch release of SimpleITK in-part to support Python 3.15. There are some very useful bug fixes in the release-5.4 branch that would be good to incorporate. It is much preferred to do a SimpleITK release against an ITK tag than a hash.
Thanks.