Face SDK Architecture
The article provides a detailed overview of Regula Face SDK architecture.
Basic Architecture
The basic version of Regula Face SDK covers only the Face Detection and Face Comparison capabilities. It includes a Web Service and the Core library:
The Web Service operates via an HTTP/S protocol. It receives a request and invokes the Core library that processes this request. When the Core library returns the results, they are sent back by the Web Service.
To use the basic capabilities, you need to send an image and processing parameters via API. Here is the OpenAPI specification.
Info
For the Face Detection, Face Comparison, and Face Identification features the following image file formats are supported: BMP, PNG, JPG, JPEG, TIF (TIFF), WebP, JP2.
To simplify the integration and further maintenance, we supply two additional components: Mobile SDK and API clients.
Web API
Сlients wrap the Web Service API and provide interfaces for popular programming languages.
There are four clients:
- JavaScript client for the browser and node.js based on axios
- Java client compatible with jvm and Android
- Python 3.5+ client
- C# client for .NET & .NET Core
Mobile SDK
The Mobile SDK provides a framework to interact with the Face SDK Web Service in a way that is more familiar for a mobile developer. This framework can be embedded into your mobile application to speed up and simplify the development. There are two native mobile SDK frameworks for Android and iOS and several cross-platform ones. You can find more information in the Mobile SDK section.
While the Mobile SDK integrates with the Web Service out of the box, there's also an option to use it without relying on the Service but performing the operation on the client side:
For this, you'll need to configure the SDK differently, refer to the Client-Side Match page for details.
Liveness Architecture
The Liveness Assessment module requires additional backend and end-user components.
The additional backend components for using Liveness Assessment are the following:
- Database
- Data Storage
The Database is required for storing the metadata of the liveness check, for example, transaction ID, timestamp, result, etc.
The Data Storage is used to save a selfie, video, and other binary data that are collected to carry out a check.
Both the Data Storage and Database can be allocated in a cloud as a SaaS offering. The Face SDK can also be installed in the cloud.
Info
Here is detailed information about the supported database types and data storage types.
To collect the biometric data on the end-user side, two components are provided:
As previously mentioned, the Mobile SDK provides a framework to embed into your mobile application.
The Web Component lets you add automatic capture of a user's selfie and liveness check to your web site.
Info
The liveness feature for both Web Component and Mobile SDK offers a variety of customization capabilities, which can be observed on the UI Customization page.
Security considerations
For security reasons, the Liveness Assessment procedure requires a TLS handshake between the client and the server. It is not allowed to submit data for a liveness check directly onto the server via the Web API as we can not validate if this data is compromised or not. Therefore, the Mobile SDK or Web Component must be used.
Consistency models
The liveness check feature operates with eventual consistency by default. This means that when you submit a request and receive a response, the associated data (like the selfie or video used for the check) is saved asynchronously—saving the data happens after the response is sent. This approach prioritizes quick response times for the client application. However, in this case, a requested file may not be available immediately, and you may experience a short delay. To ensure that you receive the file, use polling with a recommended timeout of 3 seconds.
If you prefer a different workflow, you can switch to strong consistency. With strong consistency, data is always saved before the response is sent and becomes available immediately. Keep in mind that this option may lead to slower response times for the client application.
To define the consistency model, refer to the Configuration guide.
Cleanup
For Liveness Assessment, transaction data is stored. The HouseKeeper component helps maintain the health of the system by automatically managing and cleaning up outdated data. For more details, see Cleaning Up Data.
Identification Architecture
Setup for using the Face Identification module is even more complex and requires the following components:
- Database to store metadata and relations
- Data Storage to keep binary data
- Milvus database as a vector storage
Info
Here is detailed information about the supported database types and data storage types.
To understand these requirements, let's explore how the feature works. There are two main parts of the identification process:
- Adding a person to a database
- Searching a person
Adding a person
The step-by-step adding a person procedure looks like that:
1. Your application sends a request that contains the person's name, photo, and, optionally, some metadata.
2. The Web Service saves the photo to S3-compatible Data Storage. The name and metadata are saved to an SQL Database:
3. The photo is passed to the Core library which calculates a descriptor (a mathematical representation of a face image that captures its distinctive features) using the photo:
4. Then the descriptor is saved to the Milvus database.
5. The Web Service returns the ID of the created person:
Adding a person using a link
The step-by-step procedure for adding a person using a link is as follows:
1. Your application provides a link to an external source as input, which is then saved in the database.
2. The backend retrieves the photo from the provided external source.
3. The Core library processes the photo and calculates a descriptor:
4. Once the descriptor is calculated, the photo is deleted, and the descriptor is added to the Milvus database.
5. The Web Service returns the ID of the created person:
Searching a person
Searching takes the following steps:
1. Your application sends a request that contains a photo only.
2. The Core library calculates the corresponding descriptor:
3. The Face SDK sends a request with this descriptor to the Milvus Database.
4. The Milvus database carries out a search and returns a list of similar persons:
5. The Web Service extracts corresponding names and metadata from SQL and photos from the S3-compatible storage.
6. Finally, the Web Service sends back a response with the found data:
Cleanup
For Face Identification, data on registered persons is stored. The HouseKeeper component helps maintain the health of the system by automatically managing and cleaning up outdated data. For more details, see Cleaning Up Data.
Next Steps
- To find the Face SDK installation guides for different configurations, navigate to the Installation page.
- The detailed instructions on how to use the Face SDK modules can be found in the Usage section.