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