# Updating Slicer's ITK to v6?
**URL:** https://discourse.itk.org/t/updating-slicers-itk-to-v6/7758
**Category:** Engineering
**Created:** [May 5, 2026, 8:12pm UTC](https://discourse.itk.org/t/updating-slicers-itk-to-v6/7758 "2026-05-05T20:12:34Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@dzenanz](https://discourse.itk.org/u/dzenanz)
#### Post date: [May 5, 2026, 8:12pm UTC](https://discourse.itk.org/t/updating-slicers-itk-to-v6/7758/1 "2026-05-05T20:12:34Z")
Has anyone started this? I am willing to give it try, but I want to avoid duplication of effort. My main motivation is adding `.vti` support to Slicer, which was recently added to ITK via [PR 6032](https://github.com/InsightSoftwareConsortium/ITK/pull/6032).
Tagging people who might have started this: @hjmjohnson @blowekamp @lassoan @jamesobutler
---
### Author:  [@hjmjohnson](https://discourse.itk.org/u/hjmjohnson)
#### Post date: [May 6, 2026, 2:51pm UTC](https://discourse.itk.org/t/updating-slicers-itk-to-v6/7758/2 "2026-05-06T14:51:10Z")
I’ve been working around the edges with the goal of getting there. I’ve done BRAINSTools updates to prepare for this change. I’ve also looked into SlicerExecutionModel and think there are no issues there.
My focus has been on getting CTK updated to Qt6 before tackling the ITK v6 changes.
---
### Author:  [@dzenanz](https://discourse.itk.org/u/dzenanz)
#### Post date: [May 6, 2026, 2:58pm UTC](https://discourse.itk.org/t/updating-slicers-itk-to-v6/7758/3 "2026-05-06T14:58:16Z")
I believe the only hard part is cherry-picking [216f772](https://github.com/Slicer/ITK/commit/216f7727070d872c54baa40af33202df12021fae) on top of current main. Applying the current style (gersemi, newer clang-format, etc) before cherry-picking should minimized number of conflicts that need to be resolved (e.g. sorting of list entries which happened between 5.4 and main). But then there are possible philosophical changes needed to that commit, which might be non-trivial. Slicer compiled (or near-compiled) with 5.4 with legacy turned off. It should compile with v6 and legacy on, with little to no changes.
---
### Author:  [@blowekamp](https://discourse.itk.org/u/blowekamp)
#### Post date: [May 6, 2026, 3:06pm UTC](https://discourse.itk.org/t/updating-slicers-itk-to-v6/7758/4 "2026-05-06T15:06:03Z")
I would also consider including this change: [ENH: Add namespace to ITK autoload symbol by blowekamp · Pull Request #14 · Slicer/ITK · GitHub](https://github.com/Slicer/ITK/pull/14/changes)
The introduction of “ITK\_LOAD\_SYMBOL” in upstream ITK should also be considered.
---
### Author:  [@dzenanz](https://discourse.itk.org/u/dzenanz)
#### Post date: [May 6, 2026, 3:18pm UTC](https://discourse.itk.org/t/updating-slicers-itk-to-v6/7758/5 "2026-05-06T15:18:08Z")
Should we integrate that change into `main`? It seems completely backwards compatible.
---
### Author:  [@jamesobutler](https://discourse.itk.org/u/jamesobutler)
#### Post date: [May 9, 2026, 2:14am UTC](https://discourse.itk.org/t/updating-slicers-itk-to-v6/7758/6 "2026-05-09T02:14:50Z")
I haven’t started any work related to this. So yes, it would be greatly appreciated 🙏@dzenanz if you work on this. The core ITK folks definitely are most familiar with any new deprecation handling and updating to new methods.
---
### Author:  [@blowekamp](https://discourse.itk.org/u/blowekamp)
#### Post date: [May 11, 2026, 4:54pm UTC](https://discourse.itk.org/t/updating-slicers-itk-to-v6/7758/7 "2026-05-11T16:54:12Z")
A slightly modified version of PR#14 could be integrated into ITK with a pre-defined ITK Namespace. But it is likely more appropriate to be merged in with the [216f772](https://github.com/Slicer/ITK/commit/216f7727070d872c54baa40af33202df12021fae) changes which add the alternate itk namespace.
---
### Author:  [@dzenanz](https://discourse.itk.org/u/dzenanz)
#### Post date: [May 12, 2026, 12:22pm UTC](https://discourse.itk.org/t/updating-slicers-itk-to-v6/7758/8 "2026-05-12T12:22:26Z")
Integrating [216f772](https://github.com/Slicer/ITK/commit/216f7727070d872c54baa40af33202df12021fae) into ITK main now seems like a good idea. @jcfr do you remember what is the outstanding work to do that?
---
### Author:  [@dzenanz](https://discourse.itk.org/u/dzenanz)
#### Post date: [August 22, 2026, 11:55pm UTC](https://discourse.itk.org/t/updating-slicers-itk-to-v6/7758/9 "2026-08-22T23:55:37Z")
Opened a PR:
>
>
> Introduces \`itkNamespace.h\` header providing the logic for redefining \`itk\` only… if a custom namespace has been provided. This ensures that the default behavior remains unchanged.
>
> To minimize the number of files to update, the itkNamespace.h may be included
> through three mechanisms:
>
> (1) Through itkConfigure.h
> =\> included either directly or indirectly by most files
>
> (2) Through Export header
> =\> support case of header like "itkFEMSolution.h" only including the export header
>
> (3) Through exlpicit include
> =\> support case of header without any includes (e.g "itkMakeFilled.h")
>
>
> This has been in use for quite a while. Instead of maintaining it in Slicer's fork, let's bring it into the main repository. Removed the word "draft" from JC's commit. Otherwise a rebase. Also included Brad's commit for autoload symbol customization.