Face recognition on CCTV footage performs substantially worse than controlled-condition demonstrations, because faces arrive at distance, at angle and in poor light. The Incoresoft installation manual names four camera-side factors: the pixels across the face where you want the capture, the light on that face, the camera tilt, and the compression and processing time in the video path. This is true for a plain detector and for cameras with facial recognition built on top of one, because recognition can only use the face crops the detector returns in time. The false positive rate you see in the field also moves with the match threshold and the size of the watchlist, not only with the algorithm the datasheet describes.
Demonstrations rely on frontal pose, controlled lighting and cooperative subjects, and CCTV footage has none of these.
Detection and recognition fail in different ways
Face detection answers “is there a face here, and where”; face recognition compares that face against stored templates to say whose it is. Axis states plainly in its AXIS Face Detector datasheet that only the face is detected and no further analysis is performed. The stages need different image quality. The Incoresoft installation manual sets a minimum interocular distance of 10 pixels for detection, 21 pixels for recognition and a recommended 40 pixels.
The two stages also have different error metrics. A detector fails by missing a face (a failed detection at the camera) or by boxing something that is not one. A recognition system fails through false positive and false negative identification rates (FPIR and FNIR) at a given threshold. “Face recognition” itself covers at least four engineering tasks, each with its own gallery, threshold and error metric. Our article on what face recognition means as a computer vision term separates those tasks. The full face recognition pipeline and the NIST bias findings are covered on the hub page.
When someone quotes an accuracy figure, the first question is which stage it describes. A detector rated on frontal faces in good light says nothing about watchlist false alerts, and a recognition benchmark assumes the detector already returned a usable crop.
How many pixels does a face need at the distance you care about?
Size the camera for pixels on the face at the spot where capture has to happen, not for megapixels on the box. The published minimums vary by vendor and by task:
| Source | Measure | Minimum or recommended |
|---|---|---|
| Incoresoft installation manual | Interocular distance (IOD) | 10 px detection, 21 px recognition, 40 px recommended |
| Innovatrics camera guides | Pixels between the eyes | At least 50 px; 30 px works with degraded templates; below 30 px not recommended |
| Google ML Kit (Android) | Face size in image | At least 100×100 px; 200×200 px for contours; input at least 480×360 |
| IEC 62676-4:2025 (human viewing), via Axis white paper (2026) | Face width | 40 px/face (250 px/m) for “Characterize”, 80 px/face (500 px/m) for “Validate” |
Some of these numbers measure the distance between the eyes and others measure the whole face, so compare them by what they measure. The IEC model assumes an average face width of 16 cm. It was written for footage that human operators interpret, and Axis notes that different definitions apply when software analyses the image. So the standard describes how much detail a frame holds for a human viewer.
More resolution is not automatically better. Innovatrics recommends at least 720 px of width, calls Full HD (1920×1080) the sweet spot, and says higher resolutions rarely improve recognition and cost processing time. Wide fields of view work against you: the face shrinks so quickly that a person standing a short distance away can be too small to recognise.
Worked example: turning a pixel-density target into coverage width
Assume a 1920-pixel-wide stream and the IEC “Characterize” level of 250 px/m. The widest horizontal scene the camera can cover at the capture distance is 1920 ÷ 250 = 7.68 m. At the “Validate” level of 500 px/m, the same stream covers only 1920 ÷ 500 = 3.84 m. Where the lens frames a wider scene than that at the capture point, either narrow the field of view or move the capture point closer. Axis also warns that the pixel-density model is a simplification: meeting it does not guarantee the outcome, because light direction, optics quality and compression affect the result.
The same arithmetic explains why detection can work on the main stream but not on the substream. A substream one third the width of the main stream gives one third of the pixels per face, so a face that passes the IOD minimum on the main stream can fall below it on the substream. Before blaming the model, check which stream the analytics actually read.
Frame rate, shutter and compression settings
Faces in motion need short exposures and clean frames. Incoresoft recommends a shutter setting no slower than 1/100 to limit motion blur. Innovatrics puts 1/50 s as the maximum exposure in low light, before blur sets in. Innovatrics also asks for at least 15 frames per second at all times, constant bitrate with quality priority, and about 4 Mbps of stable bandwidth per RTSP camera. Incoresoft advises keeping compression within 0-10% where possible and avoiding schemes such as zip streaming. The UK National Physical Laboratory (NPL), in its 2023 equitability study, saw compression artefacts in saved deployment video and noted that they may have lowered recognition accuracy compared with live uncompressed video.
Low light, backlit doorways and what WDR does to faces
Lighting is the most common cause of poor face results and the hardest variable to control, and Innovatrics notes that placement usually fixes what camera settings cannot. Incoresoft recommends even lighting of at least 150 lux on faces in the detection area, against well-lit, smooth backgrounds. Any light source inside the camera view makes the image worse. The light should also stay consistent through the day, because a finely tuned system can misbehave as the light changes.
Backlight from outside is a typical entrance problem. Doors, parking garages and tunnels combine bright exterior light with a dark interior, and a camera without WDR can expose correctly for only one of the two. Wide dynamic range (WDR) helps, but at a cost. Multi-exposure WDR can produce ghosting around moving people, uneven motion blur and visible flicker under LED or fluorescent lighting, and the noise it adds is worst where the exposures are blended. Innovatrics adds that WDR artefacts on the edges of a face can look like a presentation attack and lower passive liveness scores, so it recommends keeping WDR off where liveness checks matter.
Do not choose a camera by its WDR dB rating alone. Axis says the dB value is hard to relate to real WDR performance, which also depends on scene complexity, motion and the camera’s image processing.
Low light brings a different trade-off. Longer exposures blur moving faces, and higher ISO lowers the signal-to-noise ratio, so additional light sources are often the answer. Detecting faces at night has research benchmarks of its own. The DARK FACE benchmark, for example, provides 6,000 labelled night-time images from streets, bridges and parks, plus a held-out test set of 4,000. Poor lighting also affects accuracy unevenly across skin reflectance, according to a 2025 survey of face recognition research.
How high should the camera go, and at what angle?
Mount the camera as close to face height as the site allows, and aim it along the direction people walk. Incoresoft rates a tilt of 0-15° as high recognition quality, 15-45° as average and 50° or more as low. Innovatrics gives head-angle limits for live recognition of roll ±15°, pitch ±30° and yaw ±30°, and says larger angles still work but lower match quality. Detectors built into cameras can be stricter still: the AXIS Face Detector requires 0° or 180° placement, and only upright, frontal faces can be detected. At a fixed mounting height, the camera has to sit further away to keep the tilt inside those bands.
Location matters as well as height. Incoresoft notes that processing typically takes 0.2 to 1 second, so it recommends mounting at gates or crossings where people slow down, or in corridors where people walk towards the camera and stay in frame for 2-3 seconds. Crowds cost captures as well. In the NPL study, on the most crowded deployment day, subjects shorter than 170 cm were recognised significantly less often than taller subjects, which the authors attributed to occlusion by other people.
Requirements depend on the use case. Access control needs a confident frontal view before the person reaches the barrier, whereas security monitoring can tolerate an angled view and looser thresholds. Distance changes the face in the image, too. A study of camera-to-subject distance showed that it changes facial configuration non-linearly. In their study, human viewers matching unfamiliar faces lost 28% accuracy on same-identity pairs when the photos were taken at different distances. That finding concerns human viewers matching photos. The authors recommend lower and upper bounds on camera-to-subject distance for passport photographs, to reduce one source of identification error.
What false positive rate to expect from cameras with facial recognition
No single false positive rate holds across deployments. The rate is set by the match threshold, the watchlist size, the image quality the site delivers and the population passing the camera, so any datasheet number is a measurement at conditions you have to check against your own. The NPL study of NEC NeoFace V4, using footage from police deployments in London and Cardiff, gives one reference point. At a face-match threshold of 0.6, the study reports a true positive identification rate of 89% at both watchlist sizes. The FPIR was about 0.017% (1 in 6,000) with a 10,000-image watchlist and about 0.002% (1 in 60,000) with 1,000 images. At a threshold of 0.64 or higher, there were no false positive identifications at all. Earlier NeoFace versions, averaged over four deployments, had reported an FPIR of about 0.1% (1 in 1,000), with watchlists of 2,000 to 4,000.
Why the datasheet number does not transfer
NIST’s report on demographic effects explains part of the gap. Most deployed systems run one fixed threshold that is not tuned to cameras, environment or demographics, while many academic results report miss rates at a fixed false positive rate, which hides how false positives move. NIST also found that randomly pairing impostors underestimates the false match rates that occur in practice. The same report excluded video surveillance imagery, so its results do not cover surveillance conditions. Across demographic groups, NIST found false positive rates often varying by factors of 10 to beyond 100. The hub covers those differentials in detail.
Gallery growth alone pushes accuracy down. In a 2025 survey’s experiment on the IJB-S surveillance benchmark, Rank-1 accuracy fell from 62.0% with 202 identities to 48.4% after 10,000 external impostors were added. The Bipartisan Policy Center notes that operational results can differ from NIST and DHS test results, and that no independent body publishes operational testing across diverse deployment environments. NIST’s conclusion follows: measure the operational algorithm on the operational image data. For the surveillance-specific reasons benchmarks degrade, see our article on CCTV face recognition production challenges.
The detector’s settings feed straight into recognition false positives. In the NPL study, relaxing face detection criteria found more faces and improved true recognition, but some of the extra faces were poorer quality and more likely to match falsely, which raised the FPIR. When heat caused cameras to fail and a replacement went in without the usual tuning, the faces it captured were smaller and less frontal. True recognition dropped until the detection settings were adjusted.
| Lever | Effect on false positives | Effect on misses |
|---|---|---|
| Raise the match threshold | Fall; none observed at 0.64+ in the NPL study | Rise, as thresholds trade one error for the other |
| Grow the watchlist or gallery | Rise, because more comparisons per passer-by | Rise, as gallery size degrades accuracy |
| Relax detection criteria | Rise from poorer-quality faces | Fall, as more faces are processed |
| Improve capture (size, light, angle) | Fewer poor-quality crops to mismatch | Fall |
Should face detection run on the camera or on a server?
Run detection where the latency budget and the model you need both fit. IntelliSee, a physical security vendor, gives these typical figures in its edge-versus-cloud briefing: 5-20 ms for edge inference, against 100-300 ms for cloud-routed inference before any application logic runs. The briefing also points out that the edge advantage comes from removing network and queue stages, not from faster per-frame inference.
On-camera inference keeps bandwidth and latency low, but the embedded chip limits model size, frame rate and the range of detection classes. The AXIS Face Detector analyses the uncompressed video feed on the camera. An on-premises appliance has far more compute and can serve dozens of feeds, at the cost of hardware to install and maintain. The same briefing puts INT8 quantisation on edge accelerators at a loss of typically 1-3 percentage points on standard benchmarks. It argues that sensor quality, lighting and training-data coverage usually matter more than that loss. Server capacity has limits too. In the NPL study, real-time operation on the servers used constrained the detection settings that could be applied. Live systems may also cap the faces or frames they process when crowds are dense.
The recognition models that follow detection are computationally heavy. For example, IResNet50 needs 12.62 GFLOPs, and detection and alignment add further cost. How accelerators handle that load is covered in what “accelerate” means for facial recognition hardware. Where the system goes on to match against enrolled people, the task chosen decides the gallery, threshold and legal classification of stored data. Those topics belong to facial recognition camera deployment and its legal framework.
Checklist before you trust a face capture point
Each item can be checked on site before go-live:
- Measure the pixels between the eyes at the capture point, on the stream the analytics actually read, against the software vendor’s minimum (for example 21 px for recognition in the Incoresoft manual, or 50 px in the Innovatrics guides).
- Confirm the camera tilt stays within the high-quality band (0-15° per Incoresoft) and that head angles stay within the vendor’s roll, pitch and yaw limits.
- Measure lux on faces in the zone against a target such as 150 lux, and remove light sources from the frame.
- Look at moving faces in backlit entrances under multi-exposure WDR, checking for ghosting and flicker.
- Check that the shutter is no slower than 1/100, the frame rate is at least 15 fps and compression is kept low.
- Record the match threshold and watchlist size, and measure false alerts at those values on site footage, not with the datasheet figure.
- Measure end-to-end latency from the frame reaching the camera to the alert, not just model inference time.
The checklist settles the camera side. It cannot tell you whether your detector and matcher hold up on your own population, crowds and light. Measurement on your operational footage answers that. TechnoLynx delivers that measurement, and the retuning of detection, thresholds and the edge-server split that follows, through Computer Vision R&D on production face pipelines. The question to settle first is which error costs you more at this door, a missed face or a false alert, because every threshold and placement decision above trades one against the other.
