Registrations and brainmasks

I’ve found a good number of our functional scans seem to have brain masks that are missing the temporal poles or missing the orbital frontal cortex in MNI space and show that correctly on the report, but when I check the images, the native space bold and brain mask look fine. Can any one help me figure out if this is a registration issue or a masking issue or both? Or does fmriprep drop low snr regions from the MNI transformed brain masks?

The anatomical to standard space alignment looks fine. Here’s the functional to anatomical alignment for one of these scans.

And then the functional brain mask and compcor rois:

Here the bold ref and brain mask in native space, which looks great and isn’t cutting anything off:

Then the bold ref and brain mask in MNI152NLin2009cAsym, where you can see things cut off in the central orbitofrontal cortex and temporal poles:

Then on at least one of these that I’ve spot checked the native space bold ref and brain mask are completely screwed up, but the only issue I see in the reports are some missing bits in the functional brain mask.

The anatomical to standard space alignment looks fine. Here’s the functional to anatomical alignment for one of these scans.

And then the functional brain mask and compcor rois:

you can see the bits that are missing in z=-8, x=1, and y=58.

Then here’s the native space bold ref and brain mask overlaid in red, which are all messed up:

But the MNI bold ref and brain mask are much better, still cutting out a bit as shown in the report


Sorry, I’m just looking over this post and realizing you’ll need to click on those AFNI screen shots to see all three planes.

I’m also realizing that this issue is most common on our multi-echo resting state sequence. I passed the t2s-coreg flag to fmriprep, which may be causing the issue.


Yes, masks and coregistration of the T2* contrast calculated from echos might be suboptimal for your data. We will try to revamp ME-EPI as soon as possible.

I tried again without the t2s-coreg flag and the issues did not appear to be resolved. The scans have some significant inhomogeneities in them, and given the other N4 issue we’ve recently found, I’m suspicious that the errors may be related to that:

In one of these that I’m spelunking through the working directory to debug I’ve found that the output of split_opt_comb looks like it’s mostly skull stripped.

@oesteban is that expected behavior for split_opt_comb?

The input to split_opt_comb is bold_t2s_wf.t2smap_node.outputs.optimal_comb:

@emdupre Is the optimal combination skull-stripped?

No, it shouldn’t be. The t2smap is skull stripped (in the immediate, subsequent step) to derive the bold_mask and the bold_ref_brain.

We do compute an adaptive mask (dropping voxels that are static across echos) in the T2* map workflow. If this behavior isn’t desired, we could explicitly pass a whole brain mask to the workflow to disable it.

EDIT: I’m not sure I’m seeing how t2s-coreg would drive this problem… It seems reasonable to me that it doesn’t work either with or without it.

My first thought would be to check if you see the same issues reported above when selecting just the middle echo using echo-idx. If it’s really an inhomogeneity problem, they should persist. If they resolve, it’s more likely to be multi-echo specific.

Thanks for the suggestion! I’m running it now and will update in the morning.

1 Like

Alright, I’ve got a a variety of results for to report. This subject has multi-echo (n echos = 4) resting state scans collected at 4 sessions. I’ve run fmriprep with 3 different settings, here are the settings and commands:

With t2s-coreg:
singularity run --cleanenv /data/MBDU/singularity_images/fmriprep_1.4.1.simg /data/MBDU/midla/data/bids_defaced $TMPDIR/out participant --participant_label 23638 -w $TMPDIR/wrk --nthreads $SLURM_CPUS_PER_TASK --mem_mb $SLURM_MEM_PER_NODE --fs-license-file /data/MBDU/singularity_images/license.txt --output-spaces MNI152NLin2009cAsym fsaverage6 func --dummy-scans 4 --longitudinal --use-aroma --error-on-aroma-warnings --t2s-coreg -vvv

No t2s-coreg:
singularity run --cleanenv /data/MBDU/singularity_images/fmriprep_1.4.1.simg /data/MBDU/midla/data/bids_defaced $TMPDIR/out participant --participant_label 23638 -w $TMPDIR/wrk --nthreads $SLURM_CPUS_PER_TASK --mem_mb $SLURM_MEM_PER_NODE --fs-license-file /data/MBDU/singularity_images/license.txt --output-spaces MNI152NLin2009cAsym fsaverage6 func --dummy-scans 4 --longitudinal --use-aroma --error-on-aroma-warnings -vvv

No t2s-coreg and only use echo 2:
singularity run --cleanenv /data/MBDU/singularity_images/fmriprep_1.4.1.simg /data/MBDU/midla/data/bids_defaced $TMPDIR/out participant --participant_label 23638 -w $TMPDIR/wrk --nthreads $SLURM_CPUS_PER_TASK --mem_mb $SLURM_MEM_PER_NODE --fs-license-file /data/MBDU/singularity_images/license.txt --output-spaces MNI152NLin2009cAsym fsaverage6 func --dummy-scans 4 --longitudinal --use-aroma --error-on-aroma-warnings --echo-idx 2 -vvv

Here’s some screenshots of the results from all the sessions for each of those settings:
With t2s-coreg you can see that the brain mask in all sessions is missing some orbital-frontal cortex from the brain mask.

No t2s-coreg:

Here, the brainmasks are also missing the orbitalfrontal cortex, but something has gone seriously wrong with the functional to anatomical registration for session 1.

No t2s-coreg, echo2:

Here, the brainmasks have worked much better, but session 1 still has functional to anatomical issues.

Here’s a link to a zip directory containing all of the reports:

In summary, It seems like the masking issue is related to the multi-echo processing, but something has gone totally wrong in the bold to anatomical registration for session 1 if I don’t use the t2s-coregistration.

@emdupre, any thoughts?

Also, I’ve just noticed that the skulls aren’t stripped in the echo 2 run, whereas they are in the others, so maybe that’s part of what’s going wrong.

Thanks for pulling all of this together ! This is really helpful for thinking this through.

Just to recap: It seems like session 1 inhomogeneities are yielding a poor anatomical-functional coregistration – but we only see that with the --echo-idx 02 test because the T2* driven coregistration is a better target (hooray, it works the way it’s supposed to !).

So, the remaining issue (from my end, not sure if other folks want to think about the inhomogeneity issue) would be to figure out where the multi-echo masking issue is arising.

My first guess is that we want to pass an explicit, inflated whole-brain mask to the T2Map interface so that we don’t drop any static voxels. One quick sanity check – in the working directory, could you check the bold_mask_std output from bold_std_trans_wf and confirm that it’s showing the same pattern seen in the reports ?

Yep, same mask in the output directory. Here’s sub-23638_ses-04_task-rest_run-1_space-MNI152NLin6Asym_boldref.nii.gz overlaid with sub-23638_ses-04_task-rest_run-1_space-MNI152NLin6Asym_desc-brain_mask.nii.gz from the with t2s-coreg processing.

@emdupre, I can zip up the working directory for this run from any of these processing options and send it your way if it would help. I can also put this subject on OpenNeuro. Let me know what would be best for you.

The multi-echo resting state run from session 4 is now available on OpenNeuro:

1 Like

@emdupre could you send an issue to fMRIPrep with the action items you just listed and including a link to @Shotgunosine’s dataset?

@emdupre Have you made any progress looking into that issue?

Following up on this discussion (@Shotgunosine and I talked a bit over email), I’ve opened an issue on fMRIPrep outlining the current state of affairs:

One note: the option 3 I outline there (removing T2* coregistration) won’t solve your problem, @Shotgunosine, in that you’re still seeing the functional-to-anatomical coregistration issues with only echo 2 in session 1. Unless this coregistration is something @oesteban has addressed already in the latest release !

So I just noticed that the fix to this issue was merged 7 days ago. When might that make it to a release or release candidate?

@effigies Said that it should be “Real Soon Now” in 20.1:

@Shotgunosine did you have a chance to test this?

Yeah, I think I replied on the github issue, seems like it’s working.