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:
probseg-GM produced through FSL pipeline:
probseg-GM + WM with Freesurfer pipeline:
probseg-GM + WM with FSL pipeline:
probseg-WM with FS pipeline:
wm.mgz file in the freesurfer folder: it looks ok!
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)
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…