FMRIPREP giving different sized masks between runs

I’m trying to run some analyses with Cosmo using some preprocessed fmri from FMRIPREP but am running into issues with the masks that were output per run. In order to combine datasets Cosmo requires that the input matrices for each be of equal dimension. But after filtering the preprocessed functional run files with their associated masks each run has a data matrix with a different number of voxels chosen by the mask. These can differ in size by several hundred voxels or so in cases, and this is between runs within the same participant.

Cosmo has a function for dealing with this sort of discrepancy in size (which can be seen here) but using that I seem to be losing around a third of the voxels in the process of aligning the two datasets, which seems excessive especially for data recorded from the same participant on back-to-back runs.

Is there something in my fmriprep pipeline that might’ve caused the masks (or the BOLD images) to come out so seemingly lacking in alignment between runs? I’ve included the shell code I used to run FMRIPREP in case that might be informative:

docker run -m=“11.5g” --memory-swap=“40g” -ti --rm -v /Users/Blake/Documents/angular/Nifti:/data:ro -v /Users/Blake/Documents/angular:/out -v /Users/Blake/licenses/freesurfer/license.txt:/opt/freesurfer/license.txt -v /Users/Blake/plugin.yml:/plugin poldrack/fmriprep:latest fmriprep:latest --use-plugin /plugin /data /out/out participant --ignore fieldmaps

Thanks in advance for any help that can be offered.

There could be differences in FOV and signal dropout, but it’s just a speculation without actually seeing the masks. Check the HTML for quality of individual masks. Visualise their overlap in your favorite nifti viewer.

Thanks for replying; looking at the overlap of the masks in a few participants there are a few obvious slices where one mask includes more (in some cases a fair amount more) than another.

I’m viewing them in mricron so I’m not sure if that, by default, automatically aligns the loaded images to a fixed axis. But from what it’s showing there doesn’t seem to be any noticeable displacement in the location of the mask between runs.

Viewing the masks in the HTML files nothing looks out of the ordinary there. They all have a mask similar to the one described here, but I’m not sure if that’s related. From what’s being said in that thread that doesn’t seem like a new issue or one that’s likely to be the cause of the problem here.

So the question really is if the masks were accurately describing the borders of MRI signal. If so the large number of voxels dropped by the intersection is an indication of between run differences (due to FOV or signal dropouts).

Having gotten the chance to look through the raw data more closely it looks like the problems are a result of the different nifti files produced per run having different (in some cases very different) orientations.

This doesn’t happen for all participants, and looking at the original nifti files this difference in orientation doesn’t appear to be present there.

Is there something I might have missed in my input to fmriprep? The functional scans didn’t record the entirety of the brain and the preprocessing obviously adds space to the nifti files to create a complete image; is there maybe extra information that needs to be provided to fmriprep in these cases?

I’ve included a link to a folder here that has screenshots showing what I’m describing since I can’t as a new user include more than one image in a single post.

You can also see in the folder that not every participant has their functional scans rotated in the same way.

Limited field of view scans are notoriously hard to coregister - I would check the HTML reports for the suspicious cases to verify that coregistration is to blame.

One way I can think of that would help FMRIPREP in handling such cases is coregistering all runs together first before attempting to coregister to the T1w. See https://github.com/poldracklab/fmriprep/issues/450 for more details. Your help in adding this feature would be greatly appreciated.