Skip to content

v.5.103.0#

Changes

  • Added validation of descriptor length when creating general events "create new general events".

    Now when creating a general event together with a descriptor, the database is searched for the last saved descriptor with the same type and version as the one passed in the request:

    • if found, its length is compared with the length of the transferred descriptor. If there is a match, the event is successfully created, otherwise a response is returned with the status code 409 and error 12034 "Descriptor has incorrect length";
    • if not found, the transferred descriptor becomes the reference for subsequent checks.

    For example, if a descriptor with "type_1", "version_1" and "length_1" was previously saved in the database and when trying to create an event with a descriptor whose parameters are:

    • "type_1", "version_2", "lenght_1" - event will be created (different versions);
    • "type_2", "version_1", "lenght_1" - event will be created (different types);
    • "type_1", "version_1", "lenght_2" - event will not be created (same type+version pair, but different length) and an error with status code 409 will be returned.

    Note: Validation is performed only when a general event is created together with a new descriptor. If the descriptor already exists in the database or is not passed in the request, validation is not applied.

  • Support for descriptor encryption for generic events has been added."

    See the "Descriptors encryption" section in the developer manual.

  • A new setting LUNA_API_CORS has been added to controls the list of headers allowed to be read via Access-Control-Expose-Headers according to CORS.

    By default, X-Luna-Meta-Rescale — image scaling parameters, and X-Luna-Expiry-Date — data expiration date are allowed.

    This allows client applications running in the browser to obtain additional data that may be useful for processing responses from the server. See configuring and working with CORS for more information.

  • The new lambda type agent has been added.

    The Agent-lambda type is designed to create agents with custom video analytics. Thus, it makes it possible to use not only standard analytics (people tracking and people counting), but also custom video analysis algorithms written based on various neural network models.

    Agent-Lambda cannot process any user requests directly and functions exclusively in combination with the Video Manager service, which is a mandatory component for its operation. Also, during its operation, it can interact with the following LUNA PLATFORM services:

    • Faces
    • Sender
    • Events
    • Image Store

    Note: Agents can be internal (agents interacting directly with platform services) and external (agents interacting only via API and running outside the main platform loop, see "external mode of Video Agent service"). Agent-lambda currently operates as an internal agent.

    To create a lambda with the agent type, you must first transfer the base image dockerhub.visionlabs.ru/luna/lpa-lambda-agent-base:<lambda_version> to your registry, similar to other lambda types.

    For more information and code examples for Agent-lambda, see the "Agent lambda development" section of the Lambda service developer manual.

Fixed errors

  • Fixed an issue with the Deepfake estimator, which had a simplified mode enabled by default when making requests to the /sdk resource. This estimator now defaults to mode 2 (with image pre-check), which matches the documentation.

    For detailed information on the estimator operating modes, see the section "Deepfake".

  • Fixed incorrect behavior where completed streams (with done/failure status) were erroneously assigned the pending status after the agent processing these streams was stopped. The system now preserves the original status of completed streams.

  • Fixed behavior that caused a 500 status code error to be returned when executing a "create stream" request when the analytics streams limit license feature was disabled.

  • The human_tracking analytics can now work correctly if the agent was run in "external mode".

    Previously, an attempt to start analytics resulted in an error like "Connect call failed".

    Also fixed ​incorrect operation of human_tracking analytics, in which it was not possible to create a stream if the rate parameter, which specifies the frame processing frequency, differed from the default value.

  • Fixed a bug where responses would differ depending on the content type (application/msgpack or application/json) when sending comparison requests ("matching faces", "human body matching", "general events matching").

    Previously, when sending the same request with incorrect fields, different errors were returned:

    • for application/json — error with code 12022 and a detailed description of the problematic field.
    • for application/msgpack — error with code 12047 and a general message without specifics.

    Now in this case, a single error code and the same detailed message are returned for both content types (as was the case for application/json).