SDC using phasediff stretches signals to nonbrain areas

The data is from Siemens Prisma Fit.
For fmap, we have 2 magnitude images and a phasediff images. We did properly specify both the IntendefFor, and the B0FieldIdentifier and B0FieldSource fields in the appropriate json files.
I am using fMRIPrep 22.1.1. It ran without throwing any errors for all of our subjects. However, when visually quality checking the outputs, SDC seem to be done poorly - this is not isolated to this subject alone. Several subjects have this issue where the signal is stretched way too much out to the front, and sometimes the back.

Including example from one subject here:

Distorted/Uncorrected:

SDC Corrected:

Hi @Jagan_Jimmy, and welcome to NeuroStars!

Many users have posted about SDC issues here with latest fMRIPrep version (e.g., here).

Do you get better performance on the LTS branch (20.2.7) or using SYN fieldmapless method (on either the current or LTS branch)?

Best,
Steven

Hi Steven,

I haven’t tried running it on version 20.2.7 - I can try that now.
Likewise, I didn’t try SDC with SYN-fieldmapless method - but that is mainly due to the fact that there isn’t a ground truth available for those cases, and most importantly to my understanding that method cannot tell apart between actual distortion versus actual signal dropout.
Nevertheless, I will try running it on the older version of fmriprep and report back.

On a side note, I had other datasets with pepolar fmaps and direct fieldmap fmaps, and version 22.1.1 performed well on all SDC using either of those fmaps for all subjects in those datasets - hence I was surprised to see this issue appear when using phasediff/magnitude fmaps.

Thank you.

Hi @Jagan_Jimmy!

Have you tried skullstripping the magnitude images first?

It seems to be strongly recommended here: How to fieldmap correct | Caroline Nettekoven and, independently, some people in my Institute found that only after skullstripping that they get good SDC (also phasediff images from Prisma Fit).

Best,
Jakub

Hi @themeo,

I had figured what was most likely causing this issue was a bad skull strip of the magnitude images. I remember reading some documentation by spm12 and FSL (both of which can handle phasediff images) about needing a very tight skull strip and to avoid any and all non-brain voxels as much as possible (FUGUE/Guide - FslWiki).

I used Freesurfer’s synthstrip (SynthStrip) to skull strip my magnitude images and ran the same processing again using fMRIPrep 22.1.1. I used Synthstrip since it seems to be able to handle any type of brain image very well.
Synthstrip’s skull stripping is already very robust and tight, and I think fMRIprep basically further skull stripped the already skull stripped magnitude image such that it made an extremely tight mask (i.e., too much brain voxel taken out). I think this is why now the “phasediff_fieldmap image” it generated came out very odd looking - it looks like a lot of voxels are just missing. However, the SDC correction applied to my functional images seemed to improve (almost even perfect).

So, I am not fully sure what to make of this. Maybe fMRIprep team should implement synthstrip under the hood to skull strip the magnitude image (of course erode it as well), and remove whatever current skull stripping utility they have and then it seem like this issue would be resolved.

I am including here screeshots of the images from the HTML report.

Distorted/Uncorrected functional:

SDC Corrected:

Best,
Jagan.

Hi @Steven,

I just wanted to report back that when using the LTS branch (20.2.7) I do not have the SDC issue I originally posted. As in the discussion with @themeo, it does seem to be an issue of improper skull stripping. Looking over the SDC workflow/code it does seem like fMRIprep does perform skull stripping of the magnitude images. Given this issue with multiple subjects, it looks like the current implementation of skull-stripping isn’t good enough such that it still is retaining some non-brain voxels which is what is causing the SDC to perform worse near the edges. Maybe recommending that they add an erosion step to the skull-strip mask would resolve this.

Best,
Jagan.

2 Likes

For those interested, you can use BIDScoin’s bids-wrapper around synthstrip to easily skullstrip your (e.g.) phasediff images before feeding your data to fmriprep. The wrapper hasn’t been released yet (but will be in the coming weeks), but you can use it already if you install the github code directly:
https://bidscoin.readthedocs.io/en/latest/bidsapps.html#skull-stripping

Hi @Marcel_Zwiers ,

Thank you for this recommendation.
I have not used BIDScoin before, so my expertise is limited here. What you seem to suggest is a way to skull-strip the relevant images first and then run the data through fmriprep. If that is the case, then that is what I tried earlier and posted above.

The issue with feeding in an already skull-stripped magnitude images is that fMRIprep stil does its own additiona skull strip and thus it cuts out way too much (in the image above all the all the black voxels in the fieldmap figure are regions that are now missing once fMRIprep further skull strips the magnitude image). While documentation from FSL and SPM12 does indicate it is preferred to have a tight skull strip, I don’t know what the implications are for having such an extreme skull strip.

Best,
Jagan.

What I suggested was that you could skull-strip the phasediff images and leave the magnitude images as they are. In this way, even if fmriprep mask is too big, it doesn’t matter because the resulting fieldmap outside the brain will be zero anyhow. In BIDScoin you could do this e.g. like this:

skullstrip myproject/bids fmap/*_magnitude1* -m fmap/*_phasediff* -o extra_data fmap

This would compute the skullstrip on the magnitude1 image, which is saved in the extra_data folder (which you can discard yourself or save elsewhere). The mask is applied to the phasediff image in the fmap folder, i.e. it overwrites it (you can of course also save it elsewhere, do a QC and only then overwrite the original phasediff images). To generate a QC report do e.g.:

slicereport /project/bids fmap/*_phasediff* -o fmap/*_magnitude1*

(you can leave out the -o [..] argument if you don’t like the contour overlay image

The phasediff output then looks e.g. like this (you can also display the masked magnitude1 images if you like):

1 Like

@Marcel_Zwiers, this makes sense. Thank you for sharing this.

Best,
Jagan.