v.5.101.0#

Изменения

SDK был обновлен до версии 5.28.1.

В данной версии LUNA PLATFORM:
- обновлен эстиматор OneShotLiveness до версии 10;
- добавлен новый эстиматор Face Image Modification (см. ниже).
Добавлен новый эстиматор Face Image Modification, который позволяет автоматически определять факт модификации/редактирования изображения по наличию характерных артефактов:
- рамки (зеленые/черные), свидетельствующие о битых пикселях или о факте того, что изображение является скриншотом;
- водяные знаки/логотипы;
- наложенные изображения (композиции из нескольких изображений);
- наложенные фигуры (графические элементы поверх изображения);
- наложенные текстовые элементы (нумерация, надписи). Система реагирует только на текст, искусственно наложенный при редактировании, естественные элементы (тату, надписи на одежде) не учитываются.
Система будет считать, что изображение было модифицировано, если полученная оценка (значение от 0 до 1) будет ниже установленного порога. Значение порога по умолчанию — 0.5 (50%).

Требования к изображению:
- минимальное разрешение 640 x 480 пикселей;
- наличие только одного лица на изображении.
Ресурсы, в которых выполняется проверка:
- "/handlers"
  
  Название проверки — "policies" > "detect_policy" > "face_quality" > "checks" > "image_modification".
- "/verifiers"
  
  Название проверки — "policies" > "detect_policy" > "face_quality" > "checks" > "image_modification".
В сервис Image Store добавлена поддержка очистки объектов, созданных до внедрения lifecycle-политик, на основе TTL (Time To Live - автоматическое удаление файлов по истечении заданного срока) в S3-совместимых хранилищах без тегирования.

Теперь логика очистки S3-совместимых хранилищ приведена в соответствие с локальным хранилищем, где политики хранения хранятся в метафайлах:
- если в метаданных объекта не указано значение, отвечающее за срок жизни, решение о его удалении принимается на основе политики родительского бакета (ранее такие объекты не удалялись,что могло приводить к накоплению "устаревших" данных).
- если в метаданных объекта указано определенное значение, которого отличается от значения по умолчанию, удаление происходит только на основании этого значения, без дополнительной проверки политики бакета.
В мониторинг сервиса Video Agent добавлена новая серия frames, содержащая информацию о процессе декодирования потока. Каждая точка содержит данные о декодированных и пропущенных кадрах за определенный период.

См. подробную информацию в разделе "Monitoring" руководства разработчика.
Обновлена работа выполнения запросов "patch stream" и "patch streams in group".

Данные запросы больше не возвращают ошибку, когда невозможно перевести потоки в статус stop/pending. В этом случае теперь возвращается ответ с кодом состояния 200 и полем patched_count, содержащим количество потоков, состояние которых было изменено в результате выполнения запроса.
- "patched_count": 0 или 1 - ответ для "patch stream", где 0 — если ни поток, ни его части (если поток разделяемый) не изменились, 1 — если поток (или хотя бы одна его часть) изменил статус.
- "patched_count": N - ответ для "patch streams in group", где, N — количество потоков, у которых хотя бы одна часть изменила статус. Части потока не считаются отдельно (1 поток = 1 изменение, даже если поменялись несколько его частей).
В запросы "create stream", "put stream" и "video analytics" добавлен параметр fps, позволяющий регулировать максимальную частоту кадров при декодировании видео.

Этот параметр позволяет ограничить частоту кадров, которые передаются в аналитики. Т.е. в отличие от параметра rate, который настраивается для каждой аналитики отдельно, параметр fps применяется ко всем аналитикам сразу, что обеспечивает экономию ресурсов на декодирование видео, а также позволяет снизить нагрузку на систему при работе с менее требовательными аналитиками.

Обратите внимание, что значение fps должно соответствовать требованиям всех используемых аналитик. Для получения информации см. раздел "Аналитики".

Расположение fps:
- для ресурса "/videosdk" в секции video;
- для операций с потоками ("create stream"/"put stream") в секции data.
Теперь при старте сервиса Admin не проводится проверка наличия учетной записи администратора в рамках healthcheck.

Проверка соединения выполняется для исключения ошибок, связанных с неправильной конфигурацией LUNA PLATFORM.

Теперь запуск сервиса Admin возможен без обязательного наличия учётной записи администратора.
Теперь при создании и обновлении обработчика пользователю доступна возможность задавать максимальное количество элементов в массиве match_policy политики сравнения.

Для этого в группу настроек LUNA_HANDLERS_LIMITS был добавлен новый параметр match_policy_array_limit. По умолчанию для максимальной длины массива установлено значение 30 (как раньше).

См. запросы "create handler" и "replace handler".
В контейнерах сервисов Video Manager и Video Agent версия Python обновлена до 3.13.

Поддержка более старых версий Python прекращена.
Обновлена политика доступа к аналитикам агентов (например, агент, представленный в виде сервиса Video Agent).

Агенты могут быть внутренними (агенты, взаимодействующие напрямую с сервисами платформы) и внешними (агенты, взаимодействующие только через API и запущенные вне основного контура платформы, см. "внешний режим работы агента").

Если аналитики созданы внутренними агентами, они будут доступны всем пользователям. Аналитики, созданные внешними агентами, будут доступны только тем пользователям, которые авторизовываются в платформе под тем же account_id что и регистрируется внешний агент (независимо от типа авторизации, т.е. как BasicAuth так и BearerAuth).

Если какая-либо аналитика зарегистрирована внешним агентом, а затем зарегистрирована внутренним агентом, такая аналитика станет доступна всем пользователям, изменить это можно только, удалив ее вручную.

Имена аналитик должны быть уникальными.

Ранее не было четкого разделения прав доступа к аналитикам между внутренними и внешними агентами.

См. подробную информацию в разделе "Analytics" руководства разработчика.
Для лямбд с типом Handlers и Standalone обновлена версия SDK с v.5.21.0 до v.5.26.0.

Также теперь требуется наличие Python 3.13 для написания лямбд. Поддержка старых версий прекращена.
Добавлена возможность создания лямбды из заранее предсобранного образа.

Использование предсобранного образа может быть полезно, когда целевой сервер не имеет достаточно вычислительных ресурсов для сборки образа или когда требуется развернуть одну и ту же лямбду на нескольких экземплярах LP, не выполняя повторной сборки.

Существующий образ для импортирования можно получить с помощью нового запроса "get lambda image" к сервису Lambda. Если планируемая лямбда запускается в другом контуре, то необходимо перенести соответствующий образ в используемое хранилище образов.

Новая лямбда может быть создана из существующего образа путем предоставления параметров name и tag в группе параметров imported_image в запросе на создание/обновление лямбды.
Были удалены документы "Руководство по установке" и "Руководство по обновлению", которые описывали общий подход для развертывания LUNA PLATFORM в Docker-контейнерах без использования утилиты Storages.

В соответствии с данными документами, для подготовки окружения приходилось вручную создавать бакеты, создавать/мигрировать базы данных в PostgresSQL, включать мониторинг сервисов LUNA PLATFORM, добавлять библиотеку VLMatch для матчинга в PostreSQL. Теперь установка и обновление возможны только через утилиту Storages — она автоматизирует все этапы. Достаточно указать необходимые флаги в конфигурационном файле утилиты Storages.

Важно! Обновление с помощью утилиты Storages возможно только для версий LUNA PLATFORM v.5.46.1 и выше. При обновлении с более ранних версий необходимо запросить документацию соответствующей версии у специалистов VisionLabs. По полученной документации выполните обновление до v.5.46.1 (с поддержкой утилиты Storages), затем воспользуйтесь данным руководством для обновления до последней версии LUNA PLATFORM.

Для получения подробной информации по утилите Storages см. раздел "Руководство по утилите Storages".

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

Исправлена некорректная работа сортировки потоков по умолчанию при выполнении запроса "get streams".

Параметр order задает порядок сортировки. Если задано значение desc (установлено по умолчанию), сначала будут отображаться самые новые события. Если задано значение asc, первыми будут показаны самые старые события.

Ранее было несоответствие - новые/измененные потоки попадали в конец списка, фактически применялась сортировка asc. Теперь при запросе без явного указания order автоматически применяется desc, как указано в документации.
Исправлено поведение, которое периодически приводило к появлению ошибки с кодом состояния 500 при сохранении событий.
Исправлена некорректная обработка запроса получения данных о лицензии "get license".

Ранее в ответе ошибочно возвращались ранее запрашиваемые функции. Теперь "get license" возвращает только явно запрошенные в текущем запросе пользовательские функции.
При отсутствии кандидатов для запроса сравнения по обобщенным событиям "general events matching" теперь возвращается пустой массив вместо ошибки с кодом состояния 400.

Изменения UI сервиса API

В раздел "Верификация" добавили уведомления о фильтрациях. Ранее при фильтрации изображений возвращалась ошибка.
Раздел "Проверки":
- Добавлены параметры для оценки перекрытия лица.
- Добавлено информационное окно, которое отображается при отсутствии результатов проверки видео.
- Теперь к результатам проверок Liveness и Deepfake добавлена информация о соответствии входящего изображения требованиям данных эстиматоров:
  - Отсутствие модификации изображения;
  - Одно лицо в кадре;
  - Углы поворота и наклона головы не должны превышать 25 градусов;
  - Лицо не должно быть затемнено, засвечено или размыто;
  - Отступы лица от краёв кадра должны составлять не менее 10 пикселей по каждой стороне;
  - Размер лица в кадре по ширине должен быть не менее 150 пикселей;
  - Размер кадра по ширине и высоте должен находиться в диапазоне от 720 до 1920 пикселей.