-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
polymorphic pixel type reader #7
Comments
@fbudin69500 Do you think the approach implemented in ITKPython could be generalized ? |
The advantage of ITKPython is that it is... in Python. So wrapping all the possible types is possible (see 1). |
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>
.
|
@pieper thanks for adding the report! |
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
The text was updated successfully, but these errors were encountered: