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
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
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!