{"id":598,"date":"2026-07-01T11:52:46","date_gmt":"2026-07-01T11:52:46","guid":{"rendered":"https:\/\/blog.aminalam.info\/?p=598"},"modified":"2026-07-01T14:29:45","modified_gmt":"2026-07-01T14:29:45","slug":"i-trained-a-headset-fit-detector-on-zero-real-photos-and-it-works","status":"publish","type":"post","link":"https:\/\/blog.aminalam.info\/?p=598","title":{"rendered":"I trained a headset fit-detector on zero real photos … and it works on real photos."},"content":{"rendered":"\n

How synthetic data let us skip the dataset entirely, and still ship 93% real-world accuracy on-device.<\/em><\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

<\/p>\n\n\n\n

The problem nobody warns you about<\/h2>\n\n\n\n

Haven is a flickering light therapy headset. For the therapy to mean anything, the device has to sit correctly on the patient’s face \u2014 level, centered, over the eyes. So before a session starts, the app looks through the phone’s camera and answers one deceptively simple question: is this being worn correctly, and if not, what’s wrong?<\/em> Tilted left? Slipped down the nose? Too high? Off to one side? Not on at all?<\/p>\n\n\n\n

This is a textbook keypoint-detection problem. The textbook solution is where it gets expensive.<\/p>\n\n\n\n

Two expensive doors<\/h2>\n\n\n\n

To train a model to recognize good vs. bad fit, you normally need examples \u2014 lots of them. That meant one of two things:<\/p>\n\n\n\n

Door A \u2014 collect a real dataset.<\/strong> Recruit a diverse set of people. Get them to wear the device, in different rooms, under different lighting, at every wrong angle we care about. Photograph it. Then label thousands of frames by hand. For a medical device, add consent, privacy handling, and the sheer calendar time of coordinating humans. Weeks of work and real money before a single model trains.<\/p>\n\n\n\n

Door B \u2014 ask an LLM at runtime.<\/strong> Skip training entirely: send each camera frame to a vision model and let it describe the fit. Tempting, until you count the costs \u2014 a recurring per-image bill that never stops, a hard dependency on network connectivity (our app is offline-first), latency far too high for a live camera preview, and \u2014 the dealbreaker \u2014 streaming a patient’s face to a third-party server. For a HIPAA-bound medical product, that last one ends the conversation.<\/p>\n\n\n\n

Neither door was good. So we built a third.<\/p>\n\n\n\n\n\n\n\n

Door C \u2014 render the world instead of photographing it<\/h2>\n\n\n\n

I generated the entire<\/strong> training set synthetically. I already had the headset’s exact 3D geometry (it’s the thing we manufacture), so we did the one thing you can’t do with real photos: I placed the goggles on virtual faces ourselves<\/em>, at precisely the poses we wanted to detect \u2014 and got perfect labels for free, because we defined them.<\/p>\n\n\n\n

The pipeline, end to end:<\/p>\n\n\n\n