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

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:

VTI format (generated with MITK):

• RGB / RGBA 2D-Image: *Wrong data displayed*
• Grayscale 2D-Image: Perfect

VTK format (generated with MITK):

• RGB / RGBA 2D-Image with VTK Legacy Reader: *Wrong data displayed*
• RGB / RGBA 2D-Image with ITK VTKImageIO: *Crash*
• Grayscale 2D-Image with VTK Legacy Reader: Perfect
• Grayscale 2D-Image with ITK VTKImageIO: Perfect

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.

Apparently, a buffer overflow of image data takes place which overwrites random addresses in memory with float values, hence causing crashes at random points. My guess is that the conversion from mitk::Image to vtkImageData is not done properly for RGB/RGBA float data which causes VTK to allocate a smaller buffer than it should.

PS: The VTK Legacy Image reader issues mentioned in the last comment are something completely different (and truly related with reader). More information at T18842.

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.

I think this is related: when loading a vti/vtk image with active scalar array not set, the application crashes. Attached is a simple patch. Consider it signed-off if you like to integrate it.

I think this is related: when loading a vti/vtk image with active scalar array not set, the application crashes. Attached is a simple patch. Consider it signed-off if you like to integrate it.