FSL bvecs handling


#1

Dear all,

so far, I found the following info very useful in trying to correctly interpret FSL bvec files


and I modeled my own scripts on how MRtrix3 handles them.

Unfortunately, I just came across an example in which my scripts exported a bvec file that led FSL 5.0.9 to estimate incorrectly oriented tensors. I tried converting the same DICOM input to FSL format using mrconvert (3.0_RC2-119-gbb9515db) and ran into the same problem. Conversion to .mif and estimating tensors with MRtrix worked fine. Conversion using Chris Rorden’s dcm2niiX version v1.0.20171215 produces output on which both FSL and MRtrix work correctly.

I noticed that, in this case, MRtrix3 and dcm2niiX created .nii files with different coordinate systems:
dcm2niiX:
srow_x 280 4 -2.205553 0.0 0.161747 119.956291
srow_y 296 4 -0.046578 2.118855 -0.628514 -91.637062
srow_z 312 4 0.155782 0.633525 2.102096 -10.426846

mrconvert:
srow_x 280 4 -2.205555 -0.0 0.161747 119.95649
srow_y 296 4 -0.046578 -2.118857 -0.628514 126.605217
srow_z 312 4 0.155782 -0.633526 2.102096 54.82629

Is this, by any chance, a known problem with a known solution?

Thanks / Thomas


#2

Yes, these issues are pretty thorny… There’s a whole host of reasons for these observations, including the possibility that there is no problem as such - hard to say without a very detailed description of what was done.

So first off, as far as I know, this should all work correctly - assuming you’re running an up to date install. First thing to check is whether the DICOM information is actually correct - simplest check here is to avoid NIfTI & bvecs/bvals, and use .mif exclusively, directly from the DICOM data (the amount of internal manipulation of the gradients is essentially zero in that format, so there’s very little that can go wrong). If that works out, and differs from the analysis of the same data in NIfTI & bvecs/bvals format, then that would indeed suggest a bug in MRtrix3 that needs fixing (please send me the data…).

If that’s not the issue, then there is a chance that this could be a bug in whatever you’re using to display the result (there was a bug in a version of fslview a while back that could explain this). But that’s a long shot… Depends on exactly what was done, and what commands from what version of what software package were used at what point, etc…


#3

Thanks for the helpful response. It might be the bug in fslview; do you happen to know which versions were affected? I’m using 4.0.1 (most recent version from neurodebian)

Here is what I did:
Convert DICOM to NIfTI & bvecs/bvals with mrconvert 3.0_RC2-119-gbb9515db (either via .mif or in one shot, didn’t matter)
Estimate DTI with FSL (build 509)
Inspect DTI_V1 with fslview (build 4110)

I don’t own the data, but I will ask if I can share it for debugging if needed.


#4

I have a feeling it was exactly that version - it was definitely the neurodebian-shipped version of fslview 4, as of March 2016. But this was quite a while ago, and the FSL team submitted the relevant patch to neurodebian at the time, so I’d be surprised if that was still a bug… Worth checking with an older version of fslview though, if you can get hold of one…

If you want yet more detail on the issue, this is where a lot of the discussion happened (not all of it though…).