Hi all,
I am trying to align DWI to T1w using FLIRT bbr_reg, the image aligns well, but I am not sure how to rotate the bvecs accordingly. I have obtained an affine matrix that maps from DWI to T1w in world space, should I apply this affine to the bvecs directly?
I compared my registration result withQSIprep, the image data looks similar, but my bvecs is obviously wrong. Is there a common practice (software, command line, package) that could do this?
Thank you in advance!
Runjia
The FSL-format bvec files are in image space, not world space. Therefore, you could apply a linear coregistration with the transform stored in the NIfTI header, for example by using SPM’s coregister function. This is lossless, as you are only changing the spatial transform, and not the voxel data. Since the image data is not resliced, the bvec files will not be influenced.
On the other hand, I would strongly discourage re-slicing the image data. Reslicing image data to a new grid is lossy. You will want to do all your image processing (dwidenoise, degibbs, TOPUP, Eddy, dtifit) in native DWI space. Some of the derived images from this processing (e.g. MD, FA, etc) can be warped to the T1 or standard space (e.g. for TBSS). In general, you can use the b=0 images to shadow register the derived images.
Here is a nice pipeline:
FSL Diffusion Toolbox Practical
I agree with @neurolabusc, why not register your T1w to your DWI?
Also, if you used qsiprep, your T1w image is already registered to your DWI in your outputs and the bvecs have been rotated for you.
You will run into issues with bvec rotation in qsiprep outputs. The bvecs are in DIPY convention (voxel coordinates), not FSL (which is voxel coordinates assuming the voxels are in LAS+ orientation).
If you absolutely must register your DWI to a T1w, I suggest converting to mrtrix .mif format using the .b file in your qsiprep outputs as the value for the -grad argument in mrconvert. Then you can use mrregister and mrtransform and finally mrconvert to get transformed images and bvals/bvecs in FSL convention.
Thank you for your reply! I will follow your advice and keep DWI in naive space. If I must do that in the future, I should try to rotate the spatial trasnform, not to reslice the data. Your reply is very helpful!
Thank you for your reply! I consider aligning DWI to T1w because in QSIprep, eddy-corrected DWI will be registered whether to ACPC (with --dwi_only) or T1w, so I mistakenly thought rotating DWI is a common thing to do. Indeed QSIprep works very well, it already rotates bvecs for me.
Just to conform, did you mean bvecs in qsiprep outputs is not in FSL space? Does that mean I CANNOT directly use qsiprep-preprocessed DWI for FDT (bedpostx, probtrackx)?
Thank you so much, your reply has been very helpful!
You can recon-mode with the arguments --recon-only --recon-spec reorient_fslstd and you will get niftis and bvals/bvecs that will work with FSL tools.
Thank you! I will try it!
Hi expert, I have one more question.
I just checked qsiprep’s code, I found that if I choose eddy for head motion correction, there is a init_dwi_pre_hmc_wf that conforms DWI series from arbitrary orientation to LAS+ (FSL space), the used class is ‘ConformDwi’ (screenshot attached here). My question is, since qsiprep outputs pre-processed DWI in LPS orientation (please correct me if I’m wrong), can I use this function to reorient it from LPS to LAS+ to work with FSL tools?
I really appreciate your open-sourced project, there are many practical utilities in your qsiprep. Thank you in advance.
Runjia
If you’re up for running some python code directly, this is the main function used in the fsl reorientation workflow and will result in the same fsl-usable files without a long qsiprep call and docker/singularity involvement.
There are also probabilistic tractography and ODF estimation workflows outside FSL that are available and worth a look too!
Thank you for your reply! I am running python code directly and glad to know that this could be used directly. I am also excited to check the probabilistic tracing and ODF estimation part, they are very good code. Thank you again for your time!
Runjia
I would carefully validate the qsiprep ConformDwi code. It does reorder and flip the bvec to match the transformation of the image data. However, it does not appear to take into account if the determinant is positive or negative.
I recognize that this is unintuitive, but the FSL bvec fromat adopted by BIDS will enforce a negative determinant by flipping the row order (NIfTI dimension I) for images with a positive determinant, but it does not flip the sign of the bvec. Therefore, if your image is LAS (negative determinant) and you flip the first dimension to get RAS (positive determinant) you should not flip the sign of the first dimension of your bvecs: FSL will read the RAS image as LAS to enforce a negative determinant. Next, consider flipping a LSA (negative determinant) to LPS (positive determinant). In this case, even though the first dimension did not change, you must flip the sign for the first dimension of your bvecs (as FSL will flip the image data as RPS to enforce a negative determinant).
It is unfortunate that this odd format was adopted by BIDS (for full disclosure, I argued against this) and it has caused grief for tools like MRtrix that used a simpler bvec specification. Both AFNI and MRtrix provide methods to test the sign of your gradients. Without these tests, I would be very nervous about transposing your image data.
Thanks for your comment here @neurolabusc. The ConformDWI code was tested against mrtrix’s handling of bvecs using the dcm2niix test data of oblique dmri acquisitions, which admittedly doesn’t cover the many possibilities of image and bvec orientation. Most of the data processed by qsiprep comes directly from dcm2niix, which produces images and bvecs in standard FSL orientation. When these LAS+ images are input, their orientation isn’t changed until after all FSL tools are finished operating on the data. Unfortunately, non-dcm2niix users have to check their results closely.
Even then I still worry about the FSL bvec convention. I wasn’t aware of the extra determinant check, which isn’t emphasized in the MRtrix write-up of bvec handling relative to the handling of the left/right direction. It also doesn’t help that the official BIDS documentation of the FSL bvec format is incorrect and actually describes the DIPY convention.
Perhaps @Runjia0124 your best bet would be to convert the image to mif (using the provided .b file, not the bval/bvec), running dwigradcheck, and then converting back to nifti/bval/bvec will be the best option.
However, this headache only exists for FSL post-processing. The .b file and the btable.txt files will work as expected with mrtrix and dsi studio respectively and the bval/bvec will work with DIPY.
Thank you all @neurolabusc @mattcieslak for your detailed reply! Your information and the attached links are very helpful for me to understand these specs.
Perhaps I should follow @neurolabusc to carefully mind my bvecs, I would convert my source to mif for grad check following @mattcieslak , then I shall consider how to employ the ‘ConformDwi’ code according to my specific data: whether or not to flip my bvecs.
I will report here to let you know if there is any issue in this process. Thank you all again!
Runjia
For completeness, see here is the FSL description of their bvec format, with a nice introduction here. Be aware that some forms of bvec errors may have no impact on some derived measures like FA and MD. dcm2niix documentation includes a description of how to ensure proper bvec specification. Most test cases are only of axial scans (where the column [i] dimension corresponds to left-right), but a thorough test set should include sagittal scans (where columns are the anterior-posterior).
The FSL team deserves high praise for developing and maintaining some of our field core tools. However, users need to be aware of its idiosyncratic features. With regards to enforcing negative determinants, the behavior varies between different tools, e.g. fslstats and fslmath.
Thank you so much for sharing the complete links! I will look through those descriptions carefully, there are indeed a lot more details for a beginner like me to dig in, your attached links are sooo helpful! I will decide which tool to use on my data based on these specs.
I will report back if there are any issues in my test. Thank you!!!
Runjia
MANAGED BY INCF