01
Entry and exit
Define a virtual line, direction rules and debounce logic for one-way or bidirectional doorways.
3D ToF cameras for privacy-conscious people counting
Build bidirectional counting and footfall analytics from depth, with mounting, validation and integration guidance for real entrances.
People counting solution outcomes
Bidirectional entry and exit events
Count direction, crossings and repeat passes from depth geometry rather than visible-light texture alone.
Occupancy and dwell context
Feed live occupancy, queue, dwell and heat-map logic to the host analytics layer.
Privacy-first sensing
Use depth features and anonymous tracks without making face recognition part of the design.
Integration-ready outputs
Expose timestamps, direction, confidence and zone events to edge software, APIs or building systems.
Define the metric first
People counting is an event model, not just a person detector
Before choosing optics or compute, define what your business system should count. Entry, exit, occupancy and heat map outputs each need different zone geometry, track state and exception rules.
Recommended acceptance language
Specify the doorway, mounting height, traffic direction, group policy, peak density, ground-truth method and tolerated event error before discussing a rollout.
02
Occupancy
Maintain an estimated in-zone population with reset, timeout and exception rules that your application owns.
03
Dwell and queues
Use track duration, queue-zone occupancy and wait-time bands to expose operational friction.
04
Heat maps
Aggregate anonymous positions into zone density maps without retaining identifiable imagery.
05
U-turn handling
Separate an actual crossing from a person who pauses, reverses or crosses the same line twice.
06
People, groups and objects
Define how strollers, carts, luggage and side-by-side groups are classified before acceptance testing.
Where projects lose trust
Design around the false-count cases your site will actually produce
A clean demo proves that a track can be detected. A production pilot proves that the event remains correct when people pause, overlap, turn back or carry objects.
Shadows and backlight
RGB-only systems can confuse a projected shadow, glare or a low-contrast silhouette with a person. Depth gives the tracker a geometric cue, while confidence rules still decide whether a sample is usable.
Side-by-side groups
Shoulder-to-shoulder people can merge into one blob or split into fragments. Validate mounting height, field of view and the host tracker with the widest real group.
U-turns and dwell
A person who enters the doorway and turns back is not the same event as an exit. Direction state, hysteresis and track timeout belong in the acceptance test.
Carts and luggage
Retail carts, cases and umbrellas change the observed silhouette. Decide whether the metric is people-only, people-plus-assistive-device or total traffic.
The engineering promise to make
Use depth to make the scene more observable and less dependent on visible-light appearance. Do not turn that into an absolute “works in every environment” claim. Publish the qualified geometry, confidence thresholds and exception path instead.
Selection logic
How 3D ToF fits beside camera, radar and thermal options
The right comparison is system-level. ToF is attractive when spatial separation and a depth-native privacy architecture matter, but its return signal and installation envelope still need qualification.
| Decision factor | Typical 2D camera concern | 3D ToF implication |
|---|---|---|
| Visible-light dependence | Sensitive to contrast, shadows, glare and camera exposure | Uses active depth plus confidence; still validate ambient IR and return signal |
| Low light and darkness | Requires enough visible-light signal for stable segmentation | Can preserve depth structure in low visible light within the qualified operating envelope |
| Spatial separation | 2D overlap can merge people with similar appearance | Height and distance cues help, but dense occlusion remains an application limit |
| Reflective or transparent surfaces | Can be visually bright while providing little geometric evidence | May create multipath, missing pixels or unstable range; test the real scene and cover glass |
| Privacy architecture | Often starts from RGB frames and then removes or masks identity | Can be architected around depth features, anonymous tracks and edge-only event output |
| System responsibility | Camera, model and event logic are often supplied as one closed product | DOMI supplies sensing hardware and integration guidance; host software owns tracking, policy and acceptance |
From depth frame to event
A transparent pipeline lets your R&D team debug the count
Treat the camera, tracking model and business event as separate layers. During a pilot, keep enough depth, confidence and timing evidence to explain why a frame became an entry, exit, exception or no-event.
01
Capture depth
Acquire depth frames with timestamp, range and confidence metadata from the selected camera.
02
Filter confidence
Reject invalid pixels, multipath artefacts and points outside the calibrated entrance volume.
03
Model the scene
Transform the depth map into a floor, doorway or zone coordinate frame with known mounting geometry.
04
Track people
Detect, associate and classify tracks, then apply line, direction, dwell and debounce rules.
05
Publish events
Send count deltas, occupancy, confidence and evidence references to the edge app, API or BMS.
Installation geometry
The doorway is part of the sensor specification
A product range number is not a finished coverage map. Mounting height, pitch, doorway width, walking direction and the floor or wall return determine the useful depth volume.
Send us the scene constraintsInputs to freeze
- Doorway width, height and traffic direction
- Mounting height, pitch, roll and cover glass
- Floor, tile, mirror, glass and clothing finishes
- Peak density, carts, luggage and accessibility aids
- Useful coverage
- Depth volume at the doorway
- Evidence to log
- Valid pixels, confidence, frame age and track state
- Acceptance output
- Count delta, direction, occupancy and exception reason
Engineering limits
The qualification checklist your pilot should answer
These are not footnotes. They are the conditions that decide whether a depth counter is reliable in your doorway and what needs to change in the mechanical, optical or software design.
Ambient infrared and sunlight
Active ToF return signal can be reduced by strong ambient infrared, especially near glazed façades or skylights.
Validation move: Test at the worst solar condition, log confidence/invalid-pixel rate and qualify shielding or placement.
Dark, glossy or transparent targets
Low return, specular reflection and transmission can create missing or displaced depth around black clothing, mirrors and glass.
Validation move: Use the real finishes and garments in a scene matrix; define a confidence threshold and exception path.
Steam, condensation and dirt
A fogged cover window, water film or cleaning residue can increase crosstalk and distort ranging. Washroom cubicle occupancy is a different sensing problem from entrance footfall.
Validation move: Validate cover material, sealing, cleaning interval, HVAC/steam conditions and whether PIR or another sensor is better for cubicles.
Multiple active cameras
Overlapping active emitters may interfere or create unstable depth if channels and placement are not coordinated.
Validation move: Stagger fields of view, use supported synchronisation or qualify camera spacing in the complete installation.
Crowds and occlusion
A single viewpoint cannot recover people fully hidden behind a dense group or a doorway stack.
Validation move: Set a density limit, consider paired views and test the busiest five-minute window, not only empty-door samples.
Host compute and latency
Depth frames are only the sensing layer. Neural inference, tracking, event buffering and network transport determine end-to-end latency.
Validation move: Specify FPS, frame age, CPU/NPU budget, queue depth and event delivery SLA before choosing the interface.
Application fit
Start with the scene where a depth signal changes the decision
Retail and shopping malls
Measure entrances, queue build-up, dwell zones and campaign lift while keeping the architecture focused on anonymous operational data.
- Doorway bidirectional counts
- Zone occupancy and heat maps
- Cart and group policy
Transport hubs
Qualify a high-throughput corridor against backlight, luggage, crowd density and multiple-camera interference before committing to a platform rollout.
- Gate and concourse flow
- Peak-window stress tests
- Edge event hand-off
Washroom entrances
Use ToF for entrance footfall and queue context only after validating steam, condensation, reflective tiles and privacy requirements. Cubicle occupancy may need a purpose-built presence sensor.
- Entrance counting
- Queue or occupancy zone
- Hygiene and cleaning validation
Evaluation hardware
Three sensible starting points for a people-counting proof
Start with a host-friendly camera for scene discovery. Move to an embedded module only after the entrance geometry, event model and acceptance evidence are stable.
DM-PS2601-VGA
DM-PS2601-VGA
Edge people-counting camera
A direct pilot path for entrance counting, occupancy and queue analytics over Ethernet.
- Depth: 640 x 480 at 30 fps
- Working range: 0.3 to 5 m; FOV 120° x 90°
- Linux, NPU and TCP output for count, coordinate, height and trail
DM-RGBD5003A
DM-RGBD5003A
USB RGB-D evaluation camera
Fast proof-of-concept on a laptop, edge PC or ROS pipeline.
- Depth: 640 x 480 at up to 25 fps
- Working range: 0.2 to 5 m
- USB 2.0, C/C++, Python and ROS path
DMOM2508CL
DMOM2508CL
Embedded MIPI depth module
Compact production hardware after scene geometry and algorithm assumptions are proven.
- Depth: 320 x 240 at 10 to 30 fps
- Working range: 0.2 to 2 m
- Dual-lane MIPI CSI-2 interface
Pilot acceptance
Turn a demo into evidence your procurement team can sign off
A useful pilot has a repeatable protocol. Record the scene, the expected events and the failure modes so a second site can be compared without moving the goalposts.
01
Ground truth
Use a manual tally or an independently reviewed reference sample with known direction and time window.
02
Directional error
Report missed, extra, reversed and duplicate events separately instead of hiding them in one accuracy number.
03
Scene matrix
Repeat under day/night, backlight, clothing, reflective finishes, groups, carts, luggage and washroom cover conditions.
04
Reproducibility
Log camera settings, firmware, host load, frame age, thresholds and mounting references for every run.
System hand-off
Keep the edge path observable from sensor to business event
The integration decision is not USB versus MIPI alone. It is where depth is decoded, where tracks are created, how events are buffered and which layer can prove a count after the installation is live.
Edge processing path
- Decode depth and confidence close to the camera
- Run filtering, detection and tracking on the qualified host
- Publish only anonymous events, confidence and health telemetry
Host integration path
- Define event schema: timestamp, direction, zone, confidence and reason
- Map occupancy and heat-map aggregates to your dashboard or BMS
- Retain the minimum evidence required for audit and privacy policy
Questions before the pilot
Answers an R&D or procurement review will need
Does 3D ToF guarantee accurate people counting in any lighting?
No. Active depth can reduce dependence on visible-light shadows and texture, but ambient infrared, sunlight, reflective surfaces, condensation, occlusion, mounting geometry and host tracking still affect performance. Specify the scene and validate it with measured ground truth.
Is the ToF camera a complete people-counting system?
No. The camera is the depth-sensing layer. Detection, multi-object tracking, line and zone rules, U-turn logic, analytics, data retention and system acceptance belong in the host application or system integrator scope.
What should we compare against mmWave radar or thermal imaging?
Compare the complete system on spatial resolution, separation of side-by-side people, privacy policy, low-light behaviour, material sensitivity, latency, installation height and total integration effort. Radar can be strong for presence and coarse motion; thermal can help in darkness but introduces its own privacy and calibration questions.
Will ToF work at a washroom entrance?
It can be evaluated for entrance footfall when the doorway, mounting height and cover environment are controlled. Steam, water film, mirrors and glossy tiles can disturb ranging. For cubicle-level occupancy, compare PIR or another presence sensor rather than assuming a doorway counter solves it.
Can multiple ToF counters be installed in one transport hub?
Yes, after a multi-camera interference and placement study. Keep overlapping active fields controlled, qualify synchronisation/channel settings supported by the chosen hardware and test the complete corridor under peak density.
Does DOMI provide the tracking algorithm and dashboard?
DOMI provides depth-sensing hardware, product specifications and engineering support for the integration path. Your team or solution partner typically owns the tracking model, dashboard, business rules, data policy and final field acceptance unless a separate scope is agreed.
Which DOMI products should we evaluate first?
Start with DM-PS2601-VGA when you want edge-side people-counting output over Ethernet. Use DM-RGBD5003A for host-side RGB-D evaluation, then consider DMOM2508CL or DMOM2808D for an embedded design once the geometry and algorithm are understood.
What evidence should be collected before a pilot?
Record frame rate, depth range, valid-pixel coverage, mounting geometry, ground-truth counts, directional error, false events, frame age, host load and exception samples across lighting, clothing, reflective finishes and peak density.
When should I leave my work email in the form?
When you have a real doorway, mounting envelope, host platform or pilot date to review. Share the constraints and DOMI can respond with a shortlist, evaluation questions and an integration path instead of a generic catalogue reply.
Bring a real scene
Get a camera shortlist built around your doorway, not a generic accuracy claim
Tell DOMI what the entrance, host platform and pilot must prove. We can help map the evaluation hardware, interface assumptions and validation questions before a production quote.
- Working distance, doorway width and mounting envelope
- Lighting, reflective surfaces, steam or cover-glass conditions
- Required outputs, host interface and expected production volume
Tell us about your people-counting pilot
A few details are enough to start the conversation.