fmriprep
fmriprep copied to clipboard
nipreps
Physiological noise model? (RETROICOR)
At the Spinoza centre in Amsterdam we usually record physiological data during fMRI scanning (pulse oximetry and a respiratory band). This can then be used to fit a, e.g., RETROICOR model (Glover, 2000) and regress out physiological noise from the fMRI runs. The BIDS specification provides for including such data (section 8.6).
Fmriprep currently does not use physiological recordings. Are you planning on including a physiological noise modelling feature? Or do you have reasons to believe it doesn't add to the t-/aCompcorr approaches? I guess there is some work that suggests this (see below), but I do not think this is true for all brain regions, paradigms and fMRI protocols...
@jwdegee and me have been working on a retroicor Nipype workflow that might be useful: https://github.com/spinoza-centre/spynoza/tree/master/spynoza/denoising/retroicor (that workflow also includes an algorithm that detects the slice timings using the gradient signal)
Behzadi, Y., Restom, K., Liau, J., & Liu, T. T. (2007). A component based noise correction method (CompCor) for BOLD and perfusion based fMRI. NeuroImage, 37(1), 90–101. http://doi.org/10.1016/j.neuroimage.2007.04.042
Birn, R. M., Cornejo, M. D., Molloy, E. K., Patriat, R., Meier, T. B., Kirk, G. R., et al. (2014). The Influence of Physiological Noise Correction on Test–Retest Reliability of Resting-State Functional Connectivity. Brain Connectivity, 4(7), 511–522. http://doi.org/10.1089/brain.2014.0284
Kay, K. N. (2013). GLMdenoise: a fast, automated technique for denoising task-based fMRI data, 1–15. http://doi.org/10.3389/fnins.2013.00247/abstract
I don't see any reason we couldn't include RETROICOR. (Sorry for not getting back to you on this point, earlier.) At present, we're focusing on testing and bug fixes in preparation for a 1.0.0 release, so I don't expect we'll get around to implementing this before the major release.
That said, if this is something you'd like soon and want to help write this feature, we accept contributions from users, and can help guide you through the process of adding a new feature.
I'll try somewhere in the coming weeks if I can pull that off. I will need it for myself anyway.
There are some issues to think about now if you would want to include this in fmriprep at some point a) Should the pipeline already regress out the fitted RETROICOR model? Or should it only return the confound regressors? b) RETROICOR regressors are supposed to be different from slice-to-slice, because of different slice timings. The current 'confounds.tsv'-format does not naturally allow for this. c) If you want to filter already in the pipeline itself, an interesting question is at what point (I would say before motion correction and slice time correction).
a) We don't return pre-regressed datasets; we just provide the regressors. However, if there's a good reason that's insufficient, we can produce variants, as we do with non-aggressive ICA-AROMA denoising.
b) It's entirely reasonable to have a .tsv of per-slice RETROICOR regressors.
c) That seems to be the recommendation of 3dretroicor.
Hi @laurenbreithaupt, nobody has yet proposed a patch to include RETROICOR in fMRIPrep. There is an existing nipype interface for it, so if you're familiar with its use, would you be interested in submitting a pull request? We can help orient you to the code base and work out the best way to do this.
@effigies We'd (@hpfisher3) be open to seeing if we can submit a pull request. My first concern is that we use singularity containers (rather than docker).
Well, if you're interested in taking on that task first, we also want to create a Singularity recipe and push to SingularityHub (#1122). The biggest concern we have is maintaining consistency between the Singularity and Docker images.
So I'm thinking the best way to do this would be to translate our current Dockerfile into a NeuroDocker recipe. We could save the JSON as .neurodocker.json, which we could then use to generate Dockerfiles and Singularity recipes.
The alternative would be to continue building Docker images and then using singularity build or docker2singularity to convert to Singularity as needed.
as an update on this issue, it looks like AFNI made it easier to incorporate physio data in confounds.tsv with RetroTS.py, could be a good issue to tackle at a hackathon to incorporate into fmriprep.
Writing an interface for RetroTS.py and incorporating that into fMRIPrep to produce the slice-wise regressor TSV seems pretty doable, but I still don't know if fMRIPrep would need to actually perform the denoising before slice-timing correction or not. Does anyone know if RETROICOR regressors can be used after STC, or is that invalid?
I think we concluded that retroicor and fMRIPrep are mutually exclusive. We should be able to work with rapidtide, though.
Per our discussion last week, it seems like RETROICOR won't work in fMRIPrep. Can this issue be closed then?
My recollection, and @demidenm would probably remember more clearly, was that we decided that RETROICOR has requirements that do not mesh easily with fMRIPrep's design. One possibility is to preprocess the BOLD file with 3dDespike, 3dTshift and RetroTS before passing to fMRIPrep. At that point it might be worth instead just using afni_proc.py.
We were looking into RapidTide #1678 and that seems like it is more compatible.
I agree this can be closed as not planned.