Data quality question

[PartyTrix]

Hi,

I'm experimenting with using your very nice toolbox for a project where I want to remotely extract heartrate variability. In my current setup I'm limited to a 30Hz/fps sampling rate - and I think this might be a cause for the issue I'm experiencing.

From my dataset (rawHR) I get quite a few false negatives I wouldn't expect.

For example from samples 0 to 1000 (0 tot 33 seconds)

where on other spots it is detected fine

I'm using this datafile (as a .csv but I can't upload that here) which is a 4minute snippet from a video where the PPG is extracted from the green channel: hr sample.txt

and preprocessing it using your butterworth 'filtersignal(data,5,30,3)' and 'scale_data' functions on it.

What would be your advice for better results? Upsample, more filtering or is the signal quality too poor.

Thank's in advance!

[paulvangentcom]

Hi PartyTrix,

The false negatives are a result of the approach. I've designed it so that it will usually err on the cautious side. This means any peak for which HeartPy isn't very confident, will be marked rejected and excluded from the analysis (you can read a little about why this is favourable to allowing false positives here: https://python-heart-rate-analysis-toolkit.readthedocs.io/en/latest/heartrateanalysis.html#on-the-accuracy-of-peak-position)

However, in the overview plot you give the majority of peaks seem detected alright. The poor segments (marked red) are also excluded from the analysis if you use the latest version of HeartPy.

The results here should be an approximation of the heart rate. Variability is of course more sensitive to outliers (especially false positives, of which I think I see two or three, so these are rare), so you should be ok. The sidenote is of course that the signal quality of ppg extracted from a webcam is far from ideal, and a lot worse than even cheap PPG sensors.

If you only want BPM consider getting a periodogram and finding the dominant frequency:

from scipy.signal import periodogram

frq, psd = periodogram(data, fs=30.0)

bpm = frq[np.argmax(psd)] * 60.0

print("hr is: %f" %bpm)

hr is: 60.298051

On a sidenote I'm also working on remote heart rate extraction in my PhD project. When there's a little time available after the paper I'm writing now I'll update heartpy accordingly. If you have time to wait, we can share findings then. I'm expecting June/July for the update.

[PartyTrix]

Thanks for your very quick and elaborate reply!

How about a situation like this where it has false positives and false negatives closely together, exclude the section?

I am interested in HRV indeed, so the link you provided applies to my situation (i.e. a conservative criterion is preferable over less misses but more false positives). The downside of (cheap) PPG sensors is that they're obtrusive and (for example the empatica E4) get distorted by muscle flexing/movement of the sensor. Or at least, that's my experience so far. And I found the plane orthogonal surface approach (Algorithmic Principles of Remote-PPG) by W. Wang (2017) to be quite usable - even when doing no face detection and just applying a virtual green screen over the video stream.

As you're very familiar with the techniques, is there an obvious downside to use pattern-matching (for example a sinusoidal, as done in this approach https://blog.orikami.nl/exploring-heart-rate-variability-using-python-483a7037c64d?)

I'd be very interested to share findings, my project ends around august/september, and I'm located in the Netherlands as well - so if there is some presentation, let me know ;)

[paulvangentcom]

Yes better to exclude such a section entirely. This will happen when extracting from video I'm afraid.

I've toyed with the pattern matching and wavelet transform in the past but found that the morphology of the wave is too variable in PPG. This occurs to some extent when using cheap sensors (but not a lot), but in PPG extracted wirelessly from webcam this was too much of an issue to be usable.

Where in the Netherlands are you located? What institution? We might meet up for a coffee.

Cheers, Paul

[paulvangentcom]

Let's continue the discussion over e-mail as we discussed, as it is becoming too detailed and specific for here.