search

ubicomplab / rPPG-Toolbox

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

About the Butterworth Bandpass Filter #209

Closed ZechenZed closed 1 year ago

ZechenZed commented 1 year 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 1 year 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 1 year 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 1 year 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 1 year 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 1 year 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.