Face detection locates a face; face capture saves a usable image; face verification compares it with one claimed identity; identification searches a reference set. Choose the required output before buying. A face thumbnail or person alert does not establish identity recognition, and a successful demonstration does not establish the error rate at your entrance.
Match the function to the reader's task
| Function | Typical output | What it does not establish |
|---|---|---|
| Detection | A face location or face event | The person's name or a usable identification image |
| Capture | A saved face crop linked to a frame and time | A comparison against enrolled identities |
| Verification, 1:1 | Match or no match against a claimed identity | Who an unknown person is |
| Identification, 1:N | A candidate or candidates from a reference set | That the candidate is certainly the person in the image |
If a reviewer needs to find an entrance clip, face events or person detection may be sufficient. If access requires confirming a badge holder, the question is verification. Finding a person without a claimed identity is identification. Ask the supplier to name the exact function and return data instead of accepting “AI face camera” as a specification.
NIST's technical testimony distinguishes detection, verification and identification, and explains false-positive and false-negative errors and their application-dependent consequences. These definitions do not certify any camera system or establish QuarkView recognition support.
Follow the chain from image to decision
- Detect and capture: the camera or software locates a face and selects an image. Keep the time and original-frame association so a reviewer can inspect the surrounding event.
- Quality check: the system may reject unsuitable images. Establish whether rejection appears as “no face,” “poor quality” or “no match”; otherwise an imaging failure can be mistaken for an identity result.
- Template and comparison: where recognition is supported, software derives a representation and compares it with enrolled references. Specify whether processing occurs on the camera, recorder or a separate server.
- Threshold and result: the matching score is evaluated against a configured decision threshold. Ask what the score means; do not describe a vendor score as a probability unless its documentation establishes that interpretation.
- Operator or access action: the receiving application presents a candidate or sends an access event. Test authorization, time, audit records and the response to uncertain or missing results.
Request the camera, analytic software, licensing, reference-set limit, enrollment tool, supported client and integration interface in writing. Receiving ordinary video on an NVR does not prove that face metadata, identity search or access events reach it. Specify who maintains references and who may change thresholds.
Create a capture view that suits normal movement
Inspect the saved image, not only the live preview. Note the face size in pixels at the near and far points of the route, head direction, camera elevation, focus and motion. A wide, high-mounted lobby overview can be useful for context while showing mostly the tops of heads; a separate entrance capture view can serve the face task.
| Condition | Possible failure | Practical check |
|---|---|---|
| Backlit glass door | Face detail is too dark or clipped | Inspect morning and evening saved crops; compare position and lighting changes |
| Normal walking or turning | Blur, profile view or no accepted frame | Use normal passage speed, not only a person standing for the camera |
| Hats, glasses or masks | Occluded features or increased rejections | Test permitted everyday clothing and record rejected images separately |
| Different heights and mobility needs | View misses or steeply angles some faces | Check the full intended route and capture positions |
| Night illumination | Different appearance or insufficient detail | Compare actual night captures with the enrolled reference conditions |
NIST's video-image study illustrates why lower-quality video faces can undermine matching. Its historical experimental results are not accuracy predictions for your installation. Ask for the chosen software's image requirements and test against them; there is no universal megapixel label that guarantees useful recognition.
Example: separate entrance search from access verification
Design example, not a customer deployment: assume an office with one controlled entrance and a reviewer who needs to find entry incidents. Start with an overview recording plus a verified face-capture or person-event workflow, linked by synchronized time. Do not create an identity database merely to search clips.
If the separately approved task is verification of enrolled staff, assume a claimed identity supplied by a badge, a compatible recognition service and an access controller. Document their interfaces and test the face comparison against that claim. Include a badge/PIN or staffed alternative. No exact camera height, matching threshold or accuracy is specified here: those require the chosen product's instructions and trials with the intended people and entrance.
Evaluate errors with the right denominator
Split imaging failures from comparison failures. For 1:1 verification, count genuine attempts rejected and non-matching attempts accepted separately. For 1:N identification, count enrolled probes that miss the correct identity, enrolled probes assigned to a wrong person, and unknown probes that return an accepted identity. Record ambiguous results and no-face/quality rejections rather than dropping them from the report.
Arithmetic example only: assume 200 authorised genuine verification attempts, of which 12 fail to match: the observed genuine-attempt rejection proportion is 12/200 = 6%. Separately assume 300 deliberately non-matching attempts, with 3 accepted: the observed false-accept proportion is 3/300 = 1%. These invented counts illustrate reporting, not a product result, a standard test or an acceptable security target. State whether the genuine denominator includes capture failures. Repeated attempts from a few people are not an independent population sample.
- Freeze software version, threshold, reference-set size and enrollment images. Obtain the necessary authority for participating people and test data.
- Test normal entrants across actual lighting, movement and permitted clothing. Include both enrolled and non-enrolled participants where identification is evaluated.
- Keep an attempt log with ground truth, saved-image reference, quality outcome, score/result and final operator decision. Avoid an undifferentiated “accuracy” percentage.
- Review errors by condition and intended user group where appropriate and lawful. A strong overall result can hide poor performance under one lighting condition or for some users.
- Repeat after a threshold change using comparable trials. A stricter acceptance threshold can reduce wrong matches while increasing missed genuine matches; choose it for the consequences of both errors.
- Exercise unknown persons, duplicate/outdated enrollment, revoked access, lost server connectivity and disputed matches. Confirm the alternative process works and that an operator can correct a record.
A small trial is a commissioning screen, not proof of a rare-error rate. Zero false accepts in a short demo does not establish zero risk. If access security matters, separately evaluate presentation-attack controls for photos or screens using the chosen system's documented capabilities; identity comparison alone does not establish liveness.
Treat reference data as an operational responsibility
Document images, templates, event metadata and access logs separately: where they reside, who can enroll/search/export, how they are protected and how deletion propagates to servers, devices and backup policies. Test revocation and deletion, including reference copies outside the main interface. Limit a candidate alert's visibility to the people who need to review it; retain the review outcome and correction history where required.
For deployments under the UK GDPR, ICO biometric guidance requires a lawful basis and a separate condition for special-category biometric processing. Consent, where relied on, must provide genuine choice and an appropriate alternative; walking into a camera view is not consent to recognition. For UK worker identification, ICO workplace guidance requires a DPIA before processing and discusses alternatives without disadvantage. These are UK-specific requirements, not a worldwide permission to deploy.
Detection without an identity comparison can still involve personal images and records; decide the applicable controls from actual processing, not the feature name. Send the needed function, entrance conditions and existing software with a project inquiry. Compare person detection when the goal is an event rather than identity matching.