Hi MRtrix experts,
Apologies if this has been answered elsewhere.
I’m currently working on converting a dataset from Nifti to Mif. As I understand, Nifti-formatted files are unable to store gradient direction information in the header of the associated image, and are instead contained in separate “bvec and bval” files.
However, the dataset that I am working on contains two separate bvec files (“dti.vecs_absolute” and “dti_bvecs_image”). I’m just wondering what are the differences between the two, and which would be the most appropriate file to specify in
I’d expect it should be
dti_bvecs_image – FSL bvecs are expected to be provided with respect to the image frame of reference. I’m guessing the other one refers to the vectors with respect to world/scanner coordinates (which incidentally is how MRtrix & DICOM manipulate them internally). More details on the DW scheme handling page.
Thanks for your response @jdtournier!
I have converted all of the images from nifti to mif using
dti.bvecs_image instead of
dti.bvecs_absolute as suggested (sorry, I noticed a typo I had made with naming the bvec files in my previous post! ).
Overall, this approach seemed to have worked successfully (i.e. the images are opening up in
mrview). I have provided the
mrinfo output of one subject as an example below. Please note that I’m using the
mrtrix3tissue module on a HPC, but also hoping to leverage some of functionalities from the most recent update of
mrtrix3 in my pipeline. Is there anything else I should look out for to ensure that the conversion was successful?
Dimensions: 64 x 64 x 50 x 65
Voxel size: 3 x 3 x 3 x 5.2
Data strides: [ -1 2 3 4 ]
Data type: signed 16 bit integer (little endian)
Intensity scaling: offset = 0, multiplier = 1
Transform: 1 -0 -0 -93
0 1 -0 -93
-0 0 1 -74.95
command_history: mrconvert 29254/dti_2/dti.nii.gz 29254/dti_2/dwi.mif -fslgrad 29254/dti_2/dti.bvecs_image 29254/dti_2/dti.bvals -force (version=3Tissue_v5.2.8)
[65 entries] 0,0,-1,1000
Ok, that’s good to hear. First thing to note, which you’re hopefully aware of, is that the version you’re using is not endorsed by the MRtrix team (see e.g. this post). That’s not to say it won’t work, but if you come across issues, the first thing we would ask for is replication with one of our official releases.
In terms of checking whether that worked as expected, the simplest is visual inspection, but that requires some familiarity with what to expect. Another way to check is to use the dwigradcheck command, which comes in handy in such cases.