[Insight-developers] Problems with typeinfo logic in itkImageIOBase

[Kent Williams]

I'm trying to enhance the itk::NiftiImageIO class so that it can read 
and write images with a pixel type of complex. I have a problem, though:

In NIfTI-world, an image of complex pixels will have one component per 
pixel of one of three complex types -- 64 bit complex (i.e. 
std::complex<float>)
128 bit complex (std::complex<double>) and 256 bit complex 
(std::complex<long double>. That last type is patently absurd and mostly 
non-portable, so I am not going to bother with it.

But when you into the itk::ImageIOBase::SetPixelTypeInfo, it sets the 
Pixel type to itk::ImageIOBase::COMPLEX, the Compenent type to double or 
float, and the number of components to 2.

This seems screwy to me, because there's going to be only one component, 
of a std::double<> type.  Right now this makes the itk::NiftiImageIO 
class to think it has to read and write twice as much data as it really 
needs to.

The question is this: should I

1. leave itk::ImageIOBase alone, and just accomodate the fact that if 
the pixel type is complex, assume itk::ImageIOBase is lying about the 
number of components
or
2. try to get itk::ImageIOBase to understand that a pixel of type 
std::complex<> only has one component per pixel, unless it's a vector of 
std::complex<> ?

The original goal was to try and accomodate images whos pixel type was a 
vector of complex, but I've tabled that. Now I'm just trying to get it 
to read images of pixel type complex, and use the fourth dimension to 
specify how many complex numbers are in the file per pixel.