FSL bvecs handling

Development
21

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.

    I’ve no experience with AFNI, so can’t comment on how it might handle these data. But looking at voxel indices only will definitely suggest a discrepancy, even if the images are in perfect alignment. In the simple case of a RPI ⇔ LPI switch, the direction of the x axis is reversed. That means the voxel at (0,0,0) goes from initially being in the right-most corner to being in the left-most corner (assuming your original convention, I would ordinarily state it the other way around…).

    I also can’t comment on how the AFNI viewer will handle overlaying data with different voxel orderings (strides). I do know that FSL’s fslview doesn’t handle these cases gracefully (at least it didn’t use to), all images need to be stored with the same orientation. I am surprised to find such a pronounced shift in the IS direction in your screenshots – but not that surprised in your particular case given that the operation performed is an inversion of the AP axis, and the image is strongly oblique (tilted back, as far as I can tell), which explains the origin’s z coordinate going down from ~34 to ~82 mm. But I expect they’ll overlay perfectly in mrview, which was designed from the outset to handle data correctly with respect to real space, no matter how they were stored.

  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?

22

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