polymorphic pixel type reader

[pieper]

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

[jcfr]

@fbudin69500 Do you think the approach implemented in ITKPython could be generalized ?

[fbudin69500]

The advantage of ITKPython is that it is... in Python. So wrapping all the possible types is possible (see 1).
In C++, the problem comes with the templates. @pieper : In the example you shared, it seems that you are wrapping only scalar types. I used a similar paradigm (macros) to wrap more types (see 2 and 3). [2] is difficult to read and applied to a complex case, but something similar could be done in ITK. [3] is a more straightforward reader. The example I shared supports scalar, vector, and RGB/RGBA images. One could extend it to other types of images too.

[pieper]

Hi Francois - You're right, I only sent the scalar types, but of course in Slicer we actually instantiate the scalar, vector, color, and even tensor types : D They are broken up in multiple classes because the compilers wouldn't support them all in one compilation unit (the code is all over 10 years old). Looks like the same issues keep coming up over the years, so maybe it's time for some of the useful and clean paradigms to make their way to ITK proper or as a remote module. Cheers, Steve

…

On Tue, May 30, 2017 at 8:00 PM, Francois Budin ***@***.***> wrote: The advantage of ITKPython is that it is... in Python. So wrapping all the possible types is possible (see 1 <https://github.com/InsightSoftwareConsortium/ITK/blob/master/Wrapping/Generators/Python/itkTemplate.py#L419-L481> ). In C++, the problem comes with the templates. @pieper <https://github.com/pieper> : In the example you shared, it seems that you are wrapping only scalar types. I used a similar paradigm (macros) to wrap more types (see 2 <https://github.com/BlueQuartzSoftware/ITKImageProcessing/blob/develop/ITKImageProcessingFilters/Dream3DTemplateAliasMacro.h> and 3 <https://github.com/BlueQuartzSoftware/ITKImageProcessing/blob/develop/ITKImageProcessingFilters/ITKImageReader.cpp#L155-L229>). [2] is difficult to read and applied to a complex case, but something similar could be done in ITK. [3] is a more straightforward reader. The example I shared supports scalar, vector, and RGB/RGBA images. One could extend it to other types of images too. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHsfUcPadZLcC1kNeFST7gzDBGrRBmUks5r_K24gaJpZM4Nq2zN> .

[thewtex]

@pieper thanks for adding the report!