ENH: Add JPEG2000 support

[lassoan]

The change only has effect if CTK is used with DCMTK that is built with DCMTKcs JPG2K module.

[jamesobutler]

Will you be updating the DCMTK build configuration in https://github.com/commontk/CTK/blob/master/CMakeExternals/DCMTK.cmake with the defined option for DCMTK_WITH_DCMJP2KCS? This being for folks or CI building CTK on its own with its defined external projects.

[lassoan]

Will you be updating the DCMTK build configuration in https://github.com/commontk/CTK/blob/master/CMakeExternals/DCMTK.cmake with the defined option for DCMTK_WITH_DCMJP2KCS? This being for folks or CI building CTK on its own with its defined external projects.

Yes, we could do that. It would serve as a simple example and test for DCMTKcs. I would just wait for the DCMTK/DCMTKcs implementation to be finalized - see if we need to fork DCMTK, or DCMTK upstream accepts our patch, etc.

[hjmjohnson]

This looks correct as the first step.

[hjmjohnson]

Quick upstream-status check for reviewers — the DCMTK side of this story is settled.

DCMTK upstream — what landed, what didn't

What	Where	State
DCMTK_EXTERNAL_MODULES CMake mechanism (the prerequisite for building dcmjp2kcs alongside DCMTK without copying it into the source tree)	DCMTK/dcmtk#144 — Make it easier to add external DCMTK modules	Merged upstream as commit d974b87ca. The GitHub PR shows closed (not merged) because the canonical DCMTK repo is internal at Kitware/OFFIS and GitHub is a mirror — see @michaelonken's last comment on #144: "Merged in commit d974b87ca, visible upstream in a few days after running through our internal build dashboard." Reviewed by @michaelonken / @jriesmeier / @eichelberg.
The actual dcmjp2kcs codec module	lassoan/DCMTKcs (community-supported, last pushed 2026-04-14)	Not in upstream DCMTK proper. Built externally via the new DCMTK_EXTERNAL_MODULES mechanism.
Competing / follow-up DCMTK PRs (JP2K, JPEG2000, dcmjp2k)	gh search prs --repo DCMTK/dcmtk	None. Only #144 matches. No open upstream blocker, no superseding work.

Implications for this PR

• The mechanism this PR depends on is in DCMTK upstream as of d974b87ca (2026-04-14).
• CTK's change is purely the consumer-side opt-in, gated on #ifdef DCMTK_WITH_DCMJP2KCS, so it's a no-op for any DCMTK build that does not opt into the codec — fully backwards-compatible.
• Worth confirming that commontk/DCMTK's pinned tag in CMakeExternals/DCMTK.cmake either already contains d974b87ca or gets bumped before any project tries to actually exercise the JP2K path. The #ifdef makes that pre-condition a runtime non-issue, just a build-system one.
• No reason to wait on additional upstream work; this is mergeable from the DCMTK-side as soon as CTK reviewers are happy with the C++ change.

[lassoan]

DCMTK has merged the OpenJPEG library patch today (that was needed to avoid CMake changes in projects that link DCMTK libraries) into their internal repository (see DCMTK/dcmtk#145 (comment)). Their github repository should be updated tomorrow and then I can finalize the changes (move DCMTKcs to the Slicer organization and then finalize merge all the pull requests) in the next few days.