CircadifyCircadify
rPPG Model Training7 min read

Why can my new phone read my pulse but my friend's can't?

Discover why phone camera vitals accuracy differs between devices. Learn how camera sensors, ISPs, and model training impact remote photoplethysmography.

tryvitalsapp.com Research Team·
Why can my new phone read my pulse but my friend's can't?

The question is simple, but the answer reveals a fundamental challenge for the future of connected health. You download a new app that promises to measure your heart rate using your phone's camera, and it works. Your friend, with a different phone, tries the same app and gets a persistent error. The experience isn't random; it's a direct consequence of the vast hardware and software diversity in the world's cameras. Understanding the reasons for this discrepancy is crucial for any hardware OEM or IoT device maker looking to integrate robust, camera-based vitals into their products. The core of the issue relates to phone camera vitals accuracy different devices and how a model trained for one specific sensor may be completely ineffective on another.

"A calibration method that corrects for non-linear scaling in smartphone camera photoplethysmography was shown to reduce measurement errors by 61% to 87% on devices like the Samsung Galaxy S22 and Google Pixel 4."

  • Adapted from findings by C. F. L. M. F. et al., Frontiers in Physiology, 2023.

Why camera-specific models are non-negotiable

A remote photoplethysmography (rPPG) model is not a simple piece of software that can run on any hardware. It is a highly specialized algorithm whose performance is intrinsically tied to the physical device used to capture the input video. The light that travels from your face, to the phone's lens, through its sensor, and into the image signal processor (ISP) undergoes a unique journey on every single device model.

An rPPG model trained on data from a Google Pixel, for example, has learned to find the minute, blood-flow-induced color changes as interpreted by that specific combination of a Sony IMX sensor, its corresponding lens assembly, and Google's proprietary ISP and image processing algorithms. When that same model is run on a Samsung phone, which uses a different ISOCELL sensor and a completely different ISP, the input data it receives is fundamentally alien. The model may fail to find a signal, or worse, it may hallucinate a plausible but incorrect measurement. This problem of phone camera vitals accuracy different devices is the primary reason why a "one-size-fits-all" approach to rPPG software is destined to fail in real-world deployments.

Feature Representative Phone A Representative Phone B Impact on rPPG Model
CMOS Sensor Sony IMX series Samsung ISOCELL Different quantum efficiency, noise floor, and spectral response.
Image Processor (ISP) Prioritizes HDR and noise reduction Prioritizes color saturation and sharpness Heavily alters the raw pixel data the model receives.
Lens Aperture f/1.8 f/2.0 Affects light-gathering ability, critical in low-light conditions.
AI Co-Processor Optimized for specific ML frameworks Different architecture and optimizations Influences on-device model speed and deployment feasibility.
Required Model Custom-trained on Phone A data Custom-trained on Phone B data A model trained on A will not be accurate on B, and vice-versa.

Industry applications for custom-trained models

The challenges seen in the consumer smartphone space are magnified in professional and industrial use cases. For hardware OEMs, relying on a generic rPPG model is a significant product risk.

  • Automotive OEMs: A Driver Monitoring System (DMS) needs to work reliably across a range of lighting conditions, from direct sunlight to a dark garage. The camera's infrared (IR) or visible-light sensor has a unique spectral response that a custom model must be trained to handle.
  • IoT Device Makers: A smart mirror or a wellness kiosk installed in a home or gym has no control over ambient lighting. The model must be robust to everything from fluorescent light to tungsten bulbs, as captured by its specific, chosen camera module.
  • Telehealth and Medical Devices: For a device used in remote patient monitoring, accuracy is critical. A model must be trained and validated specifically for the camera being used in the patient's home or a clinical setting to provide data that clinicians can trust.

Current research and evidence

The academic and engineering consensus is clear: hardware heterogeneity is a major variable that must be controlled for. Researchers like Wim Verkruysse at the Eindhoven University of Technology have long investigated the fundamental physics of rPPG, showing how signal quality is dependent on the properties of the light-tissue interaction and its measurement.

More recent work directly addresses the cross-device problem. A 2023 study published in Frontiers in Physiology demonstrated a calibration method that dramatically improved heart rate variability metrics on smartphones. The researchers found that each phone's automatic tone mapping creates a unique non-linear distortion of the PPG signal. By creating a calibration profile for each device, they could correct these distortions and significantly improve accuracy. This reinforces the concept that every camera has a unique "fingerprint" that a model must be taught to understand. Similarly, a 2023 paper from Samsung Research presented a normalization algorithm specifically designed to achieve robust SpO2 estimation across different users and devices, acknowledging the need to solve for sensor variability.

The future of camera-based vitals

The future of reliable, camera-based health monitoring is not in a single, universal algorithm. Instead, it lies in a platform-based approach where highly optimized models are custom-trained for the specific hardware they will run on. As cameras become embedded in more devices, from cars and mirrors to glasses and kiosks, the demand for sensor-specific AI models will grow. The engineering teams that succeed will be those who treat the camera, sensor, and rPPG model as a single, integrated system, not as interchangeable parts.

Frequently asked questions


Q: Why can't an app developer just support all the major phone cameras? A: The sheer number of camera modules and the proprietary nature of their internal image processing pipelines make this impossible. Each new sensor and ISP combination creates a new, unique environment. Supporting even a fraction of the phones on the market would require a massive and continuous data collection and training effort for each specific device.

Q: Is a more expensive phone camera automatically better for reading vital signs? A: Not necessarily. While a high-end camera may have better low-light performance, its aggressive image processing may interfere with the rPPG signal. A less expensive camera with a more predictable and stable ISP might provide a cleaner signal for a custom-trained model. The key is not price, but the quality of the model's training for that specific hardware.

Q: What is the difference between a generic rPPG model and a custom-built one? A: A generic model is trained on a wide but uncontrolled variety of data from different cameras, hoping to find a "one-size-fits-all" solution that rarely works well. A custom-built model is trained exclusively on data collected from your specific target hardware (e.g., the camera in an automotive cabin or a smart mirror), ensuring it is optimized for that sensor's unique characteristics.

The variability between devices highlights a critical need for hardware-specific model development. Circadify specializes in creating custom-trained rPPG models that are optimized for the unique camera, sensor, and operating environment of your specific device. To learn how a custom build can de-risk your product development and deliver the accuracy you require, visit our team to discuss your project at circadify.com/custom-builds.

rppgcomputer visionvital signs monitoringmachine learningcamera sensor
Start a Custom Build