Fmriprep 1.5.5 fails on freesurfer call: ERROR! FOV=282.000 > 256

This is happening for some subjects with a single session, does not seem to happen when multiple sessions are available.

The available T1w is below 256mm in size, but a conversion is happening by freesurfer and size is changed.

Original image header:

 Size : 208 256  256

  Image Dimensions   : [208, 256, 256]
  Bounding Box       : {[115.751 127.057 -134.726], [344.551 409.057 147.274]}
  Voxel Spacing      : [1.1, 1.10156, 1.10156]
  Intensity Range    : [0, 1138]
  Mean Intensity     : 61.593
  Direction Cos Mtx. :
-1 0 0
0 -1 0
0 0 1

fmriprep call:

/usr/local/miniconda/bin/fmriprep /DATA/dorian/fmriprepdata/STUDY1/data/processed/fmriprep-1.5.5/bids /DATA/dorian/fmriprepdata/STUDY1/data/processed/fmriprep-1.5.5 participant --participant-label 123456 --nthreads 4 --omp-nthreads 3 --fs-license-file /DATA/DAPPS/freesurfer/2019_08_05/freesurfer//license.txt --work-dir /DATA/dorian/fmriprepdata/STUDY1/data/processed/fmriprep-1.5.5/work_sub-123456 --longitudinal --cifti-output --resource-monitor --notrack --no-submm-recon --use-aroma --skip_bids_validation --write-graph --force-syn --low-mem --output-spaces MNI152NLin2009cAsym:res-02 HDSTUDY160v1:res-02 OASIS30ANTs:res-02 fsaverage fsaverage5 T1w func

Error log:

RuntimeError: Command:
recon-all -autorecon1 -i /DATA/dorian/fmriprepdata/STUDY1/data/processed/fmriprep-1.5.5/bids/sub-123456/ses-01/anat/sub-123456_ses-01_run-02_T1w.nii.gz -noskullstrip -openmp 3 -subjid sub-123456 -sd /DATA/dorian/fmriprepdata/STUDY1/data/processed/fmriprep-1.5.5/freesurfer
Standard output:
Subject Stamp: freesurfer-Linux-centos6_x86_64-stable-pub-v6.0.1-f53a55a
Current Stamp: freesurfer-Linux-centos6_x86_64-stable-pub-v6.0.1-f53a55a
INFO: SUBJECTS_DIR is /DATA/dorian/fmriprepdata/STUDY1/data/processed/fmriprep-1.5.5/freesurfer
Actual FREESURFER_HOME /opt/freesurfer
Linux mri 3.10.0-1062.9.1.el7.x86_64 #1 SMP Fri Dec 6 15:49:49 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
'/opt/freesurfer/bin/recon-all' -> '/DATA/dorian/fmriprepdata/STUDY1/data/processed/fmriprep-1.5.5/freesurfer/sub-123456/scripts/recon-all.local-copy'

 mri_convert /DATA/dorian/fmriprepdata/STUDY1/data/processed/fmriprep-1.5.5/bids/sub-123456/ses-01/anat/sub-123456_ses-01_run-02_T1w.nii.gz /DATA/dorian/fmriprepdata/STUDY1/data/processed/fmriprep-1.5.5/freesurfer/sub-123456/mri/orig/001.mgz 

mri_convert.bin /DATA/dorian/fmriprepdata/STUDY1/data/processed/fmriprep-1.5.5/bids/sub-123456/ses-01/anat/sub-123456_ses-01_run-02_T1w.nii.gz /DATA/dorian/fmriprepdata/STUDY1/data/processed/fmriprep-1.5.5/freesurfer/sub-123456/mri/orig/001.mgz 
$Id: mri_convert.c,v 1.226 2016/02/26 16:15:24 mreuter Exp $
reading from /DATA/dorian/fmriprepdata/STUDY1/data/processed/fmriprep-1.5.5/bids/sub-123456/ses-01/anat/sub-123456_ses-01_run-02_T1w.nii.gz...
TR=2200.00, TE=0.00, TI=0.00, flip angle=0.00
i_ras = (1, 0, 0)
j_ras = (0, 1, 0)
k_ras = (0, 0, 1)
writing to /DATA/dorian/fmriprepdata/STUDY1/data/processed/fmriprep-1.5.5/freesurfer/sub-123456/mri/orig/001.mgz...
#@# MotionCor Wed Jan 22 06:10:03 EST 2020
Found 1 runs
Checking for (invalid) multi-frame inputs...
WARNING: only one run found. This is OK, but motion
correction cannot be performed on one run, so I'll
copy the run to rawavg and continue.

 cp /DATA/dorian/fmriprepdata/STUDY1/data/processed/fmriprep-1.5.5/freesurfer/sub-123456/mri/orig/001.mgz /DATA/dorian/fmriprepdata/STUDY1/data/processed/fmriprep-1.5.5/freesurfer/sub-123456/mri/rawavg.mgz 


 mri_convert /DATA/dorian/fmriprepdata/STUDY1/data/processed/fmriprep-1.5.5/freesurfer/sub-123456/mri/rawavg.mgz /DATA/dorian/fmriprepdata/STUDY1/data/processed/fmriprep-1.5.5/freesurfer/sub-123456/mri/orig.mgz --conform 

mri_convert.bin /DATA/dorian/fmriprepdata/STUDY1/data/processed/fmriprep-1.5.5/freesurfer/sub-123456/mri/rawavg.mgz /DATA/dorian/fmriprepdata/STUDY1/data/processed/fmriprep-1.5.5/freesurfer/sub-123456/mri/orig.mgz --conform 
WARNING ==================++++++++++++++++++++++++=======================================
The physical sizes are (228.80 mm, 282.00 mm, 282.00 mm), which cannot fit in 256^3 mm^3 volume.
The resulting volume will have 282 slices.
If you find problems, please let us know (

$Id: mri_convert.c,v 1.226 2016/02/26 16:15:24 mreuter Exp $
reading from /DATA/dorian/fmriprepdata/STUDY1/data/processed/fmriprep-1.5.5/freesurfer/sub-123456/mri/rawavg.mgz...
TR=2200.00, TE=0.00, TI=0.00, flip angle=0.00
i_ras = (1, 0, 0)
j_ras = (0, 1, 0)
k_ras = (0, 0, 1)
changing data type from float to uchar (noscale = 0)...
MRIchangeType: Building histogram 
Reslicing using trilinear interpolation 
writing to /DATA/dorian/fmriprepdata/STUDY1/data/processed/fmriprep-1.5.5/freesurfer/sub-123456/mri/orig.mgz...

ERROR! FOV=282.000 > 256
Include the flag -cw256 with recon-all!
Inspect orig.mgz to ensure the head is fully visible.

Inspection of the image is fine. I can crop the bottom to remove some of the neck, which might resolve the issue, but this is a standard BIDS dataset and I don’t like to mess the raw data to create ad-hoc data to overcome the problem.

From the data you provide:

  Image Dimensions   : [208, 256, 256]
  Voxel Spacing      : [1.1, 1.10156, 1.10156]

It looks like you have a FoV of (228.80 mm, 282.00 mm, 282.00 mm), as described by mri_convert.

Right. What is the solution to make fmriprep work with these data? Is there a way to get fmriprep to pass -cw256 to the freesurfer call to resolve the problem?

We’ll probably need to update fMRIPrep to detect this case.

The place to do it will be here:

I am using a singularity container which I built myself from your docker image. Any chance you can push a fix in the docker image (i.e. 1.5.7) so I don’t attempt hacks on the singularity image myself?

Thank you.

Looks like we can do this without changing the API, so we should be able to put out a bug-fix release in the next couple days.

1 Like

@dorianps 1.5.7 is out. Let us know how that goes.

I am waiting to finish the current processing for another week or so (using 1.5.5), then will go back to run 1.5.7 on the cases with the above fail error. Will report here how it goes.

Many thanks for the quick fix.

Excellent. The changes from 1.5.5 to 1.5.7 are small enough that you should be able to reuse working directories and minimize recomputation.

@effigies This is fixed now in v1.5.7. I confirmed on two subjects that had this issue.

Thank you.