I am trying to develop a RGB camera-based non-contact measurement of heart rate using principles of remote photoplethysmography. I want to be able to measure a range of heart rates I have been looking into multiple methods, which are all quite similar though. Typically, they all detect/track the ...
@A_A sorry about the confusion, but 50 bpm is not 50 Hz... 1 Hz = 60 bpm. Even so, I don't think the camera could pick up the mains line frequency. I am not sure about the flicker compensation and automatic exposure (it's a webcam of my laptop), but I will check in on that. How would those parameters affect the program as I would like this to work in a wide variety of illumination environments and I would assume these features would allow for that?
No, really, the confusion is all mine, you are of course right. It would need a webcam with at least 120fps to be able to "catch" the mains flicker. But, under artificial lighting, flicker does creep into the video feed as aliasing. As a response, cameras have compensation for it built in. The idea behind turning off all compensations is to keep modulations of the ppg signal at a minimum. Can you obtain a "plot" of the PPG signal before you estimate BPM and post it please?
@A_A I am not sure what the setup with regards to the flicker compensation and automatic exposure is for my webcam and it really isn't controllable. From the Camera application on my computer, it says Flicker Compensation is set to 60 Hz (I am not sure what that means, I don't work much with cameras) but I don't think changing this setting will change it when I access the webcam from OpenCV. I will try though. I will post the figures of signals from each of the different signals (avg. R,G,B temporal signals, normalized RGB, each of the components from ICA) later today & will let you know.
:) Thank you very much. I am very tempted to say that what you see is artifacts. 1) Are the first 3 plots the RGB averages of the face pixels? 2) Can you please have the camera pointing at the back of your chair and see if you get that 50 spike Hz again? 3) Can you print a face picture and shoot that one and see if it has a heart rate? 4) If you have a second monitor, can you do a "pulsating gif" at some frequency (say 4Hz) and the right colour and see if this signal can track your input? Or maybe a pulsating face "phantom" to make sure that all parts of the algorithm participate....
...we need to determine where is this system sensitive at and work at that region. Otherwise, your BPM estimation is probably latching on whatever component happens to be more powerful or the ringing of some filter or in general, NOT what it is supposed to. The numbers will be churned anyway, some result will always be produced. The question then is, is it valid? Is it within specification?
@A_A I added the plots for background. I also normalized the FFTs which somehow reduced the noise in that plot. Clearly, something seems to be wrong with probably the camera, but what exactly?
Thank you for your response once again. In no particular order: 1) The spectrum seems to be almost identical (?) 2) Sorry to trouble you but can you please plot the components too? My impression was that the spectrum is obtained from the components 3) Are you simply plotting the spectrum from ~0.75Hz onwards, how come the rest of the components are zero? 4) What is your FPS and do you take the timestamp of the frames into account when you derive the spectrum? That bump between 1.0-1.5 might be telling about this
Sorry, I missed some of the edits in your post which I just noticed, the 4th order butterworth you mention, can you please provide the cut off frequencies of that filter? (My question on FPS is answered but please let me know if you are taking the timestamp of the frame into acount).
@A_A 1) oops I am sorry lemme fix that! 2) I will add that soon too... But I wasn't sure if it was relevant since it was just another oscillating signal... 3) Yeah only plotting from 0.75 Hz onwards 4) Yes, the FPS is calculated from the timestamps.
@A_A the cutoff frequencies are 0.6 and 1.5 Hz... would you like to move this discussion to chat or keep it here?
@TanMath Thank you very much. It's starting to look a bit clearer. I don't know if I will be able to pin point exactly what is going on but I will certainly try to provide a more detailed response. Regarding (4): That is not what I mean. What I mean is, do you take into account the relative time that passes between frames in your time signal or do you simply just put the values of each frame one next to the other as if they were acquired at fixed time intervals?
@TanMath In a way that's a detail. All that it will do is "correct" the shape of the spectrum.
@A_A so I do record the time for each frame, but now that I realize, the frequencies from the FFT are coming from a fixed period/frame rate calculated between the first and last frame... So I guess the answer to your question is no... But I don't know how I would account for the time between the frames in the FFT
Discussion between A_A and TanMath
Discussion between A_A and TanMath