IOTransformDCMTK example uses GDCM fallback; verify DCMTKImageIO MetaDataDictionary path works end-to-end

[hjmjohnson]

Background

While ingesting IOTransformDCMTK into ITK proper (PR — pending; ITK#6308), the example test driver still relies on GDCM instead of DCMTK for series-reading + MetaDataDictionary access:

// Modules/IO/IOTransformDCMTK/test/itkDCMTKTransformIOResampleTest.cxx
// (the upstream comment removed during refactor said:
//   "DCMTKImageIO does not populate the MetaDataDictionary yet")
using ImageIOType = itk::GDCMImageIO;
using SeriesFileNamesType = itk::GDCMSeriesFileNames;
...
ITK_TEST_EXPECT_TRUE_STATUS_VALUE(
    itk::ExposeMetaData<std::string>(fixedMetaDataDict, "0020|0052", fixedFrameOfReferenceUID),
    testStatus);

This is awkward because the module under test is the DCMTK path, but a DCMTK test depends on GDCM to extract the Frame-of-Reference UID.

State of the world today

The original gap (no metadata population in DCMTKImageIO) was filled by 54887f7e9b (ENH: add missing metadata to DCMTKImageIO) — DCMTKImageIO::ReadImageInformation() now calls DCMTKFileReader::PopulateMetaDataDictionary(this->GetMetaDataDictionary()) at line 481 of Modules/IO/DCMTK/src/itkDCMTKImageIO.cxx. Further refinements landed in b99df555e1 (skip EVR_SQ), f5a977cf49 (cover binary VRs), and 394306614d (encapsulate the metadata loop in DCMTKFileReader).

So DCMTKImageIO does populate the MetaDataDictionary for a single-file read.

What still needs verification / work

1. Does ImageSeriesReader<…>::Update() propagate DCMTKImageIO's MetaDataDictionary correctly after reading a series? GDCM's GDCMSeriesFileNames participates in this; DCMTK's DCMTKSeriesFileNames does not currently expose the same series-grouping API by the same name. Worth a small standalone test.
2. Is itk::ExposeMetaData<std::string>(dict, "0020|0052", uid) retrievable from a DCMTKImageIO dictionary? The PopulateMetaDataDictionary loop encodes keys as "GGGG|EEEE" (lowercase hex) and stores values as std::string — but only for non-binary, non-sequence VRs. Frame-of-Reference UID (tag (0020,0052)) is VR UI, so it should be there.
3. DCMTKSeriesFileNames API parity with GDCMSeriesFileNames — does the type have SetInputDirectory, GetInputFileNames, GetSeriesUIDs with comparable semantics?
4. Swap the example in Modules/IO/IOTransformDCMTK/test/itkDCMTKTransformIOResampleTest.cxx from GDCM* to DCMTK* once 1–3 above are verified. Confirm the baseline image still matches.

Acceptance

• A patch in Modules/IO/IOTransformDCMTK/test/itkDCMTKTransformIOResampleTest.cxx that replaces itk::GDCMImageIO/itk::GDCMSeriesFileNames with their DCMTK* counterparts.
• The image baseline DATA{Baseline/DicomTransformResampledMovingOutputBaseline.mha} still matches under the swap.
• No new ITK module dependencies introduced (the test already TEST_DEPENDS ITKIOGDCM ITKIODCMTK).

Provenance

• Module ingested into ITK in PR — pending (parent of this issue).
• Related: ITK#6308 (test improvements migrated from ITKIOTransformDCMTK#5).
• Original upstream remote-module comment that became stale: Modules/IO/IOTransformDCMTK/test/itkDCMTKTransformIOResampleTest.cxx history.