Fieldmapless syn-sdc output in fmriprep 22

Hi all, I’m trying to use the fieldmap-less sdc approach and have run fmriprep v 22.1.1 with --use-syn-sdc

In posterior regions it looks like this is working well but the output shows that something funny is happening with the anterior ventricle borders, which are getting stretched forward. The inhomogeneity map below reflects areas where this boundary mismatch is happening, rather than actual field inhomogeneity. Has anyone else seen similar output using this method?

Here is an image from the html report

and a screenshot of the actual output

I have fieldmap data but this syn-sdc output above was run for a subject whose existing fieldmap folder was removed (see other post about testing different calls here). In separate instances of running fmriprep, the non-sdc corrected output looks normal, and the PEPolar method of sdc looks fine (see image below) but seems to produce sdc-corrected output that is fairly variable between runs (even in regions with fairly low susceptibility), which is why I’m trying to test the fieldmapless approach. For reference, here’s an imhomogenity map from the PEPolar method, which looks more expected:

Hi @embers,

Does 23.0.2 (most recent stable release) or 20.2.7 (latest long-term support branch version) work better?

Best,
Steven

Hi @Steven, thanks for your reply. I’ve just finished running it in 23.0.2 and it looks about the same. The alignment of surfaces to the T1 is a little better in the new output but the position of the ventricles has the same basic issue and the inhomogeneity maps have the same profile (the last sentence of the fieldmap-less report still mentions “two or more EPI images with the same PE encoding”, but I think this is holdover text from fieldmap-based SDC?).

I will try to run with 20.2.7 next.

(Just in case it’s relevant, I have two sessions per subject and have also been running fmriprep with --longitudinal to generate output in intermediate T1w space with --output-spaces anat since I have a T1 in each session. This seems to be working as expected so far and the alignments/normal fieldmap SDC look good but I can try with just a single session if it there’s a chance this aspect could be interacting with the ANTS processes)

Thank you for this thorough report!
It is interesting as most of the complaints with SDC and fmriprep are about using the “Phase-difference B0 estimation” approach, not the PEPOLAR one.

Could you illustrate your statement about sdc-corrected outputs with the pepolar method that look wrong? Could it be that there was a change of position of the subject between the SE images and the BOLD images for those cases?
We do use this pepolar method with fmriprep within our center and the output is usually well corrected and in good alignment with the anatomical images.

If you are looking at alternative methods for SDC, you may look at SynBold-DISCO which gives promising results in some cases: https://neurostars.org/t/using-synthetic-field-map-from-synbold-disco-with-fmriprep

One thing that’s worth trying in all of these is running fslreorient2std on all of your input images (and fixing your PhaseEncodingDirections!) and rerunning fMRIPrep. If the issue is resolved, then there’s likely to be a straightforward fix for us to apply.

I’ve recently found an OpenNeuro dataset that’s showing some strange distortions under SyN-SDC that I’ll be working on as I can.

Very interesting thread on SynBold-DISCO-- thanks for linking.

The first gif below is the concatenated initial volumes for six runs of PEPOLAR data, according to the html output which references this method. I’m still not confident I’m following the correct procedure here but I obtained this by having the same unique string listed in the jsons for the spin echo AP/PA fieldmap pair of volumes for each run (B0FieldIdentifier) as was in the corresponding task AP task run (B0FieldSource). These identifier strings show up as expected in the SDC section for each run in the html report. (Per my other post linked above, this is with --ignore fieldmaps in the call, which doesn’t seem to have actually ignored the fieldmaps)

pepolar

For comparison, here is the corresponding output for preprocessed data with no SDC performed, which I obtained by including --ignore fieldmaps after also deleting the fieldmap directories and removing the json fields.

nosdc

There is definitely a position shift, especially between run 1 and run 2, but the SDC process seems to introduce other fairly big spatial inconsistencies. I don’t think this participant had particularly bad fieldmaps in terms of motion but I will try with another participant.

Thank you for this very interesting comparison with nice visuals!
I agree with, looking at these results, I prefer the SynDC method.

Are these images in the bold native space? Was the subject moving a lot within runs and between runs?
It would also be interesting to see the same movie for the native images before correction.

Which fmriprep version was it? If you have time, could you try with fmriprep LTS, v 20.2.7?

Great, thanks for the suggestion-- I’ll give this a try and see if it helps with the SyN approach, which I also still need to test with 20.2.7

Thanks— this is all with 22.1.1 so I will try and rerun with 20.2.7.

The images are in T1w output space with --longitudinal that I think should be intermediate between the two T1s collected in each session (on same day).

There was very little within-run motion but considerable between run movement on some runs as you can see here. The below now has the raw/true native space images on top (first volume of each run followed by that run’s SE fieldmap, AP vol only for this visualization) and the PEPOLAR SDC output from fmriprep below. Some of the variability in the SDC data seems to be related to movement between the task run and fieldmap, but not all? We have the fieldmaps at the end of the task run but perhaps this isn’t ideal since there is a slight gap where participants may be tempted to move despite instructions.
native_sdc_compare

Unfortunately I doubt this participant will be an outlier in terms of changing head position even if they are on the worse side. One of the things I’ve been trying to figure out is whether it makes sense to continue using the fieldmaps at all, and if so, whether there is ever a rationale for not automatically applying each run’s corresponding fieldmap. With the caveat that I have to try a few more things to make sure that the PEPOLAR SDC is actually working as intended, it seems like a non fieldmap method (even no SDC of any type) would prioritize cross-run spatial consistency, which might be more important for our purposes than matching anatomy. It would be great to get one of the SyN methods working.

1 Like

Very nice visual!

I think your strategy to use one fieldmap per run is very sensible, even if not everyone does that, many projects just acquire one fieldmap for the whole fMRI session.

There was indeed some motion, but acquiring one fieldmap per run should definitely help, compared to the use always the same fieldmap for every run ! I don’t think it is implemented yet, but SDCflows should at some time be able to correct SDC and motion at the same time and should be more robust toward these cases.

Your feeling about choosing the SyN method was actually shared by the Amsterdam group in this paper for which they were also collecting fieldmap data:
Snoeket al. The Amsterdam Open MRI Collection, a Set of Multimodal MRI Datasets for Individual Difference Analyses. Sci Data 2021, 8 (1), 85. The Amsterdam Open MRI Collection, a set of multimodal MRI datasets for individual difference analyses | Scientific Data.

Fieldmap-less” distortion correction was performed by co-registering the functional image to the same-subject T1w image with intensity inverted53,54 constrained with an average fieldmap template55, implemented with antsRegistration (ANTs). Note that this fieldmap-less method was used even for PIOP2, which contained a phase-difference (B0) fieldmap, because we observed that Fmriprep’s fieldmap-based method led to notably less accurate unwarping than its fieldmap-less method.

I was always puzzled by this statement but it looks like you are in the same situation (but you use the PEPOLAR method while they use the B0 Phase difference method).

What may help is to use a little higher degree-of-freedom for the registration toward the T1w image (9 or 12) to account for the residual distorsion?

Would you mind providing further information on how one goes about ensuring that the PhaseEncodingDirection is correct after running fslreorient2std? Many thanks in advance!

The PhaseEncodingDirection is i, j, k, or i-, j-, k-. This corresponds to the first, second or third axis in the image and whether the phase increases or decreases as the index along that axis increases.

Suppose you have an image in SPL orientation with PhaseEncodingDirection i-, which corresponds to superior-to-inferior. Reorienting to RAS, the PE direction is still superior-to-inferior, which means you need to update the metadata field to be k-.

Thank you @effigies for the prompt reply, really appreciate it!

Would you mind confirming if the following changes look right to you?

  1. Dataset in LPS orientation with j phase encoding direction should be changed to j- after applying fslreorient2std to reorient to RAS
  2. LPS orientation with i- phase encoding direction should be changed to i after reorientation to RAS
  3. PLI orientation with j phase encoding direction should be changed to i- after reorientation to RAS

Could I also ask what the downstream impact of incorrect phase encoding direction information is on fieldmapless syn-sdc correction? Does this differ between versions v20.2.7 and v24.0.1? Can this be visually inspected?

Lastly, am I correct in thinking that whether the input scans are in LAS or RAS orientation doesn’t matter in fMRIprep?

Yes, all of the changes you list look correct.

If you are using SyN-SDC, then only the axis (i, j, k) is significant, not the direction. The result of getting the direction flipped will be a sign reversal in the estimated fieldmap, but the reversed direction will also invert the direction of distortion correction, so the two inversions will cancel out. Still best to try to get it right.

And yes, fMRIPrep should equally happily accept LAS and RAS images. If it produces different results, that’s a bug.

Thank you so much for the clarifications, it has been extremely helpful!