Hey Paul, hey Rick,

Happy New Year!

Thanks for your response and sorry for taking some time to reply, I needed to think about what you both said.

I think it might be helpful to give you a bit more background on the data: we acquired a 10 min (TR = 2, 300 volumes) resting-state scan [pre-learning rest] before subjects participated in an incidental learning paradigm where we displayed short movie clips and asked participants to rate them. There were three task blocks with slightly varying scan durations due to pseudo-randomization of trials (see previous post, average duration 12min 39 seconds, all 3 runs combined 1140 volumes with TR = 2). After the last task block, we acquired a second 10 min resting-state scan [post-learning rest].

Re. high-frequency noise:
In the resting-state analysis, I am interested in the *change* in resting-state functional connectivity (RSFC) between two ROIs from pre-learning to post-learning resting-state. I hence calculate the correlation of the signal in both ROIs separately for each run and then calculate the difference between them. This change in RSFC is later also correlated with behavioural measurements like the number of movie clips encoded. Because I am looking at the difference in functional connectivity, I am tempted to say that either

• (A) high-frequency noise affects pre- and post-learning resting state in the same manner (participants still have to breath) and the effect of high-frequency noise on functional connectivity correlation estimates cancel each other out when looking at the difference

or

• (B) high-frequency-noise is different between pre- and post-learning rest because participants breath more or less after the incidental encoding task, but in that case, this could also be a function of the task and not necessarily noise per se.

In either case (and especially weighing in the downsides of band-passing), I think it might be better to not bandpass after all. But maybe it would be better to examine this empirically and see whether the change in functional connectivity differs depending on whether or not the data was bandpassed - I have a feeling that this is something a reviewer will say to me at some point...

Re. modelling the drift:
Thanks for sharing that note again, Paul, I thought I had read something about this topic before, but just could not remember where exactly. I have used the larger polort (i.e. 6) for everyone in my pipeline, but I was not aware that the run length makes it difficult to model the baseline accurately. Additionally, I forgot to mention that there is one subject whose second task block was interrupted and who has hence two 3dT+ epi volumes capturing that block, totalling to four 3dT+ task volumes with 363, 169, 219, and 389 volumes respectively. I also haven't mentioned that we concatenate the fully pre-processed time series (errts*fanaticor+tlrc.) at the end using 3dTcat before we compute the intersubject correlation maps using 3dTcorrelate. This is because the movie clips were displayed in pseudo-randomised order and we need to "re-order" the volumes so that say the first 30 volumes in each subject always cover the same input movie clip regardless of when that movie clip was displayed across the three runs and so on. Sorry that I did not provide this information in my previous message. So taking all these things into consideration, do you still think it would be better to model the drifts using sinusoids (-regress_bandpass 0.01 1) + regress_polort 2 instead of -regress_polort 6? If so, just so clarify: when applying a low-pass filter as suggested, I would not lose 60% of DoF because the Nyquist frequency at TR = 2 is 0.25 Hz and I define 1 as the low pass boundary? And would it also be better to apply sinusoids (-regress_bandpass 0.01 1) + regress_polort 2 to the slightly shorter (10 min, 300 volumes, TR = 2) resting-state runs than using regress_polort 5?

Also, thank you for clarifying again how the resting state note is meant, Rick. I actually watched your talk on the MITCBMM YouTube channel earlier and fully understand now that the note is more meant as a rant about bandpassing than a recommendation to perform bandpassing.

I really appreciate all the input and help from the AFNI gurus, thanks again!

Best wishes,
Stef