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:
Hi, I know this topic was over a year ago, but I would like to ask the source of that Siemens bug, or an official report. I am currently facing the same problems, and I was previously informed about a potential bug in these scanners when I asked others about those discrepancies. Still, no one seems to have an official statement from the manufacturer. I saw this thread and thought of asking here. Thanks!
Hi @DianaTru , this bug in Siemens sequences is resolved (as far as I know) with Syngo software versions XA. Which Siemens software version do you have on your MRI machine?
Hey @jsein, thanks for your response. It is great that the bug is already fixed. I am not sure what software version we had. It was a Siemens skyra (if that is of help). The thing is, I am working with legacy data, meaning it was acquired between 2016 and 2019, apparently while the bug was there, and we had two phase encode directions (PA and RL) in a sample of 200+ subjects. My main concern is that I have not found a legitimate source indicating the bug (as I said, officially addressed by Siemens) or nothing about the fix. Can you point me out on sources? Also, do you know if the data can be preprocessed as a single group (especially fMRI) given the two directions?
The scanner model doesn’t say much but the dates of acquisition make it very likely that the scanner version must have been VE or VD that were affected by this bug.
I don’t know any official source to document this bug. The fix was to copy the sequence in AP and manually rotate the phase encoding direction into PA, not relying on the “copy parameter” capability of the software as mentioned previously by @Chris_Rorden . As some point before the fix was made, there was a check box “copy phase encoding direction” that I think was more robust toward this bug.
In your case, it would be interesting to know how the protocol was saved at the console, and how it was run. Do you mean that the bold runs have either PA or RL phase encoding directions? What kind of fieldmap was acquired for theses subjects?
Prisma XA30 Software Bugs
This is a list of known software bugs/glitches. If you encounter any other suspected issues,
please report them to bmctechs@mednet.ucla.edu and during study reporting.
AP/PA Copy Reference Issue
If you are using Siemens product sequences with different phase encoding directions (e.g. AP
then PA), you MUST NOT use the copy reference option. This glitch will change your second
PA sequence to RL. This glitch does not affect CMRR, HCP or ABCD sequences as the phase
encoding direction is controlled on the special card instead of the routine parameter card.
Workaround:
You must manually input the angle for each sequence if you are manually prescribing
your FOV
If you use autoalign and DO NOT manually adjust your FOV in any way, then your scans
will not be affected and there would be no need to use copy reference
***This glitch has been reported to Siemens, but there is no way to know when and if
there will be a fix.
