smriprep: Wrong probseg fmriprep output from freesurfer pipeline

Hi, I noticed that the output of the segmentation from the freesurfer pipeline vs the FLIRT pipeline produced different probseg files. Especially, the probseg files from Freesurfer pipeline stream are binarized and not looking nice at all. probseg-GM produced through Freesurfer pipeline: T1w_probseg_GM_FS

probseg-GM produced through FSL pipeline: T1w_probseg_GM_FSL

probseg-GM + WM with Freesurfer pipeline: T1w_probseg_GM+WM_FS

probseg-GM + WM with FSL pipeline: T1w_probseg_GM+WM_FSL

probseg-WM with FS pipeline: T1w_probseg_WM_FS

wm.mgz file in the freesurfer folder: it looks ok! T1w_probseg_wmMGZ_freesurfer

Has anybody also noticed this on its data?

What version of fMRIPrep are you using?

20.2.0

What kind of installation are you using? Containers (Singularity, Docker), or “bare-metal”?

Singularity

What is the exact command-line you used?

</usr/local/miniconda/bin/fmriprep /work/EcritApp /work/EcritApp/derivatives --fs-license-file /work/freesurfer/license.txt participant --participant_label 001 --fd-spike-threshold 0.9 --return-all-components -w /work/temp_data_EcritApp --omp-nthreads 8 --nthreads 12 --mem_mb 40000 --ignore slicetiming --output-spaces T1w MNI152NLin2009cAsym MNIPediatricAsym:cohort-3>

Have you checked that your inputs are BIDS valid?

Yes

Did fMRIPrep generate the visual report for this particular subject? If yes, could you share it?

Can you find some traces of the error reported in the visual report (at the bottom) or in crashfiles?

<No errors to report!>

Are you reusing previously computed results (e.g., FreeSurfer, Anatomical derivatives, work directory of previous run)?

Yes Freesurfer results were re-used

fMRIPrep log

If you have access to the output logged by fMRIPrep, please make sure to attach it as a text file to this issue.

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 15 (9 by maintainers)

Most upvoted comments

No significant increase (25m38s to 27m2s) in runtime going from 7 to 1 thread, and no change in output. So that’s at least a reasonable first pass. Should still look into reusing if we can…