Wrong probseg fmriprep output from freesurfer pipeline

[julfou81]

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.

[julfou81]

This issue is still present for version 20.2.2. It looks that something is not working properly in smriprep.workflows.anatomical, for the case with freesurfer: the part which is converting the .aseg file from freesurfer (which looks fine) to t1w_tpms is somehow doing something wrong.

[julfou81]

Here is another illustration. T1w image from 1 subject, preprocessed with FMRIPREP and normalized to MNI152NL2009cAsym.
1st case: with freesurfer processing, overlap of the tissue probability map of CSF:

2nd case: same input T1w image, but this time, the overlapping TPM of CSF was generated from the fmriprep stream with the flag --fs-no-reconall:

I wish I could help but I don't really understand how this code works, especially the part converting freesurfer outputs to fmriprep derivatives:
https://www.nipreps.org/smriprep/_modules/smriprep/workflows/anatomical.html#init_anat_preproc_wf

[oesteban]

Yes, I think we can agree on these tissue probability maps being poor. I think the one issue is that I never bothered to find the right way to generate tissue probability maps (as in GM, WM and CSF) from FreeSurfer outputs.

If someone more versed in FreeSurfer (@ahoopes?) could give me a hand, it would be very much appreciated. Right now we are just mapping labels from aseg to {WM, GM, CSF}.

[oesteban]

Okay, I'm assigning this to the upcoming new release, as new TPMs will drastically affect the results of aCompCor.

[ahoopes]

There's no direct way to generate gm/wm/csf tissue probabilities in FS, but you could add the -write_probs <filename> flag to mri_ca_label via the recon-all expert options. This saves the aseg posteriors, then you could do some post-processing on that to generate the tissue maps.

[effigies]

@ahoopes Can mri_ca_label be run post-hoc without modifying the FreeSurfer directory? And is this the same between 6.0.1 and 7.1? We bundle 6.0.1, but 7.1 shows up as "complete", so we won't try to re-run things with mixed versions. As long as running mri_ca_label v6.0.1 on a 7.1 directory produces the same results, then we should be good to go.

[effigies]

@mgxd @oesteban I have a pre-run FreeSurfer with v6.0.1 in /data/out/ds000005-fmriprep/freesurfer'. Looking at scripts/recon-all.log`, I see we ran:

mri_ca_label -relabel_unlikely 9 .3 -prior 0.5 -align \
    norm.mgz \
    transforms/talairach.m3z 
    /opt/freesurfer/average/RB_all_2016-05-10.vc700.gca \
    aseg.auto_noCCseg.mgz

I re-ran with FreeSurfer 7.2.0:

OMP_NUM_THREADS=7 mri_ca_label -relabel_unlikely 9 .3 -prior 0.5 \
    -write_probs ./posterior.mgz \
    -align
    /data/out/ds000005-fmriprep/freesurfer/sub-01/mri/norm.mgz \
    /data/out/ds000005-fmriprep/freesurfer/sub-01/mri/transforms/talairach.m3z \
    /usr/local/freesurfer/7.2.0/average/RB_all_2016-05-10.vc700.gca \
    ./aseg.auto_noCCseg.mgz

The good news is that the resulting aseg.auto_noCCseg.mgz is identical to the original. The bad news is that it took 25 minutes even with 7 threads. I'm not sure if there's a way we can re-use the first run through.

[mgxd]

Is there a significant time difference vs running with a single thread? If not, adding 25 mins might be fine...