Skip to content

LUNA PLATFORM v.5.53.0#

Changes

  • The VisionLabs image for PostgreSQL has been updated from version 12 to version 16.

    If you previously used this image, then to migrate to the new version you must perform the migration yourself according to official documentation. If necessary, you can continue to use PostgreSQL 12 by specifying the "postgis-vlmatch:12" image in the container launch command.

    Mounting PostgreSQL 12 data from the "/var/lib/luna/postgres" directory into a PostgreSQL 16 container will result in an error.

    The section "Migrate PostgreSQL 12 to PostgreSQL 16" has been added to the upgrade manual, containing a reminder about the need for migration.

  • The ability to detect facial spoofing using DeepFake technology in photo images has been added.

    The "estimate_deepfake" parameter has been added to the requests "create handler", "create verifier" and "sdk".

    The "deepfake" field has been added to the event structure. This field can be used as a value for the "target" field or as a filter to receive an event using GET requests.

    Deepfake estimation may return the following results:

    • "prediction" = "fake" — The person is not real.
    • "prediction" = "real" — The person is real.
    • "score" = [0...1] — The degree of reliability of the estimation.

    In requests "create handler" and "create verifier" it is possible to set the "real_threshold" and "mode". The "sdk" request will use the default values of these parameters without the possibility of explicitly specifying them.

    Using the "real_threshold", you can set a value in the range [0...1], below which the system will consider that the person is not real.

    Two operating modes are available:

    • "mode" = "1" — Simplified operating mode.
    • "mode" = "2" (default) — Operating mode using an additional neural network model for preliminary estimation. If the result of the preliminary estimation determines that the person is fake, then the result "score" = "0" and "prediction" = "fake" will be returned in the response body.

    The following image requirements must also be met to perform the estimation:

    • head pose: "pitch" = [-20...20]
    • head pose: "yaw" = [-30...30]
    • face width: "face_width" > 150

    The "deepfake" filter can also be used in matching requests.

    The "deepfake_states" parameter has also been added to the handler and verifier, which allows filtering events by the expected result of the Deepfake estimation.

    The "deepfake" field has also been added to the filters for Clustering, Exporter, Cross-matching and Linker tasks. For the Exporter and Reporter tasks, the field is supported as a column.

    The "deepfake" field has also been supported as a filter in the "ws handshake" request.

  • A new request "get list of plugins" has been added to the API service, which enables you to get a list of imported plugins and their status.

  • A new "callbacks" policy has been added to the "storage_policy" of the handler and verifier, with which you can send generated events (notifications) to the third-party system at the specified URL.

    In fact, callbacks are analogous to sending notifications via web sockets, but with the key difference that they use the principles of HTTP webhooks, which provides a more flexible and customizable mechanism for sending notifications to third-party systems. You can configure the protocol type, external system address, request parameters and authorization data.

    Events sent using the "callbacks" field have a format corresponding to the format of the "generate events" request.

    For more information, see the requests "create handler" and "create verifier".

  • The Handlers-lambda input data structure has been updated.

    This means that all existing lambdas must be revised and recreated according to the new structure.

    All examples have also been updated.

    Example of the old input data structure: {"body": getImage("empty.jpeg"), "filename": "empty.jpeg", "source_type": 0}

    Example of a new input data structure: {"source": {"body": getImage("empty.jpeg")}, "filename": "empty.jpeg", "source_type": "raw_image"}

  • Now the Kaniko executor image (the image for building lambda) should be in the registry specified in the "LAMBDA_REGISTRY" setting.

    Instructions for transferring the Kaniko executor image from the VisionLabs registry to the user registry have been added to the installation manual.

  • New connection settings with Redis and Redis Sentinel have been added.

    The "user" parameter has been added to the settings groups "REDIS_DB_ADDRESS", "TASKS_REDIS_DB_ADDRESS", "LUNA_ATTRIBUTES_DB", "BACKPORT3_EVENTS_DB_ADDRESS".

    The "user" and "password" parameters have been added to the "sentinel" section of the above settings.

  • Guardant has been updated from version 3.15 to 3.21.