OK, there seems to be a bit of confusion here, I’ll try to clarify.
DICOM typically stores that information in its headers (at least the product sequences from the major manufacturers do). You can check yourself whether MRtrix3 can find this information using
mrinfo your_DICOM_folder, e.g.:
$ mrinfo DICOM/
[21 entries] -0.99949686000000004,-0.0050327100000000001,-0.0050327100000000001,1000
shows a DW scheme with 21 entries, the first of which is a b=0, and the others b=1000 along different directions. Use the
-dwgrad option to display the whole gradient table, by default you only see the first and last 2 lines.
mif format can also store this information. Again, use
mrinfo to see if that information is present in any given
On the other hand, NIfTI (
nii.gz) files don’t store this information. It is typically stored as separate bvecs/bvals files. To analyse DWI data stored in
nii format, you need to also provide the corresponding bvecs & bvals files – and it’s your responsibility to ensure that the information in those files is consistent with the data.
What all this means is that if you’re converting from DICOM to
mif, the DW information will be transferred over. If converting from DICOM to
nii, that information is lost – unless you explicitly request it be stored in bvecs/bvals files with the
-export_grad_fsl option (available in many relevant commands, by the way, not just
mrconvert). For the same reason, this also holds true if you convert from
mif to NIFTI.
If you convert from NIfTI to
mif with no other options, the DW information will not magically appear in the
mif, the command has no knowledge of where you may have stored the DW scheme (or indeed, that you even have it available). So for this step, you need to manually provide them with the
-fslgrad option, at which point
mrconvert will insert the corresponding information into the
mif header (again, you can check with
mrinfo). As before, note that the
-fslgrad option is available in all commands that process DW data, so you can always process your NIfTI data as-is – you just need to always provide the bvecs/bvals as well when you do so.
Our recommendations are to stick with the
mif format throughout your processing pipeline, since we take great care to ensure that information is preserved and modified appropriately when necessary, without users needing to think about it. If you do need to deal with NIfTI at some point (maybe due to interactions with other packages), then we recommend you convert your data to NIfTI at that point, immediately before its use in the other package, to ensure the DW scheme is correct. Likewise, I’d recommend converting right back to
mif when you’re done, to ensure the correct DW information remains as an integral part of that dataset, and guaranteed consistent.
If you use the
-rpe_header option to
dwipreproc, then you will most likely still need to use
mrcat to concatenate the various images. See option 4 in this page. But in terms of what it means, it’s saying that you want to concatenate the images along axis 3, which is the 4th dimension (indexed from zero), i.e. the volume axis. If you’d requested axis 0, then you’d have got all your images concatenated along the x-axis, i.e. left to right, etc. If it’s not supplied,
mrcat will guess which axis might be most appropriate, which will generally do what you expect, but I tend to state this explicitly anyway.
It works for (Siemens) DICOM and
mif (if converted from said DICOM data), and not for NIfTI, for the same reasons as the DW scheme. That information is stored in some DICOM data (only Siemens, as far as we’ve been able to figure out), and can be stored in
mif files too (look for
pe_scheme entries in the
mrinfo output). But as soon as you convert to other formats that can’t store this type of information, it will simply be discarded.
Hope this helps…