Problem in perfoming MSMT constrained spherical deconvolution

Dear Matrix Experts,

I’m trying to follow the HCP tutorial: http://mrtrix.readthedocs.io/en/0.3.16/tutorials/hcp_connectome.html *

and now facing a problem with performing multi-shell, multi-tissue constrained spherical deconvolution.

I ran the following command:

dwi2fod msmt_5tt DWI.mif RF_WM.txt WM_FODs.mif RF_GM.txt GM.mif RF_CSF.txt CSF.mif -mask nodif_brain_mask.nii.gz

but got an error as follows:

dwi2fod: [100%] uncompressing image “nodif_brain_mask.nii.gz”
dwi2fod: [ERROR] unexpected value supplied for argument “algorithm” (valid choices are: csd, msmt_csd)

So I used msmt_csd instead of msmt_5tt and WM_FODs.mif, GM.mif, CSF.mif, was created.
After that, I ran the following command:

mrconvert WM_FODs.mif - -coord 3 0 | mrcat CSF.mif GM.mif - tissueRGB.mif -axis 3

and had this following warning

[WARNING] Diffusion encoding of input file does not match number of image volumes; omitting gradient information from output image

I first ignored this warning and went through all the step to connectome generation (tck2connectome).
But when I tried to visualize with mrview with following command:

mrview nodes_fixSGM.mif -connectome.init nodes_fixSGM.mif -connectome.load connectome.csv

I got this error massage:

mrview: [ERROR] Input parcellation image must have an integer datatype; try running mrconvert -datatype uint32
mrview: [ERROR] Connectome matrix contains 84 nodes; expected 0

I guess this error is due to the ignoring the warning appeared during diffusion image processing.
Is it because I used msmt_csd instead of msmt_5tt? (but the command dwi2fod msmt_5tt DWI.mif … didn’t work for me)

Thanks :slight_smile:
Lee

*now located at Processing of HCP data

Hi Lee,

dwi2fod: [ERROR] unexpected value supplied for argument "algorithm" (valid choices are: csd, msmt_csd)

That’s me stnanking the documentation in light of the most recent tagged update. dwi2response has an algorithm called ‘msmt_5tt’, named such because it uses a five-tissue-type (5TT) image to assist in determining appropriate tissue response functions for the MSMT algorithm. But longer-term, this will not be the exclusive algorithm for determining response functions for the MSMT algorithm. In dwi2fod, the algorithm is referred to as msmt_csd.

Thankfully the terminal error pointed you in the right direction, but thanks for letting us know: I’ll fix the documentation imminently.

[WARNING] Diffusion encoding of input file does not match number of image volumes; omitting gradient information from output image

The MRtrix3 developers have had multiple internal arguments about this issue. What’s happening here is:

  • MRtrix3 will store the diffusion gradient table within the image header where possible. In this particular example, these data are used by dwi2fod.

  • These data are also propagated through to the image(s) output by dwi2fod. Note however that these images are not diffusion volumes, but represent coefficients in the spherical harmonic basis. Therefore, the number of volumes in such an FOD image will almost always differ from the number of DWIs (and hence the number of entries in the diffusion gradient table).

  • Later, when you run mrconvert -coord 3 #, the mrconvert command observes that you are extracting a subset of image volumes, and tries to extract only the appropriate corresponding entries in your diffusion gradient table. But it can’t do this unambiguously, since there is a mismatch between the number of diffusion gradient table entries, and the number of image volumes. Therefore, it discards the gradient table, and warns you that it is doing so.

Some argue that the diffusion gradient table is no longer relevant / necessary if an image contains spherical harmonic coefficients, and will inevitably result in ambiguous cases and corresponding warnings such as this, and should therefore be erased from the image header by dwi2fod. Others argue that knowing the diffusion gradient table that was used in deriving a spherical harmonic representation may still be useful later on.

We welcome user feedback regarding what people think is the most intuitive / useful behaviour here.

mrview: [ERROR] Input parcellation image must have an integer datatype; try running mrconvert -datatype uint32 mrview: [ERROR] Connectome matrix contains 84 nodes; expected 0

This is not to do with the diffusion image processing, but the parcellation image nodes_fixSGM.mif. A ‘label image’ must by design contain integer values corresponding to different parcels. Therefore, the mrview connectome tool will refuse to be initialised by an image that is stored using a floating-point value type. Note that it’s possible for an image to in fact contain only integer values, despite using a floating-point data representation; but I chose to instead enforce the data type of the image when used as the parcellation image in the mrview connectome tool, as a way of guaranteeing that an appropriate image is being provided.

Short-term, you can use the suggestion contained within the terminal error message to fix the problem:

mrconvert nodes_fixSGM.mif nodes_fixSGM_int.mif -datatype uint32

Longer-term, I’ll need to figure out where the issue is arising and fix it. labelconvert explicitly makes the output image an integer type for precisely this reason, so there must be a command being used within the labelsgmfix script that is setting the image type back to floating-point.

The second error line:

mrview: [ERROR] Connectome matrix contains 84 nodes; expected 0

is a red herring. That’s mrview loading your connectome matrix, and checking to see if it has the same number of rows/columns as your parcellation image has parcels; but because the parcellation image didn’t load properly, there’s an inevitable mismatch between these two quantities.

Thanks for the reports, and welcome to the forum!
Rob

Thanks for your help Rob.
Now it runs without any errors :slight_smile:

Thanks again.
Lee