Skip to content

LUNA PLATFORM v.5.51.0#

Changes#

  • The SDK has been updated to version 5.16.0.

    Support for the new 62 neural network model for face descriptor extraction has been added to LUNA PLATFORM.

  • A new Lambda service has been added, intended to work with user modules that mimic the functionality of a separate service. This functionality is currently in beta testing.

    Full-fledged work with the Lambda service is possible when deploying LUNA PLATFORM services in Kubernetes. To use it, you must independently deploy LUNA PLATFORM services in Kubernetes or consult VisionLabs specialists. If necessary, you can use Minikube for local development and testing, thus providing a Kubernetes-like environment without the need to manage a full production Kubernetes cluster.

    The service enables you to write and use your own handler or write an external service that will closely interact with LUNA PLATFORM and have several functions typical of LP services (such as logging, automatic reloading of configurations, etc.). Users just need to write the code and send it to the Lambda service, after which they can use their module without deploying additional containers, etc.

    The service creates a Docker image based on a ZIP archive with developer code and then runs it on a Kubernetes cluster. The custom module running on the Kubernetes cluster is called lambda.

    To work with the Lambda service, you need a separate license feature. In requests "get platform features", "get system info" and "get license ", "lambdas" fields have been added, displaying the status of the license feature.

    A new "lambda" permission has been added to the token, regulating the "creation", "view", "modification", and "deletion" rights for lambda.

    To work with the Lambda service, the following environment requirements are required:

    • Availability of running Licenses and Configurator services*.
    • Availability of an S3 bucket for storing archives with developer code.
    • Availability of a Docker registry for storing images.
    • Availability of a Kubernetes cluster.

    * during its operation, lambda will additionally interact with some LUNA PLATFORM services. The list of services depends on the type of lambda.

    In addition to the above requirements for the environment, it is necessary to comply with the requirements for writing code and archiving, as well as properly configuring the service. See additional information in the documentation.

    Lambda is created using the "create lambda" request, which specifies the archive, the name and its type (see below).

    Lambda can be of two types:

    Handlers-lambda

    This type is intended to replace the functionality of the classic handler. The Lambda handler can be used in two cases:

    • As a custom handler that has its response scheme, which may differ from the response of classic handlers and cannot be properly used in other LUNA PLATFORM services (for example, {"similarity": 0.123});
    • As a custom handler that mimics the response of a classic handler (for example, { "images": [ { ... } ], "events": [ { ... } ] ... }). Such a handler must match the response scheme of the event generation request and process the data correctly so that other services can use it.

    Due to the addition of Handlers-lambda, the response body schema of the "create handler" request has been upgraded. A new parameter "handler_type" has been added to the request body, which accepts three values - "0" (static handler), "1" (dynamic handler) and "2" (lambda handler). To use the value "2", you also need to specify the "lambda_id" (see the logic below). The "is_dynamic" parameter is considered deprecated and will be ignored when using the "handler_type" parameter.

    There are two ways to interact with Handlers-lambda: 1. Using the requests "generate events" or "estimator task". To use these requests, you must first create a handler by specifying "handler_type" = "2" and "lambda_id" obtained at the lambda creation stage. In response to the event generation, a custom result will be output, the format of which either matches the format of the classic event and enables it to be used by LP services in the future, or does not match. 2. Using the "proxy post request to lambda" request when it is not intended to mimic the response of a classic handler, since LP services assume a strict format for responding to the event generation request.

    For example, with Handlers-lambda you can implement the logic for sending, extracting, and matching two descriptors in a single request. In the response, only the similarity of candidates can be given without unnecessary information. In the classic scenario of using the LUNA PLATFORM, the user cannot execute this scenario and is forced to write logic on the side of the external system. See the code examples in the developer manual.

    Standalone-lambda

    This type is intended to implement independent functionality to perform close integration with the LUNA PLATFORM. To work with this type, a request "proxy post request to lambda" with its own request and response scheme is used. This type is intended for a narrow target audience and is quite difficult to implement.

    Using Standalone-lambda, you can write a service that implements the recording of a video stream to a file and saves it to the Image Store service for subsequent processing by the FaceStream application.

    Dashboard creation for the Lambda service has also been added to the LUNA Dashboards service.

    See lambda creation and processing sequence diagrams in the "Lambda diagrams" section.

    See additional information for a basic introduction to the functionality of the Lambda service in the "Lambda service" section of the administrator manual.

    See more information for a deeper dive in Lambda service developer documentation. The manual provides a set of steps to quickly get started with the service.

  • The response to the "get system info" request to the Admin service has been expanded with additional information on statistics on the use of estimators and images.

    The "estimators_performance_stats" field has been added, displaying the month, the name of the estimator, the average time of the estimate and the average size of the batch for each estimator. Example:

    "estimators_performance_stats": [ { "month": "2021-09", "name": "body_descriptor", "execution_time": 0.029135203011156546, "batch_size": 1.0952380952380951 } ]

    The "image_processing_stats" field has been added, displaying the month, the average decoding time of the image, the number of images by their size and the number of images by face height. Example:

    "image_processing_stats": [ { "month": "2021-09", "image_load_time": 0.006479793069339647, "image_size": { "w_1000_h_1050": 4, "w_1000_h_800": 212, }, "face_detection_size": { "h_100": 2, "h_180": 197 } } ]

    Here: - "w_1000_h_800": 212 -- 212 images with a width of 1000 pixels and a height of 800 pixels - "h_180": 197 -- 197 images with a face height of 180 pixels

    Images are rounded to the nearest 50 pixels. For example, if an image has a width of 105 pixels, it will be rounded to 150 pixels. All images with the same rounded values will be in the same bucket.

    Note: To use the new statistics, run the python influx2_cli.py create_usage_test --luna-config http://127.0.0.1:5070/1 after starting the Admin service (see the installation manual).

  • The Schedules tab has been added to the Admin service user interface, which enables you to manage the task schedule and create a schedule for a Garbage collection task.

    The tab displays all created task schedules and all relevant information (status, ID, Cron string, etc.). In the tab, you can also create, delete and edit schedules, as well as manage delayed start (pause and start stopped schedules).

    For more information, see the section "Admin service user interface".

Fixed errors#

  • Fixed the absence of the following sorting parameters for accounts and tokens:

  • Fixed the error in which during the launch of the Admin service, the connection and healthcheck to the Remote SDK service were not checked.

  • Fixed the error where during the migration of the database of the Handlers service to version v.3.0.0, the field "detect_policy" > "estimate_people_count" was incorrectly updated in existing handlers.

    As a result, after the update, when trying to use handlers with such a field, an error could occur with the code "12022" and the description "Failed to validate input json. Path: 'policies.detect_policy.estimate_people_count', message: 'value is not a valid dict'".