ENH: Add ConvertCompositionToItkTransform to ElastixRegistrationMethod

[N-Dekker]

The existing ConvertToItkTransform appears inconvenient for composition transforms, as it may cause end-users to "downcast" the return value to itk::CompositeTransform.

[N-Dekker]

Interesting compile errors on Azure Pipelines, from MacOS, at https://dev.azure.com/kaspermarstal/d9c40921-2d83-43b7-b98b-be691988c03a/_apis/build/builds/6261/logs/52

2026-08-21T16:23:54.2620140Z [ 40%] Building CXX object Components/Metrics/Impact/CMakeFiles/ImpactMetric.dir/elxImpactMetric.cxx.o
2026-08-21T16:23:57.9894740Z In file included from /Users/runner/work/1/s/Components/Metrics/Impact/elxImpactMetric.cxx:19:
2026-08-21T16:23:57.9896090Z In file included from /Users/runner/work/1/s/Components/Metrics/Impact/elxImpactMetric.h:24:
2026-08-21T16:23:57.9896970Z In file included from /Users/runner/work/1/s/Components/Metrics/Impact/itkImpactImageToImageMetric.h:24:
2026-08-21T16:23:57.9899580Z In file included from /Users/runner/work/1/s/Components/Metrics/Impact/itkBSplineInterpolateVectorImageFunction.h:40:
2026-08-21T16:23:57.9900450Z In file included from /Users/runner/work/1/libtorch/include/torch/csrc/api/include/torch/torch.h:4:
2026-08-21T16:23:57.9901420Z /Users/runner/work/1/libtorch/include/torch/csrc/api/include/torch/all.h:5:2: error: C++20 or later compatible compiler is required to use PyTorch.
2026-08-21T16:23:57.9902210Z #error C++20 or later compatible compiler is required to use PyTorch.
2026-08-21T16:23:57.9902790Z  ^
2026-08-21T16:23:58.1956200Z In file included from /Users/runner/work/1/s/Components/Metrics/Impact/elxImpactMetric.cxx:19:
2026-08-21T16:23:58.1960310Z In file included from /Users/runner/work/1/s/Components/Metrics/Impact/elxImpactMetric.h:24:
2026-08-21T16:23:58.1962590Z In file included from /Users/runner/work/1/s/Components/Metrics/Impact/itkImpactImageToImageMetric.h:24:
2026-08-21T16:23:58.1967670Z In file included from /Users/runner/work/1/s/Components/Metrics/Impact/itkBSplineInterpolateVectorImageFunction.h:40:
2026-08-21T16:23:58.1970790Z In file included from /Users/runner/work/1/libtorch/include/torch/csrc/api/include/torch/torch.h:4:
2026-08-21T16:23:58.1974760Z In file included from /Users/runner/work/1/libtorch/include/torch/csrc/api/include/torch/all.h:8:
2026-08-21T16:23:58.1976680Z In file included from /Users/runner/work/1/libtorch/include/torch/csrc/api/include/torch/autograd.h:4:
2026-08-21T16:23:58.1978680Z In file included from /Users/runner/work/1/libtorch/include/torch/csrc/autograd/autograd.h:4:
2026-08-21T16:23:58.1981900Z In file included from /Users/runner/work/1/libtorch/include/torch/csrc/autograd/variable.h:7:
2026-08-21T16:23:58.1984720Z In file included from /Users/runner/work/1/libtorch/include/torch/csrc/autograd/cpp_hook.h:3:
2026-08-21T16:23:58.1990610Z In file included from /Users/runner/work/1/libtorch/include/torch/csrc/autograd/function_hook.h:4:
2026-08-21T16:23:58.1991430Z In file included from /Users/runner/work/1/libtorch/include/ATen/Tensor.h:4:
2026-08-21T16:23:58.1992700Z In file included from /Users/runner/work/1/libtorch/include/ATen/core/Tensor.h:4:
2026-08-21T16:23:58.1993500Z In file included from /Users/runner/work/1/libtorch/include/ATen/core/TensorBody.h:17:
2026-08-21T16:23:58.1994270Z In file included from /Users/runner/work/1/libtorch/include/c10/core/Scalar.h:11:
2026-08-21T16:23:58.1995100Z In file included from /Users/runner/work/1/libtorch/include/c10/core/SymBool.h:5:
2026-08-21T16:23:58.1995820Z In file included from /Users/runner/work/1/libtorch/include/c10/core/SymNodeImpl.h:8:
2026-08-21T16:23:58.1996580Z /Users/runner/work/1/libtorch/include/c10/util/intrusive_ptr.h:775:27: error: no type named 'strong_ordering' in namespace 'std'
2026-08-21T16:23:58.1997310Z [[nodiscard]] inline std::strong_ordering operator<=>(
2026-08-21T16:23:58.1997850Z                      ~~~~~^

However, I'll ignore them for now, as they appear unrelated to this PR!

[vboussot]

@N-Dekker Thanks for flagging this! The issue is that the newer libtorch requires C++20, while ImpactElastix is currently built with C++17.

I think the clean fix is to enable C++20 only for the IMPACT component:

if(USE_ImpactMetric)
find_package(Torch REQUIRED)
target_link_libraries(ImpactMetric ${TORCH_LIBRARIES})
target_compile_features(ImpactMetric PRIVATE cxx_std_20)
endif()

That way we don’t need to move all of Elastix to C++20.

[N-Dekker]

The issue is that the newer libtorch requires C++20, while ImpactElastix is currently built with C++17.

Thanks @vboussot ! Just wondering:

1. Why do the errors only occur on MacOS (not on Windows or Ubuntu)?
2. Why do the errors only occur on Azure Pipelines (not on GitHub Actions)?

Do you have a clue?

That way we don’t need to move all of Elastix to C++20.

Indeed, because I'm not sure if it is already time for Elastix to drop C++17, and move to C++20. Elastix usually "follows" the latest released version of ITK with compiler/language upgrades.

[vboussot]

@N-Dekker Yes, I think the difference is simply that both CI systems build LibTorch from source on macOS, because recent PyTorch binaries are not available for macOS Intel.

GitHub Actions pins PyTorch to v2.8.0, while Azure currently clones PyTorch without a tag, so it builds the latest main, which now requires C++20.

So pinning the Azure macOS build to the same PyTorch version should fix it.

[N-Dekker]

Thanks for explaining, @vboussot Is this somehow related to your PR #1463? I mean, when Elastix would use https://github.com/InsightSoftwareConsortium/ITKIMPACT, would the Elastix CI no longer need to pin the PyTorch version?

[vboussot]

@N-Dekker Yes, it is related to #1463, but using ITKIMPACT does not remove the PyTorch dependency.

In that PR I improved the LibTorch setup for Linux and Windows: the appropriate PyTorch/LibTorch package is now provided through pip instead of manually downloading the binaries.

Unfortunately macOS remains a special case. The CI runners are Intel, and recent PyTorch wheels are no longer provided for macOS x86_64, so LibTorch still has to be built from source there. We therefore still need to pin the PyTorch version for the macOS build.

[N-Dekker]

The CI runners are Intel, and recent PyTorch wheels are no longer provided for macOS x86_64, so LibTorch still has to be built from source there.

Are you sure these CI runners are still Intel? Pull request #1387 commit d189229 (merged on Dec 5, 2025) has upgraded the CI from macos-13 to macos-14, and as far as I understand, the macos-14 VM of Azure and GitHub Actions is ARM64! Would that make things easier?

Maybe I should have informed you about pull request #1387 before🤷 I still opened a discussion of elastix Intel support, though: #1322

[vboussot]

@N-Dekker I actually tried using the macOS PyTorch wheels, but ran into issues with the current CI setup. At the moment, building LibTorch from source is the only approach I found that works reliably there.

[N-Dekker]

@vboussot Do you mean that even on ARM64 runners like macos-14, it is still necessary to build LibTorch from source?

[vboussot]

Only on Azure, and the image name is misleading: both CIs run macos-14, on different hardware.

GitHub Actions is ARM64, and the wheel already works there. In #1463 all three OSes get LibTorch from pip install torch==2.11.*, macOS included:

Downloading torch-2.11.0-cp311-cp311-macosx_11_0_arm64.whl (80.4 MB)

That job passes, so the source build is gone from GitHub Actions.

The Azure agent is x86_64 throughout. From the LibTorch configure step of the same PR's Azure build:

Target processor: x86_64
Host processor: x86_64
-- Could not find hardware support for NEON on this machine.
-- Performing Test COMPILER_SUPPORTS_SSE2 - Success
-- Performing Test COMPILER_SUPPORTS_SSE4 - Success

NEON is ARM's SIMD, SSE2/SSE4 are x86's. So this is not a matter of picking a different Python interpreter: the whole toolchain is x86_64, and pip resolves x86_64 wheels for every package there (numpy-2.5.2-cp314-cp314-macosx_14_0_x86_64.whl, and so on).

PyTorch publishes no macOS x86_64 wheel past 2.2.2, so there is nothing to install on that agent. It keeps building LibTorch from source, now pinned to v2.11.0, the release the other two platforms install, so all three compile against the same headers.

That pin is also what fixes the failure you reported: cloning pytorch without a tag builds the development branch, which requires C++20.