Face detection locates a possible face within an image. Face recognition compares characteristics to verify a claimed identity or search for candidates in a gallery. These are different tasks with distinct inputs, outputs and testing criteria. Drawing a rectangle around a face does not identify the person.
For a business, the distinction changes the entire specification: which data is needed, who administers it, which error is measured and which action may follow. Saying only that the company wants an AI camera leaves undefined the mechanism that affects people and organisational processes.
This guide uses fictional labels and original diagrams without real faces, identities or biometric templates in its demonstrations. Photographs illustrate storage and infrastructure administration, not a biometric installation delivered by WebHat. The person in the contextual photograph is neither enrolled nor analysed within the article.

What is the difference between face detection and face recognition?
The question asked determines the type of output
A detector searches for regions corresponding to the face class. A verification system compares a sample with the reference associated with a claimed identity. An identification system searches a collection of references for potential matches. These functions can appear within one product without becoming the same operation.
Within the map of types of artificial intelligence, image analysis is a family of tasks rather than general permission to identify people. Write the requirement around the actual question and necessary output instead of a commercial label combining all these functions.
Three different questions, three different outputs
- Detection
Is there a region that appears to contain a face? → Coordinates, not a person's name.
- 1:1 verification
Does the sample match the reference for the claimed identity? → Comparison result.
- 1:N identification
Which gallery references are candidates for the sample? → Candidates or no accepted result.
At the initial discussion, request an example input, expected output and subsequent action. If the required result is simply checking image framing, searching a personal database would introduce an additional function. Assess that extension separately rather than activating it implicitly because a technical library includes it.
What does a face detector produce?
Coordinates and landmarks are not a person's name
OpenCV documentation distinguishes the detector from the recognition component. The former can return regions and facial landmarks; the latter constructs and compares representations. Implementations have their own outputs and conventions. A point indicating an eye position supports geometric processing but does not confirm personal identity.
A detection result can support framing or capture-quality checks. The application also needs to handle no region, several regions or an incorrect proposal. Do not assume the first returned region automatically belongs to the person intended by the user. The selection rule must match the stated task. Specify the response to each output: a message, another capture or review. Explain the observed problem without declaring someone unauthorised when only framing was checked. A capture problem should not be communicated as an identity conclusion.
Compared with other business computer vision applications, the analysed class differs, but separating prediction from action remains useful. Displaying a region for review has a different effect from saving an identity or granting access. The specification explicitly describes the boundary between these effects.
How does 1:1 face verification work?
The claimed identity determines the reference
Verification asks whether a sample matches the reference for an already indicated profile. It does not ask for an unrestricted search across every profile. In our diagram, A17 is simply a fictional reference label. There is no concealed real person behind this demonstration or an actual comparison output being displayed.
Fictional labels without real faces or identities
- 1:1 path
Sample X → claimed reference A17 → comparison → match or inconclusive result.
- 1:N path
Sample X → gallery A17 / B24 / C31 → search → candidates or none above threshold.
The comparison assumes the reference was correctly associated with the profile. If enrolment linked an image to the wrong profile, a strong comparison algorithm does not independently repair that record error. The project must define reference provenance, who approves the association and how the record can be corrected.
An inconclusive result needs a defined procedure rather than an automatic assumption about the person. The interface may request an acceptable capture or direct the case to an approved alternative method. That procedure belongs to the assessed project, and technical reasons are communicated without exposing other users' references.
How does 1:N face identification differ?
A candidate list is a search result
Identification compares a sample with a gallery of references. The result may contain ranked candidates or no match meeting the specified criterion. The profile at the top of a list does not automatically become confirmed identity: ranking describes the relationship between scores returned by that particular search.
NIST's identification evaluation distinguishes searches with a genuine reference in the gallery from searches without one. That distinction matters to testing. A demonstration using only people known to be enrolled has not thereby evaluated the system's ability to reject people who are absent from the gallery.
Document gallery contents, enrolment conditions, updates and the situation where no result is accepted. Do not automatically add references from publicly available photographs. Rights, purpose and data requirements are assessed before collection, separately from the technical ability to process a file. Public availability is not a project specification.
Which stages connect the camera to a comparison result?
Capture, processing and application policy have separate responsibilities
A workflow may include capture, quality checking, detection, alignment, representation building and comparison. The actual sequence depends on the component. Transform data consistently with the selected model and retain the processing version alongside the evaluated configuration. Do not mix representations from incompatible models merely because their lengths happen to match.
One application can fail at different stages
- Capture
Incomplete image, unsuitable lighting or unaccepted source.
- Detection
Missed face or region that contains no face.
- Comparison
Incorrect association or rejection of a genuine pair.
- Decision
Output treated as access authority without checking policy.
Some components use convolutional neural networks, but the architecture name does not define the whole system's behaviour. Input, training, representation and evaluation protocol matter together. Selecting a model family is a design stage, not an acceptance-test result or evidence that the application meets its operating requirement.
During integration, separate model version from operational-rule version. Changing a threshold or gallery can alter outputs without retraining. Change records should support reproducing the tested configuration and identifying which component produced a decision, within the agreed retention limits. An unchanged model file does not mean the whole system is unchanged. Define service-unavailability handling: do not apply an old response to a new sample. Distinguish an actual result from no result and check its association with the current request. These conditions can be tested with fictional labels before introducing real data.
How should we read FMR, FNMR and search errors?
The denominator matters as much as the percentage
In NIST terminology, FMR concerns false matches in different-person comparisons, while FNMR concerns false non-matches in same-person comparisons. These measures answer different questions. One percentage generically labelled accuracy may conceal the error type that matters to the process, particularly when the consequences of the two errors differ.
Two illustrative rates with different denominators
- Different-person pairs
3 false matches / 1,000 different-person comparisons = 0.3% FMR.
- Genuine pairs
8 false non-matches / 200 same-person comparisons = 4% FNMR.
Our example is purely arithmetic. It describes no actual image dataset and recommends no threshold. For identification, define search-level errors, candidate criteria and gallery size separately. Do not transfer a pair-comparison rate to a complete search system without the corresponding evaluation. The measurement unit must remain explicit.
A test report also retains case counts, capture conditions, cases rejected before comparison and the procedure for inconclusive outputs. Compare configurations under the same protocol. Removing difficult images from a report solely to improve its percentage would change the measured question rather than demonstrate an application improvement. Link observations to the component and actual effect, not just a generic error label. For each correction, define the retest and acceptance criterion. Reducing one error may change other outputs, so repeat the full relevant protocol.
Why do lighting, camera and evaluated population matter?
Input quality belongs to the system, not just the photograph
A test should reproduce defined operating situations: distance, position, illumination, movement and capture method. A well-framed file result does not automatically describe a video workflow under different conditions. Check response time including processing and communication rather than timing only an isolated component. Specify which moment starts and ends the measurement.
NIST documents error variations associated with image quality and evaluated groups. For a particular project, justify the chosen test population and conditions. Supplement an aggregate result with relevant case analysis without turning observed differences into assumptions about people's character or behaviour. The assessment concerns system performance under a defined protocol.
The interface should offer actionable instructions and an alternative route when a sample cannot be processed appropriately. Repeating the same operation indefinitely is not a support procedure. Define who receives the case and which technical information they may see, without implicit access to every stored image and reference.
What should we assess about personal data and purpose?
Detecting a region does not remove requirements concerning the original image
EDPB explains that images do not automatically constitute special-category biometric processing: specific technical processing and unique-identification purpose matter. Nevertheless, an image containing identifiable people can remain personal data. The absence of a name in detector output does not automatically make the entire workflow unrelated to people.
Our proposed assessment documents purpose, necessity, alternatives, applicable basis, data categories and their journey. Evaluate biometric and AI requirements for the particular use with the responsible specialist. 1:1 verification and remote identification do not automatically receive the same classification, and a technical distinction is not general authorisation to deploy.
The guide to data protection in an AI application helps structure discussion of access, processing and retention. For this kind of project, do not begin by copying an existing image database. Establish what information is necessary and who may decide its use before considering technical access. Our proposed project record inventories capture, representation, profile association and operational logs separately, with destination, access and deletion arrangements. A single delete-photo option does not describe every copy and derived record; check the actual approved data journey.
Why is a match insufficient for authentication?
Sample source and account permissions are checked separately
NIST SP 800-63B treats biometric comparison, presentation-attack detection and authentication as distinct aspects within its digital-identity framework. Biometric characteristics are not secrets in the same sense as a password. A similarity score alone does not cover sample provenance or every impersonation attempt. Those properties require their own assessment.
The discussion of deepfakes and identity verification in business communications complements this distinction. A material's convincing appearance grants no authority. In application design, check the connection between session, accepted source, technical output and requested operation without publishing bypass procedures. The control is tied to the effect being requested.
A possible match does not independently activate a suspended account's permissions or approve every action. Application policy remains enforced by the component producing the effect. Logs retain operational outcomes and necessary configuration evidence without unnecessarily duplicating sensitive images or templates across every monitoring system. More copies do not automatically create better accountability.

How should a project be prepared before choosing technology?
The first useful deliverable is a clear requirement rather than a spectacular demonstration. Describe the problem, required output and alternative that might solve the same need with less data. Assessment may show that a capture rule, document check or access method without face comparison is sufficient for the intended purpose.
Before selecting a technical component
- Purpose
Which problem is being solved and what output must the system produce?
- Alternative
Can the purpose be achieved with less personal data?
- Assessment
Which legal, operational and security requirements apply to this situation?
- Test
Which errors, capture conditions and exception procedures are checked?
- Operations
Who owns access, retention, deletion and changes?
If assessment justifies a technical stage, define test criteria and boundaries before selecting data. Separate a label-based demonstration from an experiment with real data, which has its own requirements. Establish ownership, acceptable outcomes, exception handling and conditions that stop progression or require revision of the specification. These decisions precede collection.
The principles of aligning AI behaviour with business rules help here: objective, output and permissions must be verifiable. Do not control an unwanted function solely through a promise that operators will not use it. Design limits the data and operations that are actually available to each role.
How does WebHat approach specification and integration?
In custom software development, start with the company's process and separate the functional requirement from the AI component. For a biometric subject, specialist assessment precedes potential implementation. This guide and its photographs are not presented as evidence of a biometric system delivered to a customer.
Within custom business digitalisation, we can organise analysis of data, roles, interfaces and integrations with defined test outputs and responsibilities. The proposal specifies what is included: analysis, prototype, integration or operations. A demonstrative prototype is not described as an accepted production system and does not replace assessment of the actual use.
The initial discussion needs only a problem description, involved applications and required outcome. Do not send customer photographs or reference databases to explain the idea. Together we can construct a fictional-label workflow, then establish the checks and specialists needed before accessing real data. Keep the design conversation separate from data collection.
Frequently asked questions about face detection and recognition
Does a rectangle around a face mean the person has been identified?
No. The rectangle indicates a region proposed by a detector. Identification requires other data and comparison operations. The specification and interface distinguish the detected region from confirmed identity and from permissions the application may grant. These outputs should not share a misleading success label.
Does 1:1 verification automatically search every profile?
That is not the question posed by 1:1 verification. It compares a sample with the claimed identity's reference. A gallery search is a distinct operation requiring its own specification, data and assessment rather than implicit activation. The available component does not define the permitted business purpose.
Is the first candidate certainly the person being sought?
List position alone does not confirm identity. The protocol establishes acceptance criteria, the situation without a genuine reference and the review procedure. A system that always returns a top result must also be tested on cases where the person is absent from the gallery.
Does removing a name make a processed image cease to be personal data?
Removing the name does not automatically resolve direct or indirect identifiability. Assess the image, representations, links to other information and purpose. The technical distinction between detection and biometrics does not remove assessment of the complete data journey. Consider what can actually be linked or inferred.
Can the article's photographs be used in a recognition demonstration?
We do not use them that way. They are contextual photographs with documented rights for the described editorial use. Diagrams use fictional labels only. Testing real people and biometric data is a separate activity whose requirements are established before collection, rather than inferred from a stock-photo licence.
What should be prepared for the first project discussion?
Describe the purpose, desired output, existing alternative and subsequent action. Add the applications and roles involved, not people's biometric data. This information allows the requirement and necessary assessment to be scoped before selecting a technical component. The first discussion can use fictional records rather than personal images.