COMP: Update vendored DCMTK to 3.7.0

[hjmjohnson]

Update the vendored DCMTK ExternalProject pin from the 2024-03-11 3.6.x snapshot to the DCMTK-3.7.0 patch branch on the InsightSoftwareConsortium/DCMTK fork. Single-file change to DCMTKGitTag.cmake; the ITK-specific patch stack (ITK codec sharing, WASI/Emscripten, GSPS/CSPS, plastimatch) rides on top of the upstream DCMTK-3.7.0 release tag.

Built and tested locally — all DCMTK and GDCM tests pass (details below).

Local build & test results (macOS arm64, Release, Clang)

Built in a worktree with Module_ITKIODCMTK=ON, ITK_USE_SYSTEM_DCMTK=OFF (all unrelated Remote modules disabled):

• DCMTK ExternalProject (3.7.0 + ITK patches): all 29 DCMTK libraries compiled.
• ITKDCMTK + ITKIODCMTK: built, 0 errors, 0 ITK-side warnings.
• ITKIODCMTK test label: 24/24 passed.
• GDCM tests (shares JPEG/PNG/TIFF/ZLIB): 65/65 passed — confirms codec libraries are undisturbed.

The DCMTK 3.7.0 EP resolved its image codecs to ITK's own libraries (verified in the EP CMakeCache.txt):

PNG_LIBRARY  = .../lib/libitkpng-6.0.a
TIFF_LIBRARY = .../lib/libitktiff-6.0.a
ZLIB_LIBS    = .../lib/libitkzlib-6.0.a
JPEG_LIBRARY = .../lib/libitkjpeg-6.0.a

Not exercised locally: Linux, Windows/MSVC, and the WASI/Emscripten path. Several of the carried 3.7.0 patches are WASM-specific and rely on CI for first execution.

Relationship to #5537

PR #5537 (draft, DCMTK_USE_FIND_PACKAGE=ON) attempted to make DCMTK consume ITK's PNG/ZLIB/TIFF via standard find_package. On the 3.6.x pin that approach failed at configure time (its own build log shows FindJPEG.cmake choking on the :::-mangled include paths ITK passes).

With this 3.7.0 update, DCMTK already links ITK's codec libraries through the carried patch stack (verified above), so the goal of #5537 — DCMTK using ITK's bundled codecs — is achieved. This may invalidate the need for #5537; it is left to the maintainers / a follow-up to evaluate whether #5537 should be closed as superseded, or re-scoped to retire the carried codec patches in favor of upstream 3.7.0's improved find_package support. This PR intentionally does not touch that mechanism.

PR Checklist

• No API changes were made (or the changes have been approved)
• No major design changes were made (or the changes have been approved)

[greptile-apps]

Greptile Summary

This PR advances the vendored DCMTK ExternalProject pin from the 3.6.x 20240311 snapshot to the DCMTK-3.7.0 patched branch on the InsightSoftwareConsortium fork, and drops dcmwlm/dcmrt from the built-library list consistently across CMakeLists.txt and the test driver.

• DCMTKGitTag.cmake: commit hash replaced (8197ee21 → 1158255a); patch-list comment updated to reflect the expanded set of WASI/Emscripten and plastimatch patches (Matt McCormick 1→7, Shreeraj Jadhav 1→9), including one patch carrying a WIP: prefix.
• CMakeLists.txt / test/CMakeLists.txt: dcmwlm and dcmrt removed from _ITKDCMTK_LIB_NAMES and the test-driver include-path list; no ITK source code references these modules so the removal is self-contained.
• Local testing (macOS arm64, Release, Clang) shows 24/24 ITKIODCMTK and 65/65 GDCM tests passing; Linux, Windows/MSVC, and WASI/Emscripten paths are untested locally and rely on CI.

Confidence Score: 4/5

The change is narrowly scoped — one hash bump and two library removals — and should be safe to merge once CI validates the untested platforms.

The library-list pruning is safe (no ITK code references dcmwlm or dcmrt), and the git hash is immutably pinned. The sole open question is a WIP-labelled patch in the carried stack whose behavior on stricter compilers (MSVC /permissive-, C++20 mode) has not yet been exercised in CI for this branch.

DCMTKGitTag.cmake — specifically the WIP-prefixed patch entry and its runtime behavior on Windows/MSVC builds

Important Files Changed

Filename	Overview
Modules/ThirdParty/DCMTK/DCMTKGitTag.cmake	Core pin update: replaces 3.6.x 20240311 commit hash with DCMTK-3.7.0 patched-branch commit; patch list updated to reflect expanded set (Matt McCormick 1→7, Shreeraj Jadhav 1→9); one patch carries a WIP: prefix
Modules/ThirdParty/DCMTK/CMakeLists.txt	Removes dcmwlm and dcmrt from _ITKDCMTK_LIB_NAMES; no ITK source code references these libraries, so the removal is clean and consistent with DCMTK 3.7.0 restructuring
Modules/IO/DCMTK/test/CMakeLists.txt	Mirrors the ThirdParty change: drops dcmwlm and dcmrt from the per-library include-path construction list used only for the test driver

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[ITK CMake configure] --> B{ITK_USE_SYSTEM_DCMTK?}
    B -- YES --> C[find_package DCMTK]
    B -- NO --> D[DCMTKGitTag.cmake pin: 1158255a DCMTK-3.7.0 patched]
    D --> E[ExternalProject_Add ITKDCMTK_ExtProject]
    E --> F[Build DCMTK 3.7.0 + ITK patch stack]
    F --> G[DCMTK libs built: dcmdata, dcmpstat, dcmsr, dcmqrdb, dcmimgle, dcmimage, dcmjpeg, dcmjpls, dcmnet, dcmiod, dcmfg, dcmseg, dcmpmap, ijg8/12/16, oflog, ofstd, oficonv]
    F --> H[Removed from 3.7.0: dcmwlm, dcmrt]
    G --> I[ITKIODCMTK test driver]
    I --> J[24/24 tests pass macOS arm64]
    style H fill:#f9d5d3,stroke:#c00
    style D fill:#d5f9d5,stroke:#060

Loading

_{Reviews (1): Last reviewed commit: "COMP: Update vendored DCMTK to 3.7.0" | Re-trigger Greptile}

[greptile-apps]

WIP-tagged patch in the pinned stack

The patch list includes WIP: Do not use non-type template argument -1 in variadic template (Matt McCormick). Using a non-type template argument of -1 in a variadic template is UB-adjacent in pre-C++20 and can trigger hard errors with strict MSVC /permissive- or Clang -Wtemplate-arg-local-addr. On the tested macOS/arm64/Clang configuration this may be silently tolerated, but the same code could fail to compile on Windows/MSVC or with stricter -std=c++20 flags. Could you confirm whether this is intentional (i.e. the patch is known to be incomplete and the WIP label is just a historical artifact of the commit message) or if there is a follow-up planned?