You’d get this message if your input data contains a DW gradient table, but the number of entries in it doesn’t match the number of volumes in your DWI file (here’s where it comes from). This would be confirmed using mrinfo, e.g.:
mrinfo ./Downloads/anger/anger_mrconverted.mif
if that reports a different number of volumes than entries in your DW scheme, that’s the problem. For a well-formed input, this should look like:
Dimensions: 104 x 104 x 54 x 167
...
dw_scheme: [ 167 entries ]
Assuming that’s the problem, it’s difficult to help without knowing the particular of how your input DWI data were produced…
Dimensions: 128 x 128 x 75 x 3
...
dw_scheme: [ 65 entries ]
You have 3 volumes in your image, yet your DW scheme consists of 65 entries. You need to have a look at where your data come from, and make sure you actually have a proper diffusion MRI acquisition here.
So there doesn’t seem to be anything wrong with your DW encoding. As I’d mentioned earlier, the issue seems to be that you only have 3 volumes in your input DW image - there’s no way that can be the full DWI image series, you’ll need to investigate where the data came from to figure out what went wrong.
If your DW encoding file is correct, yes. There’s just no meaningful diffusion analysis you can do with just 3 volumes… And judging by the fact that you’re trying to provide a 65 DW direction encoding, I’m guessing you’re expecting your data to match that - they don’t.
More or less what you had, but just provide the enclosing DICOM folder for the input data. And if your DICOM data are half-decent, you shouldn’t need to provide the DW encoding separately, it should already be in the DICOM headers. So this might look something like (depending on where your DICOM data reside):
If you still get an error about the DW encoding not matching, then my guess is either the data you’re trying to process are not the raw diffusion data, or they were produced by some non-standard implementation (data from the 3 major MRI manufacturers should be fine). Bear in mind that the data may look like a diffusion sequence, but might correspond to a derived metric; for instance, on Siemens scanners, you’ll often find the raw DW series, followed by other similarly named series that correspond to the FA, MD, DEC, etc. (my guess is you have the DEC, given that it comes out as 3 volumes). You need to pick out the raw DW series.
The image for which you have provided the output of running mrinfo is in fact a NIfTI image, not a .mif (see “Format:” field). This format is fundamentally incapable of encoding the diffusion gradient table within the image header; that feature only applies to the MRtrix image format. See documentation on image formats here, and on gradient scheme handling here.
MRtrix3 will capture the gradient table at DICOM import, and propagate it from input to output image for all MRtrix3 commands where appropriate. However if you convert to NIfTI (or any other format) at any point during your processing chain, this information will be lost from the header, and will therefore also be absent from all subsequently-generated images - unless you explicitly import it using one of the -grad or -fslgrad options.
thanks a lot for your quick and clear answer! And sorry for a really basic question, just started using mrtrix.
I was indeed doing a DICOM to NIfTI conversion without the - export_grad_mrtrix / -export_grad_fsl option to export the gradient table, so impossible to retrieve that info later.