I am using XCP to denoise task data. I have just realized that it automatically removes volumes containing motion from the data, which is something that is detrimental to my analysis (it would mess with the task timings).
Here are my questions:
Am I right in assuming that the default behavior is censoring, that is if FD is above a certain threshold it will remove volumes
Is it correct that despiking would be an alternative way to account for motion spikes, without losing volumes?
If I turn on despiking with the option --despike, how can I make it not do censoring? In other words, how can I remove the effect of motion without losing volumes?
Yes, and the two strategies are not mutually exclusive (i.e., you can do both). But, keep in mind that despiking is mainly just going to limit the amplitude of BOLD signal at motion contaminated time points. The data will still not be very “biologically true”, but they should influence the results less since they won’t be as much of an outlier in magnitude.
You can set an unreasonably high FD threshold with the --fd-thresh flag. (edit, you can more simply just set a negative value for the threshold to disable it)
Not that you can’t process task data with XCP_D, but if you are looking to run a GLM analysis on your data (that is, not connectivity), then you may be better suited using a software such as fitlins, which is also designed to work with fMRIPrep outputs.
Framewise displacement threshold for censoring. Any volumes with an FD value greater than the threshold will be removed from the denoised BOLD data. A threshold of <=0 will disable censoring completely.
Default: 0.2
Is it correct that if I put for example -1 then no volumes will be removed? And the spikes will be “interpolated over”?
Oh good catch I did not see that (editing my original reply to reflect that).
Interpolate isn’t really the right word, since no data are removed to warrant interpolation. The spikes in data will just be truncated. Interpolation does happen if you censor volumes. Whether or not you are comfortable with interpolation is up to you.
That’s interesting, so the interpolation happens before the filtering with the censoring, but then the volumes get removed again? Or not? I would be fine with censoring + interpolation, but I want to be sure that in the final denoised file no volumes have been cut out, i.e. the timeseries is not shorter or doesn’t have “gaps”.
Maybe I am just being paranoid, because I have observed that my timeseries is of the same number of volumes before and after denoising, but from your documentation had understood that the censored volumes were being “cut out” and not interpolated over.
Prior to version 0.4.0rc2, the interpolated time series were written out as the primary derivative (i.e., desc-denoised_bold). However, this was a bug, as we don’t want folks analyzing interpolated data. Starting in 0.4.0rc2, XCP-D writes out the censored data instead. The interpolation is only done to enable bandpass filtering; once the filtering is completed, the data are re-censored.
Is your goal to feed your data into a task GLM? If so, I wouldn’t recommend using XCP-D at all. Your nuisance regressors should be included in your task GLM (i.e., remove noise and model your task in the same step, rather than doing it in two separate regressions).
My goal to analyze the data includes several types of analyses, all of which take into account the time component, for example ICA, GLM, dynamic modeling etc.
More in general, I have a large dataset of both task and rest data and my hope was to use XCP to process it all consistently, since I really like that it’s a reproducible workflow and easy to use. I don’t want to introduce too many researcher degrees of freedom by having different strategies for each project/analyst.
However, it seems like there are quite a few options like this that are not obvious and prevent from doing these types of analyses. I think the functionality of saving interpolated data is quite useful and maybe you could consider reintroducing it. From what I understand, without it, people won’t be able to do a lot of popular things even for resting state, like ICA, dynamic connectivity etc. and are limited only to calculating correlations between time series.
Maybe I have one of the “bugged” versions that actually does what I need. I’ll check that, but I thought I had the latest version and my time series don’t seem to be shorter. To clarify again, are the censored volumes cut (time series becomes shorter) or are they replaced with 0?
I’ll consider switching back to doing the denoising separately for each of my projects! Thanks a lot for your help!
Perhaps we could add a nuisance parameter option that does not actually denoise the data. The resulting postprocessed BOLD data would be the same as the preprocessed data, except potentially for despiking, bandpass filtering (which I would also recommend disabling for task data), and smoothing.
In that situation, I would recommend that people disable censoring completely, rather than use interpolated data. Disabling censoring is an option, whether by using a very high FD threshold in older versions, or settings the threshold to <= 0 in new versions. The filtered FD should still be written out, so users can still include outliers in their subsequent analyses (e.g., as one-hot regressors in a task GLM).
XCP-D censoring removes those volumes (i.e., the time series becomes shorter).
At the end of the day, maybe scrubbing could be also an option, from what I understand scrubbing would mean regressing out those “hot regressors” you mentioned, right? Is it possible right now to do scrubbing without censoring?
I agree for the bandpass, I would suggest adding the possibility to high pass and/or low pass separately from band pass. I had decided to use the acompcor_gsr option for my analyses because it was the only one that allowed me to have a high pass filter, see discussion here: