Could you help me solve my problem? I have one fMRI (json: “PhaseEncodingDirection”: “i”, “ImageOrientationText”: “Tra>Cor(-21.6)>Sag(1.6)”) and three fmap - magnitude1 (json: “PhaseEncodingDirection”: “j-”), magnitude2 (json: “PhaseEncodingDirection”: “j-”), phasediff (json: “PhaseEncodingDirection”: “j-”).
During automatic Fmriprep processing, I get a heavily distorted fmri file. Did I understand correctly that I need to change “i” to “j” in fmri json-file for correct preprocessing?
Command used (and if a helper script was used, a link to the helper script or the command generated):
I convert DICOM files via MRIcroGL. Import → Convert DICOM to NIfTii. After that I have nii and json files.
Hello. I believe the root cause of your issue is a bug in Siemens software when using copy references to acquire a polarity reversed phase encoding scan. For example, if the first scan specifies an anterior->posterior (A->P) scan and the second specifies a P->A, when the scanner copies the references it will convert the latter to right-left (R->L). This is unfortunate, as for tools like TOPUP we want a pair of images with identical slice centers and angulation but reversed phase encoding. If you are using Siemens product sequences, you should work with your Siemens Research Collaboration Manager to resolve this. If you are using the CMRR sequences keep the explicit phase encoding idetnical for the two scans, but apply the reverse RO/PE checkbox in the Special tab.
Tools like TOPUP attempt to correct EPI disortion by acquiring two images with identical magnitude of distortion but opposite direction. In your case, the directions differ by 90 degrees, not 180 degrees, so these tools are unlikely to yield a good result.
Hi @mkhazova, could you please provide the other information that was requested in the pre-populated Software Support template? You can edit your original post.
Hi, it looks like you are in the case of phase difference map, which is not a case where FSL topup is used but rather FSL PRELUDE as it can been seen here (look for function: init_phdiff_wf).
I don’t think that it is a problem to have your phase difference image with different phase encoding direction than in your functional images (usually phase difference images map are generated using a GRE sequence with no distorsion along the phase encoding direction).
For the phase different map correction implemented by fmriprep (details of the method are here) you may need to try to change “i” into “-i” in fmri json file to see if the correction is better.
How are your native functional images? Are the distorsions really along the L-R direction (meaning that the phase encoding direction is really “i” or “-i” )?
My understanding is that one set of images was acquired with AP axis and the other LR. The assumption of TOPUP and similar tools is that the truth lies precisely in the middle of the two phase reversed images (e.g. A>P and P>A or alternatively L>R and R>L). This axiom does not work if the image pair do not have 180 degree phase difference relative to each other (e.g. A>P and R>L). dcm2niix is faithfully labelling the directions as they were acquired. The images are not suitable for undistortion.
One diagnostic for whether this is potentially fixable is trying to run the latest fMRIPrep LTS release (20.2.7). That used a different architecture for susceptibility distortion correction, and will let us know if this is a regression. If that works correctly, there is a high likelihood we can track down the deviation and fix it in a later release. It is also possible that you have an unusable fieldmap, as Chris suggests, so I can’t make promises.
We do have a fieldmap-less SDC approach (use --ignore fieldmaps --use-syn-sdc) in the meantime, which will make a best effort to correct distortions in the phase-encoding direction, using the anatomical image as a reference.
Hi @Chris_Rorden, indeed, according the the initial post, the GRE-EPI sequence used for functional images seems to have been acquired in LR whereas the set of images acquired with the GRE recalled sequence seems to have been acquired with the phase direction along the AP direction. I use intensively topup for SDC of my EPI images (both for functional and diffusion) and I was thinking that the SDC with the phase difference map method (which is not based on the acquisition of two SE-EPI images with reverse polarity, but rather two GRE images with two different echo times) would work for a different phase encoding direction direction of the fieldmap with respect to the phase encoding direction of the functional scans.
As stated by @effigies, this may not be the case and that could be the source of the problem observed by @mkhazova . Thank you @effigies for starting this new issue, I will be on the lookout for this interesting topic.
As a side note, I read this part from the topup User guide, meaning that you don’t necessarily need to have your set of EPI images with exactly 180 degree phase difference relative to each other to work with topup, even if the latter is preferred in the general case:
Topup gives you lots of freedom in how to acquire your data and still be able to calculate and correct for distortions. You can e.g. use
1 0 0 0.087
0 1 0 0.087
indicating that the first scan was acquired with phase-encoding in the left-right direction and the second in the anterior-posterior direction. One can even acquire ones data like
0 1 0 0.087
0 1 0 0.107
i.e. with distortions going in the same direction in both acquisitions but with slightly larger distortions in one case (the latter in this example).
Despite this flexibility it is nevertheless best to manipulate the phase-encoding so that it yields the maximum difference in the observed images, and that will a reversal of the blips. So unless one has a very good reason to do otherwise that is the recommended type of acquisition.
I’m very confident this doesn’t have anything to do with the phase encode direction, and is just a manifestation of the SDC regression that has been noted elsewhere. I am using the same technique: phase difference field map GRE acquisition with phase encoding i, and my bold acquisition has phase encoding j-. I have identical looking distortions with version 22.1.1 and 22.0.2, but the suggestion to try the LTS release (20.2.7) gave a good result. I posted screenshots showing a comparison of both versions on the same data here: fmriprep-sdc-distort-the-image-and-there-is-error-for-some-subjects
I also tried manually changing the phase encode direction on the phase difference and magnitude fmap images from i to j-, this predictably had absolutely no effect (ran on version 22.1.1, still looked really bad).
For me this artifact is super consistent, I ran around 60 datasets and I would say about half had very severe artifacts. I’ll update when all 60 are done running on 20.2.7 but so far they look good.
I’m happy to help by sharing more examples or data if you need it.
All 60 datasets have been completed with 20.2.7 with very good results. Again I can send example data of cases where the SDC regressed if that is helpful.
Hello, dear colleagues.
I apologize for the long answer - I had to set up a virtual machine for data processing this files. I am new to working with the fmriprep, so I will write a sequence of actions. I use fMRIPrep 22.1.1.
Before running the script, I add the following lines to the json-files:
