Avoid memcpy when possible

[finetjul]

vtkIGTLToMRMLImage.cxx:326 (vtkIGTLToMRMLImage::IGTLToMRML), there is a coslty memcpy.

Instead, the pointer on the array could be passed to the vtkImageData array. For example (I did not try, but something like that could work):

switch(imageData->GetDataType())
   {
   vtkTemplateMacro(static_cast<vtkDataArrayTemplate<VTK_TT>* >(imageData->GetPointData()->GetScalars())->SetVoidArray(imgMsg->GetScalarPointer(), imgMsg->GetSubVolumeImageSize(), /*save*/1);
  }

Of course, the array memory should stay valid for as long as the imagedata is around.

See:
http://www.vtk.org/doc/nightly/html/classvtkDataArrayTemplate.html#a5d4281c3356c18a276ae7a8db8ca0c87
https://github.com/Slicer/Slicer/blob/master/Libs/vtkITK/vtkITKArchetypeImageSeriesScalarReader.cxx#L130-L132

[tokjun]

Thanks for the suggestion. This is a bit tricky issue for the following reasons:

1. Although the array format of the igtl::ImageMessage class is similar to VTK's, the array may contain values in different Endian. I'm not sure VTK can handle it properly. Probably we call memcpy() only when the array uses different Endian? I guess both external software and Slicer use the same Endian in most cases.
2. A thread in the vtkMRMLIGTLConnectorNode will keep updating the array, while it is receiving image stream from external software. So the question is, what would happen if the array is being updated by another thread, while vtkImageData is handling the same array. (I guess it should be safe most of the time, because vtkMRMLIGTLConnectorNode uses circular buffer to pass received images from the connector thread to the main thread...)