# OHBM 2024 abstract

## Metadata

### Title

fmriprep-next: Preprocessing as a fit-transform model

### Authors

* [x] Chris Markiewicz | [e-mail] | https://orcid.org/0000-0002-6533-164X
* [x] Mathias Goncalves | [e-mail] | https://orcid.org/0000-0002-7252-7771
* [x] Ma Feilong | [e-mail] | https://orcid.org/0000-0002-6838-3971
* [x] Lea Waller | <[e-mail]> | https://orcid.org/0000-0002-3239-6957
* [x] John Kruper | [e-mail] | https://orcid.org/0000-0003-0081-391X
* [x] Robert E. Smith | [e-mail] | https://orcid.org/0000-0003-3636-4642
* [x] Joseph Wexler | [e-mail] | https://orcid.org/0000-0001-6424-8740
* [x] Juan Sanchez-Pena | [e-mail]
* [x] Gaurav H Patel | [e-mail] | https://orcid.org/0000-0003-0028-2098
* [x] Russ Poldrack
* [x] Oscar Esteban

### Categories

* Primary Category: Workflows
* Secondary Category: Motion Correction and Preprocessing
* Additional Categories:

### Keywords

* Computing
* Data analysis
* Functional MRI
* Informatics
* Open-source software
* Workflows

### Abstract Information

* Software demonstration: No
* Oral presentation: Yes
* Press: Yes
* Resting/Task: Both
* Subjects: Healthy
* US: Yes
* IRB: No
* Human subjects approved by IRB: Not applicable
* Animal research approved by IACUC: Not applicable
* Methods used in research:
* Structural MRI
* Functional MRI
* Field strength
* 1.5T
* 3T
* Processing packages
* [x] AFNI
* [ ] SPM
* [ ] Brain Voyager
* [x] FSL
* [ ] Analyze
* [x] FreeSurfer
* [ ] LONI
* [x] Other
* ANTs
* Nipype
* nitransforms
* References: see below

## Abstract

### Introduction

The value of publicly shared neuroimaging data depends on the level of
processing applied to the data.
While raw data provide the greatest opportunity for asking novel questions,
each step of processing left to secondary researchers is a
potential source of analytical variation that can lead to conflicting
results from the same source data [NARPS].
A researcher wishing to share the data they have collected can reduce
sources of variability in downstream analyses by providing a canonical
set of preprocessed data for reuse [HCPPipelines].

Publication of data that have been resampled into several spaces can
enable different analyses while limiting analytical variability,
but this requires significantly more storage and bandwidth.
Generation of many derivatives may also be inefficient on shared,
high-performance computing systems suited to computationally
intensive tasks with relatively little storage use.
It would thus be beneficial to calculate and distribute a compact set of
preprocessing derivatives that permit the remaining derivatives to be generated
cheaply and deterministically at the time of analysis.

Here we present recent changes in the architecture of fMRIPrep [fMRIPrep], a preprocessing pipeline for functional MRI. These changes separate the typical processing pipeline into two discrete, user-accessible workflows. Firstly, a computationally expensive "fit" stage performs steps such as segmentation, registration, and surface reconstruction, the derivatives of which are small and therefore easy to distribute. A second "transform" workflow then utilizes the raw input data and the derivatives from the "fit" workflow to deterministically generate dense pre-processed fMRI data in any desired target space with minimal additional computational cost. We discuss the practical consequences of these software changes for fMRI data processing and distribution.

### Methods

The fit-transform architecture has been published in version 23.2.0a2. To test the impact of the described changes, fMRIPrep 23.2.0a2 and the prior release, 23.1.4, were run on two subjects from two different datasets.

Dataset A: 6 T1-weighted, 3 T2-weighted structural scans, 2 phase-difference fieldmaps, 4 single-echo BOLD runs with 195 volumes (total 784 volumes), and 1 single-band reference volume per BOLD series.

Dataset B: 2 T1-weighted structural scans, 6 spin-echo fieldmaps, and 8 single-echo BOLD runs with varying lengths, for a total of 4274 volumes.

These results were gathered on a single, 20-core Intel i9-10900 2.8GHz processor. The host system was Ubuntu Linux 22.04 LTS, running Docker version 24.0.7.

The commands tested requested outputs registered to MNI152NLin2009cAsym volumetric template and the fsLR "grayordinate" template.

> [name=Lestropie] If you wanted to sell it better, should have done a dataset where you generate the pre-processed fMRI data in every single supported output space; since that's what you would otherwise need to do to facilitate any downstream analysis for a given raw dataset. :-P

### Results

Table 1 compares runtimes and the storage usage in each version. Running fit-only workflows resulted in 34-66%, 94-98% and 84-92% reductions in runtime, data size and file counts, compared to the previous version. These reductions reflect the compute/storage utilization of the prior transform processes.

> [name=Lestropie] Fact that performance in both computation and scratch use has changed between versions needs to be addressed explicitly in text. It's not an obviously expected result given the description of structural changes provided.

Running fit and transform workflows resulted in 25-52%, 43-54% and 72-87% reductions in runtime, data size and file counts.

Some efficiency was achieved through changes incidental to the structural changes described here.
The increase in output sizes reflects additional outputs needed for resampling, present in the
fit-only derivatives, as well as some unintended outputs which will be removed in future revisions.

### Conclusions

Here we describe changes which result in a significant decrease in computational
time and storage utilization for users of fMRIPrep. These changes particularly
benefit researchers and data stewards interested in ensuring access to large scale
data repositories.

We also anticipate that these changes will simplify the process of resolving errors
in preprocessing, as errors of fit and transformation can be addressed separately, and
researchers will have the option of providing alternative fit results to be used in
transformation. At the same time, the full workflow continues to provide the full range
of derivatives that make fMRIPrep an attractive option.

### Figures

<figure>

| Dataset | Version/Mode | Runtime | Scratch Size | Scratch Files | Output Size | Output files |
|--|--|--|--|--|--|--|
| A | 23.1.4 | 2h24m | 54.8GB | 36.8K | 2.30GB | 176 |
| A | 23.2.0a2 / fit | 1h35m | 2.91GB | 5.89K | 602MB | 128 |
| A | 23.2.0a2 / fit+transform | 1h47m | 19.8GB | 10.0K | 6.37GB | 206 |
| B | 23.1.4 | 4h25m | 121GB | 157K | 5.10GB | 286 |
| B | 23.2.0a2 / fit | 1h29m | 1.88GB | 12.0K | 543MB | 206 |
| B | 23.2.0a2 / fit+transform | 2h7m | 56.5GB | 19.8K | 14.7GB | 348 |

<figcaption><span style="font-size: smaller">

**Table 1**: Comparison of runtimes and disk usage between fMRIPrep version 23.1.4
and 23.2.0a2.
"fit" mode included only fit workflows and their outputs; "fit+transform" includes
all outputs, with rough parity with 23.1.4 outputs.
All processes were completed independently, with no shared CPU, memory or files.
</span></figcaption>
</figure>

> [name=Lestropie] For many researchers, a key interaction they will have with this software in the future will be "I obtained the raw fMRI data and "fit" workflow derivatives; combined they are of this size. I then ran the "transform" workflow; that took this long, and produced scratch and output data of these sizes". That may be of greater interest than "what do if I get if I run "fit" then "transform"", which from a user perspective is not really any different to current usage.

<figure>

%%{init: {'theme':'neutral'}}%%
graph LR;
    classDef opt stroke-dasharray: 5

    subgraph raw[Raw dataset];
      direction TB;
      T1w & fmap[Fieldmap]:::opt & bold[BOLD]
      sbref["Single-band
             reference"]:::opt
    end
    
    subgraph min[Fit derivatives];
      direction TB;
      T1w ---> norm["T1w-to-template
                     transform"]
      boldref & T1w --> coreg
      bold --> boldref["BOLD
                        References"]
      sbref -.-> boldref
      bold & boldref --> hmc["HMC
                              transforms"]
      boldref --> boldmask["BOLD mask"]
      coreg["BOLD-to-T1w
             transform"]
      fmap' & boldref -.-> bold2fmap["BOLD-fieldmap
                                  transform"]
      fmap -.-> fmap'["Preprocessed
                      Fieldmap"]
    end
    
    subgraph Archive;
      raw & min
    end
    
    subgraph Transform;
       direction LR;
       bold --- s(["Slice-timing
                    correction"]):::opt --> boldr;
       fmap' & bold2fmap -.-> fmap''["Resampled
                                      Fieldmap"] -.-> boldr
       hmc --> boldr
       coreg & norm -.-> boldr["Resampled
                                       BOLD"]
    end

<figcaption><span style="font-size: smaller">

**Figure 1**: Schematic diagram of data dependencies
in the fMRIPrep-next workflow model. Dashes indicate
optional data or processes. The "fit" derivatives
include a collection of individual volumes and
transform files. The "transform" section shows the
process used to generate resampled BOLD series.
The available inputs, such as fieldmaps and
slice-timing metadata, and the target space, such
as an MNI template, determine the final result.
<br>
The raw and fit derivatives may be distributed as
an archive, and the transform process may be
performed by the analyzing researcher.
Not shown here are confound time series, which
are products of both fit and transform workflows.
</span></figcaption>
</figure>

> [name=Lestropie] "Confound time series" is not a derivative of "Resampled BOLD". Maybe like the "Fit derivatives" subgraph you need a "Transform derivatives" sub-graph where "Resampled BOLD" and "Confound time series" are generated from their respective inputs.

### References

0. Botvinik-Nezer, R., Holzmeister, F., Camerer, C.F. et al. Variability in the analysis of a single neuroimaging dataset by many teams. Nature 582, 84–88 (2020). https://doi.org/10.1038/s41586-020-2314-9
0. Esteban, O., Markiewicz, C. J., Blair, R. W., Moodie, C. A., Isik, A. I., Erramuzpe, A., Kent, J. D., Goncalves, M., DuPre, E., Snyder, M., Oya, H., Ghosh, S. S., Wright, J., Durnez, J., Poldrack, R. A., & Gorgolewski, K. J. (2019). fMRIPrep: A robust preprocessing pipeline for functional MRI. Nature Methods, 16(1), 111–116. doi:10.1038/s41592-018-0235-4
0. Gorgolewski, K.J. (2016), ‘The brain imaging data structure, a format for organizing and describing outputs of neuroimaging experiments’ Scientific Data, 3:160044. doi:10.1038/sdata.2016.44
0. Glasser MF, Sotiropoulos SN, Wilson JA, Coalson TS, Fischl B, Andersson JL, Xu J, Jbabdi S, Webster M, Polimeni JR, Van Essen DC, Jenkinson M; WU-Minn HCP Consortium. The minimal preprocessing pipelines for the Human Connectome Project. Neuroimage. 2013 Oct 15;80:105-24. doi:10.1016/j.neuroimage.2013.04.127. Epub 2013 May 11. PMID: 23668970; PMCID: PMC3720813.