LUNA PLATFORM v.5.8.0

Изменения

• В политику \«detect_policy\» для ресурсов \«/handlers\» и \«/verifiers\» добавлены параметры для работы с Liveness V2. При включении определения Liveness следует учитывать требования Liveness V2 к входящим изображениям. См. \«Требования Liveness V2\» для получения более подробной информации.

  При отсутствии лицензии для Liveness V2 в ответе на запросы \«/handlers/{handler_id}/events\» и \«/verifiers/{verifier_id}/verifications\» вернётся ошибка \«License problem: 'Liveness v.2 feature disabled'\». Поэтому при отсутствии лицензии значение \«estimate_liveness > estimate\» должно равняться 0.

  Для обработчиков сервиса Backport 4 возможность определения Liveness недоступна.

  Liveness в обработчиках (handlers и verifiers)

  Группа параметров \«estimate_liveness\» позволяет включить определение Liveness и статуса входящего изображения:

  • \«estimate\» — включить определение Liveness на входящих изображениях. По умолчанию значение равно \«0\», и Liveness V2 не используется.
  • \«liveness_threshold\» — задать порог Liveness. Лицо на входящем изображении будет считаться настоящим (статус \«real\») только если значение Liveness равно или превышает заданный порог. В противном случае лицо будет считаться фейком (статус \«spoof\»). Значение по умолчанию: \«0.88\».
  • \«quality_threshold\» — задать порог качества изображения для оценки Liveness. Если качество входящего ниже указанного порога, то событию будет присвоен статус \«unknown\». Значение по умолчанию: \«0\».

  Параметр \«liveness_states\» позволяет задать фильтр по статусам Liveness. Обработаны будут только те события, статусы которых соответствуют одному из указанных в данном параметре статусу.

  Если событие отфильтровано по \«liveness_states\», то для его детекции лица в ответе возвращаются все определённые свойства лица, но последующие политики \«extract_policy\», \«match_policy\», \«storage_policy\», \«conditional_tags_policy\» не будут выполнены для данного события.

  В фильтре \«liveness_states\» можно указать одно или несколько значений из следующего списка:

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

  По умолчанию значение параметра равняется \«null\», фильтрация по нему не выполняется. Если использование Liveness выключено в \«estimate_liveness > estimate\», то поле игнорируется.

  Фильтр \«liveness\» добавлен в следующие политики:

  • \«match_policy\».
  • \«storage_policy\» для всех создаваемых объектов.
  • \«conditional_tags_policy\».

  Поле \«liveness\» добавлено в политику \«match_policy\» в качестве возможного значения поля target.

  Агрегация результатов Liveness

  При включённой в запросе \«/handlers/{handler_id}/events\» опции \«aggregate_attributes\» для нескольких переданных изображений будет выполнена агрегация результатов проверки Liveness для получения более точных данных. Эти данные будут возвращены в поле \«aggregate_estimations\».

  Поле \«aggregate_estimations\» является обязательным и всегда возвращается в ответе на данный запрос. При этом в ответе также возвращаются значения Liveness для каждой из детекций. При отключённой опции \«aggregate_attributes\» значения Liveness для детекции лица и значения в поле \«aggregate_estimations\» будут одинаковыми.

  При сохранении события в БД Events будет записан агрегированный результат проверки Liveness из поля \«aggregate_estimations\».

  Новое поле «liveness»

  Поле \«liveness\» было добавлено в события. Это позволяет:

  • Получать события, используя фильтр \«liveness\», и указывать \«liveness\» в качестве \«target\» в запросе GET \«/events\».
  • Получать статистику по событиям и указывать \«liveness\» в качестве target или фильтра в запросе GET \«/events/statistics\».
  • Использовать \«liveness\» в качестве фильтра для событий в запросе в ресурс \«/ws\» и получать значения \«liveness\» в ответе данного ресурса.

  Поле \«liveness\» было поддержано в качестве:

  • фильтра для событий для запросов сравнения \«/matcher/face\» и \«/matcher/body\».
  • фильтра для событий в задачах перекрестного сравнения (\«/tasks/cross_match\»), кластеризации (\«/tasks/clustering\»), и привязки (\«/tasks/linker\»).
  • столбца для отчёта в задаче создания отчета (\«/tasks/reporter\»).

  Значения параметров \«liveness\» можно задать при ручном создании события с помощью ресурса \«/handles/{handler_id}/events/raw\». Возможно указать как отдельные значения Liveness для каждой детекции лица, так и агрегированное значение.

• Добавлена возможность повторно извлекать базовые атрибуты и биометрические шаблоны лиц и тел для событий в запросе \«/tasks/additional_extract\» в сервисе Admin. Теперь возможен переход на новую версию нейросети для событий.

  В задачу \«/tasks/additional_extract\» добавлены:

  • Возможность задавать события в качестве объектов для обновления биометрических шаблонов лиц и базовых атрибутов.
  • Возможность повторно извлекать биометрические шаблоны тел для событий.

  В запросе в задаче повторного извлечения биометрических шаблонов следует указать извлечение базовых атрибутов или биометрических шаблонов (лиц или тел). После этого для извлечения биометрических шаблонов в фильтрах следует указать, для каких объектов (лиц или событий) следует извлечь биометрические шаблоны.

  В пользовательский интерфейс сервиса Admin добавлена возможность повторно извлекать атрибуты событий. Для этого следует выбрать \«Events\» в качестве \«Object type\» и указать \«Face\» или \«Body\» в качестве \«Descriptor type\».

  В сервисе Events добавлен запрос PATCH в ресурс \«/events/{event_id}\» для обновления базовых атрибутов и биометрических шаблонов существующих событий.

  В сервис Events добавлены ресурсы для получения событий с биометрическими образцами и отсутствующими атрибутами \«/events/attributes/missing\» и для подсчёта количества таких событий \«/events/attributes/missing/count\».

  См. дополнительную информацию в \«Запуск задачи повторного извлечения\» в документе LP_Administration_Manual.

• В сервисах API, Faces, Image Store, Tasks, Events, Configurator, Sender, Handles, Backport 3, Backport 4, Licenses теперь используется Python 3.9. Поддержка более старых версий Python прекращена.

  Для работы клиентской библиотеки \«luna3\», скриптов миграции с LP 3 и скрипта загрузки изображений \«folder_uploader.py\» доступно использование Python 3.7 и более новых версий.

• В POST запрос в ресурс \«/handlers/{handler_id}/events\» для схем \«application/json\» и \«multipart/form-data\» добавлено поле \«image_origin\».

  В этом поле можно указать ссылку на исходное изображение для каждого из передаваемых в запросе изображений. Переданный URL будет добавлен в поле \«image_origin\» созданного события.

  Изображение, переданное в поле \«image_origin\», не будет обработано в запросе \«/handlers/{handler_id}/events\», оно используется только в качестве исходного изображения.

  Если поле \«image_origin\» в запросе не пустое, то указанная в нём ссылка будет использована в создаваемом событии независимо от настроек в политике \«image_origin_policy\».

  См. дополнительную информацию о сохранении исходных изображений в события в разделе \«Особенности сохранения исходных изображений\» в LP_Administration_Manual.

• Добавлена поддержка символов UTF8 в тегах EXIF. Добавлено распознавание кириллицы.

  Символы в ответе ограничены множеством ASCII. Для всех символов в тегах EXIF, которые не входят в это множество, используется экранирование.

  Например, экранированные символы для тега «artist\» будут выглядеть следующим образом:

  "exif": {"artist":"\u041f\u043e\u043f\u043e\u0432"}

Исправленные ошибки

• В OpenAPI документации сервиса Image Store были добавлены отсутствовавшие схемы ответов..
• Исправлена ошибка, когда некоторые EXIF теги изображений приводили к \«Internal server error\».