Skip to content

v.5.101.0#

Changes

  • The SDK has been updated to version 5.28.1.

    In this version of LUNA PLATFORM:

    • the OneShotLiveness estimator has been updated to version 10;
    • a new Face Image Modification estimator has been added (see below).

  • A new estimator Face Image Modification has been added, which allows you to automatically determine the fact of image modification/editing by the presence of characteristic artifacts:

    • frames (green/black), indicating broken pixels or the fact that the image is a screenshot;
    • watermarks/logos;
    • superimposed images (compositions of several images);
    • superimposed figures (graphic elements over the image);
    • superimposed text elements (numbering, inscriptions). The system reacts only to text artificially superimposed during editing; natural elements (tattoos, inscriptions on clothes) are not taken into account.

    The system will consider the image to have been modified if the received score (a value from 0 to 1) is below the set threshold. The default threshold is 0.5 (50%).

    Image requirements:

    • minimum resolution 640 x 480 pixels;
    • presence of only one face in the image.

    Resources where the check is performed:

    • "/handlers"

      Check name — "policies" > "detect_policy" > "face_quality" > "checks" > "image_modification".

    • "/verifiers"

      Check name — "policies" > "detect_policy" > "face_quality" > "checks" > "image_modification".

  • The Image Store service now supports cleaning up objects created before the implementation of lifecycle policies based on TTL (Time To Live - automatic deletion of files after a specified period) in S3-like storages without tagging.

    Now the logic for cleaning up S3-like storages has been brought into line with local storage, where storage policies are stored in metafiles:

    • if the object metadata does not specify a value responsible for the lifespan, the decision to delete it is made based on the parent bucket policy (previously, such objects were not deleted, which could lead to the accumulation of "outdated" data).

    • if the object metadata specifies a specific value that differs from the default value, deletion occurs only based on this value, without additional checking of the bucket policy.

  • A new series of frames has been added to the Video Agent service monitoring, containing information about the stream decoding process. Each point contains data on decoded and dropped frames for a certain period.

    See the "Monitoring" section of the developer guide for more information.

  • The execution of requests "patch stream" and "patch streams in group" has been updated.

    These requests no longer return an error when it is impossible to set streams to the stop/pending status. In this case, a response with status code 200 and the patched_count field containing the number of streams whose state was changed as a result of executing the request is now returned.

    • "patched_count": 0 or 1 - response for "patch stream", where 0 - if neither the stream nor its parts (if the stream is splittable) have changed, 1 - if the stream (or at least one of its parts) has changed its status.

    • "patched_count": N - response for "patch streams in group", where N is the number of streams for which at least one part has changed its status. Parts of a stream are not counted separately (1 stream = 1 change, even if several of its parts have changed).

  • The fps parameter has been added to the "create stream", "put stream" and "video analytics" requests, allowing you to adjust the maximum frame rate when decoding video.

    This parameter allows you to limit the frame rate that is sent to analytics. That is, unlike the rate parameter, which is configured for each analytics separately, the fps parameter is applied to all analytics at once, which saves resources on video decoding, and also reduces the load on the system when working with less demanding analytics.

    Please note that the fps value must meet the requirements of all analytics used. For more information, see the "Analytics" section.

    The location of fps:

  • Now when the Admin service starts, the healthcheck does not check for the presence of an administrator account.

    The connection check is performed to exclude errors related to incorrect LUNA PLATFORM configuration.

    Now the Admin service can be launched without the mandatory presence of an administrator account.

  • Now when creating and updating a handler, the user can set the maximum number of elements in the match_policy array of the matching policy.

    For this purpose, a new parameter match_policy_array_limit has been added to the LUNA_HANDLERS_LIMITS settings group. By default, the maximum array length is set to 30 (as before).

    See the requests "create handler" and "replace handler".

  • The Python version in Video Manager and Video Agent service containers has been updated to 3.13.

    Support for older Python versions has been discontinued.

  • The policy for accessing agent analytics (for example, an agent represented as a Video Agent service) has been updated.

    Agents can be internal (agents interacting directly with platform services) and external (agents interacting only via API and running outside the main platform circuit, see "external mode of Video Agent service").

    If analytics are created by internal agents, they will be available to all users. Analytics created by external agents will be available only to those users who log in to the platform under the same account_id that the external agent is registered with (regardless of the authorization type, i.e. both BasicAuth and BearerAuth).

    If any analytics are registered by an external agent and then registered by an internal agent, those analytics will be available to all users and can only be changed by manually deleting them.

    Analytics names must be unique.

    Previously, there was no clear separation of access rights to analytics between internal and external agents.

    See the "Analytics" section of the developer guide for more information.

  • For lambdas with the Handlers and Standalone types, the SDK version has been updated from v.5.21.0 to v.5.26.0.

    Python 3.13 is also now required to write lambdas. Support for older versions has been discontinued.

  • Added the ability to create a lambda from a pre-built image.

    Using a pre-built image can be useful when the target server does not have enough compute resources to build the image, or when you want to deploy the same lambda to multiple LP instances without rebuilding.

    An existing image for import can be obtained using a new "get lambda image" request to the Lambda service. If the intended lambda runs in a different loop, the corresponding image must be migrated to the used image store.

    A new lambda can be created from an existing image by providing the name and tag parameters in the imported_image parameter group in the lambda create/update request.

  • The "Installation manual" and "Upgrade manual" documents, which described a general approach for deploying LUNA PLATFORM in Docker containers without using the Storages utility, have been removed.

    According to these documents, to prepare the environment, you had to manually create buckets, create/migrate databases to PostgresSQL, enable monitoring of LUNA PLATFORM services, and add the VLMatch library for matching in PostgreSQL. Now installation and upgrade are only possible via the Storages utility — it automates all steps. You just need to specify the necessary flags in the Storages utility configuration file.

    Important: Updating using the Storages utility is only possible for LUNA PLATFORM v.5.46.1 and higher. When upgrading from earlier versions, you must request documentation for the corresponding version from VisionLabs specialists. Using the documentation you received, upgrade to v.5.46.1 (with Storages utility support), then use this guide to upgrade to the latest version of LUNA PLATFORM.

    For detailed information on the Storages utility, see "Storages Utility Manual".

Fixed errors

  • Fixed incorrect default stream sorting when executing the "get streams" request.

    The order parameter specifies the sorting order. If desc is specified (the default), the newest events will be shown first. If asc is specified, the oldest events will be shown first.

    Previously, there was an inconsistency - new/modified streams were at the end of the list, in fact, the asc sorting was applied. Now, when making a request without explicitly specifying order, desc is automatically applied, as stated in the documentation.

  • Fixed behavior that would occasionally result in a 500 status code error when saving events.

  • Fixed incorrect processing of the request to obtain license data "get license".

    Previously, the response erroneously returned previously requested functions. Now "get license" returns only user functions explicitly requested in the current request.

  • When there are no candidates for "general events matching" request now returns an empty array instead of an error with status code 400.

API service UI changes

  • Notifications about filtration were added to the "Verification" section. Previously, an error was returned when filtering images.

  • "Checks" section:

    • Parameters for face occlusion check have been added.
    • An information window has been added that is displayed when there are no video check results.

    • Now the Liveness and Deepfake check results have been added with information on whether the image meets the requirements of these estimators:

      • No image modification;
      • One face in the frame;
      • The angles of rotation and tilt of the head should not exceed 25 degrees;
      • The face should not be darkened, overexposed or blurred;
      • The face indents from the edges of the frame should be at least 10 pixels on each side;
      • The face size in the frame in width should be at least 150 pixels;
      • The frame size in width and height should be in the range from 720 to 1920 pixels.