Hi
I have noticed that when I use the function
mrinfo -export_grad_fsl
I get flipped values (fields 1 and 2 but not 3) compared to those made by dwifslpreproc. I am pretty confident the values in the file ‘bevs’ from dwifslpreproc are correct. I see this when using raw data (as from the scanner).
1 Like
Hi Mark,
Whether this is a problem or not depends on the strides / transform of the original and processed data. Because bvecs are specified relative to the axes of the NIfTI header, they will change if the data are regridded, reordered or rotated in any way. One way to check is to look at the output of mrinfo (or alternatively, fslhd) for the raw and processed NIfTI data respectively, and then look at whether the axis vectors or strides have been modified during processing. If you post the output of either or both of these commands for your raw and processed images, we can help interpret that.
Cheers,
Donald.
1 Like
Hello @mschira ,
Also, dwigradcheck can be used for depicting the correct bvecs in addition to strides check.
Cheers,
Suren
Hi Donald
So you are suggesting this is essentially because mrinfo exports the bvec relative to how the data is in the .mif file,
dwifslpreproc exports and rotates the the data fitting for eddy. With the data rotated so need the bvecs?
M.
Edit: and I can confirm the orientation in the mif file is correct and works fine for MRtrix processing and so is the bvec file made by dwifslpreproc.
The thing I wonder is, what is the purpose of the fslgrad bvec file made by mrinfo. It says fslgrad so I would assume it’s fit for FSL, but in truth it isn’t.
Yes – assuming I understand your question correctly. We do our best to follow the convention for the bvecs as per the FSL FAQ. The idea is that when a .mif file is converted to NIfTI, the bvecs produced by the -export_grad_fsl option will be correct for that NIfTI.
mrinfo itself produces no output image, but in this case, it can be used to export the bvecs that would have been produced if that .mif had been converted as-is to NIfTI.
dwifslpreproc will typically re-order the data (‘change the strides’ in MRtrix-speak) to better match FSL’s historical assumptions. We found it best to stick with the standard ‘Analyze’ data ordering (RAS), at least in older versions of FSL. I’m pretty sure this is no longer a concern for more recent versions, but there’s no harm in doing it, so it’s done by default in dwifslpreproc. When that happens, the bvecs will be amended to match if necessary. It’s all done internally and consistently as long as the DW scheme is available somewhere in the input to dwifslpreproc (whether in the image header if data are passed as .mif or DICOM, or via the -grad or -fslgrad options otherwise).
That’s good to hear. No matter what happens, the original bvecs file should be OK to use with the original data, and the amended bvecs file should also be OK to use with its corresponding processed data. But there’s no guarantee that you can mix original bvecs with processed data or vice-versa, because the interpretation of these directions depends on the image axes, and these may have been permuted or modified in some other way during processing.
I’m not sure what you mean by the ‘fslgrad bvec’ file. We provide the -fslgrad option to relevant MRtrix commands to allow passing the bvecs/bvals files as inputs, and we have the corresponding -export_grad_fsl option to allow producing these files as outputs. The files are just bvecs files, and as far as I know are 100% compatible with FSL – we checked all of that with Mark Jenkinson back in 2016 when we came across a bug in our FSL handling. And its purpose is precisely to allow interacting with other packages such as FSL that expect the DW scheme to be provided in bvecs/bvals format.
OK, please provide specifics here so we can investigate. Like I said earlier, I’m pretty confident our handling is 100% compatible with FSL. There are however a million ways to trip yourself up with bvecs/bvals, and I’m hoping (for our sake) that what you’re referring to here is one of those… 
As an aside, I personally recommend not using bvecs/bvals if you can avoid it, and instead rely on the MRtrix .mif format to deal with these issues, since the DW scheme is then stored in the image header and always handled correctly (it’s also stored relative to the scanner/world axes, so its interpretation is independent of the corresponding image). Otherwise, you’ll need to provide the matching bvecs/bvals to every command that requires knowledge of the DW scheme (via -fslgrad), and potentially export the updated bvecs/bvals with every command that may potentially alter them (e.g. any regridding operation).
As an illustration, the following commands change the strides to NIfTI standard orientation (LAS) and omit the first volume. First using NIfTI as input & output:
mrconvert dwi.nii -fslgrad bvecs bvals -stride 1,2,3,4 -coord 3 1:end dwi_reordered.nii -export_grad_fsl bvecs_reordered bvals_reordered
You need to provide bvecs & bvals as both inputs and outputs since the command will definitely modify them (by skipping the first volume) and potentially also permute them depending on whether the strides of the input image already match those requested.
In contrast, using the .mif format, no need to worry about the bvecs/bvals at all since the full DW scheme is stored in the image header (i.e. it’s already an implicit input & output):
mrconvert dwi.mif -stride 1,2,3,4 -coord 3 1:end dwi_reordered.mif
Thanks, Donald I think I understand this now.
It’s a little non-intuitive, but when thinking it through it makes perfect sense.