The KWStyle test is currently ignored in test/Docker/test.sh. It should be re-enabled after all header files have been populated.

When using an ITK reader one needs to specify a pixel type, but many file formats, including DICOM, are polymorphic and the actual data type is only known by reading the file.

Slicer includes a layer that queries the data type and then uses macros so that the native data type of the file can be returned. This is all implemented in the VTK code that wraps ITK, such as these examples:

https://github.com/Slicer/Slicer/blob/master/Libs/vtkITK/vtkITKArchetypeImageSeriesReader.cxx#L190

https://github.com/Slicer/Slicer/blob/dac2a3d60e91aeee5912751509455be2217f69fd/Libs/vtkITK/vtkITKArchetypeImageSeriesScalarReader.cxx#L90

It would be great if ITK implemented a more native support for this pattern to simplify the logic for users of the code.

This was discussed as an issue on the Slicer forum topic here:

https://discourse.slicer.org/t/slicer-dicom-scalar-volume-plugin-relies-on-old-gdcm-why-do-we-not-use-dcmtk/354/11

Request from the mailing list:

When I try to save an 8bit 3D image to a single DICOM file using ITK/GDCM, it succeeds. A suitable SOP class (Multi-frame Grayscale Byte Secondary Capture Image IOD) is assigned to the DICOM image. The same code fails when the image is 16bit, though DICOM standard does seem to have a suitable SOP class (Multi-frame Grayscale Word Secondary Capture Image IOD) for the 16bit image.

Port:

https://slicer.readthedocs.io/en/latest/user_guide/modules/dicompatcher.html

into re-usable C++ classes here.

@jcfr