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...

[effigies]

Haven't tested the effect of threading.

[effigies]

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...

[effigies]

These are the histograms of the posteriors. Unclear how to get a tissue probability map from these. @ahoopes a little guidance would be appreciated.

@oesteban Is there any reason not to revert to FAST for TPMs until this is resolved?

[mgxd]

Is there any reason not to revert to FAST for TPMs until this is resolved?

Good point, may be the easiest solution for now..

[oesteban]

The only reason is to minimize the use of commercially restricted FSL. But in the short term, it might actually be a decent solution.

An alternative to post-processing these posteriors and avoiding FSL (while being an acceptable solution with --fs-no-reconall) would be to use ATROPOS instead, and feed it with priors generated from either aseg (roughly what we already have, converting from aseg to 3-tissue segmentation) or from a template (for the --fs-no-reconall pathway). @eilidhmacnicol is probably the best resource here as she has played quite a bit with ATROPOS' priors (although she's off right this minute, will be back next week).

[effigies]

Sounds good. Then, in order not to block a 21.0.0 release, we will revert to FAST for now. Let's make an issue to further explore FreeSurfer/ANTs replacements for 21.1.

[ahoopes]

These are the histograms of the posteriors. Unclear how to get a tissue probability map from these.

Just looked at the code a bit. It's kind of a hidden feature, so there's no much (or any) documentation. The -write_probs flag saves a volume that includes only the top 3 label probabilities for each voxel. So, it's a 6-frame image where each frame represents (label-1, prob-1, label-2, prob-2, label-3, prob-3).