Demian, you commented out bvalue computation on line 853 in MRMLIDImageIO
::SetDWNodeValues(). That's what causing the crash. Please investigate.

Demian can also help sort this out.

I am pretty sure the problem comes from Slicer, but I could be wrong. When I run this module in a terminal, it seems to work perfectly. However, from within Slicer4, it crashes, or gives a bad output.
The type of the output image is defined by <image type="any"> in the xml description file. In Slicer3, that meant that the user had to choose the type of node for the output image (Scalar, Vector, DWI). However, in Slicer4 this option has disappeared, and I am guessing Slicer creates the wrong type of node, thus leading to a crash of the application.

I just tried to replicate this bug on a build of the current trunk (r22207). I followed the steps listed above but got no crash and the result looked reasonable (mac, debug build).

I just realized some tests with the nightly build for linux64 (r22208) and here are my results:
-I select a DWI as an input, and create a new node as an output->It runs but the result is an image with diagonal stripes and multiple slices on one slice (4D image badly converted into a 3D image?)
-I select a DWI as an input and select the same node as the output->Slicer crashes
-If I run the module in a terminal and load the result in Slicer->It works

I was able to reproduce this. I'm using a mac with a developer build of the current trunk (r22209).

Steps:

• download sample data DWI
• select resample scalar/vector/dwi module
• pick dwi as both input and output (other parameters as defaults)
• run the module and there is a crash with a similar dump as in the original report.

@Demian -

Can you have another look at what you did in this commit:

https://github.com/Slicer/Slicer/commit/bc3f4d6b

You commented out a block of code (why?) that included the line which populates the bvalues vector:

https://github.com/Slicer/Slicer/blob/master/Libs/MRML/IDImageIO/itkMRMLIDImageIO.cxx#L859

As a result, when I run the steps from my previous note in the debugger, it crashes at line 875 because it accesses past the end of the vector:

https://github.com/Slicer/Slicer/blob/master/Libs/MRML/IDImageIO/itkMRMLIDImageIO.cxx#L875

Thanks in advance,
-Steve

I had commented that because it was performing the normalization of the gradients. And, in some cases incurr in a divided by 0 error on line 884 and also generated a discrepancy when loading and saving the same file without modificationts.

https://github.com/Slicer/Slicer/blob/master/Libs/MRML/IDImageIO/itkMRMLIDImageIO.cxx#L884

The gradients of the DWI image should be normalized by its specification so, including a new normalization seemed like something that should not have been done here. Probably a better idea would have been to throw an exception and force the code making use of this of this IO to perform the normalization on the outside.

What do you think?

I forgot to say that the NRRD spec is that there is only 1 reference b-value and then the norm of each gradient times that b-value is the actual b-value of the DWI image. When I looked at the code to handle this in ITK, this was the case but maybe it was update to a different scheme now?
(comment for François on the bottom)

It is not clearly documented if we should keep that (meaning erasing line 895) or normalize all gradients again.

I'm currently off site. I can check this beter next week.

@Francois, could you check how is that you are feeding the gradient directions into the output? Are they according to the NRRD standard? (1 reference bvalue and the b-value of each gradient is the norm of the gradient times the reference one)

Thanks

In ResampleScalarVectorDWIVolume, when transforming a DWI, the transform is applied directly to the gradient vector. The vector is not normalized. This, as far as I understand follows the NRRD specifications that Demian was mentioning. See:
https://github.com/Slicer/Slicer/blob/master/Modules/CLI/ResampleScalarVectorDWIVolume/ResampleScalarVectorDWIVolume.cxx#L1009-L1024

The gradient directions are then just written in the output image metadata dictionary as they were in the input image.

Warning: obviously, the user has to be careful to only apply a rotation or a translation transform (rigid transform in ITK3), otherwise the output image will be meaningless.

Did we get a final resolution on this?

@pieper: the steps provided in the original report crash Slicer as before, so nothing changed as far as the user is concerned

The problem is still the same. Seem my comment (0009106) above. Slicer4 still does not offer to choose the type of the output node for a CLI. In Slicer3, the user had to choose. In Slicer4, to select the output of the CLI, the user can either create a new volume (scalar, no choice), or use an existing volume.
If the user specifies an existing volume that is a DWI to resample a DWI, it is going to work. If the user specifies a volume that is not a DWI, or creates a new volume (which is going to be a scalar volume), Slicer is going to crash.

We think we have a plan:

• vtkMRMLNode* qMRMLNodeComboBox::addNode() could be expanded to accept a parameter of what class to create
  • the CLI widget could be configured to have all the valid classes that the output could create (right now the variable output types of this module are specified by the "any" type)

It seems feedback from Julian is needed.

Seems like a good plan. The baseName property could become a QStringList to support multiple node types that can be created by the combobox.
As a hack, qMRMLNodeComboBox:: addMenuAction() could also be used.

Resolving the issue since I am not able to reproduce this problem using Slicer r23759.

Please, re-open if this is still a problem.

Steps to reproduce the error:
-Download latest nightly (r23755)
-Start Slicer and download the example DWI image (Download Sample Data->Download DWIVolume)
-Open Resample Scalar/Vector/DWI Volume
-Select "dwi" as your input node
-Create new volume for the output volume
-Run
->Crash

Additional note: If you run the module with a scalar image, it will work correctly. The problem is that Resample Scalar/Vector/DWI Volume can create different types of output depending on the input image. In Slicer3, the user would select the type of the output node when creating a new output volume. In Slicer4, this is not the case anymore. The output volume created is always a scalar volume, which will lead to Slicer crashing if you run this module with a vector image or a DWI.

Looking at this issue, I tried the following:
(1) Load DWIVolume from sample data
(2) Open "ResampleScalarVectorDWIVolume" module
(3) Create a new parameter set
(4) Select "dwi" as input
(5) Create a new ouput of type "DiffusionWeightedVolume"
(6) Click on "Run"

Then, if I either wait or click on "Cancel", it crashed in the function "MRMLIDImageIO::SetDWNodeValues".

The function tried to get the values of the "bvalues" vector never filled with values. See [1]

This regression was most likely introduced by r20150 (BUG: Fixed bug 0002062, 0001781: problem when loading and saving DWI files) in an attempt to address 0002062 and 0001781

[1] https://github.com/Slicer/Slicer/blob/e4ebd3b2cb90a228871474bfa679cba453fb841d/Libs/MRML/IDImageIO/itkMRMLIDImageIO.cxx#L905-L950

We revisited this issue as part of our developer hangout [1]. Looking at the code that was commented out [2] it seems that

(1) the b-values are needed in order to avoid the crash reported here

(2) the gradients should be normalized for a mrml diffusion weighted volume node [3]

(3) there seems to be a mistake in the commented out code that it is missing a factor of 2 compared to the documentation [4]. That is, if the reference b-value is 1000, a vector 1,1,0 should have a b-value 1000 and a vector .707,.707,0 should have a b-value of 500, but the code in the block that is comment out [2] doesn't account for that factor of 2.

[1] http://www.slicer.org/slicerWiki/index.php/Developer_Meetings/20150922#To_Discuss

[2] https://github.com/Slicer/Slicer/blob/e4ebd3b2cb90a228871474bfa679cba453fb841d/Libs/MRML/IDImageIO/itkMRMLIDImageIO.cxx#L924-L937

[3] https://github.com/Slicer/Slicer/blob/e4ebd3b2cb90a228871474bfa679cba453fb841d/Libs/MRML/Core/vtkMRMLDiffusionWeightedVolumeNode.h#L27-L33

[4] http://wiki.na-mic.org/Wiki/index.php/NAMIC_Wiki:DTI:Nrrd_format#Describing_DWIs_with_different_b-values

I don't think this issue should be assigned to me. It is a problem in Slicer, not in ResampleScalarVectorDWIVolume.

Hi Francois,

I guess it was assigned to you because the problem initially happen when using ResampleScalarVectorDWIVolume.

That said, what do you think of the comment in http://www.na-mic.org/Bug/view.php?id=2466#c13303 ?

To answer Demian's question, ResampleScalarVectorDWIVolume does not much with the gradients. If the input image contains gradients (i.e. it is a DWI), it transforms them if the given transform is invertible. If the transform is not invertible, it gives a warning/error message. So if the input DWI respects the NRRD standard, the output DWI will also respect the NRRD standard. One should not use this module to resample a DWI with an affine transform. Even though this module will give an output, the output is not going to be correct.

Hi guys. I see this is assigned to me but I am confused. Is there still a crash in this module as in the initial bug? Or is the bug now that the expected behavior is not produced when the DWI volume is inside an affine transform?

As another note, I believe the documentation [4] mentioned by Steve is incorrect, as I noticed looking at it recently, so this should be revisited. I believe the numbers in the example are wrong (the .707 should either be squared or the square root, or similar. I forget exactly what now).

[4] http://wiki.na-mic.org/Wiki/index.php/NAMIC_Wiki:DTI:Nrrd_format#Describing_DWIs_with_different_b-values [^]

Thanks for your comment.

And do you have any feedback regarding the specific issue reported in http://www.na-mic.org/Bug/view.php?id=2466#c13303

Thanks JC. I see now where I should look. I will have to look into this more next week when I am back from MICCAI.

I don't have any additional comment. The only thing that is dangerous with Slicer though is that if you let the user choose the type of output volume like in ResampleScalarVectorDWIVolume, even if everything goes well during the computation and that the problem mention above is corrected, Slicer might still crash if the user chooses the wrong type of output (e.g. if the user chooses a DTI or scalar output node when the input was actually a DWI). But that is a different issue.

I agree with Francois that we should look at how to handle this polymorphic case in the execution model.

Lauren, maybe you and I can talk about it at some point. I agree that documentation in [4] surprised me.

I believe what is wrong in [4] is that the b-value in the NRRD header should be 500 as it would have the b-vectors corresponding to b=500 normalized (which they are) and the b-vectors corresponding to b=1000 with a norm that is larger than one [norm_7 = 1 sqrt (1000/500) = sqrt(2) = sqrt( 11 + 00 + 11 ) ]. Otherwise the norm of the b-vectors that correspond to b-val=1000 should be normalized and the norm of the vector corresponding to b-val=500 should be smaller than 1 (sqrt(1/2)), and therefore DWMRI_gradient_0001:=.5 0 .5

Fixed in r24724
See http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&amp;revision=24724