In my previous comment: *m_NumberOfComponents* should be 3 or 4 (not m_BytesPerComponent).

The root cause of this issue is that the COLOR_SCALARS attribute of the *.VTK files is ignored by the reader. Therefore, the corresponding mitk::Image members are default-initialized (to Scalar/1).

User sanchezb has pushed new remote branch:

bug-18842-vtk-legacy-reader-confidence

• Actual behavior:

The reader always initialize the mitk::Image to a single-component (scalar) object, therefore displaying a odd-looking grayscale image after loading multi-component (rgb/rgba) *.VTK files.

• Expected behavior:

VTK Legacy reader shouldn't be an option, when the file we are trying to load contains multiple components.

• Proposed solution:

Return 'Unsupported' on ImageVtkLegacyIO::GetReaderConfidence if the number of components is bigger than 1.

• Affected classes:

ImageVtkLegacyIO

I thought a little more about the actual problem and disagree with the conclusion.

With the proposed solution, we would not be able to read multi-component VTK Image data encoded in VTK's legacy (ASCII) file format. Actually, we are currently not able to read multi-component VTK image data at all, legacy (ASCII) or standard (XML) VTK formats. This is rather a bug in the MITK code (in mitkImageVtkLegacyIO.cpp as well as mitkImageVtkXmlIO.cpp) not converting the vtkImage object to a mitk::Image correctly.

I would suggest to invest more time in investigating how to convert a vtkImage object to a mitk::Image. The code could be shared between both the ASCII (legacy) and XML based VTK readers.

Yan and me investigated the problem more:

ImageVtkXmlIO calls mitkImage::Initialize(vtkImageData* vtkimagedata, ...) to initialize the mitkImage from a vtkImageData*.
The problem is, that as a PixelType it always assumes a scalar PixelType
(see e.g. line 1010:
Initialize(mitk::MakeScalarPixelType<unsigned int>(), m_Dimension, tmpDimensions, channels);

Solution after talking to Sascha: write a new MakePixelType method, which takes a vtkImageData* and creates the corresponding image type. This should solve the problem.

User wirkert has pushed new remote branch:

bug-18842-fix_pixeltype_for_RGB_A_vtk_images

Core change request:

The problem was that the number of components (in RGBs case: 3) was always set to 1 in the Initialize method of mitk::Image.

Solution:

Make a new MakePixelType(vtkImageData* ) method which gets called by mitkImage::Initialize.

Test:

Create a RGB vtkImage and load it in MITK. See if it is correctly displayed.

[c657d3]: Merge branch 'bug-18842-fix_pixeltype_for_RGB_A_vtk_images'

Merged commits:

2015-03-26 16:42:03 Sebastian Wirkert [a22d37]
Correctly set PixelType for vtkImageData*.