[Insight-developers] ImageBase->CopyInformation: Number of components per pixel copied

[Stephen R. Aylward]

Argh!

Thanks for your patience!

Stephen-the-I-cannot-get-hello-world-to-compile-guy  :)

Luis Ibanez wrote:
> 
> Hi Stephen,
> 
> 
> There seem to be a bug in your code.
> Both print outs are from the VectorImage.
> 
> 
> Your second print out:
> 
> 
>  >   std::cout << "Char # of comp = "
>  >             << myVectorImage->GetNumberOfComponentsPerPixel( )
>  >             << std::endl;
> 
> 
> 
> should probably be:
> 
> 
>  >   std::cout << "Char # of comp = "
>  >             << myCharImage->GetNumberOfComponentsPerPixel( )
>  >             << std::endl;
> 
> 
> 
> 
>   Luis
> 
> 
> 
> -----------------------------
> Stephen R. Aylward wrote:
>> Hi,
>>
>> The code below illustrates the problem.
>>
>> That code does the following:
>> 1) Creates a vector image, sets the number of components per pixel, 
>> and prints the number of components per pixel.
>> 2) Creates a "normal" (non-vector) image, calls CopyInfo passing the 
>> vector image, and prints the number of components per pixel.
>>
>> The result is that the number of components per pixel of the 
>> itk::Image<char, 3> image is reported as 3.
>>
>> Should we document, only call SetNumberOfComponents in CopyInfo if the 
>> image is a vectorimage, or other?
>>
>> Thanks,
>> Stephen
>>
>>
>> #include "itkImage.h"
>> #include "itkVectorImage.h"
>>
>> int main(int argc, char **argv)
>>   {
>>   // Create a vector image
>>   typedef itk::VectorImage< char, 3 > VectorImageType;
>>   VectorImageType::Pointer myVectorImage = VectorImageType::New();
>>   myVectorImage->SetNumberOfComponentsPerPixel( 3 );
>>
>>   VectorImageType::SizeType size;
>>   size[0] = 25;
>>   size[1] = 25;
>>   size[2] = 25;
>>   myVectorImage->SetRegions( size );
>>
>>   VectorImageType::SpacingType spacing;
>>   spacing[0] = 1;
>>   spacing[1] = 2;
>>   spacing[2] = 3;
>>   myVectorImage->SetSpacing(spacing);
>>
>>   myVectorImage->Allocate();
>>
>>   std::cout << "Vector # of comp = "
>>             <<  myVectorImage->GetNumberOfComponentsPerPixel( )
>>             << std::endl;
>>
>>   // Create a char image and copy vector images's info
>>   typedef itk::Image< char, 3 > CharImageType;
>>   CharImageType::Pointer myCharImage = CharImageType::New();
>>   myCharImage->SetRegions( myVectorImage->GetLargestPossibleRegion() );
>>   myCharImage->CopyInformation( myVectorImage );
>>   myCharImage->Allocate();
>>
>>   std::cout << "Char # of comp = "
>>             << myVectorImage->GetNumberOfComponentsPerPixel( )
>>             << std::endl;
>>   }
>>
>>
>> Luis Ibanez wrote:
>>
>>>
>>> Hi Stephen,
>>>
>>> That's a good point.
>>>
>>> Notice that yet nothing prevents you from changing the number of
>>> components of the recipient image in the GenerateData() method
>>> of your filter, before you fill in the content of the output
>>> image.
>>>
>>> Note also, that in practice, the SetNumberOfComponentsPerPixel()
>>> method only performs a real action when it is invoked in an
>>> itkVectorImage.   In any other case, ITK images have compile-time
>>> defined number of components per pixel and the call is simply
>>> ignored.
>>>
>>> Are you dealing with a filter that produces an itkVectorImage
>>> as output  ?
>>>
>>>
>>>      Luis
>>>
>>>
>>>
>>> --------------------------
>>> Stephen R. Aylward wrote:
>>>
>>>> Hi,
>>>>
>>>> The CopyInformation function of ImageBase sets 
>>>> largestPossibleRegion, Spacing, Origin, Directions...all good.
>>>>
>>>> However, it also sets NumberOfComponentsPerPixel.   Perhaps this is 
>>>> inappropriate since it is not necessary for the images to have the 
>>>> same pixel type for CopyInformation to work.  Perhaps 
>>>> NumberOfComponentsPerPixel is conceptually a pixel-type-specific 
>>>> piece of information.   Admittedly this is arguable, but consider a 
>>>> filter that has a vector image as input and outputs a scalar 
>>>> image...we cannot use the CopyInformation command.
>>>>
>>>> Of course, the point is perhaps moot given the need for backward 
>>>> compatibility...I cannot think of a backward-compatible solution 
>>>> beyond better documentation.
>>>>
>>>> Stephen
>>>>
>>>
>>
> 

-- 
=============================================================
Stephen R. Aylward, Ph.D.
Chief Medical Scientist
Kitware, Inc. - Chapel Hill Office
http://www.kitware.com
Phone: (518)371-3971 x300