Skip to content

LUNA PLATFORM v.5.62.3#

LP changes

  • SDK has been updated to version 5.19.1.

    This version of LUNA PLATFORM:

    • 64th neural network model for face descriptor extraction is supported.
    • Default model was changed from 59th to 62nd (setting "DEFAULT_FACE_DESCRIPTOR_VERSION" of Remote SDK service).

    When migrating the Configurator service settings of the latest version, the "DEFAULT_FACE_DESCRIPTOR_VERSION" setting will not be automatically updated. If you want to use the 62nd version of the neural network, you must manually change the value of the "DEFAULT_FACE_DESCRIPTOR_VERSION" setting by first re-extracting the existing descriptors with the 62 model using the "Additional extraction" task.

  • Helm charts for deploying LUNA PLATFORM in a Kubernetes cluster have been added to the distribution package.

    The administrator must have a Kubernetes cluster deployed and configured to use Helm charts. It is assumed that the user's Kubernetes cluster:

    • PostgreSQL/Oracle DBMS and InfluxDB and Redis databases are running.
    • There is access to S3-like object storage for storing buckets.

    See the example commands for deploying LUNA PLATFORM in a Kubernetes cluster using Helm charts in the new manual (document "LP_Kubernetes_Helm_Deployment_Example" in the distribution package) or at online documentation.

  • A user interface has been added for LUNA PLATFORM, implemented as a web interface for the API service.

    The user interface is available at <host:5000/ui>.

    See the description of the user interface in the new manual (document "LP_User_Interface_Manual" in the distribution package) or at online documentation.

  • In the "videosdk" request, the ability to track people in a video and estimate their attributes both in the context of the entire video and on individual frames has been added.

    For people tracking video analytics, the key concept is a track. A track is an object containing information about the position of one person in a sequence of frames. A track is created when the detection of a face, body or body with a face (depends on the detector type in the "detector_type" parameter) appears on the last frame of the specified number of consecutive frames ("probe_count" parameter). There can be as many tracks as the number of people detected on the frame. Along with a track, a video analytics event is started.

    Note: Currently there can be only one event for one track. In future releases, it will be possible to have multiple events for a track, which can be sent without waiting for the track to end.

    For example, if "probe_count" = "3" and there are detections on two consecutive frames and no detections on the third frame, the track and event will not start. If at any moment of tracking a person there were detections on two consecutive frames and no detections on the third frame, the track and event will end.

    During tracking of a person it is possible to estimate attributes of faces, bodies, images (list of estimations is set in the "targets" parameter), and also to get the image with the best detection. The estimation can be performed by one best image from the track or by several (parameter "face_samples"/"body_samples" > "count"). If necessary, you can filter the best shots by "score", "head_pitch", "head_roll", "head_yaw" parameters. All scores set in the "targets" field depend on the type of detector used.

    If necessary, you can enable Re-identification of the body (ReID). The ReID feature is used to improve tracking accuracy by combining different tracks of the same person.

    For this type of video analytics, you can also configure a rectangular region of interest (parameter "roi") on the frame (coordinates "x", "y", width, height, units - per cent or coordinates). The principle of ROI region of interest is similar to FaceStream.

    Each people count video analytics event contains the following information:

    • "event_id" — Event ID.
    • "track_id" — Track ID.
    • "video_segment" — Information about the video segment (start time of the event, end time of the event, first frame number, last frame number).
    • "frames_estimations" — Array with information about estimates on each frame, containing the following information:
      • Frame number.
      • Time corresponding to the frame.
      • Bbox coordinates and score.
    • "aggregated_estimations" — Result of the score specified in the "targets" parameter in the request body.
    • "track_count" - Number of tracks.

    See OpenAPI specification for details.

  • The ability to obtain people coordinates and images with the maximum number of people has been added to the people count video analytics.

    For this purpose, a new parameter "targets" has been added to the request body, which takes the following values:

    • "coordinates" - Calculation of people's coordinates.
    • "overview" - Obtaining an image with the maximum number of people.

    It is possible to set both values or neither. If no values are specified, a basic analysis will be performed, containing only information about the video recording, the number of people and frames associated with them.

    The coordinates of people are returned in the response body in the "events" > "aggregated_estimations" > "overview" > "people_coordinates" field.

  • The structure of the "generate stream events (beta)" request has been reworked.

    The "sources" > "source" > "face_bounding_boxes" and "body_bounding_boxes" fields (available when "source_type" = "raw_image") have been renamed to "face_detection_data" and "body_detection_data" respectively and reworked as follows:

    • "height", "width", "x", "y" parameters moved to "face_detection_data"/"body_detection_data" > "bounding_box" fields.
    • "face_detection_data"/"body_detection_data" fields now contain the new optional fields "score", "angles" (contains pitch, yaw and roll parameters) and the mandatory "bounding_box" field (see above).
    • Added the ability to specify custom keys with values to the "face_detection_data"/"body_detection_data" fields.

    The "sources" > "source" > "face" field (available when "source_type" = "detections") now contains new optional fields "score" and "angles". Also added the ability to specify custom keys with values in the "face" field.

    Also in the field "sources" > "source" added the ability to specify custom keys with values.

  • The description of the "cron" field in the "create tasks schedule", "replace tasks schedule", "get tasks schedules" and "get tasks schedule" requests has been extended.

  • Prometheus format request statistics is supplemented with the request execution time.

    The data is presented in a histogram format, which enable you to analyze the distribution of request execution times and identify potential performance problems. Each time interval (bucket) in the histogram displays the number of requests whose execution time falls into the corresponding range.

    See "Export metrics in Prometheus format" for details.

  • The ability to set labels for running lambda using specific Kubernetes nodes using the "deploy_parameters" > "selector" parameter has been added.

    This enables for more granular control over lambda deployment, allowing administrators to specify the nodes on which lambda should be deployed based on their resource needs. By applying labels to Kubernetes nodes and using the "selector" parameter, administrators can manage resource allocation not only for individual lambdas, but also for groups of lambdas with similar resource requirements.

    See the "create lambda", "put lambda", "get lambda", "get lambdas" requests.

  • Notification sent to external system using callbacks mechanism has been extended with "result_url" parameter containing external address to API service with task or subtask result.

  • SDK version for Handlers-lambda has been updated from version 5.17.0 to version 5.19.0.

  • The ability to specify the number of pods for lambda has been added.

    The number of pods is set in the "pod_count" parameter of the "deploy_parameters" section of the "create lambda" request. You can specify from 1 to 32 pods.

    You can also set CPU and memory limits for each lambda pod using the new parameters "cpu_limit", "ram_limit", "cpu_request", "ram_request" in the "deploy_parameters" > "resources" section.

    In addition, the output format in the "get lambda status" and "get lambda status" requests has been updated. The logs are now returned as a dictionary, allowing information about multiple lambda pods to be displayed.

    You can specify the number of pods and resources for an existing lambda using the "put lambda" request.

  • Support for using Kubernetes namespaces has been added to the Lambda service to provide isolation of resource groups within a single cluster.

    The namespace is specified in the "namespace" parameter of the "deploy_parameters" section of the "create lambda" request. See the namespace recommendations in the corresponding query parameter description.

    You can set the namespace for an existing lambda using the "put lambda" request.

  • The unused parameter "landmarks17_threshold" has been removed from the "LUNA_REMOTE_SDK_BODY_DETECTOR_SETTINGS" section.

  • A new /metrics resource has been added to lambda's created, allowing to collect and save metrics in Prometheus format as time series data that can be used to track lambda behavior.

    See "Export metrics in Prometheus format" for details.

  • The structure of the documentation in the distribution package has been redesigned.

    The system requirements for LUNA PLATFORM have been moved to a separate document in the scope of delivery.

    The installation manuals have been moved to the "InstallationManuals" directory.

LP fixed errors

  • Fixed the error that caused some parameters not to be displayed when the "show_all" filter was enabled in the "Service name" field on the "Settings" page of the Configurator service user interface.

In addition, the "show_all" filter is now set as the default value.

  • Fixed the error where in some cases task schedule processing would not restart properly after an environment (e.g. database) was temporarily unavailable.

  • Fixed the error in Backport 3 service that caused the list of closed web socket connections to not be cleared when web sockets were unavailable or not initialized.