The issue is not in the NRRD reader, as a .mha version of the file (attached) crashes the same way.
However, there is no crash when the volume is loaded directly using a VTK reader, only when loaded into a volume node.

Crash:

<pre>
[success,vol]=slicer.util.loadVolume(r'c:\D\S4\Modules\CLI\ResampleDTIVolume\Data\Baseline\dt-helix-ref-BS.mha', returnNode=True)
reslice = vtk.vtkImageReslice()
reslice.SetInputData(vol.GetImageData())
reslice.Update()
</pre>

No crash:

<pre>
reader=vtk.vtkMetaImageReader()
reader.SetFileName(r'c:\D\S4\Modules\CLI\ResampleDTIVolume\Data\Baseline\dt-helix-ref-BS.mha')
reader.Update()
reslice = vtk.vtkImageReslice()
reslice.SetInputData(reader.GetOutput())
reslice.Update()
</pre>

backtrace for crash in https://issues.slicer.org/view.php?id=4416#c15053

    frame #0: 0x0000000119dd9d02 libvtkImaging-7.1.1.dylib`void (anonymous namespace)::vtkReslicePermuteExecute<double>(self=0x000000014364a120, scalars=0x0000000000000000, interpolator=0x0000000144fc7c30, outData=0x0000000144fb2a00, outPtr=0x0000000127f1cf20, scalarShift=0, scalarScale=1, convertScalars=00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00, outExt=0x000070000f4b7eb0, threadId=1, matrix=0x000070000f4b7d20)(void*, void*, int, int, int, int, int, int, int), int*, int, double (*) [4]) at vtkImageReslice.cxx:2837
   2834
   2835   // if doConversion is false, a special fast-path will be used
   2836   bool doConversion = true;
-> 2837   int inputScalarType = scalars->GetDataType();
   2838   if (interpolationMode == VTK_NEAREST_INTERPOLATION &&
   2839       inputScalarType == scalarType && !convertScalars && !rescaleScalars &&
   2840       nsamples == 1)

In the backtrace above, scalars is passed down null, soscalars->GetDataType() segfaults. I don't know if that is considered a bug in vtkImageReslice, but I think the assumption that the image has scalars attached is pervasive...

The origin of the crash is the lack of scalars attached to the vtkImageData by the reader, because the imagedata is storing tensors instead.

In interactive use, this works out fine (we use the DT slice view feature very often), because scalars are assigned by the tensor -> scalar filter pipeline in vtkMRMLDiffusionTensorVolumeSliceDisplayNode. I guess the crash happens when Modified() is called directly because the pipeline has not been updated.

It is definitely a bug in vtkImageReslice. It should be checked that "scalars" is non-null before it is used. It is done like that it many other filters where GetDataType() is used.

@inorton, could you add a null-pointer check into vtkImageReslice and submit a pull request to VTK? If not, then we may ask David Gobbi (author of this class) to get this fixed.

I was able to reproduce this in Slicer r27094

In vtkImageReslice::ThreadedRequestData, I tried adding the following without success:

  [...]
  // Get the input scalars
  if (inData[0][0] == nullptr ||
      inData[0][0]->GetPointData() == nullptr ||
      inData[0][0]->GetPointData()->GetScalars() == nullptr)
  {
    return;
  }
  vtkDataArray *scalars = inData[0][0]->GetPointData()->GetScalars();
  if (scalars == nullptr)
  {
    return;
  }
 [...]

This doesn't happen with the dti sample data. Does it happen in practice with real data or only with the synthetic helix dataset?

It crashes the same way with the DTI sample data (DTIVolume.nhdr+raw):

<pre>

Load volume

import SampleData
logic = SampleData.SampleDataLogic()
vol = logic.downloadDTIBrain()

Force rendering pipeline update

vol.GetImageData().Modified()
slicer.app.layoutManager().sliceWidget('Red').sliceView().renderWindow().GetRenderers().GetItemAsObject(0).Render()
</pre>

You can also trigger the crash by just calling Modified() on the image then interacting with a slice viewer:

<pre>

Load volume

import SampleData
logic = SampleData.SampleDataLogic()
vol = logic.downloadDTIBrain()

Force rendering pipeline update

vol.GetImageData().Modified()

now add markup in a slice view => it will crash

</pre>

When I removed this hack (https://github.com/Slicer/Slicer/blob/f553c8c881c0438b0c6c229d713d430a4c95e7b0/Libs/MRML/Logic/vtkMRMLSliceLayerLogic.cxx#L678-L684) then Slicer crashed in a very similar way (there seems to be a mismatch between the expected and actual scalar type: double/float), so maybe the issue is that this workaround is not applied when calling Modified() on the input image data. The proper solution might be to fix this in VTK (but interestingly, the bug is supposed to be fixed already - see https://www.paraview.org/Bug/print_bug_page.php?bug_id=14692).

I discussed this with David Gobbi in email. vtkImageData does not support "new" (5-year-old) VTK pipeline. Imaging filters have just been upgraded to remain functional, but for example you cannot change the active scalar via pipeline (but it is hardcoded in vtkImageData object - for example vtkImageData:: GetScalarType() always uses the active scalar set in the data object and ignores information objects in the pipeline).

It would be significant effort to update the vtkImageData and all imaging filters to work properly with the new pipeline infrastructure. It would be a good time to work on this when we introduce image orientation to vtkImageData.

Until then, we must not use vtkAssignAttribute with vtkImageData. It is not supposed to work, and it does not work (with the current hack it sort of works, but a simple Modified() call on the image data crashes the application). We must only store a single point scalar array in vtkImageData (we can store tensor data in a 9-component float/double array, the same way as VTK nrrd reader does it).

@ihnorton Could you update DTI reader to store tensor data in a 9-component scalar in vtkImageData? This would allow simplification of the DTI image display pipeline: you could remove the two vtkAssignAttribute filters and remove the ugly hack.

Following discussion during the last Slicer hangout, we are re-targeting this issue.