• 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.

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).

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

Apparently, VTK files with multiple colors channels are not being properly handled by MITK which causes the crash on the VTK threads. Yan and I noticed following behaviour with the *.vti / *.vtk files:

This has been confirmed to be broken under Linux as well.

A posssible workaround for this issue would be storing the floating-point data as unsigned chars (like the VTK Legacy Image reader already does). However this would cause a loss of precision.

This has nothing to do with any of the VTK image readers. Any mitk::Image containing RGB/RGBA pixels as float data (like the ones VTKImageIO generates) will make the VTK helper threads crash.