A face ID module reaching end of life leaves a hole in the door frame. The capture hardware disappears, but the kiosk still has to know who is standing in front of it. This guide is for the integrator rebuilding that function on hardware the market still sells — an active stereo depth camera with an IR projector, plus matching software you run yourself. You get the depth-accuracy numbers that set the working distance, a decision between active stereo, structured light and ToF, the host latency budget, and a checklist before you order. The short version: the geometry holds from 0.3 m to about 1 m, the useful mount band is 0.4–0.8 m, and everything beyond that is software discipline.
Can a stereo depth camera replace a discontinued face ID module?
Yes — at a 0.3–1 m working distance an active stereo depth camera produces the depth plus RGB data the discontinued module fused internally, so you rebuild the match in host software and keep the same millimetre-class face geometry for identification and photo rejection.
The old module was two products in one shell: a depth camera and an on-device matcher, sold as a certified pair. What the 3D sensors category lists today is the sensor half. It carries an IR projector, two mono sensors for the stereo pair, an RGB sensor, and an SDK that hands over aligned depth, IR and colour streams.
The recognition half — face detection, landmarking, embedding, gallery comparison, liveness decision — moves into your host application. That is real engineering work, and it changes what you can promise: the geometry is the same class, but the accept and reject logic is now yours to tune, test and own. The migration rule is absolute: re-enroll every user, because templates from the old module's matcher do not transfer. Plan the project around enrollment effort, not camera shopping.
What does the depth camera actually give you for a face?
The camera streams three things per frame: a depth value for every pixel, the IR intensity image the projector lit, and the RGB texture — at 0.5 m that is about 0.5 mm of depth precision and 0.55 mm per pixel across a 1,280-pixel row.
Each depth pixel deprojects, through the camera's factory intrinsics, into a 3D point; the point cloud is what the matching pipeline consumes. Which camera's intrinsics to use is its own trap — depth and RGB have different ones. Aligned depth point cloud intrinsics: which camera to deproject with settles it.
The IR image is the projector-lit texture; if your colour preview suddenly looks black and white, you grabbed the IR stream instead of the RGB sensor. That mix-up is described in depth camera RGB shows black and white: you are on the IR stream. RGB and depth come from different sensors at slightly different angles, so register them before fusing colour with geometry. How to register RGB depth images for a colored point cloud walks that step.
Pixel density: at 0.5 m a 70° horizontal FOV spans 700 mm, so a 1,280-column depth map samples the face at 700 / 1,280 ≈ 0.55 mm per pixel. A 200 mm-tall face covers about 360 pixels. Face geometry needs far less than that — nose protrusion is 10–25 mm, eye sockets 5–15 mm deep — so resolution is never the constraint; depth precision is. The calculator below runs the same division for your own distance and pixel count.
How accurate is stereo depth at face working distances?
Stereo depth error grows with the square of distance: Δz = z²·Δd/(f_px·b) gives about 0.5 mm at 0.5 m for a 55 mm baseline and 0.1 px disparity precision, 2 mm at 1 m and 8 mm at 2 m — so mount the camera to keep faces inside 0.8 m.
Δz is the depth error, z the distance to the face, Δd the disparity precision in pixels, f_px the focal length in pixels and b the baseline between the two IR sensors. Three of the four inputs are frozen by the camera you buy; z is the one you control with the mounting bracket.
Two field rules back the arithmetic. Stereo depth stays usable to roughly 40× the baseline — 55 mm × 40 = 2.2 m, where the formula gives about 10 mm, too coarse to tell a face from a flat mask.
Accuracy is also not uniform across the image: disparity edges smear with distance, which is why far faces lose nose and eye-socket definition first (stereo depth edge accuracy: why distance deforms edges). The baseline is a purchase you make once. A wider one buys range (long range stereo depth accuracy with a wide baseline) but pushes the closest usable distance outward, which is why face-range cameras cluster near 50–60 mm.
These are geometry estimates, not a datasheet promise: point the camera at a flat target at 0.5 m and read the depth spread before you trust the number. Decision: mount 0.4–0.8 m from the face and enroll at that distance.
Which depth technology should you choose: active stereo, structured light or ToF?
For a face at 0.3–1 m indoors, pick active stereo with an IR projector when you want RGB-aligned depth from one device, projected structured light when you want the densest close-range cloud, and ToF only when frame rate matters more than millimetre facial detail.
Active stereo fires an IR texture pattern into the scene and triangulates it on two mono sensors, with the RGB sensor riding along for texture — the strongest all-rounder at face range and the natural fit here, because one device supplies colour for the embedding and depth for liveness. Projected structured light reads the projected pattern with a single sensor: the densest geometry at 0.2–1 m, trading away range. ToF times the round trip of light per pixel: full-frame depth at 30–60 fps but VGA-class resolution, so it decides presence quickly and flattens facial relief.
| Technology | Useful range | Depth density | Weak spot |
|---|---|---|---|
| Active stereo | 0.3–2 m | dense, RGB-aligned | direct sunlight swamps the pattern |
| Projected structured light | 0.2–1 m | densest at close range | short range, strong ambient IR |
| ToF | 0.3–5 m | VGA-class | spatial detail, camera-to-camera interference |
Those are class ranges, not any single model's datasheet. The shop lists all three families; here is one of each, with its datasheet rows:
| Specification | MV-DPS200P-02 | MV-DLS300P-04 | MV-DT01WMU |
|---|---|---|---|
| Near field of view | 180 mm × 160 mm @ 250 mm | 280 mm × 220 mm @ 400 mm | – |
| Far field of view | 420 mm × 320 mm @ 500 mm | 620 mm × 440 mm @ 800 mm | – |
| Clearance distance (CD) | 250 mm | 400 mm | – |
| Measurement range (MR) | 250 mm | 400 mm | – |
| Repeatability (Z-axis) | 0.02 mm @ 300 mm | 0.03 mm @ 600 mm | ±(10+0.5%depth1)mm |
| VDI/VDE accuracy | 0.03 mm @ 300 mm | 0.05 mm @ 600 mm | – |
| Resolution | 3200 × 1944 @ RGB image; 1632 × 1264 @ depth map | 3200 × 1944 @ RGB image; 1632 × 1080 @ depth map | Depth map: 640 × 480 @ 30 fps; RGB image: 1280 × 1024 @ 30 fps |
| Data type | Raw image (mono + color), Depth map, RGB-D image | Raw image (mono + color), Depth map, RGB-D image | Intensity image, Color image, Depth map |
| Acquisition time | 0.2 ~ 0.7 s | 0.4~0.9 s | – |
| Image output latency | 0.5 ~ 1.2 s | 0.8~1.5 s | 133 ms |
| Dimension | 126 mm × 90 mm × 50 mm | 236.3 mm × 79.8 mm × 98.5 mm | 91 mm × 26 mm × 31.2 mm |
| Weight | 0.74 kg | Approx. 1.3 kg | Approx. 70 g |
| Price | $8,829.00 · quoted | $16,579.00 · quoted | Price on request |
Values as printed in each product's data sheet; open a part for its drawing and full specifications.
Projected structured light is the family the discontinued face modules belonged to: projected pattern, one viewing sensor, dense geometry at close range. The shop's structured-light entry:
- Type
- Stereo / structured light
If the camera's second job is presence and flow — counting people through a doorway rather than authenticating a face — the trade-offs shift. Active infrared depth versus stereo for people counting compares them directly. For that job ToF decides fastest:
- Type
- Depth / ToF camera
Decision: face authentication indoors takes active stereo or projected structured light; ToF takes the job only when presence and throughput outrank facial detail.
Where should the matching software run?
Run the matching pipeline on a host PC or embedded computer next to the camera: the depth camera streams, the host detects, aligns, embeds and compares, and a current desktop host decides in about 0.5 s when you average three frames.
The SDK runs on that host too: it exposes the depth, IR and RGB streams plus the factory calibration. Prototype the geometry with ordinary point-cloud tooling — measure distance and bend angle from depth point clouds in Python is a working example of exactly that.
Latency budget: detection plus landmarking plus embedding lands at 30–100 ms per frame on a current desktop GPU and 150–400 ms on CPU alone. Three frames averaged for stability puts a GPU host's decision at 0.3–0.5 s and a CPU host near 1 s. Comparison is the small part: an embedding is a few hundred floating-point values, and one probe against a 10,000-person gallery costs about 1–5 ms, so the number of cameras, not the population size, drives host sizing.
If policy forbids a host PC at the door, the options narrow. Smart cameras run inspection models on-device, but biometric matching is not their listed function, so that becomes custom development — or the site keeps a dedicated face terminal.
How do you keep the match stable day to day?
Enroll and verify in the same 0.3–0.8 m distance band, average three to five frames, and gate acceptance on more than 10 mm of depth relief — a live face spans 30–80 mm nose to ear while a photo or screen stays under 10 mm.
Depth frees the identity side from lighting drift, but the RGB half of the pipeline still sees it. The fixes are the ones in lighting for face recognition: fix illumination drift: lock exposure instead of letting auto-exposure hunt between frames, and light the approach path evenly. Give the camera a fixed mounting height and a floor mark at 0.5 m so enrollment and verification distances match — step back to 0.7 m and the depth error rises from 0.5 mm to about 1 mm.
Stereo depth also jitters a fraction of a millimetre between frames; averaging three to five frames settles the embedding. If the wobble follows footsteps or door slams rather than distance, it is mounting vibration, not the sensor — the stereo depth jitter and IMU drift troubleshooting guide walks that diagnosis. Set the acceptance threshold from your own data: cosine-similarity thresholds for common face-embedding models start near 0.6–0.7, and the right value falls out of a ROC curve plotted from your own enrollments.
Keep the liveness gate geometric — reject any frame whose face region spans less than 10 mm of depth — and know its ceiling: a rigid 3D mask defeats depth-only liveness, which is why high-security sites add a second factor. Sunlight is the hard boundary: direct sun carries broadband IR that drowns the projected pattern, so this stays an indoor or shaded install. Extra IR flood does not rescue it — infrared flood illumination for stereo depth imaging explains what added IR does and does not fix for stereo.
When is a depth-camera rebuild the wrong choice?
Rebuild on a depth camera only when you control the whole installation: skip it where the site demands certified biometric hardware, where lookalike faces must be separated below a 1-in-100,000 false-accept rate, or where direct sunlight washes out the projector for most of the day.
Case one: the site's security policy names certified face terminals. A rebuilt pipeline is your own attestation of performance and inherits none of the old module's approvals, so keep the certified path and leave the depth camera out of the identity decision.
Case two: the false-accept target sits below about 1 in 100,000 and the gallery holds close relatives or lookalikes — the known failure mode of face matching generally. Plan multi-pose, multi-session enrollment and a second factor before promising that number.
Case three: an outdoor gate in direct sun, where the projected pattern is gone most of the day and depth degrades to passive-stereo quality — too noisy for the 10 mm liveness gate to stay honest.
The rebuild earns its keep where you control the environment: an indoor door, kiosk or locker bank at 0.4–0.8 m, a host you administer, a user population you can re-enroll. Log the depth frame with every accept decision; it is your audit trail and your tuning data.
What should you check before ordering?
Before ordering, confirm four things: the SDK exports aligned depth and RGB with intrinsics, flat-target depth spread at 0.5 m is 1 mm or better, the host decides within 1 s, and the projector is marked Class 1 — then enroll ten volunteers on one unit before scaling.
- SDK streams — aligned depth, IR and RGB, with factory intrinsics exposed; without them you cannot deproject or register colour.
- Flat-target test — depth standard deviation of 1 mm or better at 0.5 m on a white board, measured on the actual unit.
- Minimum depth distance — under 0.4 m, so the kiosk can mount close enough to hold the 0.4–0.8 m band.
- Host latency — the full decide path under 1 s with three frames averaged, timed with your models, not a demo.
- Projector class — Class 1 eye-safety marking on the housing, intact; the FAQ below covers what keeps it intact.
- Enrollment load — five to ten captures per person at the mounting distance; 500 people is about 17 desk-hours.
Shortlist hardware in the camera finder, and if the mounting distance or latency budget looks tight, run your numbers past the team on the contact page. More depth-camera geometry, from point clouds to calibration, is collected on the 3D vision topic page.
The configurator matches a camera, lens, light, light controller and cables to each other, step by step, and lists only parts that fit what you already picked.
Questions
Is the IR projector eye-safe for people who stare into it?
Depth cameras with built-in IR projectors carry a Class 1 classification under IEC 60825-1, the same class consumer depth sensors use: eye-safe under normal use with no protective measures. Keep the rating intact — never open the module, bypass an interlock, or run the projector outside its documented duty cycle. Mount so nobody can press an eye to the window, and treat projector repairs as a return, not a bench job.
Do enrolled face templates carry over from the discontinued module?
No. A template is an embedding computed by the matching software, and the old module's matcher left with its firmware. Budget re-enrollment for every user: five to ten captures at the mounting distance, glasses on and off, averaged into one embedding per person. The arithmetic is people-hours: 500 users at two minutes each is about 17 hours of enrollment desk time — a week of mornings, not a migration project.
How many faces can one host match per second?
The bottleneck is capture and embedding, not comparison. Matching one probe embedding against a 10,000-person gallery is ten thousand dot products: about 1–5 ms. Detection plus embedding costs 30–100 ms per frame on a desktop GPU, so one host serves roughly 5–10 verification requests per second — comfortable for one door, tight for a bank of ten gates.
Do glasses, beards or hats break the match?
Specular eyewear reflects the projector pattern and punches dropout holes in the depth map; averaging several frames and discarding invalid pixels usually recovers enough geometry. Beards and hats move the RGB embedding more than the depth silhouette, so enroll people in the appearance they actually wear. The depth-side rule is a minimum valid-pixel fraction: set 70% inside the face region and reject the frame before scoring if it falls below.
How does the host signal the door controller?
The camera only streams; your host decides and signals. Standard practice: the host closes a dry-contact relay or sends the grant to the door controller over the network, and the controller keeps its own fail-safe release logic. Keep the vision system out of the safety chain — the door must still open on its own hardware, whatever happens to the host, the SDK or the power supply.