We are getting ready for “production”, that is, fire up fmriprep on a dataset of few thousand sessions. I just tested fmriprep-1.5.4 with a (self created) singularity container, and seems to work well.
But before we fire up the pipeline on all the dataset I wanted to clarify some points:
We have Freesurfer run on all these subjects, using the longitudinal pipeline. I looked at other posts and looks like fmriprep cannot use those outputs. Is this still the case?
If fmriprep cannot use (by default) FS longitudinal data, which option do you suggest we can use:
Let fmriprep create it’s own “T1w average + freesurfer” output. If we go this way, I am not sure how can we move the BOLD data in native space for a certain session if needed; the T1w average created by fmriprep is in a new space and I am not sure if the transformations to/from individual T1w sessions are somewhere in the output.
Point fmriprep to use one of the processed Freesurfer sessions (either baseline or long folders).
Point fmriprep to the sst created by Freesurfer, which should be similar to what fmriprep creates itself (right?).
If you are wondering, these are data with annual sessions from Huntington’s disease. The anatomical changes are certainly there (i.e., 1-3% atrophy in the putamen) but the changes are not hugely visible.
This is the structure of our existing Freesurfer content for a subject:
Regarding this point, are you planning to enable the use of FS longitudinal outputs in the near future?
I noticed you are preparing for a new release soon. We are analyzing data just to share the community (no analyses project planned), so we don’t mind waiting 1-2 months to process the data with a better version of fmriprep. Can you give some hints when you might release the next version and what features might it have that are worth holding the processing for a little bit.
Thank you for your help and for providing such a complex well developed pipeline to the community.
I think you can point fmriprep to use the processed longitudinal freesurfer folders. Fmriprep creates 2 derivative directories: “fmriprep” and “freesurfer”. I would create symbolic links with fmriprep compatible names (“sub-”) to the longitudinal freesurfer folders in the “freesurfer” derivative folder. I have done this with standard recon-all freesurfer output and fmriprep runs. I don’t know if there are file differences between longitudinal and standard recon-all freesurfer output.
I tried linking to the sst folder in my freesurfer structure (as shown above) but fmriprep did not seem to recognize it and started running its own freesurfer processing. I thought this is because some files were probably missing or the freesurfer version that ran the original data was older.
In your case, do you point to the individual session freesurfer run? From what you say, looks like you are running fmriprep separately on each longitudinal session, right? Is that why you are able to point fmriprep to just one of the freesurfer sessions?
I did some experimenting with fmriprep version 1.5.4 as a singularity container and symbolic linking to independently created longitudinal freesurfer surfaces. I already had longitudinal freesurfer surfaces generated using version 5.3.0-HCP. The initial cross-sectional surfaces were generated with the HCP pipeline (Prefreesurfer, Freesurfer). I ran into errors similar to the one you described, so I generated new longitudinal surfaces using freesurfer version 6.0.0-2beb96c. The fmriprep singularity container uses freesurfer version 6.0.1-f53a55a. My testing resulted in 3 different scenarios:
Linking to longitudinal surfaces generated by freesurfer 5.3.0-HCP and running fmriprep.
fmriprep started its own freesurfer processing which exited with this error: mris_make_surfaces: could not read segmentation volume /rcc/stor1/depts/neurology/users/jheffernan/chess/derivatives/fp-v1.5.4/freesurfer/sub-m0045s01/mri/../mri/aseg.presurf.mgz
Linking to cross-sectional surfaces generated by freesurfer 5.3.0-HCP and running fmriprep.
fmriprep started its own freesurfer processing which exited with the same error as in 1. I tried this scenario to make sure the longitudinal surfaces were not missing any specific files.
Linking to longitudinal surfaces generated by freesurfer 6.0.0-2beb96c and running fmriprep.
Fmriprep completed without error.
I did run fmriprep separately on each longitudinal session, so I could point fmriprep to just one of the freesurfer sessions. I did not use the ses-<session> bids structure, but included the session in the subject name: sub-m0045s01 for session 1, sub-m0045s02 for session 2, and so on.
I also ran fmriprep with --anat-only in all scenarios.
Thank you @heffjos, very helpful. I followed your advice and conducted an example run after modifying subject names to e.g. IDs01. Seemed to work for a while but then I encountered an error which was not very informative. All in all, I decided to abandon the longitudinal FS integration in fmriprep because Freesurfer is not very good at segmenting the subcortical structures I am interested in. I have inspected a few thousands of FS segmentations and they are definitely not optimal. Longitudinal processing is highly suboptimal too, if a baseline timepoint is badly segmented, it will create weird segmentations in longitudinal processing (fuzzy structures). All this is to say that FS segmentations would need careful checking and would add noise to the fMRI measurements. At least the use of a single average anatomical has the benefit of measuring the same exact region at every timepoint.
Maybe fmriprep will integrate better FS longitudinal processing in the future, at which point we can run fmriprep again and see how it compares with the current anatomical averaging strategy.