Skip to content

LUNA PLATFORM v.5.33.0#

Changes

  • Starting with the next release, Liveness V1 support is discontinued. The container launch commands and description will be removed from the documentation.

  • New parameter "estimate_lower_body" was added to the "/sdk" resource and the "detect_policy" > "body_attributes" of the "/handlers" resource, which allows to perform estimation of the following bodies attributes:

    • "lower_garment" (type: trousers, shorts, skirt, undefined; color: orange, purple, red, white, yellow, pink, brown, beige, khaki, multicolored, undefined);
    • "shoes" (color: white, black, other, undefined).

    This estimation is disabled by default in both resources. Also now the "estimate_upper_body" parameter determines the color of the headwear ("headwear_apparent_color" parameter). The colors are similar to the colors of the lower garment. New body attributes were added to the event structure (see "detections" > "samples" > "body" > "detection" > "attributes"). Body attribute filters "lower_garment_types", "lower_garment_colors", "shoes_apparent_colors" and "headwear_apparent_color" were added to the "match_policy" policy of the "/handlers" resource and to the "human body matching" resource, specified when using events as candidates. The ability to set these body attributes as values for the "targets" field was also added.

    Filters on these body attributes can also be used when sending events via websockets (see the "ws handshake" resource).

    Appropriate event filters were added to Cross-matching, Clustering, Reporter, Exporter and Linker tasks. The corresponding columns were added to the Reporter and Exporter tasks.

    The ability to specify these body attributes when creating a new handler in the Estimator task is supported.

    The structure of the event in the "generate events" or "save events" requests is also extended by these body attributes. In addition, in these requests and the "sdk" request, aggregation by these body attributes is available. The aggregated attribute values are displayed in the "aggregate_estimations" fields of the respective resources.

  • Settings of the Handlers service were updated.

    Now you can set both individual runtime settings for each estimator/detector, and global runtime settings for all estimators/detectors.

    Global runtime settings are set in the "LUNA_HANDLERS_RUNTIME_SETTINGS" section and contain three settings:

    • global_device_class — device class ("cpu" or "gpu") for all estimators/detectors that have the parameter value "device_class" = "global" (see below);
    • num_threads — number of worker threads for all estimators/detectors;
    • num_compute_streams — number of streams for all estimators/detectors.

    Individual runtime settings are set in the section like "LUNA_HANDLERS__SETTINGS.aintime_settings" and contain three settings:

    • device_class — device class to perform estimation ("cpu", "gpu" or "global");
    • optimal_batch_size — batch size for estimation;
    • worker_count — amount of workers to perform estimation.

  • In the Handlers service, the ability to enable/disable the use of individual estimators and detectors was added. By default, all estimators are enabled.

    Previously, it was possible to enable/disable only all estimators at once. The ability to enable individual estimators allows you to save RAM or GPU memory, since when the Handlers service launches, the ability to perform these estimates is checked and data is loaded into memory. If you disable an estimator or detector, you can also remove its neural network from the Handlers container.

    Disabling estimators or detectors is possible by passing arguments with the names of estimators or detectors to the launch command of the Handlers service. Arguments are passed to the container using the "EXTEND_CMD" variable. A list of all the arguments and an example of launching the container were added to the LUNA PLATFORM 5 administrator manual.

  • Support for images with CMYK scheme was added.

  • The "ws handshake" resource was added to the Backport 3 service for the possibility of receiving events via web sockets.

    This functionality is similar to the functionality of the "Event & Statistic" service of LUNA PLATFORM 3.

  • Settings of the API service were updated.

    The "LUNA_HANDLERS_LIVENESS_SETTINGS" section was removed from the API service settings because it was not used.

    The "LIVENESS_THRESHOLD" parameter was renamed to "LIVENESSV1_THRESHOLD".

  • The "estimate_glasses" parameter was added to the "detect_policy" of the "/handlers" and "/verifiers" resources, which enables you to estimate the type of glasses (glasses, sunglasses, no glasses).

  • The "estimate_attributes" parameter in the "create descriptors" and "search" requests of the Backport 3 service were expanded with the ability to estimate the type of glasses (glasses, sunglasses, no glasses). Now, when performing attribute estimation, gender, age, and points will be estimated.

    The filters "glasses__gt" (lower threshold) and "glasses__lt" (upper threshold) are available in the "ws handshake" resource.

  • The "account_id" filter was added to the request parameters of most resources with GET methods that return multiple objects in the response.

    Using this filter enables you to get data (tokens, faces, attributes, etc.) belonging to a specific account. The exceptions are the "get accounts" resource, service resources ("get health", "get configs", etc.) and the "ws handshake" resource.

    Also, the "account_id" query parameter was added to the "face matching" and "human body matching" resources.

    These query parameters will only work if the "visibility_area" parameter of the token is set to "all". Otherwise, an error will be returned.

  • The ability to use a user SQL function for matching was added.

    This function can be useful if it is not possible to use C-extensions of the PostgreSQL database. The function may be needed, for example, to deploy LUNA PLATFORM 5 on AWS and use Amazon Aurora PostgreSQL.

    See the detailed description in the "Alternative matching options" section in the file "luna_v.5.33.0/extras/VLMatch/postgres/readme.md" of the distribution package.

  • The Python version was updated to 3.10 in the containers of the API and Licenses services.

  • The Redis database was updated to version 7.0.5-alpine3.16.

Fixed errors

  • The error was fixed due to which in the request to get statistics on events (resource "/events/statistics") the filter with the current "account_id" was always passed, due to which statistics were returned only according to the data of the user account that performed the request.

    This resulted in the fact that users with the account type "admin" and "advanced_used" could not receive statistics on other users.

  • The error was fixed, due to which in the request to the resource users with the account type "advanced_used" or "admin" could not get statistics on other users.

  • The error was fixed, due to which it was impossible to get both dynamic and static handlers in the "get handlers" request using the "is_dynamic" filter at the same time. Now if you do not specify this filter, both types of handlers will be returned.

  • The error in the "detect face" request was fixed in the API specification where a non-existent "liveness" field was displayed in the response body.

  • The error was fixed, due to which, when making a request to the "/3/attributes//samples" resource of the Faces service, the filter by "account_id" was not taken into account.

  • The error was fixed where the "clear authorization" request from the Admin service would return an "Internal server error" when there was no cookie.

    Now the "Cookies for current session not found" error is returned.

  • The "Internal server error" was fixed, which occurred when loading an image with a color scheme that the SDK does not support.

    Now if an attempt is made to upload an image with an unsupported color scheme, the correct error code 18003 will be returned.

  • The error in the Python Matcher service with the cache enabled was fixed, in which unexpected errors could occur in the logs after changing the settings in the Configurator service.

    Now, the service process shutdown routine takes care of cancellation of open connections and errors in the logs do not appear.

  • The error of the "account_id" filter in the Python Matcher service was fixed.

    If in the "face matching" and "human body matching" requests with the specified "account_id" filter, the value of the "account_id" field of the event reference differed from the value of the "account_id" field of candidates, then an incorrect message was returned that only the candidate was filtered. Now a correct message is returned that the specified reference has not been found.

  • The error in the Python Matcher service was fixed that occurred in "face matching" and "human body matching" requests with Basic authorization and "user" account type when specifying the account ID in the "candidates" > "filter" > "account_id" field, different from the account ID by which the request is made.

    Now, when trying to use other "account_id" in filters with the "user" account type, the correct message will be returned.

  • The error in the "upgrade attribute" request of the Handlers service was fixed when an image processing error (for example, if you specify a body sample instead of a face sample) returned an empty field, or an "Internal server error". Now, if image processing errors occur, the correct error code 11043 will be returned.