NRRD file support

The NRRD format specification requires
that extra whitespace after the field descriptor and before the line termination is ignored. However, the function ParseVector vtkNrrdReader.cxx trims the input string, but does not ignore white space within a string.

Therefore, Paraview will parse the vectors:

space directions: (2.9356703758239746,0,0) (0,2.949852466583252,0) (0,0,2.9361956119537354)
space origin: (-75.762535095214844,-110.76253509521484,-71.762535095214844)

But fail to parse the vectors:

space directions: (2.9356703758239746, 0, 0) (0, 2.949852466583252, 0) (0, 0, 2.9361956119537354)
space origin: (-75.762535095214844, -110.76253509521484, -71.762535095214844)

The user is provided with no feedback regarding an error, but no image is displayed. Careful inspection of the image properties will reveal that the spatial “Bounds” all have a delta of zero (e.g. all voxels collapsed to single point).

Here is a small example illustrating this issue.

Looks like a bug and shouldn’t be too hard to fix. Do you think you could submit an issue and work on a fix ?

I have created an issue. I would think a fix would change the code

std::string value = s.substr(0, i);
result.push_back(atof(value.c_str()));

to trim each value:

std::string value = s.substr(0, i);
value = trim(value);
result.push_back(atof(value.c_str()));

Could you push this in a MR ?

Happy to do so. Can you test the fix on your system to make sure it works? If so, I can submit a MR without compiling on my systems.

The issue is observed on the latest stable ParaView 5.8.1. It sounds like some NRRD changes were made to nightly, but nightly builds are not provided for macOS and the nightly builds for Linux do not include the client viewer. I would rather not work out all the compile dependencies for what seems like a small fix.

Fair enough. The buildbots will take care of building and testing the fix.