Hi folks,
The next patch (bugfix) release, ITK 5.4.6, is coming up.
Patches currently staged on the Git release-5.4 branch include:
Bradley Lowekamp (1):
BUG: Fix GDCM posix_memalign undefined with mingw
Dženan Zukić (2):
ENH: Update CI images from Windows-2019 to Windows-2022
COMP: Fix doc-string of TreeIteratorBase::RemoveChild from Deprecated
Hans J. Johnson (2):
PERF: Enable FFTW SIMD codelets with per-CPU introspection at configure time
COMP: Fix FFTW SIMD detection for Windows ARM64 and MSVC
Matt McCormick (7):
DOC: ITK 5.4.5 release notes
COMP: Update tool.pixi.project to tool.pixi.workspace
COMP: Update Azure Pipelines Windows image to windows-2022
COMP: Update CI ExternalDataVersion from 5.4.3 to 5.4.5
DOC: Do not upgrade CMake in emulated Linux ARM build
DOC: Update Python Xcode version to 16.2 for macos-15 runners
ENH: Add ITK_PYTHON_RELEASE_GIL option and SWIG -threads flag
Simon Rit (1):
BUG: Allow auto registering more than two factories in Python modules
Vladimir S. FONOV (1):
MINC 2025-02-24 (3b8d9c7e)
Are there other patches that are missing? Patches should be critical bugfixes, improved support for compilers, and documentation fixes.
1 Like
blowekamp
April 7, 2026, 9:01pm
2
Matt,
There should be a couple commits to update MINC too. This and the GDCM update are needed to build with R on windows with the mingw toolchain.
Brad
Hi Brad,
Is there a pointer to the relevant MINC PR’s?
Thanks,
blowekamp
April 8, 2026, 3:18pm
4
1 Like
@blowekamp thanks, that’s included.
1 Like
Just double-checking: ITK 5.4.6 will still export the old GoogleTest target names, right? (I mean GTest::GTest and GTest::Main.)
So the following pull request is for ITK 6, not for ITK 5.4.6:
main ← blowekamp:gtest_modern_targets
opened 03:49PM - 09 Dec 25 UTC
These are the targets currently exported by CMake's FindGTest, the GTest::GTest,… and GTest::Main targets were deprecated in CMake 3.20, adn removed in CMake 4.1.0.
## PR Checklist
- [ ] No [API changes](https://github.com/InsightSoftwareConsortium/ITK/blob/main/CONTRIBUTING.md#breaking-changes) were made (or the changes have been approved)
- [ ] No [major design changes](https://github.com/InsightSoftwareConsortium/ITK/blob/main/CONTRIBUTING.md#design-changes) were made (or the changes have been approved)
- [ ] Added test (or behavior not changed)
- [ ] Updated API documentation (or API not changed)
- [ ] Added [license](https://github.com/InsightSoftwareConsortium/ITK/blob/main/Utilities/KWStyle/ITKHeader.h) to new files (if any)
- [ ] Added Python wrapping to new files (if any) as described in [ITK Software Guide](https://itk.org/ItkSoftwareGuide.pdf) Section 9.5
- [ ] Added [ITK examples](https://github.com/InsightSoftwareConsortium/ITKSphinxExamples) for all new major features (if any)
Refer to the [ITK Software Guide](https://itk.org/ItkSoftwareGuide.pdf) for
further development details if necessary.
committed 04:04PM - 10 Dec 25 UTC
These are the targets currently exported by CMake's FindGTest.
Remove the GTest… ::GTest, and GTest::Main targets which deprecated in
CMake 3.20, and removed in CMake 4.1.0.
Fine to me, just double-checking
dzenanz
April 10, 2026, 6:13pm
7
Maybe 3b3c1e15bb5cdcbd83f061f9968a2704fe9e9baf from PR 6002 ?
1 Like
@Niels_Dekker correct – the names are not changing in ITK 5.
1 Like
blowekamp
April 13, 2026, 1:49pm
10
We should also consider a full update to GDCM or apply critical patched to the thridparty GDCM library.
1 Like
hjmjohnson
April 13, 2026, 9:30pm
11
Two additional items for 5.4.6 consideration:
[TODO as of 20260413] PEP 688 buffer protocol and GIL release safety ( #6042 ***,*** #6043 ***)***
▎ PRs ENH: Backport #6026 — PEP 688 buffer protocol and np.asarray() lifetime safety by hjmjohnson · Pull Request #6042 · InsightSoftwareConsortium/ITK · GitHub and ENH: Backport #6027 — comprehensive tests for itk.Image buffer protocol and lifetime by hjmjohnson · Pull Request #6043 · InsightSoftwareConsortium/ITK · GitHub backport the PEP 688 buffer protocol
(_buffer _/_release_buffer _) and comprehensive lifetime safety tests from main. These fix np.asarray(itk_image) to work correctly with Python 3.12+ and prevent
use-after-free when the backing ITK image is garbage collected. Both PRs target release-5.4 and CI is pending.
and 1 done
[DONE] Backport FFTW feature selections ( #6025 ***)***
Issue Backport #6007 For FFTW feature selections to release-5.4 · Issue #6025 · InsightSoftwareConsortium/ITK · GitHub requests backporting PR PERF: Use ABI-guaranteed SIMD baselines for redistribution-safe FFTW builds by hjmjohnson · Pull Request #6007 · InsightSoftwareConsortium/ITK · GitHub ("PERF: Use
ABI-guaranteed SIMD baselines for redistribution-safe FFTW builds"), which was merged to main on 2026-04-08. The current release-5.4 FFTW configuration has pitfalls in
cross-platform environments that #6007 resolves. The FFTW SIMD codelet changes are already partially staged (per Post #1 *),* but the full feature-selection mechanism from
#6007 is more robust.
hjmjohnson
April 13, 2026, 9:32pm
12
My vote is to do a full update. that seems like the path of least resistance.
hjmjohnson
April 13, 2026, 9:46pm
13
I’ve created a tracking issue with a prioritized list of backport candidates from `main`:
Backport candidates for ITK 5.4.6 release · Issue #6051 · InsightSoftwareConsortium/ITK · GitHub
It includes 7 Tier 1 critical bug fixes (all 1–3 file cherry-picks), 3 Tier 2 high-value fixes, 4 Tier 3 build fixes for modern toolchains, and the GDCM CVE @blowekamp mentioned. PRs #6041 , #6042 , #6043 are already merged to `release-5.4`; #6022 and #6025 are still open.
@matt.mccormick — happy to open backport PRs for any of the Tier 1 items.
Created: Backport candidates for ITK 5.4.6 release · Issue #6051 · InsightSoftwareConsortium/ITK · GitHub
1 Like
@hjmjohnson great, could you please create PR’s for the Tier 1 patches?
We should also consider a full update to GDCM or apply critical patched to the thridparty GDCM library.
This updates to current GDCM release Release 5.4 update gdcm by thewtex · Pull Request #6059 · InsightSoftwareConsortium/ITK · GitHub
Still todo is a patch for CVE-2026-3650
I am probably too late for this but there is a one liner issue that causes the ITK Lib Tiff to crash on unknown tiff tags due to a nullptr bug. It only effects Windows builds.
1 Like
Here’s the issue we’ve submitted.
opened 01:35PM - 27 Apr 26 UTC
type:Bug
### Description
The following bug was encountered when using the conda forge … package of ITK, but it will occur on when building on Windows with external libTIFF in general.
When using ITK 5 built with external libTIFF certain TIFF files will cause `TIFFImageIO` to crash when reading their tags. Specifically inside `TIFFImageIO::ReadImageInformation()` and then the private `TIFFImageIO::ReadTIFFTags()`.
There is a workaround for versions 4.0.0-4.0.2 of libTIFF based on the value of `ITK_TIFF_HAS_TIFFFieldReadCount`. This macro define is from `Modules/ThirdParty/TIFF/CMakeLists.txt` via `check_type_size(TIFFFieldReadCount ITK_TIFF_HAS_TIFFFieldReadCount)`. The CMake function `check_type_size` uses `sizeof(TIFFFieldReadCount)` to determine if the function exists or not. However this is not legal to use function types in `sizeof` according to the standard. GCC and Clang accept this by default for C programs (and rejects it by default for C++) but MSVC rejects it. The correct form would be `sizeof(&TIFFFieldReadCount)` and `check_type_size(&TIFFFieldReadCount ITK_TIFF_HAS_TIFFFieldReadCount)`.
This means that on Windows with external libTIFF the wrong code is using for accessing TIFF fields. The workaround reproduces internal libTIFF structures that are no longer correct and invalid data is read. In my case it read a 0 into `field_name` and crashes later when attempting to deference the null pointer while logging that the data type is unsupported.
Attached is a file that reproduces this issue.
[itk_crash.zip](https://github.com/user-attachments/files/27127504/itk_crash.zip)
### Steps to Reproduce
```
conda install libitk-devel=5.4.5
```
```cmake
cmake_minimum_required(VERSION 3.30)
project(itk_crash LANGUAGES CXX)
add_executable(itk_crash main.cpp)
find_package(ITK REQUIRED COMPONENTS ITKIOTIFF)
target_link_libraries(itk_crash PRIVATE ITKIOTIFF)
```
```cpp
#include <itkTIFFImageIO.h>
int main()
{
itk::TIFFImageIO::Pointer imageIO = itk::TIFFImageIO::New();
imageIO->SetFileName("./itk_crash.tif");
imageIO->ReadImageInformation();
}
```
### Expected behavior
No crash but should have this error message.
```
WARNING: In C:\P\IPP\ITK-source\ITK\Modules\IO\TIFF\src\itkTIFFImageIO.cxx, line 1264
TIFFImageIO (0000020FE6411100): ICC Profile has unsupported data type (7) for meta-data dictionary.
```
### Actual behavior
If attached to debugger:
```none
Exception thrown at 0x00007FFC40F55F31 (ucrtbase.dll) in itk_crash.exe: 0xC0000005: Access violation reading location 0x0000000000000000.
```
### Reproducibility
100%
### Versions
ITK
5.4.5
conda-forge/win-64::libitk-5.4.5-hb27c29c_0
conda-forge/win-64::libitk-devel-5.4.5-h7f67dcf_0
conda-forge/win-64::libtiff-4.7.1-h8f73337_1
### Environment
Windows
Python 3.12
conda 24.1.2
### Additional Information
None
1 Like
dzenanz
April 27, 2026, 4:07pm
18
5.4.6 has been tagged. There is more detail in this tracking issue .
@blowekamp can PR #6150 be easily backported to release-5.4 branch?
1 Like
blowekamp
April 27, 2026, 4:11pm
19
This issue only effects the 5.4 branch. The version requirement for libtiff has been increased, and this check is not longer required.
I also have a PR for the conda-forge feedstock:
main ← blowekamp:fix/tiff-check-symbol-exists
opened 04:07PM - 27 Apr 26 UTC
## Summary
Applies the fix from upstream ITK PR [InsightSoftwareConsortium/ITK#… 6150](https://github.com/InsightSoftwareConsortium/ITK/pull/6150) as a recipe patch.
### Bug
When building with `ITK_USE_SYSTEM_TIFF=ON` (always the case in this feedstock), the CMake detection of `TIFFFieldReadCount` used `check_type_size()`, which internally calls `sizeof()` on the argument. Passing a **function** name to `sizeof()` is non-standard — GCC and Clang accept it as an extension, but MSVC rejects it — so `ITK_TIFF_HAS_TIFFFieldReadCount` was never defined on Windows builds.
Without that define, `itkTIFFImageIO` falls through to a libtiff 4.0.0–4.0.2 workaround that directly accesses the internal `_TIFFField` struct. That struct layout is no longer correct for modern libtiff versions, causing reads of garbage data and **NULL pointer crashes** when encountering tags with unsupported data types (e.g. an ICC profile tag).
Fixes: [InsightSoftwareConsortium/ITK#6148](https://github.com/InsightSoftwareConsortium/ITK/issues/6148)
### Fix
Replace `check_type_size(TIFFFieldReadCount ...)` with `check_symbol_exists(TIFFFieldReadCount "tiffio.h" ...)` in `Modules/ThirdParty/TIFF/CMakeLists.txt`, which correctly detects the function symbol on all compilers.
### Changes
- `recipe/0001-BUG-use-check_symbol_exists-for-TIFFFieldReadCount.patch` — new patch applying the upstream fix
- `recipe/meta.yaml` — add `patches:` list, bump build number 2 → 3
2 Likes
seanm
May 4, 2026, 4:33pm
20
Ah darn, I didn’t notice this thread.
If there’s a 5.4.7 can we backport: Fixed compilation errors with C23, and one with C++ by seanm · Pull Request #985 · vxl/vxl · GitHub
Otherwise, building fails with:
CMake Error at Modules/ThirdParty/VNL/src/vxl/CMakeLists.txt:48 (MESSAGE):
CMAKE_C_STANDARD:STRING=17 not in know standards list
90;99;11.
1 Like
