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.
Good to hear, thanks for confirming.
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
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
fslviewdoesn’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.
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