We’re using fmriprep 20.2.0. It seems as though /fmriprep/<subj>/freesurfer/fsaverage is the copy of the fsaverage template subject and not the subject’s native freesurfer data resampled to fsaverage space. So for full fmriprep derivaitves you have copies of the same fsaverage5 and 6 template subjects for each subject? It was our initial understanding that this was the subject’s data resampled so I just wanted to confirm that these data are direct copies of the template and have no subject-specific data in them.
So to get the data in /fmriprep/<subj>/freesurfer/<subj> into fsaverage space we to add an extra step of resample into fsaverage after fmriprep?
Thanks for the reply. It was my understanding that --output-spaces refers to the target spaces for the bold data. I’m asking about the native freesurfer data (eg, freesurfer/sub-<subj>/surf/lh.sulc). Will adding fsaverage to --output-spaces put both the bold data and the subject’s native freesurfer data into fsaverage?
It appears as though fmriprep does not project the fsnative data in sub-<subj>/freesurfer/sub-<subj> to the fsaverage space specified in --output-spaces. We specified fsaverage6, and we have the following directories: freesurfer/fsaverage and freesurfer/fsaverage6 but it appears as though these are the templates and not the subject’s data projected onto these spaces.
It seems redundant to have the same template data included for each subject and it seems like a desirable option to have the freesurfer data available in a standard surface space.
@effigies and @oesteban, I can confirm that the information in fsaverage appears to be duplicated. I checked in two subjects from the ABCD data, confirming that the MD5 hash is the same for the data in fsaverage and different for the data in the subject directory:
Is this a bug? I would think we’d expect to see subject results transformed into those template spaces in each of the template directories, but maybe I’m not thinking about it clearly. In either case, it seems like quite a waste of disk space.
@Shotgunosine The fsaverage/ directories are simply copied from FreeSurfer, so they should be identical. Your approach of creating a per-subject output directory is resulting in multiple FreeSurfer subject directories.
Ok, that makes sense, so the waste of disk space is on me and the overly cautious way I chose to rsync things back together after running jobs in local scratch on our cluster. In terms of anatomical outputs, I guess it’s a little surprising that the anatomicals transformed into the requested output spaces aren’t available in the anat directory, but it’s understandable if they’re not commonly needed and are easy to generate from the output that is provided.
Thank you for the clarification. It would be nice to have the functionality where fmriprep resamples the subject’s native freesurfer data onto the surfaces provided in --output-spaces since the user is requesting a standard space, but if that’s not the current implementation then we can do it after the fact.
The subject’s “native freesurfer data” is simply the reconstruction of the subject’s surfaces, and FreeSurfer computes a transform from the subject’s surface to fsaverage. If you mean morphometric data, it’s true that fMRIPrep does not convert that. That’s something that could be added to sMRIPrep…
If you’re referring to the subject’s BOLD data, you should find that in the fMRIPrep outputs, as GIFTI files with space-fsaverage6 in the filename.
