Turnkey Face Recognition System Development

Developing a Face Recognition System: Where Accuracy Is Lost

Accuracy breaks not inside the model, but at the input. The camera looks down at the flow from above, backlight from a storefront overexposes half the frame, and in winter a hood and scarf are added. A stream that produces consistent results on a test set turns into a lottery at the site.

The cost of an error is measured not in percentages, but in incidents. At a checkpoint with thousands of passes per day, even fractions of a percent mean dozens of cases: a turnstile opens for the wrong person or turns away an employee who has used this door for six months. The first is a hole in the perimeter, the second is a queue and manual passes at reception.

That is why developing a face recognition system begins not with choosing a model, but with surveying installation points. An engineer records the camera height and angle, distance to the face, lighting scheme, and passage width, and assesses image quality during peak hours. After this, some points change configuration — optics, lighting, moving the camera to face level.

We configure comparison thresholds for the task: for biometric access control, the acceptable false positive rate is an order of magnitude stricter than for attendance tracking.

Even strong models in independent comparative tests NIST FRVT lose severalfold when the angle and lighting change — it is not the model that decides, but the combination of image quality, scenario, and threshold.

Below we break down how this is addressed at the design stage and what exactly we check before commissioning.

Implementation Effect: Response Speed, Accuracy, Rejections

Throughput is measured not by model accuracy on a test set, but by the number of people passing the control point per minute under peak load.

The system response time — from the face appearing in the frame to the passage command — is kept to fractions of a second, so a person walks without stopping, and multiple flows do not merge into a queue.

The match threshold is configured so that passage speed does not drop either during the morning peak or the evening departure.

Reducing errors is a managed balance between two classes: false acceptance of an outsider and false rejection of one's own.

Thresholds are selected for the scenario — checkpoint, barrier-free entrance, checkout — supplemented with liveness detection and revised based on logs, not by eye.

We focus on independent assessment methodologies such as NIST FRVT: the false positive rate drops by orders of magnitude, and manual checks by security are reduced severalfold.

We build fault tolerance in from day one. Recognition can run on the camera itself, events are buffered when communication is lost, and arrive at the server after it is restored.

Control nodes are redundant, and if a segment fails, the point switches to its standard backup mode — response time at the others does not increase.

We take metrics before and after: point throughput per minute, average response, false acceptance rate, recovery time after failure.

Operating Modes: Comparing Approaches and Limitations

The operating mode is determined by two questions: what exactly the system compares — a frame with one pre-known template or an entire database — and where computations run.

The answers determine the requirements for equipment at the site, the communication channel, and the permissible load on the facility.

Below are four combinations that are realistically chosen between at project start. They do not exclude each other: most often, detection and liveness detection are left at the site, while matching is moved to a secure environment.

At the start, we determine which modes are actually needed and test them under peak load — a queue at the turnstile, a flow of visitors during rush hour.

If a mode cannot withstand it, it is changed before launch: switching identification to verification or moving computations on-site is a configuration change, not a project rework.

Implementation Stages: From Conditions Audit to Handover

The order of work is structured so that each subsequent decision relies on measurements, not assumptions.

An error in the camera installation point or activation threshold surfaces during operation, when rework costs the most — therefore the audit and testing on live people happen before the system is connected to the access control loop.

1. Facility audit. We count passage scenarios: how many people per hour, through a security frame, turnstile, or open entrance, whether there is an exit flow. We separately look at illumination, installation height, angles, and glare from windows. The result is a diagram of camera points and installation requirements.
2. Equipment selection. Cameras, a compute unit for recognition, and access controllers are selected for the calculated flow, not according to the supplier's catalog. We check that the input frame provides sufficient face quality in motion.
3. Installation and calibration. We configure detection zones and cut off false positives from reflections, foreign objects, and movement in an adjacent corridor. We register reference images of employees according to a unified shooting procedure.
4. Threshold configuration. The match threshold, number of frames for confirmation, reaction to an unknown person, and opening delay are a balance between accepting one's own and falsely admitting an outsider. We fix the values together with the customer and save them as a configuration version.
5. Test scenarios. We run control passages: employees and people not entered in the database, glasses, headwear, low light, dense flow. We calculate the share of correct activations and the number of false ones — if there is a deviation, we return to thresholds rather than "tweaking" by eye.
6. Pilot operation. We launch at one point with an operator nearby, compare the event log with actual passages, and make adjustments based on real data.
7. Handover to operation. We provide documentation, staff action regulations, and shift training, move the system to monitoring, and support the first weeks.

After handover, the configuration remains manageable: any change to thresholds is versioned, and rollback to a working state takes minutes. We then develop the environment as the facility grows — adding points and scenarios without rebuilding the core.

Delivery Package: Diagrams, Configurations, Regulations

After acceptance, the customer retains not only a working environment, but also a set of documents that can be used to operate, expand, and hand the system over to another team — without reconstructing context from correspondence and developers' memory.

The package is formed in parallel with development, not written at the end: by acceptance, it describes the actual configuration, not the design one.

• Camera placement diagrams — installation points, overlap zones, working viewing angles, and light requirements so that recognition works in the flow, not on a test frame.
• System configurations — recognition profiles, similarity thresholds, zone lists, retention periods and depth for events and snapshots.
• Access policies — operator roles, separation by cameras and groups, logging of database queries and exports.
• Response regulations — operator actions upon activation, notification route, procedure for recording a false positive.
• Technical documentation — architecture description, deployment, update, and failure recovery instructions.
• Operator memos — typical actions and common failures, so a new employee can start a shift without a mentor.
• Acceptance protocol — test scenarios and accuracy metrics under which the system is considered delivered.

The package removes dependence on the contractor: expanding observation zones and changing operators proceed according to the document, not from memory.

Case: Recognition at a Production Facility Checkpoint

What It Was Before

The checkpoint had four turnstiles, a shift of about two thousand people, and street-level entry. Shooting conditions were difficult: backlight at sunrise, dust from the shop floor, winter breath vapor, and half the shift wearing hard hats, masks, and safety glasses.

The previous access control relied on cards: passes were handed over, and in low light security opened manually. Recognition accuracy on archived recordings did not exceed 82%, and at peak the entrance queue reached 10-12 people.

What Was Changed

Hikvision cameras were split across two angles — frontal and angled — with infrared illumination and exposure configured for backlight. An employee is entered into the database using a series of frames; a numeric template is stored, not a photograph.

The similarity threshold was selected on real shifts: it was more important not to reject one's own — liveness detection protects against substitution, cutting off a mask or phone screen.

The passage decision is made by a local controller, so a communication failure with the server does not stop the turnstile.

What Became

The share of confident confirmations from the first frame grew from 82% to 97% with the same shift composition, and average passage time decreased from 8 seconds to 2. Passage using someone else's pass was not recorded even once: every event is linked to a frame and a log entry.

The report on actual shift attendance is generated automatically, and the timesheet is no longer compiled manually. The scheme was then replicated to a second site — adjusted for different lighting and a different flow of people.

How Identification Differs from Verification in Practice

Verification answers one question: is this the person they claim to be. A frame is compared with a single template tied to a card, login, or document. The threshold is configured for the cost of an error: stricter at a checkpoint, softer for unlocking.

Identification searches for a match across the entire database without knowing exactly who is being checked — this is "one-to-many" search. Its accuracy depends on gallery quality: size, freshness, duplicates, and how much reference images resemble the real camera flow.

A database of tens of thousands of records and a database of a million are different requirements for indexes and different levels of false positives.

This also leads to a different cost of errors. For verification, false acceptance is critical: an employee does not pass, and the entrance queue grows.

For identification, a false match is more dangerous — the system finds a "similar" person and triggers an action on someone else's profile, so the threshold is raised and candidates are confirmed with a second factor.

The boundaries of applicability are set by the scenario. Access control, identity confirmation during issuance, app login — verification: the database is small and controlled.

Searching for a person in a video surveillance archive, an alert on a watchlist, flow analytics — identification, where it is not known in advance whether the person is in the database.

The mode is fixed before choosing a model and placing cameras: database requirements, thresholds, and the procedure for resolving disputed cases depend on it. An error here cannot be cured by configuration — it returns the project to data collection and labeling.

Technical Concerns: Light, Angle, Fault Tolerance

Engineering concerns come up before legal ones: will recognition withstand light from an opposite window, what to do with cameras already installed, where templates physically reside.

In what form are biometric templates stored?

Images are not saved — the database contains a numeric vector from which the face cannot be reconstructed. The template is tied to a person, not to a camera, so equipment replacement does not require rewriting the database. Access to the storage is separated, and requests to templates are logged.

Can the system operate in a closed environment, without external access?

Yes: detection, comparison, and storage are deployed on the customer's site and do not access external services. Model updates are brought on physical media and installed according to regulations, so the network remains isolated. This also removes the issue of transferring biometrics to third parties.

Will cameras already installed at the facility work?

Part of the fleet usually works: it is important that the stream is provided via an open protocol and that there is enough face detail in the recognition zone.

For the remaining points, we provide a scheme — where changing the angle or lens is enough, and where replacement is needed. We inventory before the start so as not to redo installation.

Let's Discuss the Task: What Data Is Needed for Assessment

Project assessment and the work plan rely on source data, not general wording. Below is what we discuss during the task discussion; the full set is not required, and we close gaps during the facility survey.

• Scenario and decision point: where the system compares a face — checkpoint, checkout, terminal — and what happens on a match and on a rejection.
• Flow volume: number of video sources, recognitions per day, peak hours, simultaneous events in frame.
• Image quality: angles, illumination, motion in frame, masks and headwear, sample recordings.
• Accuracy requirements: what is more critical — not missing one's own or not admitting an outsider, acceptable false positive rate.
• Infrastructure and data: own servers or a closed environment, rules for storing biometric templates, deletion periods.
• Integrations: where we send the result — access control, the customer's accounting system, security notification — and which interfaces already exist.
• Scope and timelines: subject consents, compliance owner, fixed launch date, readiness for phased implementation.

After the conversation, we return with a project assessment: scope and stages of work, requirements for the sample for configuration and testing, and the implementation order — from a pilot area to the full environment.

If data is insufficient, we will suggest how to collect it in a limited area and confirm accuracy before scaling.