You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the LTS release finalize soon... might be an opportunity to also consider a slight change in how fmriprep brainlife is run. There is an option to run only the anatomical part of fMRIPrep: https://fmriprep.org/en/stable/usage.html#reusing-precomputed-derivatives , and then to feed in this anatomical output to the functional processing. I could imagine this would massively cut processing times for datasets with more than one functional scan. What do you think? It would require a sort of raw frmiprep-anat datatype... that would be unzipped when the functional fmriprep is run.... does that make sense?
The text was updated successfully, but these errors were encountered:
I think it makes sense to create a new datatype for anat-derivatives. I will create the datatype (experimentally) and update the fmriprep to store output to it.
I am guessing that freesurfer is really the big chunk of the anat preprocessing. If so, then what we have right now (having freesurfer as a separate step) would probably be sufficient to reduce repeated anatomical preprocessing so we might not need to use this functionality?
@giulia-berto Yes, BL currently can't handle varying number of output objects.. so that won't work. Even if we could.... user could be feeding 5 bold images, or 500 bold images, so it becomes difficult to predict how much resource we need to run fmriprep. By processing 1 bold at a time, BL can distribute the processing across multiple jobs / clusters.
With the LTS release finalize soon... might be an opportunity to also consider a slight change in how fmriprep brainlife is run. There is an option to run only the anatomical part of fMRIPrep: https://fmriprep.org/en/stable/usage.html#reusing-precomputed-derivatives , and then to feed in this anatomical output to the functional processing. I could imagine this would massively cut processing times for datasets with more than one functional scan. What do you think? It would require a sort of raw frmiprep-anat datatype... that would be unzipped when the functional fmriprep is run.... does that make sense?
The text was updated successfully, but these errors were encountered: