search

ubicomplab / rPPG-Toolbox

rPPG-Toolbox: Deep Remote PPG Toolbox (NeurIPS 2023)
https://arxiv.org/abs/2210.00716
Other
442 stars 106 forks source link

About the Butterworth Bandpass Filter #209

Closed ZechenZed closed 11 months ago

ZechenZed commented 12 months ago

Hi guys,

When I looked into the CHROME and POS unsupervised method, I saw a scipy.signal Butterworth filter in each of them. I am curious how you guys chose the right window size for it and the order of Butterworth for the best noise-canceling trading with minimum performance loss. Is it based on the video length, sampling rate, or others?

Thanks in advance!

yahskapar commented 11 months ago

I'm assuming you're talking about these lines of code, for example, from POS:

https://github.com/ubicomplab/rPPG-Toolbox/blob/53b84584c2501f40ac925e141e7b908d1013d002/unsupervised_methods/methods/POS_WANG.py#L45-L46

Such filtering is documented a bit better in the post-processing code here. This is effectively band-pass filtering and is pretty common to eliminate frequency peaks that would not correspond to what we would define as a normal heart range, which in the case of the POS implementation appears to be 0.75 Hz to 3 Hz (or 45 beats/min to 180 beats/min assuming 1 Hz = 60 beats/min). Those values are picked based on, depending on your application, what is a reasonable range of heart rate values. For both CHROME and POS, their resulting signal would also undergo additional band-pass filtering in post-processing.

As for the order of the filter, I briefly talk about this at the end of my reply in another thread here, but generally speaking I think you could increase the order of the filter and have more precise filtering close to the band edges. I think whoever first wrote that code just picked a first-order filter since it's simple, and I believe computationally faster than any higher order filters that may not give much of an additional benefit.

ZechenZed commented 11 months ago

Thanks for getting back to me. And I agree on the bandpass from 0.75Hz to 3Hz for a practical range for HR. In line 24 in POS_WANG.py there is a parameter called Winsec which also appears in the CHROME method. I looked into the CHROME paper, and they have a pragmatic range for Window size they use, and in your case I believe you choose the smallest one. Is it based on your experiments?

yahskapar commented 11 months ago

I personally didn't do those implementations, but it's very likely that parameter value was taken from this MATLAB implementation, which happens to be by one of the senior authors behind this toolbox. From my brief investigation, it looks like it makes sense to re-use that value alongside the sampling rate fs to ultimately determine the sliding window length below:

https://github.com/ubicomplab/rPPG-Toolbox/blob/53b84584c2501f40ac925e141e7b908d1013d002/unsupervised_methods/methods/POS_WANG.py#L24-L28

If you're curious where the value 1.6 itself came from, check out sub-section C of section V in the POS paper titled Algorithmic Principles of Remote PPG. Here's an image of the particular blurb I'm referring to below:

Screenshot from 2023-09-16 08-59-30

ZechenZed commented 11 months ago

Ahh I see, that makes sense. I think I need to do more research in this signal-processing area. Thanks a lot!

yahskapar commented 11 months ago

No problem, going to go ahead and close this issue now, Feel free to create a new one if you run into any other questions or concerns.