Preprocessing Anomaly from fMRIPrep

Summary of what happened:

Hi there,

I’m having something strange happen to my preprocessed anatomical images. They go into fMRIPrep looking perfectly normal (raw bids file, first image), and they come out with a strange, light coloured bar across the brain along with a lot of shadowing (as you can see in the second image).

Can anyone help me understand what’s going on and why the images are coming out this way? Is there anything I can do to solve the issue? I was originally putting into into MNI template space, but was running into the same problem. Any input on this issue would be greatly appreciated.


Command used (and if a helper script was used, a link to the helper script or the command generated):

Below is the python script I am using to run fMRIPrep:

def run_fmriprep(input_dir, output_dir, subject):
    input_path = os.path.join(input_dir, 'BIDS_ya')
    output_path = os.path.join(output_dir, 'fmriprep')
    license_file = os.path.join(output_dir, 'license.txt')
    freesurfer_path = os.path.join(derv_dir, 'freesurfer_ya')

    # Get the current user's UID and GID
    uid = os.getuid()
    gid = os.getgid()

    docker_command = [
        'docker', 'run', '--rm',
        '--user', f'{uid}:{gid}',  # Add the --user flag with UID and GID
        '-v', f'{input_path}:/data:ro',
        '-v', f'{output_path}:/out',
        '-v', f'{license_file}:/opt/freesurfer/license.txt:ro',
        '-v', f'{freesurfer_path}:/freesurfer_subjects',
        '-v', f'{output_dir}:/work',  
        '/data', '/out', 'participant',
        '--participant-label', subject.replace('sub-', ''),
        '--output-spaces', 'func',
        '--ignore', 'slicetiming',
        '--dummy-scans', '4',
        '--n_cpus', '5',
        '--skull-strip-t1w', 'force',
        '-w', '/work'


Environment (Docker, Singularity / Apptainer, custom installation):

Docker (running Docker through Python)

Data formatted according to a validatable standard? Please provide the output of the validator:


Relevant log outputs (up to 20 lines):

fMRIPrep ran successfully.

Screenshots / relevant information:

Hi @ejdavid,

I have relabeled your post as Software Support which provides a post template that prompts you for important information we can use to help diagnose your issues. Please use this in future software-related posts.

It would help if you can edit your post to add in the missing information.


I’ve updated a bit of the information here. Just wanted to know if anyone had any ideas what might be causing this. Thanks again!

I no longer seem to be able to edit my original message. There is no relevent log output that I am aware of (the images are simply coming out as I’ve shown, though fMRIPrep says it was run successfully). I don’t have a formal validator but it’s an issue with something fMRIPrep is doing; other peoprocessing software does not seem to be having the same issue.

It will be run if you do not --skip-bids-validation.

Some other things, although probably not related to what you are seeing.

You make this binding but do not use is your command, did you intend to reuse these data?

This is not in the latest version of fMRIPrep. Are you running 23.2.0 or 23.2.1?


I am using 23.2.0.

I have freesurfer files for this data already done; I thought including the folder where these are kept would indicate for fMRIPrep to use these files; perhaps I misunderstood how to do this.

Just be wary that if you keep it as 'nipreps/fmriprep:latest', it will change versions to whatever is the latest, which is now 23.2.1.

You need to specify the --fs-subjects-dir argument to map to your already processed data. Otherwise fMRIPrep will look for them in BIDS/derivatives/fmriprep/sourcedata/freesurfer by default.


Apologies for the drive-by, I’m not going to be very interactive, but my first thought looking at that figure would be that it looks like an average of a full-brain T1w image and a limited FoV T1w image. If you have that, you may need to use --bids-filter-file to limit which T1w images are made available to fMRIPrep.

1 Like

This turned out to be the problem. Thanks for the drive-by!

1 Like