Dear Farzan,

Yes, it is perfectly fine and appropriate in your case to simply skip any preprocessing steps that have been already performed outside of CONN when importing your data. You are correct that performing preprocessing twice on the same data is not recommended and can lead to problems (for example applying motion correction to data which has already been motion-corrected leads to incorrect estimations of subject motion, which in turn leads to inadequate denoising later on, etc.) 

The only thing to keep in mind when importing fully or partially preprocessed data into CONN is to not only import the preprocessed functional images, but also import other outputs of preprocessing such as realignment parameters if the data has already been motion-corrected (so CONN can correctly estimate subject motion and derived measures), gray/white/csf masks if the data has already been normalized&segmented (so CONN can use these masks for aCompCor during denoising), or scrubbing timeseries if the data has already been run through outlier identification (so CONN can use those timeseries to properly denoise the data).

Hope this helps

Alfonso

Originally posted by Farzan Vahedifard:

Subject: Follow-Up: Native-Space Processing & Regressors in CONN

Dear Alfonso,

Thank you again for your detailed guidance. I have one quick follow-up question based on your previous response and our current setup.

We are using externally preprocessed 7T fMRI data that has already undergone motion correction, slice timing correction, spatial smoothing, and coregistration—all performed outside of CONN. However, we noticed that CONN’s preprocessing pipeline also applies its own motion correction steps by default. This may result in redundant corrections.

Following our internal discussion (cc’d here), we are considering disabling CONN’s motion correction entirely and instead importing our own motion regressors through the first-level covariates tab. From your experience, would this be the appropriate approach for ensuring consistency with externally preprocessed native-space data?

Could you please confirm whether disabling CONN’s internal motion correction is necessary in our case, and whether this duplication of motion correction (from both our external preprocessing and CONN) could negatively impact the results?

Thank you again for your continued support!

Best regards,
Farzan Vahedifard