Integrate with fmriprep #21
Labels
enhancement
New feature or request
Comments
|
Is there a list of what files need to be there ? |
|
We use the files listed in https://surfer.nmr.mgh.harvard.edu/fswiki/ReconAllTableStableV6.0 to determine if a step has been completed. The table is constructed here: https://github.com/nipy/nipype/blob/5116ee208205c8050f87fc2a45bb0f35e3dd1c0a/nipype/interfaces/freesurfer/preprocess.py#L1069-L1321 If there are different build targets between the two pipelines, then this approach is not going to work. What might be useful is a way to detect whether a subject was processed to completion with FastSurfer. |
|
Hi @effigies we write a file recon-surf.done when the pipeline completes. Depending on the flags that the user users during processing, there will be different files available at finish. What would be helpful is a list of the files that are actually needed by fmriprep as it surely does not need all freesurfer outputs. We can then let you know which files are equivalent or can provide scripts that generate the missing files. |
|
Will close this due to inactivity. Can reopen if a list with filenames is provided. |
|
fMRIPrep only really uses the |
|
Thanks @effigies , all these should be available if you run FastSurfer with the --surfreg flag to construct the spherical atlas registrations also (which would be needed also for group analysis on the cortex). |
|
Oh, we do also need T1.mgz, to account for any rigid differences between the input T1w files and what FreeSurfer has. (Usually only happens with multiple T1w files.) I assume that's still there? |
|
We don't need the T1 and therefore don't create it. In FreeSurfer it is used for the watershed (skull stripping) and we already get a full segmentation on the full-head images and create brainmask from the segmentation. Just use the nu.mgz instead which we create. |
|
@effigies just to ping this topic again. You should not need the T1.mgz. It is an intermediate file in the FS pipeline and should not be looked at for anything. Probably someone thought it is important because of its name. |
|
We actually run We run this after N4 correction, so T1.mgz does seem more comparable than |
|
OK, what exactly do you register with the T1.mgz? If it is the original scan, the reslicing matrix between that image and the FreeSurfer conform space is in the image headers, so no registration would be necessary (and could lead to misalignment). FreeSurfer does not change world coordinates, only reslices to conform 1mm isotropic voxels. For example, to map a segmentation back to the original input image: This maps aseg.mgz into the original input space (rawavg.mgz is in the original input space). -rl is "reslice like" and -rt "resample type", here nearest neighbour interpolation for segmentation. Note, that usually it is a bad idea to map a segmentation due to the interpolation artefacts and should be avoided. If it is needed for ROI analysis, you could also map the other image into freesurfer conform space: Happy to setup a quick meeting to chat about this, if you like. |
|
What we do is:
If fMRIPrep runs FreeSurfer (the user doesn't provide pre-computed FreeSurfer derivatives), then the two images are obviously in register. If there is only one T1w input or both FreeSurfer and fMRIPrep chose the same image as the first time-point, then the two images are in register. If there are multiple and the order differed, or in any other way the two images are not in alignment, then simply reslicing isn't going to do the trick. |
|
I see. I would recommend to use |
|
we are generating the T1.mgz since a while anyway. Also we create now a few symlinks at the end e.g. to point to wmparc and aparc+aseg (although we use the DKT altlas definition which merge a few lables). |
|
@m-reuter, I ran some tests in February using the stable version of FastSurfer available at the time (nipreps/smriprep#278), which failed to complete sMRIPrep when treating those FastSurfer outputs as an existing FreeSurfer directory. I am running some tests now using the current dev branch of FastSurfer, which I will update in this thread! |
|
As an update, using the FastSurfer outputs as an existing FreeSurfer directory in sMRIPrep fails (for all datasets I have tested) due to a missing file Run command: Terminal output: |
|
Hey, thanks for taking the time to checking the integration. The missing file is generated in mri_ca_label with FreeSurfer which we do not run (the segmentation is automatically generated with the DL-Net). I can check if we can generate it based on our segmentation. The aparc2aseg command might fail for FastSurfer later on, because we do not generate all surface annotations (aparc.a2009s will be missing), unless you run FastSurfer with the "--fsaparc" flag. However, I am not sure, why you are running this step (aparc2aseg) in the first place. The file aparc.DKTatlas+aseg.mgz and aparc+aseg.mgz are generated by default with FreeSurfer 6.0 and should therefore already exist in a FreeSurfer processed directory. The same is true for FastSurfer (aparc.DKTatlas+aseg.mgz and aparc+aseg.mgz already exists). Is there any specific reason why this rerun is necessary? And do you need all three atlas segmentations (aparc+aseg.mgz, aparc.DKTatlas+aseg.mgz and aparc.a2009s+aseg.mgz)? |
|
@LeHenschel thank you for the insight! From my understanding, the anatomical workflow in sMRIPrep recognizes that there is a pre-existing Freesurfer output and only runs commands that it needs to generate files that are not recognized as being present in that participant's Freesurfer (here using FastSurfer) directory. Perhaps this workflow is set to run because the nipype/sMRIPrep code is looking for these annotation files? @effigies is there a workaround to prevent aparc2aseg if it is not necessary for sMRIPrep to run again after being given FastSurfer outputs as |
|
The "workaround" would be to The fix would require a small Python function to distinguish FastSurfer- and FreeSurfer-reconstructed subjects. We could then simply detect the case at runtime and replace the entire FreeSurfer workflow with a minimal one that does not attempt reconstruction. Once that is done, we would be in a good spot to actually include running FastSurfer and not just tolerate precomputed FastSurfer directories. This would require wrapping FastSurfer as a Nipype interface/workflow. Apologies, I don't have much time to devote to this one at the moment, but I am happy to review pull requests or answer questions about the code to someone who can put in the effort. I can sketch out the workflows needed, but there will be some testing and fiddling to make sure everything works. |
|
@effigies thank you! I would like to use this as part of my thesis work, so I will work on the code and keep you updated. Would it be alright to assign me to handle the issue I opened on the sMRIPrep repo nipreps/smriprep#278 ? |
|
Sounds great. Sorry, I completely forgot that you'd started work on this. Please feel free to bug me repeatedly as my notifications get quickly buried. I'll try to make a point of monitoring sMRIPrep more closely. |
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)
|
The fix of running Run Command: Terminal Output: Thank you! |
|
I think this is currently working. May need to be revisited when we change anything major (like different names for files). Happy to re-open when necessary. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
My lab would love to use your program instead of FreeSurfer to speed up our pre-processing pipeline tenfold. However, we use fmriprep for our pre-processing and currently FastSurfer is not compatible with fmriprep due to the naming of the output files. If the output files could be changed to match the naming and structure of the FreeSurfer outputs that would enable us and many others to use your program with fmriprep.
I have also reached out to fmriprep to see if they could potentially integrate your program into their pipeline. Looks like the easiest solution would be changing the names of the output files from FastSurfer or providing a flag the would enable the option to do so.
nipreps/fmriprep#2216
The text was updated successfully, but these errors were encountered: