Guides · Reference
Camera DORI distances, worked out
DORI — detect, observe, recognize, identify — is the IEC 62676-4 way of saying how many pixels a camera must land on a target. This is the reference: the four tiers, the optics that turn them into a distance, and what a px/m number quietly leaves out.
DORI, per IEC 62676-4
- Detect
- 25 px/m — someone is there
- Observe
- 62.5 px/m — what they are doing
- Recognize
- 125 px/m — someone you know
- Identify
- 250 px/m — beyond reasonable doubt
Pixels per metre of target width — the standard's own tiers.
The tiers
What DORI actually specifies
DORI is a target-resolution scale, not a camera rating. Each tier is a minimum number of pixels the camera must place across one metre of the target — the more you need to prove, the more pixels-on-target it takes.
IEC 62676-4 is the video-surveillance-systems application guide, and DORI is its shorthand for the four operational requirements a camera might have to satisfy. The key move is that it is written in pixels per metre of the target, not pixels on the sensor — so it survives changes in resolution, lens, and distance because all three feed the same number.
| Tier | Minimum | What it supports |
|---|---|---|
| Detect | 25 px/m | A person or vehicle is present in the scene. |
| Observe | 62.5 px/m | Characteristic details — clothing, behaviour, direction. |
| Recognize | 125 px/m | A person you already know, with reasonable certainty. |
| Identify | 250 px/m | An individual established beyond reasonable doubt. |
The math
Turning a tier into a distance
A DORI tier is a pixel density; distance is where a given lens still delivers it. One formula connects them.
Across the horizontal field of view, a camera spreads its horizontal resolution over the
scene width at the target. The scene width at distance d
is 2 · d · tan(HFoV / 2),
so the pixels-on-target work out to:
px/m = Hres ÷ ( 2 · d · tan(HFoV ÷ 2) )
Rearranged for the distance a tier reaches — the number you actually want when you place a camera:
dmax = Hres ÷ ( 2 · tier · tan(HFoV ÷ 2) )
Take a 1080p camera — 1920 horizontal pixels — behind a 90° horizontal-FoV lens. Because tan(45°) = 1, the scene width is just 2·d, and the reach at each tier falls out directly:
| Tier | Max distance (metric) | Imperial |
|---|---|---|
| Detect (25 px/m) | 38.4 m | ≈ 126 ft |
| Observe (62.5 px/m) | 15.4 m | ≈ 50 ft |
| Recognize (125 px/m) | 7.7 m | ≈ 25 ft |
| Identify (250 px/m) | 3.8 m | ≈ 13 ft |
Change the lens to 60° and every distance grows; go to a 4K sensor and it grows again. That is the point of doing the arithmetic per camera rather than trusting a single headline distance on a spec sheet.
The caveat
What a px/m number does not tell you
The formula assumes an ideal target: face-on, well-lit, and unobstructed. Real buildings break every one of those assumptions.
A camera can hit its px/m on paper and still miss the shot. A warehouse rack or a glass partition blocks the line of sight the pixel math assumes is clear. IR fall-off at night shrinks the usable range the datasheet quotes for daylight. Strong backlight, an oblique approach angle, or a lens's own distortion at the frame edge all cost effective resolution the tier number never sees.
This is why pixels-on-target is a floor, not a proof. The honest way to design is to compute the tier against the actual lens, the actual mounting geometry, and the actual obstacles — and then to show the resulting point of view, so the person signing off can see what the camera sees.
On the platform
DORI computed per zone, verified in place
SiteOps Command treats DORI as a per-zone goal on the real model — not a distance you look up and hope.
You tell a space what it is for — a doorway that must identify, an aisle that only needs detection — and the camera engine computes pixels-on-target from the lens and sensor in the product's datasheet, casts the shadows the walls, glass, and racking really throw, and verifies the placement against the tier. Fisheye and panoramic lenses use their own projection models, and IR range comes from the datasheet's beam specification, so the night scene is designed, not assumed. Every camera exports a point-of-view report your customer can verify standing on the spot.
DORI questions
Is DORI measured in pixels per metre or pixels per foot?
IEC 62676-4 defines the tiers in pixels per metre of target width: 25, 62.5, 125, and 250 px/m for detect, observe, recognize, and identify. Pixels per foot is the same idea in imperial units — 250 px/m is roughly 76 px/ft — but the standard is written in metres, so that is the unit to design against.
Does more megapixels always mean more distance?
Only horizontally, and only if the field of view holds. DORI depends on horizontal pixels spread across the horizontal scene width, so a wider lens spreads the same pixels over more metres and the usable distance drops. A 4K sensor on a wide lens can resolve fewer px/m at a given distance than a 1080p sensor on a narrow one. Resolution, lens, and distance are one equation, not three separate specs.
Is a px/m number on its own enough to prove coverage?
No. Pixels-on-target assumes an unobstructed, well-lit, face-on target. A rack, a glass wall, IR fall-off at night, strong backlight, or an oblique angle can all defeat a camera that hits its px/m on paper. That is why coverage should be checked against the real building and the real lens, not just a distance on a datasheet.
How does SiteOps Command compute DORI?
Per zone, on the actual model. You set what a space is for — a doorway that must identify, an aisle that only needs detection — and the camera engine computes pixels-on-target from the lens and sensor in the datasheet, casts the shadows the walls and racking really throw, and verifies the placement against the target. Every camera exports a point-of-view report your customer can check on site.
See DORI computed on your own floor plan
Place a camera from the product library and read the pixels-on-target per zone, with the walls and racking in the way. Talk to us about what your team designs.