Fmriprep dropping '0' in run number (v20.2.0, v20.1.0)

Hello,

I am processing resting-state data using fmriprep via Docker, with different datasets using different versions of fmriprep. I have noticed that, in recent versions of fmriprep (20.2.0, 20.1.0), the filenames for the preprocessed files drop the zero from the run number. For example, if the input image is “sub-C1004_ses-baseline_task-rest_run-01_bold”, the output images will be labeled “sub-C1004_ses-baseline_task-rest_run-1_[…]”.

This does not occur in earlier versions (e.g. 20.0.5); that is, the zero is retained in the filenames of preprocessed files, e.g. “run-01”.

If it’s helpful information, I use Ubuntu 18.04.5, 16GB RAM, and 4C/8T CPU. I run fmriprep with the following tags: --use-aroma --ignore slicetiming --fs-no-reconall

I didn’t see it mentioned elsewhere on the site, so I thought I’d bring it to your attention.

Best,
Patrick

Hi @pruittpj ,

According to the BIDS spec:

If several scans with the same acquisition parameters are acquired in the same session,they MUST be indexed with the [run-](../99-appendices/09-entities.md#run) entity:_run-1, _run-2, _run-3, and so on (only nonnegative integers are allowed as run labels)

I believe BIDS generally preferred run labels to have non-negative integers, but was agnostic if runs were zero-padded (e.g. _run-01). My impression is that the newer fMRIPrep versions are adhering to the BIDS terminology more strictly, hence the conformity towards non-negative integers for run number labelling.

Moving forward, it’ll be a good idea to not zero-pad run numbers when converting your data to BIDS, thus eliminating the labelling discrepancy between your input data and fMRIPrep’s output.

@dlevitas, that makes sense. Many thanks for your reply!