Incorporating FastSurfer to sMRIPrep as surface reconstruction option #278
Assignees
Labels
enhancement
New feature or request
Comments
|
###Environment testing:###
###Adapting existing surfaces.py to use FastSurfer outputs as existing Freesurfer directory:###
My tests have found that passing nu.mgz is not sufficient for using FastSurfer outputs as the pre-existing Freesurfer directory. As a temporary approach, I made copies of the aparc.DKTatlas+aseg.deep.mgz to it's closest relative files (aparc.DKTatlas+aseg.mgz and aparc+aseg.mgz separately and then simultaneously) and then added the flag -noaparc2aseg to the autorecon3 command in surfaces.py. This also does not successfully bypass much of the recon-all workflow. ###Creating shippable code:###
|
|
Any help with integrating this to Nipype would be very much appreciated! |
|
Hi @pcamach2, thanks for this! To create a nipype interface for FastSurfer, we're going to need to know a few things:
|
|
Hi @effigies, no problem! Here is what I have so far:
Per the basic FastSurfer container run instructions, the barebones docker run command is as follows for their Docker image: From the hybrid container that I built, my tests ran with the following (with all replaced with actual labels from the test dataset): For the Singularity container (running from the project directory): From the shell in the container: Note that the FreeSurfer license is mounted to /fs60/license - this is just their convention for mounting. The full list of arguments is explained as follows:
I think the most important factor that we would need to consider is whether folks are running with GPU or CPU since this could affect the image they would use. One way to handle that would be building separate versions and tag them with "GPU" or "CPU" accordingly. Otherwise, I think we can build the general GPU version by default and allow the --no_cuda argument to handle this.
I haven't had to quit and resume with FastSurfer due to the shorter run time and the lack of long process stalling that can occur in recon-all, so I can't say from experience. The main breakpoint built in is that the segmentation via CNN can be run standalone and then followed by surface reconstruction. I have not personally taken this approach, but it might be useful if someone wants to generate a large batch of segmentations and check them before committing to surface reconstruction (although it seems more likely that they would just use standalone FastSurfer in this use case). I would lean towards using a fresh run if all output files are not detected; this also makes it easier to assess quality with their adapted QATools, which NaNs out when the recon-all log indicates restarts. For reference, here are the example outputs from a bids/derivatives/fastsurfer/sub- directory: Thank you! |
pcamach2
added a commit
to pcamach2/smriprep
that referenced
this issue
Apr 16, 2022
Added affiliation to the contributors list for work on incorporating FastSurfer into sMRIPrep nipreps#278
pcamach2
added a commit
to pcamach2/smriprep
that referenced
this issue
Apr 20, 2022
Checks FreeSurfer subjects dir for presence of files in mri/ with names indicating processing with FastSurfer, and returns a boolean fastsurfer_bool to indicate that FastSurfer is being used instead of Freesurfer. For development purposes, this also touches files that are expected outputs of Freesurfer, but not produced by default in FastSurfer. (Addresses nipreps#278 & Deep-MI/FastSurfer#21)
|
@effigies, the fix of running I added a short python function to my fork of smriprep/smriprep/utils/misc.py (https://github.com/pcamach2/smriprep/blob/1377f4c629542ba8d3ab11f90b9c593ffa29b6cc/smriprep/utils/misc.py) that checks for FastSurfer files in the --fs-subjects-dir (there are .mgz files with 'deep' in the subject's mri directory, which indicate that they were generated using the deep-learning method used in FastSurfer). If detected, this function runs the I think the next step would be to use the Thank you! |
pcamach2
added a commit
to pcamach2/smriprep
that referenced
this issue
Apr 23, 2022
Adds the check_fastsurfer function call to log FastSurfer outputs detected in subjects_dir and touch mri/aseg.auto_noCCseg.label_intensities.txt to prevent failure in surfaces.py as a temporary fix for nipreps#278
|
I removed the The next steps I can think of are:
|
pcamach2
added a commit
to pcamach2/smriprep
that referenced
this issue
Apr 24, 2022
Adds FastSurfer argument to support FastSurfer as a surface processing option (nipreps#278)
pcamach2
added a commit
to pcamach2/smriprep
that referenced
this issue
Apr 26, 2022
Adds python wrapper for FastSurfer (nipreps#278)
pcamach2
added a commit
to pcamach2/smriprep
that referenced
this issue
Apr 26, 2022
Adds affiliation to contributors for work regarding nipreps#278
|
@effigies, I am trying to connect the FastSurfer interface that I wrote and tested (https://github.com/pcamach2/smriprep/blob/pcamach2-fastsurfer-patch-dev/smriprep/interfaces/fastsurfer.py) into the overall sMRIPrep workflow. I added the following argument to the cli (https://github.com/pcamach2/smriprep/blob/pcamach2-fastsurfer-patch-dev/smriprep/cli/run.py) I am wondering where best to split workflow behavior (in anatomical.py?) based on the above argument Would it be better to make separate surfaces.py versions for FastSurfer and FreeSurfer or just different workflows within a unified surfaces.py? Note that if a dataset includes FLAIR or T2w, FreeSurfer will still want to process them automatically even if there is FastSurfer output (this adds on a few hours). Thank you again for all your help and advice! |
|
@pcamach2 Could you go ahead and open a draft PR with your changes? I think it will make it easier to look through this. Unfortunately I'm out of time today, but I'll put you on my todo list for tomorrow. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
No
Describe the solution you'd like
Addition of FastSurfer workflows as an alternative to FreeSurfer.
Describe alternatives you've considered
I have considered just running FastSurfer before running sMRIPrep or fMRIPrep and using the outputs as an existing Freesurfer output directory. This may work as discussed in #273 by @effigies.
Additional context
I brought this up in the Nipype discourse group and @oesteban suggested moving the discussion here on GitHub.
I have a working Dockerfile that includes FastSurfer and sMRIPrep, which I have used to run FastSurfer on my workstation.
Currently, building the Docker image requires having downloaded a local copy of Convert3D since my build machine was throwing errors for ca-certificates when trying to curl the tar.gz from SourceForge as part of the build. Testing this image for FastSurfer - once built as smriprep:fastsurfer_dev - can be performed with the following command:
I am building a Singularity image to test on our cluster and will test both tools separately before scripting this into the relevant nipype workflows.
I appreciate any help and/or feedback!
The text was updated successfully, but these errors were encountered: