Incorrect phase encoding direction after DICOM import

1

Dear all,

I came across an issue with importing the phase encoding direction from my DICOM images.

I would like to generate an EDDY style acquisition parameters file when converting my DICOMs to NIFTI. I use the following command:

DICOM_SERIES='*b3000*' mrconvert DICOM/ dti.nii -export_grad_fsl dti.bvec dti.bval -export_pe_eddy acq_par.txt index.txt

When I compare the PE directions in the generated acp_par.txt file with those provided in the JSON file produced by dcm2niix (MRIcroGL) they match perfectly when the PE is A>>P or P>>A (eg. when JSON file says j-, I get 0 -1 0 ... as the PE scheme in my acq_par.txt file)

However if the PE directions is L>>R or R>>L, the signs are opposite, eg. when the JSON file says i- I get 1 0 0 ... in my acq_par.txt file and vice versa. I observed this for axial as well as for oblique acquisitions. When provided to FSL’s TOPUP, the MRtrix generated PE scheme produces wrong results, while the dcm2niix PE directions produce correct results.

We have a Siemens MAGNETOM Skyra scanner with E11E software. We are sending the HARDI data in Mosaic format to our PACS. From there we export the DICOMs.

Do you think this could be fixed?

Thank you very much in advance.

Best regards

Samuel

P.S.: The reason the polarity matters to me is that sometimes at our institution the main HARDI acquisition has PE direction A>>P while the supplementary b0 images intended for distortion correction have L>>R PE direction. TOPUP documentation on this:

However, if ones acquisitions have been performed with phase-encoding along different axes it is important to get the signs to correspond to the definition by your scanner manufacturer. (topup/TopupUsersGuide - FslWiki)

P.S.: Not sure whether it’s relevant, but just in case: When I used other software for spherical deconvolution (such as Explore DTI os StarTrack), I always had to change the sign of the x component of my BVECS file.

2

Hi Samuel,

Attempting to have these information handled properly has been quite the nightmare for me. It’s unfortunately not as easy as “read” <—> “write” in this context, because there’s a bunch of other moving parts at play, including arbitrary image strides, internal image reorientation, and internal vs. external storage of phase encoding data. But I believe it was @dchristiaens who has commented to me previously that for acquisitions where phase encoding directions are not strictly sign-flipped, an inversion of the first axis is necessary for topup / eddy to work correctly; so it’s entirely possible that there is indeed some residual MRtrix3 issue even after my efforts.

I did a comprehensive test where I acquired all 12 possibilities of slice encoding direction & phase encoding direction and made sure that MRtrix3 imported that information from DICOM correctly.
So I tend to think the issue is likely downstream of that.

On reflection, I think I may have overlooked one of these confounds (sorry if this is TMI, I’m kind of thinking out loud and figuring it out as I write…). When writing any information to JSON that is based on image axes, the relevant code has to predict ahead of time what reordering of image axes is going to be done during NIfTI export, and apply the same transformations to such sidecar data, so that the two separate sources of exported data retain correspondence. However on inspection, I’m failing to account for this specifically in instances where phase encoding information in the eddy config / index format are loaded from / saved to file. So if your image is not strictly RAS, what’s happening is that the exported phase encoding data are entirely compatible with the image data as stored internally by MRtrix3, but then on export MRtrix3 modifies the image axis orientations, which is the part that breaks correspondence between the exported NIfTI and the exported phase encoding data.

You may well find that if you do:
DICOM_SERIES='*b3000*' mrconvert DICOM/ - -strides +1,+2,+3,+4 | mrconvert - dti.nii -export_grad_fsl dti.bvec dti.bval -export_pe_eddy acq_par.txt index.txt
, then topup and eddy will behave correctly. The raw data may not be identical to what dcm2niix produces, but they would be internally consistent and hence not lead to processing issues.

Having access to a dataset where the current MRtrix3 behaviour is known to be wrong would likely help me here in verifying that any fix I implement is doing the right thing. If you are able to provide such, that would be great.

I do have to be careful though in modifying the code around here as there’s yet another confound:

P.S.: Not sure whether it’s relevant, but just in case: When I used other software for spherical deconvolution (such as Explore DTI or StarTrack), I always had to change the sign of the x component of my BVECS file.

This is actually more likely to be a problem with those softwares (and historically incomplete documentation of the bvecs format), not ours. See relevant post here. Prior to that fix, we also failed to take into account the handedness of the image coordinate system in interpretation of bvecs data. This meant that the software behaved entirely reasonably if utilising data generated internally by MRtrix3, but incorrectly if both the bvecs data were generated by FSL and if the corresponding NIfTI image used a radiological / “right-handed” coordinate system (hope I got that right? :sweat_smile:). Most likely what you are observing is those softwares suffering from the same problem.

What I don’t actually recall establishing with a high degree of certainty is whether or not the topup / eddy “datain / config” file format uses the same interpretation of sign on the first image axis as does the bvecs format :grimacing:

I have created a new issue on GitHub; any updates to the code & testing thereof can be tracked there.

Cheers
Rob

3

Dear Rob,

thank you very much for the detailed explanation. I see that it is a very complicated issue.

I certainly don’t want you to invest a huge effort into fixing something that is an issue for only one user.

I was wondering therefore if there’s a simple fix I can do on my side. For example, writing a simple script that would read the PE directions from the acq_par.txt file, flip the signs and write a new file.

Would this work?

Thanks in advance.

Best regards

Samuel

4

I was wondering therefore if there’s a simple fix I can do on my side. For example, writing a simple script that would read the PE directions from the acq_par.txt file, flip the signs and write a new file.

You can certainly write a script that will apply any correction you deem necessary for your particular fixed acquisition, or indeed just overwrite that file with one defined manually.

I had a go at implementing the comprehensive solution in MRtrix3; see code here. You can see in that thread that I’ve done a lot of testing, but it would still be useful if possible if yourself or anyone else dealing with this issue could test the solution on their own data before it gets included in 3.0.3; I’d hate to have broken it in some new and creative way :grimacing:

Rob

5

I can surely share the data with you. How can I do it?

6

Yes, actually I was referring to BVECS created by dcm2niix, I’m sorry for the confusion.

7

Hi Samuel,

You can see from the dropdown at the bottom of the relevant comment that I’ve done a lot of testing of these changes. To be truthful, it would actually be a lot more reassuring for me to have somebody else test those changes and verify that the specific problem that they’re observing with their specific data is resolved; I’d hate to trick myself into thinking everything is fixed due to some systematic mistake in my own testing. But if you’re not able to compile the modified code and run it locally on your own data, PM me and I’ll send some suggestions for data sharing.

Cheers
Rob