Gradient flipped in the x-direction - FSL bvecs handling

[arnaudbore]

Hi everybody, I play a lot with MRtrix / FSL / Dipy at the same time and I've got some trouble with this "new/old" problem: http://www.mrtrix.org/2016/04/15/bug-in-fsl-bvecs-handling/ I handle bvec/bval/b generation using MRtrix. It seems that FSL has updated its documentation as well: http://fsl.fmrib.ox.ac.uk/fsl/fslwiki/FDT/FAQ#What_conventions_do_the_bvecs_use.3F I'm using dipy 0.10dev and when I reconstruct tensor I get this x-flip.

[arokem]

AFAIK, we have nothing to mitigate this issue. Would be good to have a little bit more information, what did you do that resulted in this flip? How did you go about diagnosing it ("how do you know it's wrong?")?

[arnaudbore]

Since the new version of MRtrix their "new" way to extract bvecs and bvals files results in reconstructed tensors flipped in the x direction when using dipy (Everything is correct with dtifit from FSL or dwi2tensor from MRtrix).

[arokem]

Do I understand correctly that the way to mitigate this is that if either mrtrix or FSL have touched your b-vectors, you should multiply them by a np.array([-1, 1, 1]), and then everything would be alright in dipy? Would a note in the documentation be sufficient for now?

[arnaudbore]

I agree but some investigations have to be done in order to understand what I've been done and then better handle bvecs because dipy misses something here.

[arokem]

Sure - if you could point to an example that demonstrates what might go wrong, that would be very helpful!

[arnaudbore]

Question related to this x-direction flip: I manage to flip the reconstructed tensor multiplying gradientTable.bvecs by np.array([-1, 1, 1]) but it didn't work with CSD reconstruction. I finally found that I needed to flip gradientTable.gradient in order to make it works. Why do you use two different ways to store and use the gradient table ?

[arokem]

This one's pretty old. I think we can close it. Feel free to reopen if you think this is still relevant.

[ebrahimebrahim]

I got bit by this issue.

• this is the problem: FSL generates bvecs with an x-flip when processing images that have left handed coordinates
• mrtrix had to deal with this before

This is not a problem with dipy -- dipy simply makes the very reasonable assumption that the b-vectors are given in the coordinate system defined by the image axes. But people will run into this problem if they process certain images with FSL and feed the b vectors table into dipy.

I propose the following solution: Add an argument to some of the gradient table creation functions in dipy.core.gradients called something like flip_x with a default value of False. Update docstrings to include (in a non-prominent place towards the end of the current docstrings) an explanation of when this option is expected to be needed: when the bvecs are in FSL convention and the 3x3 rotation component of the affine has ~~negative~~ positive determinant.

I think it is also reasonable not to address this in dipy and leave it up to the user to manually do the x flip before using gradient_table_from_bvals_bvecs.

Also the original post here is pretty old, and yet I'm running into this again in 2023. The fact that I'm the only one running into this again up till now suggests that I may be missing something...

@arokem @skoudoro Please let me know what you think, and if you think this ought to be addressed in dipy at all then please re-open this issue. Happy to contribute if so

[skoudoro]

Hi @ebrahimebrahim,

Thank you for the feedback.

if they process certain images with FSL and feed the b vectors table into dipy.

certain images ?

I propose the following solution: Add an argument to some of the gradient table creation functions in...

I believe that the bvecs should be flipped/corrected before creating a gradient-table.

I do not recommend to update gradient_table_from_bvals_bvecs. I personally prefer 1 function == 1 task.

I think it is also reasonable not to address this in dipy and leave it up to the user to manually do the x flip before using gradient_table_from_bvals_bvecs.

Exactly, this is user specific. I need check if we have a function to flip bvecs. If not, we should create this function and explain somewhere that if you are using FSL, you should call this function before creating a gradient table. this is the approach I would recommend but open to any other opinion.

Also the original post here is pretty old, and yet I'm running into this again in 2023. The fact that I'm the only one running into this again up till now suggests that I may be missing something...

We need to clearly document it.

reopening the issue

[ebrahimebrahim]

certain images ?

By this I just meant images for which the bvecs are in FSL convention and the 3x3 rotation component of the affine has ~~negative~~ positive determinant

Exactly, this is user specific. I need check if we have a function to flip bvecs. If not, we should create this function and explain somewhere that if you are using FSL, you should call this function before creating a gradient table. this is the approach I would recommend but open to any other opinion.

That sounds good!