Glossary#
Term | Definition |
---|---|
Bestshot | The frame of the video stream in which the face is captured in the best angle for further use in a face recognition system |
Bbox | A rectangle that bounds the image space with a detected face |
Intersection Over Union (IOU) | Parameter determines the coefficient of intersection of two detections |
JSON | A text-based data exchange format based on JavaScript |
Liveness | Software method that enables you to confirm whether a person in one or more images is "real" or a fraudster using a fake ID (printed face photo, video, paper or 3D mask) |
MessagePack (MsgPack) | A fast and compact binary serialization format for data exchange, a more efficient alternative to JSON |
Attributes | Gender and age of a person determined automatically by the system |
Detection | Actions to find areas of the image containing faces |
Spoofing attack | Substitution of a real person for a fake image (for example, a photograph) to deceive the system |
Introduction#
This document contains information about VisionLabs LUNA KIOSK and describes how the components work.
VisionLabs LUNA KIOSK (hereinafter referred to as System) is a set of libraries that provide the possibility of realizing real-time operation to perform face detection in a frame, check the vitality of a person and transfer data to an external system.
The System is designed for:
- receiving and processing a color video stream from a video recording device,
- checking the image quality,
- selecting the bestshot,
- face detection by machine calculation method on two images,
- checking the presented image by Liveness-algorithms,
- protection against image spoofing by depth map analysis,
- subsequent transfer of the bestshot to device integration systems.
System requirements#
The minimum system requirements below (Table 1 and Table 2) must be met in order to install the full System package.
Table 1. Minimum system requirements for x64 architecture
Required Resource |
Recommended |
---|---|
Processor |
Intel(R) Core(TM) i3-10110U |
RAM |
4GB or more |
Hard disk drive |
HDD or SSD at least 1,4 B |
Operating system |
|
Instruction Support |
Advanced Vector Extensions 2 (AVX2) |
To run the application on Windows, install the Visual C++ Redistributable package.
Table 2. Minimum system requirements for ARM architecture
Required Resource |
Recommended |
---|---|
Processor |
Rockchip RK3588S |
RAM |
4GB or more |
Hard disk drive |
HDD or SSD at least 128GB |
Operating system |
Armbian 23 (aarch64) |
Correct operation of the System is ensured by Intel® RealSense™ Camera D400-Series 3D cameras with firmware version 5.15.0.2, VLS LUNA CAMERA 3D cameras and VLS LUNA CAMERA 2D IR cameras:
- Intel® RealSense™ Depth Cameras D415;
- Intel® RealSense™ Depth Cameras D435;
- Intel® RealSense™ Depth Cameras D435i;
- VLS LUNA CAMERA 3D / VLS LUNA CAMERA 3D Embedded;
- VLS LUNA CAMERA 2D.
For information about VLS LUNA CAMERA 3D / VLS LUNA CAMERA 3D Embedded, please contact your VisionLabs representative.
Use USB 3.0 to work with Intel® RealSense™ Camera D400-Series 3D cameras, VLS LUNA CAMERA 3D and VLS LUNA CAMERA 2D.
System architecture#
A high-level diagram of the System architecture is shown below (Figure 1).
The system consists of the following components:
- RSEngine is a component that includes:
- VisionLabs SDK library from the VisionLabs development kit for image processing;
- libraries:
- RealSense2 SDK–for work with Intel RealSense camera;
- VLS LUNA CAMERA 3D SDK–for work with VLS LUNA CAMERA 3D camera;
- VLS LUNA CAMERA 2D SDK–for work with VLS LUNA CAMERA 2D camera;
- Camera monitoring, designed to check the status of the camera;
- RSE Server–WebSocket server for interaction with external system WebSocket Client.
Algorithm#
Bestshot selection#
The interaction of components when selecting the bestshot is shown below (Figure 2).
An explanation for the figure is presented below (Table 3).
Table 3. The description of the interaction diagram of the System components when selecting the bestshot
Step |
Description |
---|---|
(1) |
The RSE Server receives a WebSocket connection request from a client. Example request:
|
(2) |
RSE Server sends a request to RSEngine to launch the camera (to the camera library). Depending on which camera is connected, |
(3) |
Camera library launches the camera |
(4) |
The camera library receives RGB, IR, Depth video streams from the camera, splits them into frames and analyzes |
(5) |
The camera library passes a set of frames to the RSE Server. Depending on the
|
(6) |
RSE Server sends a request to frame processing (performed on each frame) to the VisionLabs SDK |
(7) |
SDK VisionLabs performs:
If all checks are passed, the process continues (go to step 8). If at least one check fails, SDK VisionLabs sends a request to the camera for new frames to perform a second check as long as there is detection (return to step 4) |
(8) |
VisionLabs SDK performs a Liveness check and compares the resulting value of the Liveness score to the threshold one. If the received Liveness value is higher than the threshold, then the current frame becomes the bestshot. If the received Liveness value is below the threshold, SDK VisionLabs sends a request to the camera to to receive new frames to perform a second check as long as there is detection (return to step 4) |
(9) |
If the Liveness check is successful, the received bestshot and facial attributes are sent to the RSE Server |
(10) |
RSE Server converts the selected bestshot and meta-information into MessagePack and sends it to the client in an external system |
Monitor camera status#
The interaction of components when monitoring the state of the camera is shown below (Figure 3).
An explanation for the figure is presented below (Table 4).
Monitoring is started by default once every 300 seconds, you can change the duration in the
camera-monitoring
andcamera-monitoring-delay
parameters in thersengine.conf
file.
Table 4. The description of the interaction diagram of the System components when monitoring the camera state
Step |
Description |
---|---|
(1) |
RSE Server sends a request to RSEngine to launch monitoring the camera |
(2) |
Camera Monitoring sends a request to the camera library for camera status—RealSense2 SDK, VLS LUNA CAMERA 3D SDK or VLS LUNA CAMERA 2D SDK depending on which camera is connected IntelRealSense, VLS LUNA CAMERA 3D or VLS LUNA CAMERA 2D SDK |
(3) |
The camera library transfers a request for camera status |
(4) |
The camera library receives the camera status |
(5) |
The camera library passes the camera status to the camera monitoring |
(6) |
RSEngine transfers camera status information to RSE Server |
(7) |
RSE Server entries camera status data to the registry (on Windows) or to the ./logs working folder (on Ubuntu 24.04 x64, Debian 10 x64 and Armbian 23) |
Component description#
RSEngine component#
RSEngine provides the interaction of the VisionLabs SDK, RealSense2 SDK, VLS LUNA CAMERA 3D SDK, VLS LUNA CAMERA 2D SDK libraries within the System.
VisionLabs SDK component#
The VisionLabs SDK is a software development kit that includes libraries and neural networks for image analysis to:
- detection of faces in images and key points (landmarks) of the face;
- choosing the bestshot;
- estimation of image attributes for further Liveness check;
- estimation of the face in the image using Liveness algorithms.
All estimations described below are performed to ensure that the image meets Liveness requirements. All checks are internal and the results are not transmitted externally. The result of the check can only be shown in case of an error, if any attribute of the image/face is not suitable for the Liveness estimation (see the description of errors in “Appendix 2. Status codes and error descriptions”);
RealSense2 SDK component#
The RealSense2 SDK is a component that allows:
- receive incoming images from Intel RealSense cameras;
- configure detection parameters;
- turn the camera on/off, change various parameters. For example, laser backlight brightness, auto exposure, brightness.
- automatically update the connection with the camera. When the connection is updated, the System reconnects to the camera. If the System fails to reconnect to the camera, a soft reset of the connection cable is performed. If the specified operations are unsuccessful, this problem will be reflected in the camera status report in the System logs.
Component VLS LUNA CAMERA 3D SDK#
VLS LUNA CAMERA 3D SDK is a component that allows:
- receive incoming images from VLS LUNA CAMERA 3D / VLS LUNA CAMERA 3D Embedded cameras;
- configure detection parameters;
- turn the camera on/off, change various parameters (e.g. laser illumination brightness, auto exposure, brightness).
Component VLS LUNA CAMERA 2D SDK#
VLS LUNA CAMERA 2D SDK is a component that allows:
- receive incoming images from VLS LUNA CAMERA 2D infrared cameras;
- configure detection parameters;
- turn the camera on/off;
- change the rotation angle of the camera video frame.
Camera functions#
Face detection#
The detector uses special face detection algorithms and solves the following problems:
- face detection in the image;
- determining 5 key points on the face: two for the eyes, one for the tip of the nose and two for the corners of the mouth;
- estimation of the detection quality–the degree of probability that the face (not another object) is detected in the image.
Image quality estimation#
Image quality is estimated using the following parameters:
- Blur–blurriness;;
- Light–lightness;
- Dark–darkness.
Oral status estimation#
An oral status estimation is performed on the following parameters:
- Opened–the mouth is open;
- Occluded–the mouth is blocked by an outside object;
- Smiling–the presence of a smile.
Eye status estimation#
An estimation of the eye status is performed using the following parameters:
- Closed–eyes are closed;
- Open–eyes are open;
- Occluded–eyes are blocked (e.g. with sunglasses).
Head position estimation#
An estimation of the head position is performed using the following parameters:
- Roll–angle of head tilt around the longitudinal axis;
- Pitch–angle of head tilt around the transverse axis;
- Yaw–angle of head rotation around the vertical axis.
Depth Liveness checking#
The “vitality” of the person in the image is checked using a depth map.
The depth matrix (16 bits) is analyzed. It contains information about the distance of the surfaces of the scene objects (faces) to the viewpoint.
IR Liveness checking#
The “vitality” of the person in the image is checked using infrared image analysis.
The camera must be equipped with infrared illumination to perform the check.
FPR Liveness checking#
FPR is an anagram of the names of the checks– FlyingFaces, Phone и Replay Liveness. The check of "vitality" of a person in the image is performed using:
- FlyingFaces Liveness–an algorithm that allows you to detect printed photos and masks.
- Phone Liveness–an algorithm that allows you to detect the presence of a phone in an extended BBox;
- Replay Liveness–an algorithm that allows you to detect video recording artifacts;
Camera Monitoring Component#
Camera monitoring is used to check the status of the camera.
Camera monitoring queries the following camera parameters:
- firmware data;
- operating status of infrared cameras–on/off;
- RGB camera operating status–on/off;
- camera serial number;
- operation status of the entire camera–on/off;
- camera temperature;
- date of the last update.
An example of the contents of the registry in the monitoring section is shown below (Figure 4).
RSE Server component#
The RSE Server is a WebSocket server that processes commands from external systems.
The RSE Server accepts requests and sends responses via WebSocket.
Request Format:
- Operation request code (1 byte)
- Additional payload (MessagePack or string)
Example of a request:
GET ws://127.0.0.0.1:4444/
–establishing a WebSocket connection.
0
–content of the message to start the session.
Response Format:
- Operation response code (1 byte)
- Additional payload (MessagePack or string)
Only one request can be processed at a time.
Depending on the type of integration required (selected at the discretion of the external system developer), you can configure RSE Server in the following ways:
- RSE Server expects requests (presented in Table 5) to connect to the camera from the external system–set the
cs_communication = msg-pack
parameter; - RSE Server starts the process of receiving video stream and face detection process as soon as WebSocket connection is established –set the
cs_communication = json
parameter.
Table 5. Description of requests to RSE Server
Request Name |
Request Code |
Description |
Payload |
Possible responses to the request |
---|---|---|---|---|
RSE_START_CAPTURE |
0 |
Starts the process of receiving a video stream and the process of detecting faces |
No |
|
RSE_STOP |
1 |
Stops all running processes |
No |
|
Depending on the type of integration selected (chosen at the discretion of the external system developer), the server response can be presented in two formats:
- if the external system developer has set the
cs_communication = msg-pack
parameter, each response will arrive inmsg-pack
format and will contain themessageType
field with the response code and some additional data fields (payloads) described in Table 6; - if the external system developer has set the
cs_communication = json
parameter, each response will arrive injson
format and will be categorized into the message types described in Table 7.
Table 6. Responses to RSE Server requests with MessagePack response format
Answer title |
Code |
Description ** |
Payload |
---|---|---|---|
RSE_CAPTURE_OK |
54 |
Captured set of video frames |
— rgbFrame—RGB frame in uint8 array format; — rgbFrameWidth—RGB frame width in pixels in int format; — rgbFrameHeight—RGB frame height in pixels in int format; — irFrame—IR frame in uint8 array format; — depthFrame—Depth frame in uint8 array format |
RSE_CAPTURE_META |
55 |
Metadata of detected persons |
— gotBestshot—indicator of whether bestshot was received, in bool format, returns:
– bestshot—RGB frame, in uint8 array format:
|
RSE_STOP_OK |
50 |
All processing has stopped. RSE Server is ready for new requests |
No payload |
RSE_UNKNOWN |
51 |
The request was not recognized |
No payload |
RSE_INTERNAL_ERROR |
52 |
An error occurred while processing the request |
No payload |
RSE_BUSY |
53 |
Request denied because server is busy |
No payload |
Table 7. Responses to RSE Server requests with JSON response format
Message type |
Description |
Payload |
---|---|---|
visual |
The type of response that is used for broadcasting the video stream to the user |
– msg_type–the type of message returned (visual); – img_b64–base64 camera frame; – metadata–parameters of the returned image:
– y–coordinates of the upper left corner of the detected face frame
|
bestshot |
The type of response when a person is successfully found. This frame can be used for subsequent processing (e.g. in an external face recognition system) |
– msg_type–the type of message returned (bestshot); – img_b64–face from camera frame in base64 format; – metadata–parameters of the returned image:
|
WebSocket Client component#
WebSocket Client is an external component for interacting with RSE Server.
WebSocket Client is a JavaScript library for communicating with RSE Server via WebSocket. It uses the minimized binary serialization format MessagePack as a protocol library to encode and decode messages if the server returns responses in MessagePack format.
System setup#
This section provides general information regarding System setup and logging.
The System allows you to customize the following parameters:
- General parameters (for more details see. "Appendix 1: General configuration parameters").
- Image capture parameters (change in the
rsengine.conf
file); - Face detection parameters (change in the
rsengine.conf
file); - Parameters of IOU check execution - check of BBox face intersection on IR and RGB images (change in
rsengine.conf
file).
Image capture parameters, face detection parameters, and IOU verification parameters are fixed by default and cannot be changed by the user (administrator). Setting of these parameters is performed only by the copyright holder (VisionLabs LLC).
There are other .conf files included in the System distribution. It is not recommended to change parameters in these files, as it may disrupt the System operation. The System can be configured only within the instructions below.
System setup on Windows#
The System is configured through the Windows Registry.
Settings received by the server from the client are saved until the System is restarted.
When configuring the System via the Windows Registry, write the settings in the following path:
\*\* HKEY\_LOCAL\_MACHINE \ SOFTWARE \ VisionLabs \ RSEServer \*\*
The configuration parameters are described in Table 8 and Table 9.
When changing configuration settings, the new configurations overwrites the previous configurations.
To change parameters in the registry, find the corresponding parameter, make changes and apply them.
System settings on Ubuntu 24.04 x64 and Debian 10 x64#
The System is configured by changing data in the client configuration files in the distribution (server.conf
and rsengine.conf
).
To apply the client configuration settings, make changes to the server.conf
and rsengine.conf
files (Table 8, Table 9) and restart RSE Server.
To change parameters, make changes to the appropriate file and apply the changes.
Logging#
RSE Server entries logs to the console as well as to a Windows log file for collections under Windows.
Log files use the following file naming scheme: server_YYYYYY-MM-DD.log.
Appendix 1: General configuration parameters#
General parameters are changed in the registry (for Windows) files server.conf
(Table 8) and rsengine.conf
(Table 9). Windows registry configuration parameters are shown below (Table 10).
Table 8. Common configuration parameters in the server.conf
file
Parameter name |
Data type |
Silent value |
Description |
---|---|---|---|
|
|
|
Path RSE Server data directory. It is not recommended to change Parameter value. |
|
|
|
Path to RSEngine library config file. Relevant for setting up the System on Ubuntu 24.04 x64, Debian 10 x64, Armbian 23 and Windows OS using configuration files |
|
|
|
The type of interaction between the server and the client. Depends on the selected System configuration. Can take the following values:
|
|
|
|
The returned image format of the bestshots. Selected based on the requirements of external software. Can accept the following values:
|
|
|
|
Saving bestshots to disk to the
directory
|
|
|
|
The directory for saving the best shots when the
|
|
|
|
Encryption of the bestshots when saving them. Not used in this version of the System.
|
|
|
|
IP address of the server on which to run to accept websocket connection. When using one copy, specify localhost; when using several running copies, specify the main server. |
|
|
|
Port on which RSE Server accepts connections |
|
|
|
The logging level filters log messages and has the following levels from 0 to 3:
|
|
|
|
Path to a writable directory for storing server logs |
|
|
|
Daily log rotation
|
|
|
|
Continue to receive bestshots in the session, even if bestshot has already been received
|
Table 9. Common configuration parameters in the rsengine.conf
file
In the
rsengine.conf
file, the unique settings for each camera are separated into blocks.
Parameter name |
Data type |
Silent value |
Description |
---|---|---|---|
|
|
|
Camera System Mode:
|
|
|
|
Parameter enables/disables monitoring of the camera status.
|
|
|
|
Parameter sets the request frequency for the camera status from the monitoring service |
|
|
|
Using RGB and IR camera data to perform checks It is not recommended to change this parameter.
|
|
|
|
Using information about eye position and status for checking Liveness.
|
|
|
|
Using information about mouth status for checking Liveness.
|
|
|
|
Using information about face volumetric on image when checking Liveness. It is not recommended to change this parameter.
|
|
|
|
FPR Liveness check. It is not recommended to change this parameter.
|
|
|
|
The minimum threshold for the Liveness value when checking face in the volumetric image. Threshold is set between 0.0 and 1.0 (0...100 for Windows), where:
|
|
|
|
Minimum threshold for Liveness value while face checking Parameter is chosen analytically by the developers and is not recommended to be changed. The threshold is set in the range from 0.0 to 1.0 (0...100 for Windows), where:
|
|
|
|
Transferring the Bbox coordinates of a face from an RGB image to an IR image for further processing.
|
|
|
|
The threshold for using IOU when building a Bbox. Parameter is chosen analytically by the developers and is not recommended to be changed. The threshold is set in the range of 0.0 to 1.0 (0...100 for Windows). |
|
|
|
Minimum threshold for evaluating image quality before checking Liveness. Parameter is chosen analytically by the developers and is not recommended to change. The threshold is set between 0.0 and 1.0 (0...100 for Windows). |
|
|
|
Face comparison threshold from IR and RGB images. Parameter is chosen analytically by the developers and is not recommended to be changed. The threshold is set between 0.0 and 1.0 (0...100 for Windows). |
|
|
|
Minimum space between the face box and the frame boundaries in pixels. The face must be at least 10 pixels from the frame border when performing a Liveness check, so that face information is not lost. 10...100 pixels |
|
|
|
Minimum image quality threshold at which the Liveness check will be performed. Parameter is chosen analytically by the developers and is not is not recommended to be changed. The threshold is set in the range of 0.0 to 1.0 (0...100 for Windows). |
|
|
|
Minimum threshold for checking the quality of face illumination at image at which the Liveness check will be performed. Parameter is chosen analytically by the developers and is not recommended to change. The threshold is set in the range of 0.0 to 1.0 (0...100 for Windows). |
|
|
|
Minimum threshold for checking the quality of darkness on the face. image at which the Liveness check will be performed. Parameter is chosen analytically by the developers and is not recommended to change. The threshold is set in the range of 0.0 to 1.0 (0...100 for Windows). |
|
|
|
Minimum threshold for checking the quality of blurred face image at which the Liveness check will be performed. Parameter is chosen analytically by the developers and is not recommended to change. The threshold is set in the range of 0.0 to 1.0 (0...100 for Windows). |
|
|
|
Maximum head tilt angle relative to the camera axis,, at which the Liveness check will be performed. Parameter is chosen analytically by the developers and is not recommended to be changed. |
|
|
|
Maximum head rotation angle relative to the camera axis, at which the Liveness check will be performed. Parameter is chosen analytically by the developers and is not recommended to be changed. |
|
|
|
Maximum head rotation angle relative to the camera axis, at which the Liveness check will be performed. Parameter is chosen analytically by the developers and is not recommended to be changed. |
|
|
|
Enable auto exposure mode for RGB images. It is not recommended to disable this setting.
|
|
|
|
Enable auto exposure mode for IR image. It is not recommended to disable this setting.
|
|
|
|
Check for lack of image illumination in IR image. |
|
|
|
Cropping the original frame to reduce the area of interest to improve the recognition quality. The preset parameters below limit the central part of the frame, where the face is least distorted. It is not recommended that this setting be turned off.
|
|
|
|
Horizontal coordinate of the upper left corner of the area of interest. Specified from the upper left corner of the frame. It is not recommended to change this parameter. |
|
|
|
Vertical coordinate of the top left corner of the area of interest. Set from the upper left corner of the frame. It is not recommended to change this parameter. |
|
|
|
Width of the area of interest. It is not recommended to change this parameter. |
|
|
|
Height of the area of interest. It is not recommended to change this parameter. |
|
|
|
The rotation angle of the camera frame. Possible values: |
|
|
|
IR Liveness check.
|
Table 10. Windows Registry Configuration Settings
Parameter name |
Data type |
Silent value |
Description |
---|---|---|---|
|
|
|
Path to RSE Server data directory. It is not recommended to change the value of Parameter. |
|
|
|
The type of interaction between the server and the client. Depends on the selected System configuration. Can take the following values:
|
|
|
|
The returned image format of the bestshots. Selected based on the requirements of external software. Can accept the following values:
|
|
|
|
Saving the bestshots to disk to the
directory
|
|
|
|
The directory for saving the best shots when the
|
|
|
|
Encryption of the bestshots when saving them. Not used in this version of the System.
|
|
|
|
IP address of the server on which to run to accept websocket connection. When using one copy, specify localhost; when using several running copies, specify the main server. |
|
|
|
The port on which the RSE Server accepts connections |
|
|
|
The logging level filters log messages and has the following levels from 0 to 3:
|
|
|
|
Path to a writable directory for storing server logs |
|
|
|
Camera System Mode:
|
|
|
|
Parameter enables/disables monitoring camera status.
|
|
|
|
Parameter sets the request frequency for the camera status from the monitoring service. |
|
|
|
Using RGB and IR camera data to perform checks It is not recommended to change this parameter.
|
|
|
|
Using information about eye position and status for checking Liveness.
|
|
|
|
Using information about mouth status for checking Liveness.
|
|
|
|
Using information about face volumetric on image when checking Liveness. It is not recommended to change this parameter.
|
|
|
|
FPR Liveness check. It is not recommended to change this parameter.
|
|
|
|
The minimum threshold for the Liveness value when checking face in the volumetric image. Threshold is set between 0.0 and 1.0 (0...100 for Windows), where:
|
|
|
|
Minimum threshold for Liveness value while face checking Parameter is chosen analytically by the developers and is not recommended to be changed. The threshold is set in the range from 0.0 to 1.0 (0...100 for Windows), where:
|
|
|
|
Transferring the Bbox coordinates of a face from an RGB image to an IR image for further processing.
|
|
|
|
The threshold for using IOU when building a Bbox. Parameter is chosen analytically by the developers and is not recommended to be changed. The threshold is set in the range of 0.0 to 1.0 (0...100 for Windows). |
|
|
|
Minimum threshold for evaluating image quality before checking Liveness. Parameter is chosen analytically by the developers and is not recommended to change. The threshold is set between 0.0 and 1.0 (0...100 for Windows). |
|
|
|
Face comparison threshold from IR and RGB images. Parameter is chosen analytically by the developers and is not recommended to be changed. The threshold is set between 0.0 and 1.0 (0...100 for Windows). |
|
|
|
Minimum space between the face box and the frame boundaries in pixels. The face must be at least 10 pixels from the frame border when performing a Liveness check, so that face information is not lost. 10...100 pixels |
|
|
|
Minimum image quality threshold at which the Liveness check will be performed Parameter is chosen analytically by the developers and is not is not recommended to be changed. The threshold is set in the range of 0.0 to 1.0 (0...100 for Windows). |
|
|
|
Minimum threshold for checking the quality of face illumination at image at which the Liveness check will be performed. Parameter is chosen analytically by the developers and is not recommended to change. The threshold is set in the range of 0.0 to 1.0 (0...100 for Windows). |
|
|
|
Minimum threshold for checking the quality of darkness on the face. image at which the Liveness check will be performed. Parameter is chosen analytically by the developers and is not recommended to change. The threshold is set in the range of 0.0 to 1.0 (0...100 for Windows). |
|
|
|
Minimum threshold for checking the quality of blurred face image at which the Liveness check will be performed. Parameter is chosen analytically by the developers and is not recommended to change. The threshold is set in the range of 0.0 to 1.0 (0...100 for Windows). |
|
|
|
Maximum head tilt angle relative to the camera axis,, at which the Liveness check will be performed. Parameter is chosen analytically by the developers and is not recommended to be changed. |
|
|
|
Maximum head rotation angle relative to the camera axis, at which the Liveness check will be performed. Parameter is chosen analytically by the developers and is not recommended to be changed. |
|
|
|
Maximum head rotation angle relative to the camera axis, at which the Liveness check will be performed. Parameter is chosen analytically by the developers and is not recommended to be changed. |
|
|
|
Enable auto exposure mode for RGB images. It is not recommended to disable this setting.
|
|
|
|
Enable auto exposure mode for IR image. It is not recommended to disable this setting.
|
|
|
|
Check for lack of image illumination in IR image. |
|
|
|
Cropping the original frame to reduce the area of interest to improve the recognition quality. The preset parameters below limit the central part of the frame, where the face is least distorted. It is not recommended that this setting be turned off.
|
|
|
|
Horizontal coordinate of the upper left corner of the area of interest. Specified from the upper left corner of the frame. It is not recommended to change this parameter. |
|
|
|
Vertical coordinate of the top left corner of the area of interest. Set from the upper left corner of the frame. It is not recommended to change this parameter. |
|
|
|
Width of the area of interest. It is not recommended to change this parameter. |
|
|
|
Height of the area of interest. It is not recommended to change this parameter. |
|
|
|
Daily log rotation
|
|
|
|
Continue to receive bestshots in session even if bestshot has already been received
|
|
|
|
The rotation angle of the camera frame. Possible values: |
|
|
|
IR Liveness check.
|
Appendix 2. Status codes and error descriptions#
Status codes and descriptions of failureReason
errors in the RSE_CAPTURE_META
response payloads when performing a Liveness check are summarized in Table 11.
Codes are common to msg-pack and JSON responses.
Table 11. Status codes and description of failureReason
errors in RSE_CAPTURE_META
response
Status Code | Description |
---|---|
0 | There are no errors, the frame passes checks |
1 | Incorrect RGB frame |
2 | Incorrect Depth frame |
3 | Incorrect IR frame |
4 | Face wasn't detected |
5 | Face wasn't detected (face too small in frame) |
6 | The detected face doesn't pass one of the configuration parameters |
7 | It is impossible to estimate the face in the frame by 5 points |
10 | The face in the frame is cropped |
11 | Face rotated—eye distance is too short |
13 | Failed to normalize RGB frame |
14 | Failed to normalize Depth frame |
15 | Failed to normalize IR frame |
16 | Incorrect head position |
17 | Eyes are closed |
18 | Neutral face expression of the mouth muscles is necessary |
19 | Liveness frame Depth check was failed |
20 | Liveness IR frame check was failed |
21 | Poor frame quality |
22 | RGB frame is too bright |
23 | RGB frame is too dark |
25 | Image is blurry |
26 | FPR Liveness check was failed |
28 | Liveness check of RGB and IR frames comparison is in progress |
29 | Liveness check IR frame without illumination |
31 | Failed to recognize face on the frame |
32 | Failed to detect face on IR frame |
33 | Low quality Depth frame |
34 | Several faces with overlapping BBox zones detected |