Fmriprep BET threshold?

hjung · March 26, 2018, 12:15am

Hi all,

I’ve been trying to figure out the FSL BET threshold used in fmriprep. Could you please clarify the threshold? I’d also like to know if there is an option to adjust the BET threshold in the fmriprep pipeline.

(My confusion comes from noticing this line of code “'bet structural.nii brain_anat.nii -f 0.70’” from niworkflows/niworkflows/interfaces/masks.py and assumed it to be .3, but
also noticed a different line of code “bet_hmc = pe.Node(BETRPT(mask=True, frac=0.6), name=‘EPI_hmc_bet’)” from fmriprep/fmripre/workflows/epi.py)

Thank you!

ChrisGorgolewski · March 26, 2018, 4:32am

For skullstriping BOLD images (which is what I assume you are interested - in contrast to skullstripping T1w) FMRIPREP uses a set of heuristics that capitalize on multiple tools (of which bet is only one step). You can see the full procedure here https://github.com/poldracklab/fmriprep/blob/6025b8b8623dfbda2b454815926c95612d487d65/fmriprep/workflows/bold/util.py#L129

Do I understand correctly that FMRIPREP did not do a good job on your data? In such case could you share the HTML reports (with images)?

hjung · April 2, 2018, 5:23am

Hello,

Thank you for the link to the BOLD image skullstriping procedure. That’s helpful to know.
I believe FMRIPREP did a nice job on the functionals. (How would I share the HTML reports with you? They don’t seem to upload in this forum. I’d be happy to share via a different route if interested)

The reason I’ve asked for the BET threshold was because I was using an intersection of the FMRIPREP functional brain masks. I’m trying to overlay it with a probabilistic atlas. However, the intersection is small compared to the MNI template, thus, many voxels dropout once overlaying the intersection with the atlas.

Due to these difficulties, I wanted to check the BET threshold - but since it’s a number of procedures, I’m assuming it might not be a simple fix after all.

ChrisGorgolewski · April 2, 2018, 5:47am

You can share reports by uploading them to Dropbox or similar file sharing service.

If masks look good in the reports and coregistration is satisfactory, small mask intersection is most likely caused by signal dropout in some of the subject. In other words it would be worth fixing inaccurate mask, but making masks more liberal (less accurate) just to increase the size of the mask intersection seems counterintuitive.

Mind that many studies use group level mask that includes voxels from at least 80% of participants (instead of 100% as in case of a pure intersection). This is more liberal option and it’s also more transparent (or easier to interpret) than making individual masks more liberal.

hjung · April 2, 2018, 6:21am

Thank you for the quick response!

Follow up on your suggestions and comments:

Here’s the link to the functional html report. https://www.dropbox.com/s/ejmsj288yjpeoil/sub-control03.html?dl=0 Please let me know if it doesn’t work.
How would I go about fixing an inaccurate mask? I’m not sure what would be an indicator of signal dropout from the reports.
Thanks for pointing out the 80% group-level intersection mask. Will definitely try that liberal option.

ChrisGorgolewski · April 2, 2018, 6:24am

Your link is giving me Error 400.

Fixing inaccurate mask would involve making changes to FMRIPREP codebase to improve the heuristic. Hard to say what exactly would need to be done without seeing the reports.

jsein · September 12, 2018, 11:37am

Hi I have an error for the brain mask calculated on the magnitude image of the fieldmap provided for SDC.
The report can be found under the following link:

These images are acquired on a 64 CH coil.
This magnitude image provided to fmriprep is already the result of FSL-topup run on 2 SE-EPI images with opposed phase-encoding directions. The fieldmap generated by topup is provided here as the fieldmap in Hz.

Would you have an insight why the mask is failing in fmriprep despite the use of N4 in the procedure for creating a skull stripped magnitude image?

Thank you for your help!

ChrisGorgolewski · September 12, 2018, 2:15pm

There is a fix in the works (https://github.com/poldracklab/fmriprep/pull/1050). Would you mind trying it? It will require building a Docker image after checking out the branch.

git clone https://github.com/ZhifangYe/fmriprep.git --branch robust_epi_mask --single-branch
cd fmriprep
docker build -t poldracklab/fmriprep:robust_epi_mask .

Don’t forget the dot at the end of the last command!

After the build is complete you can use your new custom container in fmriprep-docker via an argument (see command line help for details).

jsein · September 12, 2018, 2:57pm

Thank you for the super fast answer!
I am ready to look into it but for the moment I failed accomplishing the last command line:

docker build -t poldracklab/fmriprep:robust_epi_mask .
Sending build context to Docker daemon 35.44MB
Step 1/42 : FROM ubuntu:xenial-20161213
_ —> 104bec311bcd_
Step 2/42 : COPY docker/files/neurodebian.gpg /root/.neurodebian.gpg
_ —> Using cache_
_ —> 53bbd77da658_
Step 3/42 :[…]
_ —> Using cache
_ —> 71641d9b9dda_
Step 4/42 : RUN curl -[…]surfer.nmr.mgh.harvard.edu/pub/dist/freesurfer/6.0.1/freesurfer-Linux-centos6_x86_64-stable-pub-v6.0.1.tar.gz | tar zxv --no-same-owner -C /opt --exclude=‘freesurfer/trctrain’ --exclude=‘freesurfer/subjects/fsaverage_sym’ --exclude=‘freesurfer/subjects/fsaverage3’ --exclude=‘freesurfer/subjects/fsaverage4’ --exclude=‘freesurfer/subjects/cvs_avg35’ --exclude=‘freesurfer/subjects/cvs_avg35_inMNI152’ --exclude=‘freesurfer/subjects/bert’ --exclude=‘freesurfer/subjects/V1_average’ --exclude=‘freesurfer/average/mult-comp-cor’ --exclude=‘freesurfer/lib/cuda’ --exclude=‘freesurfer/lib/qt’
_ —> Running in f9a00bf681d7_

gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now
The command ‘/bin/sh -c curl -sSL https://surfer.nmr.mgh.harvard.edu/pub/dist/freesurfer/6.0.1/freesurfer-Linux-centos6_x86_64-stable-pub-v6.0.1.tar.gz | tar zxv --no-same-owner -C /opt --exclude=‘freesurfer/trctrain’ --exclude=‘freesurfer/subjects/fsaverage_sym’ --exclude=‘freesurfer/subjects/fsaverage3’ --exclude=‘freesurfer/subjects/fsaverage4’ --exclude=‘freesurfer/subjects/cvs_avg35’ --exclude=‘freesurfer/subjects/cvs_avg35_inMNI152’ --exclude=‘freesurfer/subjects/bert’ --exclude=‘freesurfer/subjects/V1_average’ --exclude=‘freesurfer/average/mult-comp-cor’ --exclude=‘freesurfer/lib/cuda’ --exclude=‘freesurfer/lib/qt’’ returned a non-zero code: 2

Any thoughts? Thank you for your help and for sharing all this fine work!

ChrisGorgolewski · September 12, 2018, 3:03pm

It seems that FreeSurfer changed something about their tarball distribution system. While we are figuring this out please try replacing https://surfer.nmr.mgh.harvard.edu/pub/dist/freesurfer/6.0.1/freesurfer-Linux-centos6_x86_64-stable-pub-v6.0.1.tar.gz with https://surfer.nmr.mgh.harvard.edu/pub/dist/freesurfer/6.0.1/freesurfer-Linux-centos6_x86_64-stable-pub-v6.0.1-f53a55a.tar.gz in the Dockerfile.

jsein · September 13, 2018, 9:41am

Thank you for this quick fix. The built went through but now I get the following error that I don’ know how to solve:

docker run --rm -it -v /Applications/freesurfer/license.txt:/opt/freesurfer/license.txt:ro -v ~/Documents/Centre_IRMf/BIDS/Retinopathie:/data:ro -v ~/Documents/Centre_IRMf/BIDS/Retinopathie/derivatives:/out poldracklab/fmriprep:robust_epi_mask /data /out participant --participant-label 01
/usr/local/miniconda/lib/python3.6/site-packages/bids/grabbids/init.py:6: FutureWarning: grabbids has been renamed to layout in version 0.6.5, and will be removed in version 0.8
_ warnings.warn(“grabbids has been renamed to layout in version 0.6.5, and will be removed in version 0.8”, FutureWarning)_
180913-09:38:27,883 nipype.workflow IMPORTANT:
_ _
_ Running fMRIPREP version :_
_ * BIDS dataset path: /data._
_ * Participant list: [‘01’]._
_ * Run identifier: 20180913-093827_7f159801-a39a-4e8a-b6d2-27c003159e2f._
_ _
Process Process-2:
Traceback (most recent call last):
_ File “/usr/local/miniconda/lib/python3.6/multiprocessing/process.py”, line 258, in bootstrap
_ self.run()_
_ File “/usr/local/miniconda/lib/python3.6/multiprocessing/process.py”, line 93, in run_
_ self.target(*self.args, **self.kwargs)
_ File “/usr/local/miniconda/lib/python3.6/site-packages/fmriprep/cli/run.py”, line 542, in build_workflow
_ ignore_aroma_err=opts.ignore_aroma_denoising_errors,
_ File “/usr/local/miniconda/lib/python3.6/site-packages/fmriprep/workflows/base.py”, line 210, in init_fmriprep_wf_
_ ignore_aroma_err=ignore_aroma_err)_
_ File “/usr/local/miniconda/lib/python3.6/site-packages/fmriprep/workflows/base.py”, line 445, in init_single_subject_wf_
_ num_t1w=len(subject_data[‘t1w’]))_
_ File “/usr/local/miniconda/lib/python3.6/site-packages/fmriprep/workflows/anatomical.py”, line 334, in init_anat_preproc_wf_
_ ref_img = op.join(nid.get_dataset(template_str), ‘1mm_T1.nii.gz’)_
_ File “/usr/local/miniconda/lib/python3.6/site-packages/niworkflows/data/getters.py”, line 73, in get_dataset_
_ md5sum=md5):_
_ File “/usr/local/miniconda/lib/python3.6/site-packages/niworkflows/data/utils.py”, line 61, in fetch_file
_ if not overwrite and os.listdir(dataset_dir):_
FileNotFoundError: [Errno 2] No such file or directory: ‘/niworkflows_data/tpl-MNI152NLin2009cAsym’

Any suggestion? Thanks!

ChrisGorgolewski · September 13, 2018, 2:57pm

I couple things were fixed in the meantime. Could you try doing:

git stash && git pull https://github.com/poldracklab/fmriprep master

jsein · September 13, 2018, 6:03pm

Should I then rebuild a new image with:
cd ~/fmriprep
docker build -t poldracklab/fmriprep:master . ?

Sorry for this very naive question as I am new to git and docker.
Thanks again your help!

ChrisGorgolewski · September 13, 2018, 6:27pm

you should cd to fmriprep (which you created before using clone) before doing git pull. Then you need to rebuild the image.

jsein · September 14, 2018, 3:12pm

Thank you. I was able to rebuild the image:robust_epi_mask and to run it:
Two comments:

when I included the sbref images in my data, the fmriprep:robust_epi_mask pipeline crashed with the error message below. I don’t get this error when I run fmriprep:latest on the same data.
when I re-ran the fmriprep:robust_epi_mask image with only the _bold images, it went through but the output masked magnitude image for the fieldmap looks exactly the same as before.

Here are two representative reports: image: poldracklab/fmriprep:latest. :

Here a report generated by poldracklab/fmriprep:robust_epi_mask:

docker run --rm -it -v /Applications/freesurfer/license.txt:/opt/freesurfer/license.txt:ro -v ~/Documents/Centre_IRMf/BIDS/Retinopathie:/data:ro -v ~/Documents/Centre_IRMf/BIDS/Retinopathie/derivatives:/out poldracklab/fmriprep:robust_epi_mask /data /out participant --ignore slicetiming --participant-label 01 --bold2t1w-dof 12

Traceback (most recent call last):
_ File “/usr/local/miniconda/bin/fmriprep”, line 11, in _
_ sys.exit(main())_
_ File “/usr/local/miniconda/lib/python3.6/site-packages/fmriprep/cli/run.py”, line 344, in main_
_ fmriprep_wf.run(**plugin_settings)_
_ File “/usr/local/miniconda/lib/python3.6/site-packages/nipype/pipeline/engine/workflows.py”, line 595, in run_
_ runner.run(execgraph, updatehash=updatehash, config=self.config)_
_ File “/usr/local/miniconda/lib/python3.6/site-packages/nipype/pipeline/plugins/base.py”, line 162, in run_
_ self.clean_queue(jobid, graph, result=result))
_ File “/usr/local/miniconda/lib/python3.6/site-packages/nipype/pipeline/plugins/base.py”, line 224, in clean_queue
_ raise RuntimeError("".join(result[‘traceback’]))_
RuntimeError: Traceback (most recent call last):
_ File “/usr/local/miniconda/lib/python3.6/site-packages/nipype/pipeline/plugins/multiproc.py”, line 69, in run_node_
_ result[‘result’] = node.run(updatehash=updatehash)_
_ File “/usr/local/miniconda/lib/python3.6/site-packages/nipype/pipeline/engine/nodes.py”, line 471, in run_
_ result = self.run_interface(execute=True)
_ File “/usr/local/miniconda/lib/python3.6/site-packages/nipype/pipeline/engine/nodes.py”, line 555, in run_interface
_ return self.run_command(execute)
_ File “/usr/local/miniconda/lib/python3.6/site-packages/nipype/pipeline/engine/nodes.py”, line 635, in run_command
_ result = self.interface.run(cwd=outdir)
_ File “/usr/local/miniconda/lib/python3.6/site-packages/nipype/interfaces/base/core.py”, line 521, in run_
_ runtime = self.run_interface(runtime)
_ File “/usr/local/miniconda/lib/python3.6/site-packages/fmriprep/interfaces/images.py”, line 345, in run_interface
_ img = nb.load(self.inputs.in_file)_
_ File “/usr/local/miniconda/lib/python3.6/site-packages/nibabel/loadsave.py”, line 53, in load_
_ filename)_
nibabel.filebasedimages.ImageFileError: Cannot work out file type of “/data/sub-01/ses-01/func/sub-01_ses-01_task-rest_sbref.json”

Any thoughts? Thanks!

ChrisGorgolewski · September 14, 2018, 4:27pm

Do you get the same error if you keep the _sbref.nii.gz but remove _sbref.json?

jsein · September 18, 2018, 1:17pm

Indeed the image fmriprep:robust_epi_mask was able to run when _sbref.nii.gz was present and _sbref.json was absent. In that case, the bold reference for the registration with the fieldmap is the _sbref image.
Unfortunately, the mask created for the _magnitude.nii.gz image of the field map as shown in the report is still leaving out too much of the brain. Any idea on how to improve the situation? Could it be possible the use a slightly lower threshold for bet for the magnitude image of the fieldmap? From what I tested, N4 helped a bit for the uniformity of the signal of the magnitude image but a lower fractional threshold ( approx. 0.4) in bet is still needed to get a correct brain mask of that particular image.
Thank you for your help!