Skip to content

LUNA PLATFORM v.5.8.0#

Changes

  • The parameters for using Liveness V2 were added to the "detect_policy" of resources "/handlers" and "/verifiers". When Liveness estimation is enabled, the requirements of Liveness V2 for the incoming images should be considered. See "Liveness V2 Requirements" for details.

    When Liveness V2 license is absent the "License problem: 'Liveness v.2 feature disabled'" error is returned in the response to the "handlers/handler_id/events" and "/verifiers/verifier_id/verifications" requests. The "estimate_liveness > estimate" should be set to "0" when there is no Liveness V2 license.

    Liveness estimation is not provided for the Backport 4 service handlers.

    Liveness in handlers and verifiers

    The "estimate_liveness" group of parameters provides the possibility to enable the estimation of Liveness and the status of the incoming image:

    • "estimate" — enable Liveness estimation in the incoming images. The default value is set to "0" and Liveness V2 is not used.
    • "liveness_threshold" — set Liveness threshold. The face in the incoming image will be considered real ("real" state) if the Liveness value is greater or equal to the specified threshold Otherwise, the face will be considered a spoof ("spoof" state). The default value is "0.88".
    • "quality_threshold" — set the image quality threshold for Liveness estimation. If the quality is lower than the specified threshold, the "unknown" state will be set. Default value: "0". The "liveness_states" parameter enables you to set a filter by Liveness states. You should set Liveness states values. Only events with an estimated liveness state equal to one of the specified liveness states will be processed.

    If an event is filtered by "liveness_states", the estimated face properties are returned for the face detection but the "extract_policy", "match_policy", "storage_policy", "conditional_tags_policy" policies will not be performed for the event.

    One or several values from the list can be set for the "liveness_states" filter:

    • spoof — 0
    • real — 1
    • unknown — 2

    The default parameter value is set to "null", and filtration is not performed. The field is ignored if Liveness estimation is disabled in the "estimate_liveness > estimate".

    The "liveness" filter was added to the following policies:

    • "match_policy".
    • "storage_policy" for all the objects.
    • "conditional_tags_policy".

    The "liveness" field was added to the "match_policy" as a possible "target" value.

    Liveness results aggregation

    When the "aggregate_attributes" option is enabled in the "handlers/handler_id/events" request, the aggregation of the Liveness estimation results will be performed for several processed images to receive more precise data. The data will be returned in the "aggregate_estimations" field.

    The "aggregate_estimations" field is mandatory and is always returned in the response. The response also includes Liveness estimation values for each of the detections. When the "aggregate_attributes" option is disabled, the Liveness values for the face detection and values in the "aggregate_estimations" field will be the same.

    When an event is saved, the aggregated Liveness result from the "aggregate_estimations" field is saved in the database.

    New liveness field

    The "liveness" field was added to events. The following features are provided:

    • Receive events using the "liveness" filter and set "liveness" as a "target" in the GET "/events" request.
    • Receive statistics on events and set "liveness" as a target and filter in the GET "/events/statistics" request.
    • Use "liveness" as a filter for events in the request to the "/ws" resource and get "liveness" values in response to this resource.

    The "liveness" field was supported as:

    You can set liveness parameters values when manually save events using the "/handles/handler_id/events/raw" resource. A separate liveness value can be set for each face detection and an aggregated value can be set.

  • The "/tasks/additional_extract" request from the Admin service now supports the re-extraction of basic attributes and descriptors for faces and bodies saved in events. The transition to a new version of the neural network for events is now supported.

    The following features were added to the "/tasks/additional_extract":

    • Set events as objects for descriptors and basic attributes extraction.
    • Re-extract body descriptors for events.

    You should specify descriptors (faces or bodies) or basic_attributes to be re-extracted. Then it is required to specify a filter for objects (faces or events) for which the descriptors should be extracted (for descriptors only).

    The re-extraction of events attributes was added to the Admin user interface. You should select "Events" as "Object type" and set "Face" or "Body" as "Descriptor type".

    The PATCH request to the "/events/{event_id}" resource for updating of basic attributes and descriptors of existing events was added.

    The resources for receiving events with samples and attributes "/events/attributes/missing" and calculation of the number of such events "/events/attributes/missing/count" were added to the Events service.

    See additional information about source images saving for events in the "Launch re-extraction task" in LP_Administrator_Manual.

  • Python 3.9 is now used for API, Faces, Image Store, Tasks, Events, Configurator, Sender, Handles, Backport 3, Backport 4, Licenses services. Older versions of Python are no longer supported.

    Python 3.7 and newer can still be used for "luna3" client library, the "folder_uploader.py" script for images downloading, and the scripts for migration from LP 3.

  • The "image_origin" field was added to the POST request to the "handlers/handler_id/events" resource for "application/json" and "multipart/form-data" body schemas.

    One can specify a link to the source image for each of the images provided in the request. The URL will be added to the "image_origin" field of the created event.

    The image provided in the "image_origin" field will not be processed in the "handlers/handler_id/events" request. It is used as a source image only.

    If the "image_origin" is not empty, the provided URL will be used in the created event regardless of the "image_origin_policy" policy.

    See additional information about source images saving for events in the "Saving source images" in LP_Administrator_Manual.

  • The support of UTF8 symbols was added for EXIF tags. Recognition of Cyrillic was added.

    Symbols in response are limited by ASCII encoding. Screening is used for all characters in EXIF tags, which are not included in the ASCII set.

    An example of screening for the "artist" EXIF field: '"exif": {"artist":"\u041f\u043e\u043f\u043e\u0432"'.

Fixed errors

  • Missing response schemas were added in the OpenAPI documentation of the Image Store service.

  • Fixed was the error when EXIF tags were causing "Internal server error".