I ran fMRIPrep, ran regression to denoise, ran smoothing in SPM. I used the file output with subscript _space-MNI152NLin2009cAsym_desc-preproc_bold.nii.gz from the fMRIPrep output. The smoothed data is put into 1st level analysis in SPM. The 1st level analysis using the output from fmriprep doesn’t run with default setting in SPM (especially with masking threshold at 0.8 or above 0), so I changed some settings like below:
high pass filter to Inf
masking threshold to -Inf
It ran without an error, but it resulted in implicit mask made during the model estimation process gotten larger than the size of the input (i.e. smoothed brain) when visualized. They still appear as the same size when I check their dimensions using spm_vol though.
I could not figure out how this could happen so I ran again with the same setting, but with external mask using the mask generated by fmriprep this time, which I confirmed this mask matches the size of the smoothed one. This time, it ran with correctly sized implicit mask generation.
However, a different issue arises. When I reviewed the 1st level output SPM file, it only had 1x1 design matrix. There supposed to be 3 conditions. Therefore I could not run Contrast Manager. Any idea what’s messed up?
In file “/work/apps/spm12/config/spm_run_con.m” (v7738), function “spm_run_con” at line 254.
The following modules did not run:
Failed: Contrast Manager
*This data is already fully analyzed using SPM only for the whole process. I found an issue that cannot be corrected using SPM, so that fmriprep is employed.
Any reason why you do not simply include confounds as extra regressors in the SPM GLM?
Is this because you already applied the filter during denoising?
Those 2 things are related: setting the masking threshold pretty much tells SPM:
run the GLM on every voxel in the image
Otherwise SPM uses the value from the masking threshold to determine in which voxel ‘there is enough signal’ and only includes those in its implicit mask.
Using an explicit mask (like you did) and setting the threshold to -Inf is one the strategy you can use to make sure that GLM is computed in all the voxels within a known mask.
Can you print the matlabbatch that you used for your GLM? If you only have a single regressor, then that should appear from how the GLM was set during model specification.
Here is the error (Error using spm_est_non_sphericity) I re-generated (i.e. everything default; Attempt 1). Model specification runs but estimation fails. It seemed like people get the same error commonly based on search. Below is the output from model specification.
I get the same error message when I change hrf setting to Inf (Attempt 2). Post 4, although not an error at the exactly same command line in the spm_est_non_sphericity or when doing the same analysis, gives some reasoning and solution of removing masking threshold (i.e. mthresh set at -Inf; Attempt 3). When I look at the fmriprep output, the values ranged like below. When smoothed with 6mm kernel the range changes. Although -Inf setting for masking threshold fixes the issue of ‘not running because of the spm_est_non_sphericity’ issue, this is when the larger implicit mask is generated. I assumed it may be because the smoothed data is used for input of this 1st level, and masking threshold is set at -Inf it is grabbing all the values that are numerically non-Zero.
(Attempt 5) Therefore I played around with different masking threshold values, such as 0.1, 0, -0.03. SPM spit out the same error message when the value was 0 or larger. Even if it ran without an error at negative values, the implicit mask is not correctly generated. Below is an example of -0.03 setting output, mask overlayed on smoothed data (input).
I could not find a reason how that could happen so I decided to use mask file generated from fmriprep as an explicit mask to set the boundary (Attempt 6), which ran without error, without making larger mask, and the above mentioned error happened in the next step.
This is because it’s my first time using fmriprep so I followed a protocol for a different data analysis my colleague is working on, that will be made publicly available. Since 3dTProject I used to handle detrending directly cleans the signal, they needed to do this way. Their team is not using SPM so I could not get direct help on follow-up steps. There seems no benefit on either way (using 3dTProject vs. put in as a covariate at 1st level) for my data analysis so it is certainly something I’m considering trying. I’m not sure this could be the reason for the wrong design matrix output.
Thanks for keep replying. I have tried again from the beginning for the SPM part and it actually ran fine without any errors. I’m guessing the command variable was overwritten at some point. However, I hope this post helps other people solving rather common errors that can occur when switching from fmriprep to SPM.
Selfish plug in case anyone wants to run SPM GLM on fmriprep datasets: there is a BIDS app to help you do this to prevent you from reinventing the wheel (disclaimer I am the maintainer of the app)
