fMRI Data Preprocessing: Tools and Workflow Explained

Raw fMRI data is unusable for analysis straight out of the scanner. Head motion, physiological noise, scanner drift, and differences in brain anatomy between participants all introduce artifacts that, left uncorrected, can produce results that look statistically significant but actually reflect noise rather than genuine brain activity. This is exactly why fMRI data preprocessing is treated as its own rigorous discipline within neuroimaging rather than a quick formality before "the real analysis."

Preprocessing is the sequence of corrective steps applied to raw functional and structural MRI data before statistical analysis: converting file formats, correcting for motion and timing differences, aligning images to a common anatomical space, and removing known sources of noise. Get this pipeline wrong, and even a well-designed experiment can produce misleading activation maps.

This guide walks through the standard fMRI preprocessing workflow, the software packages researchers actually use to run it, and the decisions that most often trip up graduate students new to neuroimaging.

Key Takeaways

• fMRI preprocessing corrects for motion, timing differences, and anatomical variability before any statistical analysis is run — skipping or misordering these steps can invalidate results.
• The standard pipeline includes format conversion, quality control, slice timing correction, motion correction, coregistration, spatial normalization, smoothing, and noise removal.
• SPM, FSL, and AFNI are the long-standing manual/scriptable toolboxes, while fMRIPrep has become a popular standardized, automated alternative for improving reproducibility across studies.
• Excessive head motion is one of the most common and most damaging sources of artifact in fMRI data, and needs explicit quality-control screening, not just correction.
• Preprocessing choices should be decided and documented before analysis begins, not adjusted after seeing which choice produces a more favorable result.

Why fMRI Preprocessing Matters

Functional MRI measures the blood-oxygen-level-dependent (BOLD) signal, an indirect proxy for neural activity, and that signal is small relative to the noise present in any scan. Even a few millimeters of head movement between scans, breathing-related signal fluctuations, or scanner drift over a long session can produce changes in signal intensity larger than the actual neural effect a study is trying to detect.

Preprocessing exists to remove or correct for these confounds so that the statistical model applied afterward is actually testing for task-related brain activity, not motion or physiological artifacts that happen to correlate with the task timing. Because functional data from different participants also has to be compared or averaged together, preprocessing also needs to align every participant's brain into a common anatomical space.

Getting the order and parameters of these steps wrong is a well-documented source of both false positives and false negatives in neuroimaging research, which is why reviewers and examiners increasingly expect a detailed, justified preprocessing description in methods sections rather than a vague reference to "standard preprocessing."

It also matters because fMRI studies are typically expensive and time-consuming to collect, so a preprocessing mistake discovered only at the analysis stage cannot simply be fixed by collecting a little more data, the way a small survey study might absorb an error. Getting the pipeline right before running statistical models protects the entire investment the study represents.

Task-Based vs Resting-State fMRI: Different Preprocessing Priorities

Not every fMRI preprocessing decision applies equally to every experimental design. Task-based fMRI, where participants perform a specific cognitive task while being scanned, and resting-state fMRI, where participants simply rest while spontaneous brain activity is recorded, place different demands on certain preprocessing steps.

Resting-state analyses, which typically examine correlations in low-frequency signal fluctuations between brain regions, are especially sensitive to motion artifacts and physiological noise, since these can create spurious correlations that mimic genuine functional connectivity. This is why resting-state pipelines usually apply more aggressive nuisance regression and denoising, alongside careful temporal filtering, compared with many task-based designs.

Task-based fMRI, by contrast, often relies more heavily on precise slice timing correction for fast event-related designs, since the analysis depends on accurately modeling the timing of the BOLD response relative to specific task events. Recognizing which category your study falls into helps you prioritize which preprocessing steps deserve the most careful parameter selection and quality control.

The Standard fMRI Preprocessing Workflow

While exact parameters vary by study design, scanner, and software package, nearly every fMRI study follows the same broad sequence of preprocessing steps. Some pipelines combine or reorder a few of these, but understanding the standard sequence makes it much easier to follow any specific software's documentation.

1

Convert raw scanner data to a standard format

Convert DICOM files from the scanner into NIfTI format, ideally organized following the Brain Imaging Data Structure (BIDS) convention, which most modern preprocessing tools now expect as input.

2

Run initial quality control

Visually and quantitatively inspect raw functional and structural scans for gross artifacts, incomplete brain coverage, or excessive motion before investing further processing time in unusable data.

3

Apply slice timing correction

Because most fMRI sequences acquire brain slices at slightly different times within each volume, slice timing correction adjusts for this by interpolating each slice's signal to a common reference time point, which matters most for studies with fast event-related designs.

4

Correct for head motion

Realign every functional volume to a reference volume (often the first or mean volume) to correct for small head movements during scanning, and record the resulting motion parameters for later use as quality metrics or nuisance regressors.

5

Coregister functional and structural images

Align the lower-resolution functional images to the participant's own high-resolution structural (anatomical) scan, so activation results can later be localized precisely onto recognizable brain anatomy.

6

Normalize to a standard anatomical template

Warp each participant's coregistered images into a common stereotactic space, typically the MNI template, so that results can be compared and averaged across participants despite individual differences in brain shape and size.

7

Apply spatial smoothing

Apply a Gaussian smoothing kernel to the normalized functional data to improve signal-to-noise ratio and account for residual anatomical variability between participants, at the cost of some spatial precision.

8

Remove residual noise

Use nuisance regression (including motion parameters, and white matter or cerebrospinal fluid signal) and, increasingly, automated denoising tools like ICA-AROMA to remove structured noise components that survive the earlier correction steps.

9

Apply temporal filtering

Apply a high-pass (and sometimes band-pass) temporal filter to remove slow scanner drift and very low-frequency noise, particularly important for resting-state functional connectivity analyses.

Popular fMRI Preprocessing Software

Several established toolboxes cover this workflow, each with a somewhat different philosophy about how much manual control versus automation the researcher should have.

Tool	Platform	Typical use case
SPM (Statistical Parametric Mapping)	MATLAB-based, graphical interface	Widely used in academic neuroimaging labs, strong first-level and group statistical modeling
FSL (FMRIB Software Library)	Command-line and GUI, runs on Linux/Mac	Popular for both task-based and resting-state analysis, strong tools for registration (FLIRT/FNIRT)
AFNI	Command-line, runs on Linux/Mac	Flexible scripting, strong for advanced statistical and connectivity analyses
fMRIPrep	Containerized (Docker/Singularity), automated pipeline	Standardized, largely automatic preprocessing designed to improve reproducibility across labs and studies

Manual Pipelines vs Automated Pipelines Like fMRIPrep

Traditionally, researchers built a custom preprocessing pipeline in SPM, FSL, or AFNI by choosing and ordering each step manually. This gives fine-grained control but introduces a risk: two labs studying the same phenomenon might use meaningfully different preprocessing choices, making their results harder to directly compare.

fMRIPrep was developed specifically to address this by providing a standardized, largely automated pipeline that makes sensible, well-documented default choices at each step while still generating detailed quality-control reports for every participant. It has become popular precisely because it reduces the number of subjective, easy-to-misjudge decisions a graduate student has to make alone.

The tradeoff is flexibility: fMRIPrep is intentionally less customizable than building a pipeline by hand, and some specialized analyses, unusual acquisition sequences, or non-standard populations may still require a manually built pipeline in SPM, FSL, or AFNI, or additional processing before or after fMRIPrep's standard steps.

Many labs now adopt a hybrid approach: running fMRIPrep for the standardized core steps (motion correction, coregistration, normalization, and confound estimation) and then applying study-specific smoothing, denoising, or first-level modeling separately in SPM, FSL, or AFNI. This combines fMRIPrep's reproducibility benefits with the flexibility needed for a particular analysis plan.

Common fMRI Preprocessing Pitfalls

Excessive head motion is the single most common data-quality problem in fMRI research, and it disproportionately affects certain populations, including young children, older adults, and clinical groups with movement-related symptoms. Screening and reporting motion metrics, and having a predefined threshold for excluding a scan, is essential rather than optional.

A second common mistake is applying smoothing before normalization, or in the wrong order relative to other steps, which can blur meaningful anatomical detail before it has been properly aligned. Following the documented order for whichever software package you use, rather than an order borrowed informally from a different pipeline, avoids this.

A third mistake is deciding on preprocessing parameters after looking at preliminary results, effectively tuning the pipeline until it produces a desired activation pattern. Preprocessing decisions should be fixed and justified before hypothesis-testing analysis begins, and any deviations should be reported transparently.

Finally, many first-time neuroimaging researchers under-document their preprocessing pipeline in the methods section, reporting only "standard preprocessing was applied" without specifying software, version, parameters, or template space. This makes the study difficult to replicate and is increasingly flagged by reviewers and examiners.

It is also worth reporting standard quality-control metrics alongside your results, such as framewise displacement summaries and temporal signal-to-noise ratio (tSNR), rather than only a pass/fail exclusion decision. These numbers give readers a concrete sense of overall data quality and let them judge whether your motion or noise correction was adequate for the conclusions you are drawing.

When to Bring In Additional Expertise

fMRI preprocessing sits at the intersection of MRI physics, statistics, and software engineering, and it is common for even experienced researchers to need a second opinion on pipeline choices, especially when working with a new scanner, an unusual population, or a novel experimental design. Getting the pipeline reviewed before running a full study, rather than after collecting all your data, is far cheaper in time and effort.

If you need someone experienced in neuroimaging methods to review your pipeline or mentor you through an ongoing project, browsing ResearchDecode's eSupervisors connects you with researchers who have run fMRI studies before. For hands-on help actually running or troubleshooting a preprocessing pipeline on your dataset, ResearchDecode's data analysis and bioinformatics consultancies can take on that specific technical work. If your need is narrow — for example, a second opinion on a single quality-control decision — posting it as a request is often the quickest path to an answer.

Frequently Asked Questions

What is the difference between fMRI preprocessing and first-level analysis?

Preprocessing corrects and prepares raw scan data (motion correction, normalization, smoothing, and so on) so it is suitable for analysis. First-level analysis is the subsequent statistical modeling of each participant's preprocessed data to identify task-related activation.

Is fMRIPrep better than manually building a pipeline in SPM or FSL?

Neither is universally better. fMRIPrep offers standardization, reproducibility, and built-in quality reports, which many labs now prefer, while manual pipelines in SPM, FSL, or AFNI still offer more flexibility for non-standard designs or acquisitions.

How much head motion is too much for fMRI data?

There is no single universal threshold, since acceptable motion depends on study design and analysis type, but most labs define a maximum framewise displacement threshold in advance and exclude or flag scans exceeding it, rather than deciding on a case-by-case basis after seeing results.

Do I need to smooth fMRI data before every analysis?

Not always. Smoothing generally helps task-based group analyses by improving signal-to-noise ratio, but some analyses, such as multivariate pattern analysis, deliberately use unsmoothed or minimally smoothed data to preserve fine-grained spatial information.

What is BIDS and why does it matter for preprocessing?

BIDS (Brain Imaging Data Structure) is a standardized way of organizing and naming neuroimaging files and metadata. Many modern tools, including fMRIPrep, expect data in BIDS format, and using it from the start makes your dataset far easier to process, share, and reproduce.

Should slice timing correction always be applied?

It depends on your acquisition and design. Slice timing correction matters most for fast event-related designs with longer repetition times, and is less critical for very short repetition times or block designs, so check current guidance for your specific sequence and design.

Need a second opinion on your fMRI preprocessing pipeline?

Get your pipeline, parameters, or quality-control decisions reviewed by a researcher experienced in neuroimaging methods before you commit to a full study.

Explore Neuroimaging & Data Analysis Consultancies →