Antipodally reflected bvecs for sagittal DWIs

[Lestropie]

Describe the bug

Where DWIs are acquired with sagittal slice orientation, the saved bvecs are antipodally reflected with respect to the diffusion sensitisation gradients that the sequence was instructed to apply. This happens irrespective of phase encoding direction or slice order.

To reproduce

Build and run the Docker image at: https://github.com/Lestropie/DWI_metadata

Expected behavior

The gradient table utilised during acquisition contains three fiducials at the head, applying diffusion sensitisation gradients along the three axes of the Device Coordinate System. The software tool reads these three columns from bvecs, transforms them to RAS real space according to my understanding of the bvecs format (which is seemingly confirmed correct via other tests), and compares them to the fiducials. If these correspond, no warning will be issued.

Version

The Docker image builds the most recent tag, v1.0.20240202, from source.

---

PS. In case it's a clue: I found that with Eigen used by MRtrix3, when trying to access the 3x3 portion of an affine transform, .rotation() gives a different result to .linear() only for sagittal acquisition, as the former actually invokes a decomposition.

[neurolabusc]

@Lestropie I did create a validation dataset and minimal validation pipeline as dcm_qa_sag. It looks to me like the issue is with Siemens data where sagittal data is saved as slices (either enhanced or separate files) rather than mosaics.

Series 4 (from this VE11 scanner) saves the sagittals as mosacis and the direction looks fine:

The same sequence, but saving the data as one 2D slice per file does not look correct:

I suspect this is the same root issue with issue 797.

[Lestropie]

Visualisation of peak orientations does not discriminate between the presence and absence of this particular bug. The reported gradient directions for the sagittal acquisitions are specifically the antipodal reflection of what was actually applied. This is inconsequential to typical fibre orientation estimation, which assumes the diffusion-weighted signal to be antipodally symmetric.

I am assuming that the error is in the dcm2niix output rather than the DICOMs themselves given that with the rectifications put in place in https://github.com/MRtrix3/mrtrix3/pull/3011, which results in code that is both simpler and has a stronger expectation of being correct on first principles, no such reflection is detected. This is not only for DICOM load but also for an insane barrage of other tests, reading/writing from various formats with various configurations. So while it's not inconceivable that there could be adjoint bugs in the DICOM data and the updated MRtrix3 implementation that cancel one another out, resulting in my erroneously attributing fault to dcm2niix, I would consider that scenario far less likely.

[neurolabusc]

OK. Now I understand. b-vectors that are have polar opposite directions have identical sensitivity to fiber direction, but have the eddy-current distortions have opposite direction but identical magnitude. Therefore, getting all the bvec directions 180-degrees off will create identical tensors. I also believe that tools like Eddy will not be influenced by this, as it will undistort to the spatial position between the two images. Given the fact that our tools are so tolerant to this polarity reversal, what is the best way to objectively test this? For example, you and I both acquired E11 mosaic data, and I also acquired E11 non-mosaic images. We also want to make sure our solution works for XA data. Maybe you can expand on the consequences of this error, that can help mitigate data acquired before this issue was identified. Can you provide the mrtrix version that fixes this and also the canonical way to convert DICOM data with mrtrix to NIfTI (rather than mif) format that provides a solution? I am eager to solve this, but want to make sure we have a comprehensive solution that improves dcm2niix and other tools (e.g. dicm2nii).

As an aside, I did fix scripts for my validation scripts so fsleyes generates line images for each dataset. This does suggest that the line directions are correct for all the data (although this is expected when direction is off by 180 degrees):

Series 4 (Sag AP mosaic):

Series 5 (Sag HF mosaic):

Series 6 (Sag AP not mosaic):

Series 7 (Sag HF not mosaic):