Dear AFNI experts,
I am analyzing some resting-state data. I also collected physiological recordings (cardiac and respiratory) for this dataset.
For preprocessing the dataset, I am following this order of blocks on afni_proc.py:
despike > ricor > tshift > align > tlrc > volreg > mask > regress
My ricor regressors are created from RetroTs.py - which outputs 13 columns of regressors. This includes RVT (respiratory volume per time), along with regressors for the phase of the cardiac and respiratory signals.
One of our collaborators suggested we should also include the cardiac rate (cardiac rate= 1/interval between the cardiac peaks) as a regressor to account for variations in cardiac rate during the scan duration. Importantly, RVT and cardiac rate should be convolved with the respiratory response function and cardiac response function, respectively.
My questions are:
When AFNI regresses out the RVT (derived from RetroTs.py), along with the other ricor regressors, does it convolve it with the respiratory response function before doing so?
How do I go about adding the cardiac rate convolved with the cardiac response function as a regressor into AFNI (before bandpass)?
I do not believe we currently have any function to perform such a convolution, though we are considering some enhancements to RetroTS.py.
Supposing one can generate such regressors, if they do not vary across slices, then they can be simply added as regressors of no interest in the afni_proc.py command, via -regress_extra_ortvec for example. Would they vary?
Sorry for the late reply to this.
Yes, the regressors would vary across slices, just like the RETROICOR regressors. I can generate an RVT time series and convolve it with the appropriate kernel (and do the same for the heart rate), but how what would be the correct way to regress out these signals in afni_proc.py?
Thanks in advance.
The current slice-based regressors provided to afnI_proc.py are already seen as regressors - they are not manipulated, except for possibly removing some time points from the start of each run. Therefore, if you could insert additional regressors to make a larger file (more regressors per slice), the updated file could be fed without any changes to afni_proc.py at all. At least, I believe that to be the case.
Peter is currently working RetroTS.py, and might be interested in this operation. Are you going to convolve as in: for each time point, put down a basis function scaled by the unconvolved RVT? Which basis function do you plan to use, GAM? BLOCK(1)?
Thank you for the reply. The basis functions used will be those specified in these papers:
Chang, C., Cunningham, J. P., & Glover, G. H. (2009). Influence of heart rate on the BOLD signal: the cardiac response function. Neuroimage, 44(3), 857-869.
Birn, R. M., Smith, M. A., Jones, T. B., & Bandettini, P. A. (2008). The respiration response function: the temporal dynamics of fMRI signal fluctuations related to changes in respiration. Neuroimage, 40(2), 644-654.
Basically, I will generate the slice-based HR and RVT time-series, convolve that time series with the respective basis function (as above), and then regress out these as nuisance regressors from the data.
Do you have a suggestion as to how I should include this additional set of regressors into my afni_proc.py script? I have them as slice-based regressor 1D files, similar to the retroicor regressor 1D files.
Has anyone done this before?
What is the standard way to include these convolved slice-based regressors into afni_proc.py?
Thanks in advance.
Sorry, I forgot to come back to this.
You should be able to pass these exactly as is currently done with the RetroTS.py output. So make a text file of regressors, one per column, where for each slice there are all the regressors you want. For example, if you create 10 regressors per slice and there are 30 slices, then the file should have 300 columns where column 0-9 is for slice 0, 10-19 is for slice 1, etc.
It is also passed as one file per run (since regressors are created per run), using the same sort of format:
-ricor_regs sb23/RICOR/ricor_regs_run1.1D \
Does that seem reasonable?