Development of a face identification system (Face Identification, 1:N)

Why face identification in a live stream produces false positives

The face identification pipeline breaks not at the comparison stage, but earlier — at the frame. Capture quality in a live stream is determined by three things: light, movement, and angle.

A person walks through a checkpoint without stopping, a window behind them creates backlight, they turn their head 30–40 degrees — and a blurred frame with an overexposed background enters the recognition module.

Then the arithmetic on vectors begins. A blurred frame reduces similarity to the "correct" reference template, but sometimes increases it to someone else's: the interference blurs precisely the differences that distinguish people.

The tracking algorithm loses the face for several consecutive frames, merges it with a neighboring passerby — and the decision is made based on a garbage fragment.

The temptation is obvious: lower the matching threshold so that "authorized" people pass without delays. This is exactly what generates false positives — passage using someone else's face or denial to a person who is legitimately in the database.

A separate cause is an outdated reference template database: a single photo from an old pass, taken face-on under different lighting, stops resembling a person wearing glasses and with a changed beard.

At the facility entrance this is immediately visible: employees wait at the turnstile, security returns to manual mode, some people stop using biometrics and take out a card — that is, the system formally works, but it does not handle the flow.

We break down how this is addressed: from capture setup and thresholds to the regulation for updating reference templates.

What changes after implementation: speed, denials, load

The effect of implementation is measured not by a demonstration on a single volunteer, but by four values on a live stream: denial rate, time for one person to pass, behavior under peak load, and volume of manual review.

We measure them before launch and repeat them on the same scenario after a month of operation — otherwise the numbers are not comparable.

The denial rate is a balance between false accepts and false rejects, and the threshold is selected for the task, not taken by default.

We choose the model based on independent accuracy measurements, for example NIST FRVT: at access control, the false rejection rate goes from 8–10% to 1–2%, while false accepts remain within the acceptable band for the facility.

Throughput increases without replacing cameras or access points: one lane serves up to 20–30 people per minute, because the decision is made in fractions of a second and does not require stopping in front of a screen.

Under peak load, when there are three times as many people as usual, the queue does not grow: requests go into parallel processing, and during the decline resources return to the baseline profile — there is no overpayment for idle time.

Manual review ceases to be part of the process. The operator sees only disputed cases — their share in a typical stream is measured in single-digit percentages, the rest passes without human involvement, and the event log remains for incident investigation.

Face identification modes: 1:N, 1:1, and access control

A mode is not a property of the algorithm, but a formulation of the task. 1:1 verification compares the presented face with a single reference template: an employee taps a card or enters a code, and the system confirms the match.

It is difficult to spoof such a scenario, so the triggering threshold here is set stricter and yields a minimum of false accepts.

1:N face identification works across the entire gallery and without a hint — accuracy depends on the size of the database, the quality of reference templates, and the input angles.

Access control is not a separate algorithm, but a layer on top of 1:N: the system does not just find a match, but makes a decision according to rules and writes the event to the log.

How it is chosen at a facility

Modes are almost always combined: 1:1 for critical operations, 1:N for the stream, and access rules on top of them.

What exactly to deploy and with which thresholds is decided based on the number of people in the database, the quality of input frames, and the consequences of a false accept — we work through this at the design stage.

Stages of implementing a recognition system: from audit to acceptance

The implementation stages are structured so that each step ends with an artifact that is checked before moving to the next. A discrepancy in data or in the placement plan is identified at an early stage, when a correction takes hours rather than weeks of rework.

1. Infrastructure audit. We record what already exists at the facility: cameras and their angles, lighting at different times of day, communication channels, available computing resources. The output is a report with bottlenecks and a list of replacements.
2. Placement plan. Installation points, overlap zones, frame requirements — face angle, minimum size. We agree before installation: moving a camera after launch is more expensive than calculating it in advance.
3. Reference template database. Collection, labeling, deduplication of records, and rejection of unusable frames. We check that a person is represented by several frames — otherwise the comparison is wrong.
4. Pilot launch. The system operates in a limited environment: one zone or one stream. We take metrics on live traffic, not on a test sample.
5. Threshold calibration. We select values for the task: where it is more important not to reject a person, where it is more important not to let in someone else. The protocol with justification remains with the customer.
6. Acceptance by metrics. A joint run through agreed scenarios, including communication loss and restart, comparison with target values, documentation handover, and personnel training.

After handover, a retraining loop remains: quality improves on new data without re-implementation.

Delivery package: configurations, plans, regulations, documentation

The delivery package is what remains with the customer after handover: not only a working system, but also materials by which it can be operated and developed without us.

We write documentation for a specific installation, not from a template: it contains the real roles, segment addresses, and parameter values of your environment.

• Working configurations — search parameters (matching threshold, queue size, deduplication rules) are exported to a repository and versioned: reverting to the previous set takes minutes.
• Access policies — role separation: who adds to the reference template gallery, who starts a search, who works with the log; rules and grounds are described for each level.
• Placement plans — camera installation plans, coverage and overlap zones, heights and viewing angles, communication and power channels, binding to the floor plan.
• Operations regulation — operator actions when recognition degrades, a channel fails, and during scheduled works, frequency of checks, and areas of responsibility.
• Instructions for the operations service — step-by-step scenarios: registering a new employee, updating a reference template, investigating a false positive.
• Integration documentation — exchange methods, request and response formats, error codes, and load limits on adjacent systems.
• Biometric handling — where and in what form templates are stored, how they are protected, retention periods, and the procedure for deletion on request.

We coordinate the package with your services before final handover, so by launch time operations already has verified instructions.

Case study: how the false positive rate was reduced at a facility

The facility is a checkpoint with a dense flow: several thousand people pass through it per hour during the morning peak.

Identification was launched in 1:N mode using a single archived photo from the personnel file, while frames were taken from the general stream of Hikvision surveillance cameras.

At the start, a look-alike candidate appeared in almost every fortieth event, and the operator confirmed each match manually.

The recognition denial rate — when a person is in the database but the system does not find them — stayed around 6%, and the entrance queue grew faster than the shift could react.

What was restructured in capture

We changed not the matching threshold, but the frame quality: the entrance camera was moved to a separate calibrated zone with a frontal angle and short exposure so the face would not blur in motion.

Capture was tied to the moment when a person slows down before the turnstile — suitable frames instead of random ones began entering the comparison.

Reference templates were rebuilt: instead of one archived photo — a set of 5–8 frames from different angles and lighting, without small or blurred ones. The template was calculated from the entire set, so evening backlight and head turns stopped being a cause of denial.

What the metrics became

On the control sample, the false positive rate fell from 1 in 40 to 1 in 250 events, recognition denials — from 6% to 1.5%, and the correct candidate appearing in the first line of the list grew from 82% to 97%.

Passage through the turnstile decreased from 4–6 seconds to 1–2, and the operator returned to reviewing exceptions instead of manually processing every match.

What to do if a recognition system is already deployed

First we determine exactly where quality is lost: at the input (angle, lighting, frame resolution), in the reference template gallery, or in the comparison logic.

In a running environment, it is often not the algorithm but the capture conditions that are at fault — so we start by measuring each channel: the false accept rate and false positive rate separately.

Keep the core and tune it. Re-capture reference templates, clean the gallery of duplicates and outdated records, select the comparison threshold for the task (stricter for accepts or for false positives), calibrate detection and illumination zones. This branch takes days, does not require stopping the facility, and often removes most errors.

Rebuild the capture setup. We change what comes before recognition: camera installation points for the required angle, illumination, and the compute node closer to the camera so the stream does not depend on the communication channel.

The core remains the same; what changes is the quality of the input frame — and that is exactly what determines the result in 1:N mode.

Replace the recognition core without downtime. A new engine is brought up alongside (VisionLabs or another current core), both receive the same stream and compute in parallel. We compare outputs on real events, then migrate cameras in groups, preserving one-step rollback.

Compatibility with the existing system is provided by an adapter: events and reference templates remain in their current form and format, and only the comparison module changes.

Partial replacement is also possible — the new core on one group of facilities, the previous one on the rest, until enough error statistics are accumulated.

Common concerns: capture quality, privacy, load

Engineers and security services accumulate the same set of questions about a face identification system: how it will behave under non-standard conditions and what exactly it stores.

We work through them before the start — on a prototype tested on your frames, not on selected demonstration ones.

How are reference templates stored and what goes into the database?

What goes into the database is not photographs, but mathematical templates: the original image cannot be reconstructed from them.

Reference templates are stored in a separate encrypted environment, keys are kept outside the database, access is granted to the service by roles, and every access is recorded in the log with a justification.

Data protection is built so that exporting a template outside without your involvement is technically impossible.

What changes when the database grows to tens of thousands of people?

As the database grows, the share of false matches also grows, so a single threshold is not enough: we work with a pair of metrics — false matches versus false accepts — tuning the balance for your scenario.

Sharding the database by department, preliminary filtering by metadata, and multi-stage checking help: first a narrow subset, then full comparison. We distribute the load across several nodes, so response time under peak streams remains within the limits set during design.

Let's discuss the task: we'll select an operating mode and come back with a plan

So that the work estimate is based on facts, not assumptions, what you already have is enough to start. Describe the task in your own words — we will come back with clarifying questions and a preliminary implementation plan.

What significantly speeds up moving to an estimate and timeline:

• Scenario: where exactly face identification is needed — a checkpoint, video archive analysis, a mobile application, or photo search.
• Gallery size: how many people are in the database now and what growth it is designed for.
• Stream: number of cameras or capture points, simultaneous connections, operating mode — real-time or batch processing.
• Material quality: angles, lighting, people movement, whether there are ready-made images for a validation set.
• Accuracy requirements: what false positive rate you consider acceptable and what should happen in a disputed match.
• Integrations and environment: turnstiles, HR system, notifications, where biometric data is permitted to be stored and processed.

Our next step: we review the source data, ask questions about disputed points, and come back with a work estimate and a stage-by-stage implementation plan — with responsibility boundaries, quality checkpoints, and rollback options. Then you decide which stage to start from.