Skip to content

LUNA PLATFORM v.5.16.0#

Changes

  • The "top_similar_external_id" field was added to the events, containing the "external_id" of the most similar candidate (event or face) with whom the face was matched.

    The "external_id" field was added to the "top_match" event object, which contains the "external_id" of candidates for matching in responses to the following requests: * "generate events". * "get event". * "ws handshake".

    These fields enable you to immediately receive the "external_id" of the most similar faces or events after performing requests. For example, previously, the event did not contain the "external_id" of the most similar face, either in the response to the request or in the event database. An additional request was required to determine the "external_id" of a face by his "face_id".

    Appropriate filters were added to the requests listed below to sort events by the external ID of the most similar object:

    • The "top_similar_external_ids" filter was added to the "match_policy" policy for events (see the policy description in the "create handler" request).

    • Filtering by the value of the "top_similar_external_ids" parameter for receiving events in API and Events services was added (see the "get events" request).

    • The "top_similar_external_id" filter and target were added to the request for getting statistics on events in API and Events services (see the "get statistics on events" request).

    • The "top_similar_external_id" filter was added when specifying events as candidates for "match faces" and "match bodies" requests.

    • The "top_similar_external_id" filter was added to the event filters for the following tasks:

    • "linker task"

    • "clustering task"
    • "cross-matching task"
    • "exporter task"

    The "top_match" column in the results of reporter task and exporter task now contains the "external_id" of the top matching candidate.

  • For candidates in the "matching faces" and "human body matching" requests, the "order" parameter was added, which determines the sorting order of the results. Sorting is available in ascending order of event creation time (option "create_time_asc"), in descending order of event creation time (option "create_time_desc") and by candidate similarity (option "similarity").

    Using the new sorting parameters enables, for example, to get events and faces in the order in which they transferred into the system. In this way, you can determine the first occurrence of the object.

    For the time sorting parameters to work correctly, you need to set a threshold based on the objects similarity. When specifying new sorting parameters, database matching is used. The request processing speed will be lower than when matching a list sorted by "similarity".

    By default, the "similarity" option is used.

  • The "limit" parameter was added to the "clustering task", which enables you to set the maximum number of candidates returned for each matching. The default value was changed from 5 to 20 000.

    The parameter controls the number of candidates returned in the response. The more candidates come back, the better. But with a large cluster size, there may be performance and accuracy issues.

Fixed errors

  • The error was fixed, in which the specified "targets" parameters were not returned in the results of Backport 4 requests for matching by indexed list, and the default set of fields was returned as "targets". The problem occurred in the Python Matcher Proxy service when performing a matching of one reference with several candidates.

  • The image loading behavior was changed. Now each image is loaded independently. If an error occurs when loading one of the images, the loading of other images is not interrupted.

  • The "result" field in the response to the "get task result" request for the estimator task is no longer required in the Tasks service.

    If an error occurs during the performing of one subtask, then only the "errors" field with an error will be returned in the response body. Previously, an empty "result" field was returned along with "errors".

  • In the Tasks service, the limitations for markup the "ROC-curve calculating task" were fixed. The maximum value can now be set to 20 000 elements.

    Previously, when transferring more than 20 000 elements, the error "Uncaught exception occurred" was returned in the logs of the Tasks Worker service. An error with the level "Error" and a description of the error are now returned.

  • The unused "CLUSTERING_MATCH_LIMIT" setting was removed from the Configurator service settings.

  • The information returned in the "LUNA_CONFIGURATOR" section in response to the "get service configuration" request was fixed. It now contains the current state of the parameter.

  • In the "EventsReferenceManual.html" document, the description for the following fields in the "create new events" request schema now specifies that the fields are not "Nullable":

    • matches/candidates/face/external_id
    • matches/candidates/face/user_data
    • matches/candidates/event/external_id
    • matches/candidates/event/handler_id
    • matches/candidates/event/user_data

  • In the "EventsReferenceManual.html" document, the description for the following fields in the "get event" and "get events" request schemas now specifies that the fields are "Nullable":

    • top_match/event_id
    • top_match/face_id
    • match_result/candidates/event/event_id
    • match_result/candidates/event/create_time

  • In the "EventsReferenceManual.html" document, the description for the following fields in the "face matching" and "human body matching" request schemas now specifies that the fields are "Nullable":

    • matches/result/event/top_match/event_id
    • matches/result/event/top_match/face_id

  • In the "SenderReferenceManual.html" document, the description for the following fields in the "ws handshake" request schema now specifies that the fields are "Nullable":

    • event/matches/candidates/event/match_result/candidates/event/external_id
    • event/matches/candidates/event/match_result/candidates/event/user_data
    • event/matches/candidates/event/match_result/candidates/event/top_match/face/face_id
    • event/matches/candidates/event/match_result/candidates/event/top_match/event/event_id

  • In the "HandlersReferenceManual.html" document, the description for the following field in the "generate events" request schema now specifies that the fields are "Nullable":

    • events/matches/candidates/event/match_result/candidates/event/user_data