# FSL bvecs handling

**URL:** <https://community.mrtrix.org/t/fsl-bvecs-handling/1434>\
**Category:** Development\
**Created:** [January 29, 2018, 4:22pm UTC](https://community.mrtrix.org/t/fsl-bvecs-handling/1434 "2018-01-29T16:22:09Z")\
**Posts on this page:** 2\
**Page:** 2

<div class="post-metadata">

**Author:** ![jdtournier](https://community.mrtrix.org/user_avatar/community.mrtrix.org/jdtournier/32/2594_2.png) [@jdtournier](https://community.mrtrix.org/u/jdtournier)\
**Post date:** [January 14, 2019, 8:50am UTC](https://community.mrtrix.org/t/fsl-bvecs-handling/1434/21 "2019-01-14T08:50:59Z")

</div>

OK, I appreciate it _looks_ like there’s a problem, but as far as I can tell from what you’ve shown me, everything checks out.

1. Good to hear, thanks for confirming.

2. Yes, the qform & sform will differ, since that’s the only way to change the orientation of the axes. The NIfTI standard assumes fixed stride ordering with respect to the image axes, so the only way to change an image from say RPI to LPI is by changing the orientation of the axes relative to the anatomy – in other words, modifying the transform (sform / qform) – and then reordering the voxel intensities to match. This is what `mrconvert -strides` does.

3. The interpretation of the bvecs will be identical to what it was if the image is stored assuming a left-handed coordinate system, with negative determinant (this was how Analyze images were stored). You can to this with `mrconvert -stride -1,2,3,4` – this will produce the kind of LAS images (what you call RPI) that other software packages might refer to as ‘FSL NIfTI’. But what testing did you do to come to the conclusion that you need the previous (buggy) version of `mrconvert`?

---

<div class="post-metadata">

**Author:** ![ajaysk](https://community.mrtrix.org/letter_avatar_proxy/v4/letter/a/f475e1/32.png) [@ajaysk](https://community.mrtrix.org/u/ajaysk)\
**Post date:** [January 14, 2019, 5:29pm UTC](https://community.mrtrix.org/t/fsl-bvecs-handling/1434/22 "2019-01-14T17:29:58Z")

</div>

Thanks for the quick reply.

I checked and it looks correct in mrview so it must be a difference in the other viewer and not necessarily the image. Thanks for the suggestions.

In terms of using the “buggy version”, 3dAllineate outputs the affine matrix in RAI (what you refer to as LAS) convention regardless of the input image orientation. Their general vector multiplication tool (Vecwarp) accepts a vector (Also in RAI) and a transform in RAI orientation (3dAllineate input) and will apply the transform to a set of vectors. Since this is a general tool (not specific for bvec or matching FSL bvec formatting), and they do not assume a sign flip if it the determinant is positive. Since we have several different projects with varying orientations (including the ASL orientation for one project), I wanted to use the “buggy” version for this step so that I don’t introduce a sign flip that potentially doesn’t get undone when converting back and forth.

I use Camino for the tensor creation which I believe does not explicitly account for the sign flip. They provide flags for introducing sign flips in the x, y or z component that the user can set used on viewing the gradient orientation. I wanted to do further testing to see whether the “buggy” or corrected version will best interface with CAMINO for this step. In testing I will use cases where the original orientation is right handed and left handed and see if I need to introduce a sign flip or not. In order to get to this phase of the testing I wanted to finish step 1, for which I think the “buggy” version may be necessary.

Thanks again for your advice and help.

Ajay

[Previous page](https://community.mrtrix.org/t/fsl-bvecs-handling/1434.md?page=1)