Peak detection comparison to PhysIO

[tsalo]

PhysIO Toolbox is a MATLAB toolbox for physiological data preprocessing for fMRI. In the manuscript, they refer to a two-stage automated peak detection algorithm. I noticed that the peak detection algorithm in peakdet (see below) has two stages as well. I'm just curious, is the method the same? Has anyone done a head-to-head comparison?

Tagging @rmarkello.

https://github.com/physiopy/peakdet/blob/b1166910c9ec7a2ff80a3aeaba3404c5291742be/peakdet/operations.py#L125-L136

[rmarkello]

The methods are not the same. We were originally basing peakdet off of PhysIO, but then scipy integrated their own algorithm and I just went with that because 🤷‍♂️

We do (I believe) do a two-pass peak detection to try and get a better bound on the distance between peaks but we don't use the same procedure for the actual peak detection (i.e., the template matching).

That said, template matching is very good and I'd strongly encourage someone who has the time + energy to integrate it do so!

[tsalo]

Do you know how the template matching compares to manual peak removal? Is it a viable substitute or should it only be used as a last resort when you can't do manual correction (e.g., with huge datasets)?

[rmarkello]

Not from experience, no. I do remember a paper showing that template matching is great and can yield impressive temporal resolution boosts even when data are undersampled (trying to find that reference now).

I would argue that the template matching + manual peak removal/QC aren't mutually exclusive. Even if you have what you believe to be a top-of-the-line algorithm the manual QC is still important cause even one or two missed (or extra) beats can really mess with your derived metrics.

[tsalo]

That helps, thank you. I started looking into this mainly because there are open issues about incorporating physio info (specifically using PhysIO) into fMRIPrep. Given the need for manual QC, even with the best algorithms, that doesn't seem like a good idea. At least not without the ability to integrate other derivatives (which could include manual QC) the way they do Freesurfer.

[tsalo]

On the peakdet side, I think we will want to do a head-to-head comparison with other physio tools as part of validating the toolbox at some point. Then again, we've also had plans to do that for tedana for a while now, and no one's actually gotten around to it...

[rmarkello]

I mean, the manual QC bit is gonna vary based on who you ask. If you ask a neurophysiologist type, of course they're gonna tell you that you need manual QC; if you ask a the answer will probably differ. I can't think of terribly many neuroimaging studies that report manual correction of physio data even when they include e.g., heart rate and respiratory regressors (though I know, for example, Jonathan Power has always made a point in his studies to highlight that this is a necessary processing step).

That said, I do think including physio is super important in fMRI preprocessing (for obvious reasons), so even if you can't integrate the manual QC immediately I'd rather see physio included than not 🤷‍♂️

Re validating the toolbox: my goal with peakdet was never to provide "better" algorithms but to come up with a solution where manual QC + intervention could be transparently + reproducibly (via peakdet.Physio.history) integrated into a physio processing workflow. I'd be happy to see it evolve beyond that (again, I've ceded all decision-making power here 😅), but I think that retaining the reproducibility of the manual QC is important.

[tsalo]

That makes sense. I'd generally agree that supporting physio in standard workflows is more important than having perfect physio data. On the other hand, at least for some approaches (e.g., computing RVT, convolving with RRF, and then regressing it out in the first level GLM), physio can safely be applied after fMRIPrep's minimal preprocessing. If that's the case for all physio denoising approaches, then I'd lean toward leaving it out of fMRIPrep and simply making sure that users are aware of tools that can handle that step (e.g., the physiopy suite).

But then, even though fMRIPrep devs are concerned about feature creep, they do include a lot of confounds that could easily be calculated after minimal preprocessing (e.g., FD, AROMA components), so I don't know what their preference will be.