Перейти к содержанию

# v.5.137.0

Изменения

- SDK обновлён до версии 5.32.0.

  В данной версии:

  - эстиматор Deepfake обновлён до версии 10
  - эстиматор OneShotLiveness обновлён до версии 13
  - эстиматор HeadPoseEstimator обновлён до версии 4

- Теперь в ресурсах `/images` и `/objects` доступна система папок — новый способ организации файлов.

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

  Основные операции для ресурсов `/images` и `/objects` при работе с папками:

  1. Создание и удаление папок (вместе с содержимым).
  2. Получение информации о папке и проверка ее существования.
  3. Работа с файлами внутри папок:
     - загрузка файлов с автоматическим созданием вложенных папок (например, при загрузке файла по пути `6/images/folder/subfolder1/subfolder2/filename` система создаст недостающие папки `subfolder1` и `subfolder2`, а корневая папка `folder` должна быть создана заранее).
     - получение и проверка существования файлов.
     - удаление вложенных папок и файлов.
  4. Получение списка файлов в папке.
  5. Копирование файлов и папок (только внутри одного типа ресурсов).

  Ключевые особенности работы с папками:

  - изоляция по аккаунтам — каждая папка принадлежит конкретному аккаунту. Для операций с папками используются те же токены доступа, что и для работы с ресурсами `/images` и `/objects`.
  - работает как с локальным диском, так и с S3-хранилищем. Примечание. В S3-хранилище "папки" — это логическая группировка файлов по префиксам в их именах. Например, файл `folder/file.txt` будет отображаться как находящийся в папке folder, хотя физически это просто часть его имени.

  Полный список новых запросов для работы с папками см. в ресурсах `/images` и `/objects`.

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

  Ранее группировка потоков позволяла только запускать, останавливать и удалять потоки. Теперь группы потоков могут содержать общие настройки (`stream_settings`) и аналитики (`analytics`), которые автоматически применяются ко всем связанным потокам по правилам объединения. Это позволяет:

  - упростить настройку множества потоков;
  - централизованно управлять аналитиками для групп камер.

  Подробно о правилах объединения и сценариих использования см. в разделе "Группировка потоков".

- Версия утилиты Guardant в поставке LUNA PLATFORM обновлена с версии 3.29 до 4.4.3.

- В запрос сравнения по обобщённым событиям (general events matching) добавлена фильтрация кандидатов по группам источников событий.

  Теперь с помощью параметра `source_groups` можно ограничить поиск кандидатов только теми обобщёнными событиями, которые принадлежат указанным группам.

  См. раздел "Работа с группами источников событий".

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

- Теперь при удалении лямбды (delete lambda) система также пытается удалить её образ из Docker registry.

  Для этого удаляется манифест образа в фоновом режиме. Операция выполняется только при включенной в Docker registry функции удаления (`storage.delete.enabled`). Если удаление невозможно, система фиксирует ошибку в базе мониторинга (серия `lambda_errors`). Успешное удаление манифеста также сохраняется в базе мониторинга.

  Примечание. После удаления манифеста образ становится недоступным и будет удалён при следующем запуске задачи сборки мусора (garbage collection) в registry.

  См. подробную информацию в разделе Lambda usage руководства разработчика.

# v.5.134.0

Изменения

- Добавлена поддержка работы с группами источников событий (`source_group`).

  Это изменение упрощает работу с событиями от логически связанных источников (например, набором видео, объединённых в одну группу), а также расширяет возможности фильтрации и классификации данных.

  Работа с группой источников событий затрагивает три ключевых этапа:

  1. Укажите группу источника событий при создании/редактировании потока в новое поле `event_source_group`. Если агент поддерживает это поле, данные из него будут сохраняться в каждом сгенерированном событии в поле `source_group`.

  2. Когда события созданы, с ними можно работать с помощью группы ресурсов `/general/events`, используя поле `source_group` для фильтрации обобщенных событий по группам источников.

  3. Для получения обобщенных событий по WebSocket используйте новый query-параметр `source_groups`. Можно указать одну или несколько групп источников событий через запятую (например, source_groups=group1,group2). Это позволяет подписаться на события сразу от всей группы источников или нескольких групп одновременно.

- Добавлена поддержка кодека `H.266` (или VVC - Versatile Video Coding) для декодирования видео на CPU.

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

- В сервис `Video Agent` добавлен новый запрос `get agent info`, позволяющий получить информацию об агенте.

  В ответе возвращаются следущие данные:

  - `agent_id` — идентификатор агента;
  - `analytics` — список аналитик;
  - `streams` — информация об обрабатываемых потоках, включая их количество и идентификаторы;
  - `groups` — имена или идентификаторы групп источников, потоки из которых обрабатываются агентом.

# v.5.130.0

Изменения

- Изменена временная зона внутри контейнеров сервисов LUNA PLATFORM с MSK (Europe/Moscow) на UTC.

  При необходимости можно вернуть прежний часовой пояс, явно указав его при запуске контейнера:

      docker run -e TZ=Europe/Moscow

  В поставочные Helm-чарты k8s в секцию `env` также добавлены комментарии по установке собственной временной зоны.

  В скрипте Docker Compose в комплекте поставки для контейнеров используется временная зона хоста за счет следующего монтирования:

      volumes:
        - /etc/localtime:/etc/localtime:ro

  Соответственно, изменение временной зоны не повлияет на установку через поставочный скрипт Docker Compose.

- Расширены допустимые форматы электронной почты при создании аккаунтов.

  Теперь при создании аккаунта поддерживаются адреса с поддоменами. Например, стали допустимы адреса вида "username@sub.domain.com", которые ранее не проходили валидацию. При этом сохраняется ограничение: доменная часть адреса не может начинаться или заканчиваться точкой.

  Подробнее см. в разделе "Аккаунты, токены и способы авторизации".

- Внутренняя библиотека лицензирования обновлена до версии `1.13.0`.

- Обновлена работа с пользовательскими функциями лицензии.

  В ответе на запрос "get license" сервиса Licenses для пользовательских функций теперь возвращаются данные о сроке действия и доступности функции.

- В запросе на получение статистики по обобщённым событиям добавлена поддержка агрегация `group_by` для вложенных полей `event.*`.

  Теперь можно группировать данные по любым вложенным полям события, например, `event.user_info.temperature` — для анализа распределения температурных показателей пользователей.

  Пример запроса:

      {
      "targets": [
          {"column": "event_id", "aggregator": "count"},
          {"column": "event.user_info.temperature", "aggregator": "group_by"}
      ]
      }

  Пример ответа:

      {
      "fields": [
          "event.user_info.temperature, aggregator 'group_by'",
          "event_id, aggregator 'count'"
      ],
      "stats": [
          ["36.6", 45],
          ["37.0", 23],
          ["37.5", 34]
      ]
      }

  Здесь "36.6", "37.0" и "37.5" — значения температур, а 45, 23, 34 — количество событий для каждой группы.

  Примечание. При использовании агрегатора `group_by` значения группируемых полей всегда конвертируются в строковый тип данных.

  См. запрос "get statistics on general events".

- Для видеоаналитик теперь доступен новый тип callback'а `luna-kafka`, позволяющий отправлять данные о событиях в Apache Kafka. Это расширяет возможности интеграции с системами, использующими Kafka для потоковой обработки данных.

  Для настройки callback'а `luna-kafka` используются следующие параметры:

  - servers - один или несколько адресов Kafka-серверов
  - topic - топик для отправки сообщений
  - protocol - протокол безопасности
  - username, password - имя пользователя и пароль для аутентификации SASL

  Подробнее о типах см. в разделе "Отправка и сохранение результатов аналитики".

- В руководстве разработчика сервиса Lambda обновлен пример использования `Agent-Lambda` с аналитикой для обнаружения людей в костюмах/спецодежде.

  Теперь в примере явно указано имя папки (`suit_analytics`) для размещения файлов пользовательской аналитики и приведён список необходимых файлов. См. подробную информацию в разделе Agent lambda examples.

- Добавлена возможность управлять активностью лямбд через новый параметр `eternal` для оптимизации ресурсов кластера Kubernetes.

  Теперь при создании, обновлении и импорте лямбд можно использовать параметр `eternal`, который принимает следующие значения:

  - `0` (значение по умолчанию): лямбда будет автоматически отключена, если не используются в течение времени, заданного в настройке `LUNA_LAMBDA_INACTIVE_LAMBDA_CLEAR_INTERVAL`.
  - `1`: лямбда будет активна до тех пор, пока не будет отключена вручную.

  Для лямбд с `eternal = 0` доступен новый параметр `last_usage`, который отображает время последней активности лямбды. Это значение обновляется на основе метрики `last_activity`, которую лямбда отправляет при каждом использовании. См. get lambda и get lambdas.

  Важно! Для автоматического отключения неактивных лямбд необходимо включить настройку `LUNA_LAMBDA_METRICS_SETTINGS`.

  Подробнее см. в разделе last activity руководства разработчика.

- Добавлена новая группа параметров `LUNA_LAMBDA_INACTIVE_LAMBDA_CLEAR_INTERVAL` для автоматического отключения неактивных лямбд.

  Это позволяет освободить ресурсы кластера Kubernetes, отключая лямбды, которые не использовались в течение заданного времени.

  Периодическое отключение неактивных лямбд настраивается с помощью параметров из группы `LUNA_LAMBDA_INACTIVE_LAMBDA_CLEAR_INTERVAL`:

  - `interval` — задаёт интервал неактивности. Значение по умолчанию — `3`.
  - `interval_type` — задает тип интервала (weeks, days, hours, minutes). Значение по умолчанию — `days`.
  - `check_interval` — задает частоту проверки активности лямбд (в секундах). Значение по умолчанию — `30`.
  - `active` — включает/выключает автоматическое отключение неактивных лямбд. По умолчанию — `true`.

  При включённом параметре `active` с настройками по умолчанию система каждые 30 секунд проверяет активность лямбд и отключает те, которые не использовались более 3 дней.

  Подробнее см. в разделе Отключение/включение lambda.

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

- Исправлена ошибка `segmentation fault`, которая ранее могла приводить к аварийному завершению обработки некоторых видео. Была улучшена логика обработки временных меток в декодере.

- Был обновлен медиасервер MediaMTX, который используется в составе сервиса `Streams Retranslator` для преобразования видеопотоков в формат HLS. Это позволило повысить стабильность работы HLS-ретрансляции.

- Исправлена ошибка кеширования в сервисе Licenses, которая могла влиять на корректность отображения статуса функций.

# v.5.128.0

Изменения

- Раздел "Руководство по обновлению" переименован в "Руководство по миграции (Обновление/даунгрейд)".

  Ранее в документации описывалась только процедура обновления на новую версию LUNA PLATFORM. Теперь в разделе явно описано, что утилита Storages поддерживает как обновление (upgrade) на более новую версию, так и понижение версии (downgrade) на более раннюю.

  См. "Руководство по миграции (обновление/даунгрейд)".

- В запрос для получения количества потоков добавлены новые параметры для фильтрации потоков по следующим критериям:

  - диапазону идентификаторов потоков (`stream_id__gte`, `stream_id__lt`);
  - названию и идентификатору группы (`group_name`, `group_id`);
  - идентификатору агента (`agent_id`).

- В запрос `get lambda metrics` добавлен новый параметр `resources`.

  Теперь с его помощью можно выбирать метрики для конкретных ресурсов lambda, например: `POST:/main` или `GET:/additional/{parameter}`. Параметр `resources` поддерживает перечисление нескольких ресурсов через запятую.

  Кроме того, расширен набор собираемых метрик:

  - для Agent-lambda добавлена новая метрика типа счётчик `agent_counter_total` с лейблом `agent_action`. Она позволяет отслеживать жизненный цикл потоков (старт, ошибки, удаление) и статистику по обработке кадров.
  - для Tasks-lambda добавлена новая метрика типа счётчик `tasks_counter_total` с лейблом `task_action`. Она позволяет отслеживать этапы работы с задачей: разделение на подзадачи, их выполнение, а также ошибки на каждом этапе.

  Подробные значения лейблов и описание метрик см. в разделе "Метрики Lambda".

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

- Исправлена ошибка, из-за которой данные об использовании эстиматора Face Image Modification не учитывались в системе мониторинга.

# v.5.126.0

Изменения

- SDK обновлён до версии 5.31.2.

  - DeepfakeEstimator обновлён до версии 9. Повышена точность работы алгоритма.
  - Параметр `numThreads` — теперь создаёт ровно `numThreads` потоков (ранее было `numThreads - 1`).

- Добавлен новый запрос `create restream`, позволяющий запускать HLS-ретрансляцию любого видеопотока по ссылке без создания сущности 'поток'.

  Это ускоряет настройку и тестирование потоков, позволяя сразу получать ссылку и токен для воспроизведения.

- В запрос `get faces` добавлены query-параметры `sort` и `order`, позволяющие настроить сортировку данных в теле ответа.

  Параметр `sort` может принимать значения `create_time`, `external_id`, `user_data`, `face_id` или `none` (отключает сортировку). Значение по умолчанию - `face_id`, если задан фильтр по `face_ids`, в остальных случаях - `create_time`.

  Параметр `order` задает порядок сортировки: `asc` — по возрастанию, `desc` — по убыванию (по умолчанию `desc`). Сортировка по `user_data` выполняется лексикографически (по алфавиту).

- Добавлен параметр `agent_groups` в запрос registration request.

  Настройка позволяет управлять распределением потоков по агентам. Если в параметре указана одна или несколько групп, то агент будет обрабатывать только потоки из этих групп. Возможно указание группы через `group_id` или `group_name`.

- Параметр `LUNA_VIDEO_AGENT_GROUPS` был добавлен для сервиса Video Agent. Он позволяет указывать группу потоков для агента. Только потоки из указанной группы будут обработаны.

  Возможно так же задавать группы в контейнере Luna-Video-Agent через переменные окружения:

  `VL_SETTINGS.LUNA_VIDEO_AGENT_GROUPS.GROUP_NAMES=[my_greate_group_1,my_greate_group_2]`

- Настройка `PIN_THREADS` удалена из разделов `LUNA_REMOTE_SDK_RUNTIME_SETTINGS`, `LUNA_LAMBDA_AGENT_UNIT_RUNTIME_SETTINGS`, `LUNA_VIDEO_AGENT_RUNTIME_SETTINGS`. Настройка более не используется.

- В запрос `get streams` добавлен параметр `order_column`.

  Он позволяет выполнять сортировку потоков по полю `name`. Ранее была доступна сортировка только по полю `create_time`.

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

- Добавлена поддержка пользовательской метаинформации (meta) для объектов.

  Теперь при создании объекта можно передавать пользовательские данные в виде набора заголовков `X-Luna-Meta-<ключ>`, где `<ключ>` — имя поля метаинформации, а значение заголовка — его содержимое (в формате JSON).

  Пример: `X-Luna-Meta-user_info: {"temperature": 36.6}`

  Для получения сохраненной метаинформации нужно в запросе на получение объекта использовать query-параметр `with_meta=1` — в этом случае метаданные вернутся в ответе также через заголовки запроса `X-Luna-Meta-*`.

- Сервис Video Agent теперь сразу отправляет отчет в сервис Video Manager для потоков, обработка которых завершилась или прервалась из-за ошибки.

  Раньше такие отчеты отправлялись периодически.

  См. подробную информацию в руководстве разработчика сервиса Video Agent.

- В группу параметров `LUNA_LAMBDA_AGENT_UNIT_RUNTIME_SETTINGS` добавлены новые настройки:

  - `PROGRAM_CACHE_SIZE` — ограничивает количество кэшируемых элементов, что ускоряет работу при большом числе задач;
  - `DEFAULT_GPU_DEVICE` — позволяет выбрать GPU-устройство по умолчанию (актуально для систем с несколькими GPU);
  - `CPU_HIGH_WATERMARK` и `GPU_HIGH_WATERMARK` — задают максимальный объём памяти для CPU и GPU.

  Для подробной информации см. документацию SDK.

- В сервис Video Agent добавлена ​​возможность задать уровень логирования SDK, передав в контейнер переменные окружения `LUNA_SDK_RUNTIME_LOG_LEVEL` и `LUNA_SDK_LOG_LEVEL`.

- Теперь сервис Lambda может собирать и сохранять метрики в формате Prometheus в виде временных рядов, что позволяет отслеживать поведение и состояние пользовательских лямбд.

  Доступен стандартный набор метрик, как и для других сервисов LUNA PLATFORM: общее количество запросов (`request_count_total`), общее количество ошибок (`errors_count_total`) и гистограмма длительности выполнения запросов (`requests`). См. Экспорт метрик в формате Prometheus.

  Для получения метрик конкретной lambda добавлен запрос `get lambda metrics`.

  Для сбора метрик необходимо:

  - запустить и настроить сервис Prometheus для сбора метрик с `/lambda_metrics`;
  - включить сбор метрик в группе настроек `LUNA_SERVICE_METRICS` сервиса Lambda;
  - в `LUNA_LAMBDA_METRICS_SETTINGS` установить параметр `origin` на актуальный IP-адрес Prometheus.

  См. подробную информацию в разделе Lambda руководства разработчика.

- Добавлена возможность включения/отключения lambda по запросу пользователя.

  Это позволяет освободить ресурсы кластера Kubernetes, когда какие-то из лямбд не используются, без удаления их данных. При этом запуск отключённой лямбды происходит быстро, без необходимости повторной сборки Docker-образа.

  Добавлен новый параметр `alive`, который отображает текущее состояние lambda: `0` (выключена) или `1` (включена). Этот параметр возвращается в ответе при запросе информации о лямбде через get lambda, а также в списке лямбд через get lambdas.

  Для управления состоянием lambda необходимо использовать запрос `switch lambda`.

  Примечание. Использование lambda в отключенном состоянии через ресурс `/lambdas/{lambda_id}/proxy` недоступно.

  См. подробную информацию в разделе Lambda руководства разработчика.

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

- Исправлена некорректная регистрация пути в метриках Prometheus для запросов с недопустимыми HTTP-методами (код состояния 405).

  Ранее при обращении к существующему маршруту с неподдерживаемым методом в метриках отображалось значение "{unknown_route}". Например, при выполнении запроса DELETE к `/version`:

  `{path="DELETE:{unknown_route}",service="luna-api",status_code="405"}`

  Теперь в метриках корректно указывается конкретный путь и метод запроса:

  `{path="DELETE:/version",service="luna-api",status_code="405"}`

- Исправлена неработающая отправка данных мониторинга функционала SDK в сервисе Video Agent.

- Исправлена проблема при которой сервис Remote SDK переставал выполнять эстимацию на новых фотоизображениях из-за некорректного выделения VRAM.

LUNA Vector Search Module

- Начиная с этой сборки для LUNA PLATFORM 5 доступен новый модуль LUNA Vector Search Module (LVSM), расширяющий возможности платформы за счёт использования векторной базы данных Qdrant.

  LUNA Vector Search Module — это модуль для создания векторных коллекций на основе пользовательских наборов дескрипторов LUNA PLATFORM 5, предназначенный для организации гибкого и высокопроизводительного матчинга по событиям. LVSM позволяет:

  - Организовывать быстрый и гибкий поиск по миллиардам векторов (дескрипторов) с использованием векторной базы данных Qdrant.
  - Создавать коллекции с автоматической синхронизацией данных из LUNA PLATFORM (синхронизация включает только добавление и удаление событий), поддерживая фильтрацию с учетом параметров (например, `account_id`, `create_time`).
  - Интегрироваться с существующей инфраструктурой LUNA PLATFORM через систему плагинов Python Matcher Proxy.

  Для реализации этих задач модуль использует векторную базу данных Qdrant, которая обеспечивает:

  - Встроенное шардирование — механизм горизонтального масштабирования, обеспечивающий равномерное распределение нагрузки и отказоустойчивость за счет автоматического распределения данных между шардами.
  - Построение индексов на GPU — расширяет область применения векторного поиска на задачи с большими объемами данных и требованиями к производительности.
  - Расширенные фильтры при поиске (включая временные промежутки и GPS-координаты) с возможностью постфильтрации — применения дополнительных фильтров к результатам поиска.

  LUNA Vector Search Module поставляется в качестве отдельного дистрибутива, содержащего руководство администратора с информацией о работе модуля, инструкции по установке (ручной и с помощью Docker Compose), спецификации OpenAPI и скрипты запуска.

  Для дополнительной информации см. руководство администратора LUNA Vector Search Module.

# v.5.122.0

Изменения

- Добавлена поддержка отправки данных мониторинга в `ClickHouse`.

  Теперь для всех сервисов LUNA PLATFORM поддерживается отправка данных мониторинга в ClickHouse — высокопроизводительную, столбцовую систему управления базами данных.

  В отличие от InfluxDB, где данные делятся на теги и поля, ClickHouse использует единую табличную структуру с поддержкой `JSON` формата. Каждая запись представляет собой строку таблицы, где:

  - поле `time` — временная метка создания записи;
  - поле `data` — JSON-объект, объединяющий все данные (включая то, что в InfluxDB хранилось бы как теги или поля).

  Основное преимущество перед InfluxDB — скорость: ClickHouse значительно быстрее обрабатывает сложные аналитические запросы и агрегации, особенно на больших объёмах данных.

  Примечание. На текущий момент вариантом по умолчанию остаётся `InfluxDB`. В будущих версиях LUNA PLATFORM возможен переход на `ClickHouse` для мониторинга.

  Для подробной информации см. раздел "Мониторинг". Процедуры настройки мониторинга также описаны в разделах, посвящённых установке и обновлению LUNA PLATFORM.

- Полностью прекращена поддержка следующих сервисов: `Backport 3`, `Backport 4`, `UI 3` и `UI 4`. Вся связанная с ними информация удалена из документации LUNA PLATFORM и скрипта Docker Compose.

- Возможность выбора режима работы (mode) для оценки `deepfake` объявлена deprecated и больше не учитывается в запросах.

  Параметр "estimation_mode" удален из групп параметров LUNA_REMOTE_SDK_DEEPFAKE_ESTIMATOR_SETTINGS и LUNA_VIDEO_AGENT_DEEPFAKE_ESTIMATOR_SETTINGS.

  Для обратной совместимости поле `mode` сохраняется в ответе, но всегда принимает значение по умолчанию `2`.

- Обновлена спецификация OpenAPI.

  Теперь для ресурса "/videosdk" по умолчанию отображается описание аналитики `human_tracking` вместо `people_count`.

  Чтобы использовать на аналитику `people_count`, необходимо указать соответствующее значение в поле "analytics > name".

- В группу параметров "LUNA_VIDEO_AGENT_RUNTIME_SETTINGS" добавлены новые настройки для управления ресурсами сервиса `Video Agent`.

  Эти параметры являются настройками среды выполнения LUNA SDK. Для подробной информации см. документацию SDK.

  Перечень новых настроек:

  - `PROGRAM_CACHE_SIZE` — ограничивает количество кэшируемых элементов, что ускоряет работу при большом числе задач;
  - `DEFAULT_GPU_DEVICE` — позволяет выбрать GPU-устройство по умолчанию (актуально для систем с несколькими GPU);
  - `CPU_HIGH_WATERMARK` и `GPU_HIGH_WATERMARK` — задают максимальный объём памяти для CPU и GPU;
  - `PIN_THREADS` — включает/отключает привязку потоков к ядрам процессора.

- Добавлена возможность управлять доступом к лямбдам через новый параметр `shared` в запросах.

  Ранее использовать lambda через ресурс "/lambdas/{lambda_id}/proxy" мог только создавший её пользователь. Теперь при создании, обновлении и импорте лямбды можно предоставить это право другим пользователям, настроив параметр `shared` в секции `parameters`.

  Параметр принимает следующие значения:

  - `0` (значение по умолчанию): лямбда будет доступна только пользователю, который её создал;
  - `1`: лямбда становится доступной для использования другими пользователями.

  Важно! Ограничение для лямбд типа `Agent`: если агент является внешним (параметр `external_agent = 1`), то такая лямбда не может быть общедоступной. Это связано с тем, что агенты во "внешнем режиме работы" взаимодействуют с платформой только через API (без доступа к основным сервисам).

  См. подробную информацию в разделе Lambda руководства разработчика.

- В руководство разработчика сервиса Lambda добавлен новый пример использования `Agent-Lambda`.

  `Agent-lambda` позволяет использовать не только стандартные аналитики (отслеживание людей и подсчет количества людей), но и собственные алгоритмы для видеоанализа, написанные на основе различных моделей нейронных сетей.

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

  См. подробную информацию в разделе Agent lambda examples.

# v.5.120.1

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

- Исправлена ошибка, из-за которой в ответе на запрос "get platform features" функция `Deepfake` была недоступна.

  Теперь при наличии в лицензии данной функции корректно возвращается статус `deepfake: true`, что обеспечивает доступ к оценке Deepfake.

- Исправлена ошибка, которая приводила к зависанию сервиса `Video Manager` при одновременной обработке большого количества запросов на остановку/возобновление обработки потоков.

- Исправлен код ответа, возвращаемый при обращении к ресурсу "/sdk": теперь в случае ошибки, связанной с нехваткой видеопамяти, возвращается код ответа 500 с сообщением Internal Server Error.

  Ранее в такой ситуации ошибочно возвращался код 200 (успешное выполнение запроса), хотя в теле ответа содержалось сообщение об ошибке.

# v.5.119.0

Изменения

- Оптимизирована работа процедуры сравнения.

  Скорость выполнения сравнения увеличилась на 3-5% в некоторых случаях благодаря обновлению библиотеки в сервисе Python Matcher.

- Отправка в `Video Manager` схем валидации аналитик, реализованных в `Video Agent`, включена по умолчанию.

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

- Добавлена возможность дополнительной настройки лямбд пользователем через сервис API.

  Теперь для каждой лямбды можно задать дополнительные настройки (user_config) в формате JSON. Это позволяет гибко управлять поведением лямбды (например, задавать пороговые значения или пути к файлам) без необходимости повторной сборки Docker-образа — система автоматически перезапускает лямбду с новыми параметрами.

  Настройки передаются при создании, обновлении или импорте лямбды через параметр `user_config`. Пример:

      {
        "SETTING_1": "value",
        "SETTING_2": {"key": "value"}
      }

  Добавлены новые запросы для получения и обновления настроек: "update lambda config" и "get lambda config"

  См. подробную информацию в разделе Lambda configuration руководства разработчика.

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

- Исправлена работа механизма `CORS`.

  Теперь заголовок `Access-Control-Expose-Headers` из группы параметров `LUNA_API_CORS`, содержащий `X-Luna-Meta-Rescale` и `X-Luna-Expiry-Date`, корректно возвращается во всех ответах сервера.

  Ранее он применялся только для предварительных запросов, что не соответствовало спецификации.

- Исправлена ошибка, при которой во время запуска сервиса `Video Agent` не выполнялась проверка соединения к сервису `Licenses`.

- Исправлено некорректное поведение при повторной регистрации аналитики, созданной внешним агентом.

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

  Для подробной информации см. документацию сервисов Video Manager и Video Agent в руководстве разработчика.

- Исправлена логика работы запроса "ws handshake for general events".

  Ранее пользователи могли получать через WebSocket обобщённые события из всех аккаунтов системы. Например, пользователь с правами `user`, видел события, созданные пользователем с правами `admin` из другого аккаунта.

  Теперь пользователи получают только те обобщенные события, которые созданы в рамках их собственной учетной записи.

- Исправлена ошибка в обработке запроса generate stream events, из-за которой для лица не устанавливалось поле `avatar`.

  Ранее поле `avatar` не устанавливалось, если у первого элемента массива детекций `sources > source` отсутствовал биометрический образец (БО) лица. Это происходило, даже если БО лица присутствовал в последующих детекциях того же события. Теперь система корректно обрабатывает все элементы массива и использует для аватара идентификатор БО лица из первого обнаружения, где он присутствует, независимо от порядка детекций.

- Исправлена ошибка, из-за которой отсутствовала документация OpenAPI для лямбд типа `agent` в ответ на запрос `get lambda openapi documentation`.

  Ранее при выполнении запроса сервер возвращал ошибку с кодом состояния 500 и сообщением "Internal server error Service static folder not being loaded", так как необходимые файлы документации (OpenAPI) отсутствовали. Теперь запрос на получение спецификации стабильно возвращает данные в требуемом формате (YAML/HTML) вместо ошибки сервера.

# v.5.117.0

Изменения

- В следующем релизе LUNA PLATFORM поддержка сервисов Backport 3, Backport 4, UI 3 и UI 4 будет прекращена. Вся связанная с ними информация будет удалена из документации и скрипта Docker Compose.

- В шаблонах Helm-чартов всех сервисов обновлен HPA с `autoscaling/v2beta1` на `autoscaling/v2` для совместимости с современными версиями Kubernetes.

- В сервис Video Manager добавлено периодическое удаление неактивных агентов.

  Теперь автоматическое удаление агентов, прекративших работу можно настроить с помощью новой настройки `LUNA_VIDEO_MANAGER_AGENT_CLEAR_INTERVAL`. По умолчанию функция включена и раз в сутки выполняется удаление агентов, неактивных более 3 дней.

  Это предотвращает накопление в системе устаревших записей об агентах, которые завершили работу аварийно или без отправки запроса на удаление. См. раздел Автоматическое удаление неактивных агентов.

- Добавлена поддержка библиотеки ipp для повышения производительности декодера на CPU.

  Теперь декодирование видеопотоков на CPU выполняется быстрее с использованием библиотеки. Никаких дополнительных настроек для этого не требуется.

- В группу параметров `LUNA_REMOTE_SDK_RUNTIME_SETTINGS` добавлены новые настройки для управления ресурсами сервиса Remote SDK:

  - `PROGRAM_CACHE_SIZE` — ограничивает количество кэшируемых элементов, что ускоряет работу при большом числе задач;
  - `DEFAULT_GPU_DEVICE` — позволяет выбрать GPU-устройство по умолчанию (актуально для систем с несколькими GPU);
  - `CPU_HIGH_WATERMARK` и `GPU_HIGH_WATERMARK` — задают максимальный объём памяти для CPU и GPU;
  - `PIN_THREADS` — включает/отключает привязку потоков к ядрам процессора.

  Для подробной информации см. документацию SDK.

- Наличие полей `expiration_time` и `faces_limit` в лицензии больше не является обязательным условием для успешного выполнения запроса "get license" сервиса Licenses.

  Ранее при запросе "get license" без указания query-параметра `targets` возвращалась ошибка, если в лицензии отсутствовали поля `expiration_time` или `faces_limit`. Теперь, если лицензия не содержит эти поля, запрос без указания `targets` успешно выполняется и возвращает все имеющиеся данные о лицензии.

- Изменено значение по умолчанию параметра `wait_events_saving` с `0` на `1` в запросе на создание обобщённых событий create new general events.

  При значении по умолчанию `wait_events_saving = 1` система дожидается полного сохранения обобщённых событий в БД и только затем возвращает ответ с кодом состояния 204 (ранее при `wait_events_saving = 0` ответ возвращался сразу после помещения событий в буфер, код 202).

  Для подробной информации см. раздел Способ сохранения обобщенных событий.

- Теперь `Agent-lambda` поддерживает внешний режим работы.

  Ранее `Agent-lambda` работал только как внутренний агент (непосредственное взаимодействие с сервисами платформы). Теперь доступен "внешний режим работы", при котором агент взаимодействует с платформой только через API и может быть запущен вне основного контура платформы.

  За запуск во внешнем режиме отвечает параметр `external_agent` (см. в запросы create lambda, put lambda, get lambdas, get lambda).

  См. подробную информацию в разделе External agent руководства разработчика.

- В запросы на получение информации о видеопотоке (get stream, get streams) добавлен новый query-параметр `targets`.

  Данный параметр позволяет выбрать конкретные поля, которые должны быть возвращены в ответе на запрос. Это сокращает объем передаваемых данных и повышает удобство их анализа. По умолчанию возвращаются все доступные поля.

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

- Исправлена ошибка, из-за которой Video Agent не мог повторно зарегистрироваться в сервисе Video Manager после удаления из списка активных агентов.

  Ранее при длительном разрыве соединения Video Manager удалял агента, и последующее восстановление связи не приводило к его повторной регистрации.

- Исправлена последовательность отправки уведомлений о статусах подзадач с помощью механизма "callback-ов".

  Ранее в редких случаях статус подзадачи мог мгновенно меняться с "в ожидании" (`pending`) на "завершен" (`done`), пропуская важный промежуточный статус "обрабатывается" (`in_progress`). Теперь все уведомления приходят в правильном порядке.

- Исправлена ошибка, из-за которой сервис API не мог проверить лицензию и завершал работу с ошибкой 11055 и сообщением "License problem: Cannot get license information", если в ней отсутствовало поле `expiration_time` (время истечения срока действия LUNA PLATFORM).

  Теперь сервис корректно обрабатывает лицензии без поля `expiration_time` и продолжает работу без ошибок. Однако, отсутствие данного поля может привести к тому, что система будет воспринимать лицензию как истекшую. Поэтому рекомендуется использовать лицензии с полным набором параметров, включая `expiration_time`.

# v.5.115.0

Изменения

- Через один релиз LUNA PLATFORM поддержка сервисов Backport 3, Backport 4, UI 3 и UI 4 будет прекращена. Вся связанная с ними информация будет удалена из документации и скрипта Docker Compose.

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

  В данной версии LUNA PLATFORM были обновлены:

  - `OneShotLiveness` до версии 11
  - `AgeNet` до версии 7 — обновлена основная сеть и добавлена оптимизированная версия для сценариев, где приоритетом является скорость обработки при допустимом уровне точности
  - `EyeEstimator` до версии 3
  - `QualityEstimator` до версии 4

- Добавлена поддержка отрицательных углов ориентации видео (`-90`, `-180`, `-270`).

  Ранее, если в качестве источника данных для определения поворота (параметр `orientation_strategy`) было установлено `video_info` (угол поворота определяется по метаданным видео) и видео содержало метку поворота с отрицательным углом, обработка завершалась ошибкой с кодом `43010` и сообщением `Unsupported image rotation from video info: -90.0`.
  Теперь обработка видео с отрицательными углами, полученными из информации видео, выполняется корректно.

- Обновлены разрешения, задаваемые в токене:

  Для разрешения "event" добавлено право на удаление событий ("deletion"). См. запрос create token.

- Добавлена возможность удаления событий/обобщенных событий по их `event_id` с помощью новых запросов: delete event и delete general event.

- Обновлена спецификация OpenAPI.

  Теперь в документации явно указаны группы параметров для настройки ограничений по умолчанию:

  1. Для запросов сравнения: в группах параметров `LUNA_HANDLERS_LIMITS` и `PLATFORM_LIMITS` регулируется максимальное количество эталонов в запросе и кандидатов в ответе.
  2. Для обработки изображений (запросы sdk resource и generate events): в группах параметров `LUNA_REMOTE_SDK_LIMITS` и `LUNA_HANDLERS_LIMITS` регулируется максимальное количество изображений в одном запросе.
  3. Для обработчиков (create handler): в `LUNA_HANDLERS_LIMITS` регулируется максимальное количество элементов в `match_policy`.

  Примечание. При увеличении лимитов необходимо учитывать, что это может повлиять на производительность работы системы.

  Об упомянутых выше параметрах см. в разделе Описание параметров сервисов.

- Добавлена возможность импорта и экспорта лямбд.

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

  Результатом экспорта Lambda является zip-архив, содержащий:

  - Docker образ лямбды;
  - исходный архив, предоставленный при создании лямбды;
  - JSON-файл с параметрами лямбды, указанными при её создании, а именно: учётные данные `credentials`, настройки лямбды `parameters` и параметры развёртывания `deploy_parameters`.

  См. запрос export lambda archive.

  Lambda можно импортировать с помощью запроса import lambda archive. Архив, предоставленный в запросе, должен соответствовать структуре экспортированного.

  Примечание. При импорте архива можно изменить параметры, хранящиеся в JSON-файле, путем их указания в теле запроса.

  См. подробную информацию в разделе Lambda export and import руководства разработчика.

- Добавлена поддержка автоматического переподключения к видеопотокам при разрыве соединения из-за ложного сигнала о завершении передачи видеоданных.

  Теперь при получении сигнала `END_OF_FILE` от видеопотока система автоматически пытается восстановить соединение на стороне агента (не поддерживается для видеофайлов).

  Новые параметры в `behavior_parameters` позволяют настроить:

  - `eof_retry` > `delay` задает интервал между попытками в миллисекундах (по умолчанию 100 мс);
  - `eof_retry` > `attempt_count` определяет максимальное количество попыток (по умолчанию 10, значение 0 отключает повторные попытки).

  См. запросы create stream, put stream, get stream, get streams.

  Это изменение особенно полезно для работы с RTSP-потоками в условиях нестабильного сетевого соединения, когда ложный сигнал о завершении потока может привести к остановке обработки видео.

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

- Для запроса `stream events ws handshake` при отсутствии авторизационных данных теперь возвращается код состояния 401 (Authorization failed) вместо ошибочного 403 (Forbidden. Specified token corrupted).

- Исправлен список доступных значений для параметров `targets` и `filters` в запросах получения статистики событий.

  Ранее документация содержала неактуальные значения, что приводило к ошибке с кодом состояния 400 (Bad/incomplete input data) при попытке их использования. См. запросы getEventStats и getGeneralEventStats.

- Исправлена ошибка, при которой видеопоток не мог перезапуститься после обновления через запрос put stream.

  Теперь после обновления потока:

  - остановленный/завершившийся с ошибкой поток автоматически перезапускается со статусом `pending`;
  - активный поток сначала корректно завершает текущую обработку, после чего переводится в `pending` для повторного распределения.

  Также теперь информация об обновлении потока записывается в логи сервиса Video Agent.

- Исправлена некорректная логика отправки статусов для видеопотоков, завершающихся с ошибкой.

  Ранее система могла ошибочно отправлять статус "stop" ("обработка потока остановлена пользователем") для потоков, которые фактически завершились с ошибкой (статус "failure"). Это приводило к противоречиям в логах, где сначала фиксировалась ошибка (например, проблемы с декодированием или недоступностью источника потока), а затем статус "stop".

  Теперь потоки, завершающиеся с ошибкой, не отправляют статус "stop".

- Исправлена ситуация, когда по причине некорректно настроенных значений `LUNA_VIDEO_MANAGER_STREAM_STATUS_OBSOLETING_PERIOD`/`LUNA_VIDEO_MANAGER_AGENT_STATUS_OBSOLETING_PERIOD` агенты не отправляли обратную связь с требуемой периодичностью.

  Ранее это приводило к непреднамеренному понижению версии агентов или потоков и отказу агентов обрабатывать потоки.

  Теперь система автоматически обеспечивает оптимальную частоту отправки обратной связи независимо от точности заданных настроек `LUNA_VIDEO_MANAGER_STREAM_STATUS_OBSOLETING_PERIOD` и `LUNA_VIDEO_MANAGER_AGENT_STATUS_OBSOLETING_PERIOD`.

- Исправлена ошибка, из-за которой невозможно было добавить кастомные эндпоинты для Agent-lambda.

  Теперь функционал работает корректно. Подробности и примеры использования см. в разделе "Additional routes".

- Исправлена ошибка, которая приводила к некорректной инициализации клиента для Tasks-lambda.

# v.5.112.0

Изменения

- В ресурс `/sdk` добавлена возможность оценки изображения на наличие модификаций — `estimate_image_modification` (см. раздел Face Image Modification).

  Система будет считать, что изображение было модифицировано, если полученная оценка (значение от 0 до 1) будет ниже установленного порога.
  Значение порога по умолчанию — 0.5 (50%).

  При необходимости пороговое значение можно задать в настройке `LUNA_REMOTE_SDK_IMAGE_MODIFICATION_ESTIMATOR_SETTINGS.estimator_settings.threshold` сервиса Remote SDK.

  Функция отключена по умолчанию.

- Сервис Accounts теперь относится к необязательным и регулируется в группе параметров "ADDITIONAL_SERVICE_USAGE".

  При отключенном сервисе Accounts будет недоступен функционал по созданию/изменению/удалению учетных записей и токенов, а также в ответе на запрос "get system info" к сервису Admin в секции "services_versions" не будет отображаться информация о данном сервисе.

  Важно. Чтобы запустить LUNA PLATFORM с отключенным сервисом Accounts, необходимо в настройке `CONFIG_AUTHORIZATION_USERS` указать список учётных записей и их токенов, которые могут использоваться при авторизации запросов. Учетную запись и ее токены можно создать внутри контейнера сервиса Admin с помощью команды `create_account`. См. подробнее в разделе Последствия отключения сервиса Accounts.

  Также в сервис Accounts добавлен новый ресурс `/generator`, позволяющий заранее (перед отключением сервиса — если это необходимо пользователю) сгенерировать учётные записи и их токены. Эти данные можно сохранить в настройке `CONFIG_AUTHORIZATION_USERS` для дальнейшего использования.

- В сервисе Remote SDK размер очереди изображений для обработки был ограничен. Это позволяет предотвратить неконтролируемый рост потребления оперативной памяти, который ранее возникал при превышении времени выполнения запросов и приводил к проблемам с производительностью.

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

- Исправлена ошибка, из-за которой происходило неправильное формирование поля `match_result` в ответах на запросы сравнения ("matching faces", "human body matching", "general events matching") при использовании событий в качестве кандидатов.

  Теперь в содержимое `match_result` корректно добавляется поле `stream_id` (ранее в ответах для этого поля всегда проставлялось значение "None").

- Исправлено некорректное поведение при работе с пустыми результатами матчинга.

  Ранее, если в политиках обработчика был установлен фильтр `similarity__lte` для результатов матчинга (например, в политике "storage_policy" > "face_policy" > "filters" > "match" > "similarity__lte"), то при отсутствии совпадений фильтрация не выполнялась, соответственно все действия, которые предполагалось сделать при проверке данного условия, не выполнялись (например, сохранение лица/события/атрибутов и др.).

  Теперь при пустых результатах матчинга и значении `similarity__lte` фильтрация выполняется успешно, что соответствует логике "ни один кандидат не похож на эталон".

  Примечание. Если установлен фильтр `similarity__gte` и вернулся пустой результат - фильтрация не выполняется, т.к. это не соответствует условию "есть хотя бы один кандидат, похожий на эталон".

  См. запрос create handler.

- Исправлена проблема в сервисе Remote SDK, которая приводила к зависанию при обработке изображений.

# v.5.110.0

Изменения

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

  Примечание. Новая возможность доступна только для обработки видеопотока (недоступно для видеофайлов).

  Примеры возможных расписаний выполнения аналитик:

  - Каждый день с 9:00 до 18:00
  - Каждый будний день с 8:30 до 12:30
  - Каждые 15 минут круглосуточно
  - Каждую субботу в 23:00 на 2 часа
  - Первый день каждого месяца с 00:00 до 06:00
  - Понедельник, среда и пятница с 3:00 до 5:00
  - Раз в день на сутки (24 часа) с любого времени старта

  Есть два способа указать расписание аналитики в запросе на создание или обновление потока:

  1․ Указание интервалов выполнения аналитики напрямую (`analytics.schedules.start_time/end_time`):

      [
        { "start_time": "2025-07-01T09:00:00Z", "end_time": "2025-07-01T11:00:00Z" },
        { "start_time": "2025-07-02T09:00:00Z", "end_time": "2025-07-02T11:00:00Z" }
      ]

  Такие интервалы можно рассчитать заранее с помощью нового запроса `calculate intervals`, указав cron-выражение, длительность, временной диапазон и часовой пояс.

  2․ Указание идентификатора ранее созданного шаблона расписания (`analytics.schedules.schedule_id`).

  Шаблон позволяет автоматически генерировать интервалы на основе заданных параметров (cron, длительность, диапазон) и повторно использовать их между аналитиками. Работа с шаблонами выполняется с помощью новой группы ресурсов `/streams/templates`.

  Также можно комбинировать оба способа — передать одновременно `schedule_id` и дополнительные интервалы. В этом случае все указанные интервалы будут объединены в одну итоговую группу рабочих интервалов.

  Чтобы получить как необъединённые, так и объединённые интервалы аналитики, можно воспользоваться запросом `get stream analytics working intervals`, передав параметр `merged=true`.

  Важно: - Если для аналитики не заданы интервалы, она б удет работать всё время, пока обрабатывается поток. - Если аналитика временно на паузе (вне интервала), но поток находится в состоянии `in_progress`, агент при этом будет продолжать считаться занятым. - Если поток завершится или станет недоступен во время паузы всех аналитик, система не выдаст ошибок или предупреждений до тех пор, пока хотя бы одна аналитика не достигнет следующего рабочего интервала.

  См. подробную информацию в разделе "Распределение аналитик" в руководстве администратора.

- Добавлена возможность выбора алгоритма распределения потоков между агентами.

  Доступны два варианта:

  - "simple" (установлен по умолчанию): из числа доступных агентов для обработки потока (или его части) выбирается случайный агент.
  - "percent": среди доступных агентов выбирается наименее загруженный (в процентном соотношении).

  Важно! Алгоритм распределения потоков не распределяется на уже запущенные потоки. То есть если выставить значение "percent" при уже запущенных потоках, то они не будут переброшены на менее загруженного агента. Для перераспредения нагрузке нужно будет остановить все потоки и запустить их заново.

  Для выбора алгоритма необходимо использовать новый параметр `LUNA_VIDEO_MANAGER_STREAMS_DISTRIBUTION_ALGORITHM`.

  См. подробную информацию в разделе "Распределение потоков".

- Обновлены ответы POST-запросов:

  - create stream
  - create group
  - register agent
  - create analytic

  В них добавлены:

  1. новые параметры в тело ответа: `url` — относительный путь (например, `/6/streams/:id`) и `external_url` — абсолютный URL (например, `http://<host>:<port>/6/streams/:id`)

  2. новый заголовок: `Location` — расположение созданного ресурса (аналогично `url`).

- В запросы группы ресурсов `/streams` добавлен новый параметр `ffmpeg_kwargs`, предназначенный для передачи дополнительных аргументов в `ffmpeg`, используемый при декодировании видео.

  Этот параметр позволяет управлять низкоуровневыми настройками `ffmpeg`, если стандартных параметров недостаточно для подключения или корректной обработки потока. Например, для нестандартных RTSP-серверов может потребоваться указание `rtsp_transport`.

  Если `ffmpeg_kwargs` передан, он должен содержать словарь дополнительных именованных аргументов для ffmpeg (например, "rtsp_transport": "udp"). Для RTSP-потоков, если `rtsp_transport` не указан, по умолчанию будет использоваться `TCP`.

  Важно! Все параметры передаются напрямую в `ffmpeg` без проверки на валидность или безопасность. Используйте на свой страх и риск. Ошибки, связанные с неверными параметрами, отображаются в логах потоков.

  Список возможных параметров и их значений см. в официальной документации ffmpeg.

- Добавлена предварительная проверка доступа к GPU в сервисе Video Agent.

  Для эстиматоров, которым требуется GPU, теперь при запуске контейнера выполняется проверка наличия и доступности GPU-устройства.

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

  Теперь в логах сервиса появляется сообщение `Check access to GPU:`, где фиксируется результат проверки. В случае ошибки доступа будет выведено сообщение от CUDA.

- В руководство разработчика сервиса Lambda, в раздел "Standalone lambda development", добавлен пример Standalone-lambda, запускающей ML-модель.

  См. подробную информацию в разделе Standalone-lambda

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

- HTTP-заголовок `Location` добавлен в ответы для нескольких ресурсов спецификации OpenAPI.

- Исправлена ​​ошибка, из-за которой поля даты не проверялись во время выполнения запроса на создание события.

  Ранее могла возникнуть ошибка типа "Internal server error" с кодом состояния 500 из-за некорректного формата даты.

- Исправлено описание мониторинга нод `human_tracking` в документации разработчика. Серии для аналитики `human_tracking` теперь явно отмечены.

  См. подробную информацию в разделе "Monitoring" руководства разработчика.

- Исправлена ошибка в сервисе Video Agent, из-за которой не удавалось подключиться к сервису Events.

# v.5.108.0

Изменения

- В запросе create stream максимальная длина поля `reference` (ссылка на источник потока) увеличена с 512 до 2083 символов.

  Важно! При переходе на более раннюю версию LUNA PLATFORM убедитесь, что у вас нет критичных потоков со ссылками длиннее 512 символов — они будут удалены.

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

  В данной версии LUNA PLATFORM обновлен эстиматор DeepFake до версии 8.

- В мониторинг сервиса Remote SDK добавлено поле `face_descriptor_score` для сбора данных о качестве дескрипторов лиц. См. подробную информацию в разделе "Monitoring" в руководстве разработчика.

  Также был расширен ответ на запрос "get system info" к сервису Admin: добавлено поле `face_descriptor_score`, предоставляющее статистику качества дескрипторов лиц. Данные автоматически распределяются по бакетам с шагом 0.05. Пример:

      "face_descriptor_score": {
      "score_0.85": 2,
      "score_0.9": 197,
      "score_1": 4
      }

  Где "score_0.9": 197 — означает 197 дескрипторов с оценкой в диапазоне 0.90–0.94.

- Агрегация данных мониторинга теперь необязательна и может быть отключена в новой настройке `MONITORING_AGGREGATION` сервиса Admin.

  Формат задания настройки — `boolean`. Значение по умолчанию — `true`.

  Примечание. При отключении настройки статистические данные в секции `stats` ответа на запрос "get system info" не будут отображаться.

- Изменена логика подготовки окружения для мониторинга с помощью утилиты Storages.

  Ранее создание бакета для хранения данных мониторинга `luna_monitoring` (если не задано иное имя) и создание бакета для хранения статистики использования LUNA PLATFORM `luna_monitoring_aggregated` (теперь необязательно, см. выше) выполнялось в два этапа, а теперь это единый этап подготовки окружения мониторинга. Это означает, что в случае включенной настройки `MONITORING_AGGREGATION` (включено по умолчанию) во время подготовки окружения для мониторинга будет выдана ошибка `Bucket <bucket_name> already exists` если какой-то из двух бакетов существует, т.к. утилита Storages воспринимает отсутствие любого из бакетов как необходимость создать оба.

  Во всех документах по установке и в скрипте Docker Compose команда запуска InfluxDB теперь выполняется с инициализацией бакета с именем `default` вместо `luna_monitoring` (переменная окружения `DOCKER_INFLUXDB_INIT_BUCKET` для контейнера InfluxDB), а утилита Storages далее создает бакет(ы) самостоятельно. Это позволяет избежать ошибки, когда бакет `luna_monitoring` уже был инициализирован на этапе запуска InfluxDB, а утилита Storages обнаружила его наличие в паре с отсутствием бакета `luna_monitoring_aggregated`.

  При необходимости можно не менять привычную команду запуска контейнера InfluxDB и использовать аргумент `--ignore-integrity` во время подготовки окружения Storages. Это позволит создать только бакет `luna_monitoring_aggregated`, проигнорировав наличие бакета для хранения данных мониторинга, однако следует использовать этот аргумент с осторожностью, т.к. он может проигнорировать и другие существующие сущности при вызове в паре с позиционным аргументом `prepare all_entities`.

  Важно! При обновлении с предыдущей версии, где не использовался сервис Admin, и не был создан бакет `luna_monitoring_aggregated`, но был создан бакет `luna_monitoring`, также будет получена ошибка `Bucket <bucket_name> already exists`. В таком случае нужно отключить настройку `MONITORING_AGGREGATION`, либо воспользоваться аргументом `--ignore-integrity` (см. выше).

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

- Исправлен некорректный вывод команды `luna_prepare prepare --help` в контейнерах сервисов Video Manager и Video Agent.

- Для сервиса Licenses восстановлена ​​поддержка переменной окружения `EXTEND_CMD`. С её помощью можно передавать дополнительные аргументы в команду запуска сервиса, если для них не предусмотрены отдельные переменные окружения.

  Например, можно явно задать тегированные настройки при запуске сервиса: `--env=EXTEND_CMD="--LUNA_MONITORING=TAG_1"`.

  См. подробную информацию о переменных окружения и аргументах в разделе "Аргументы сервисов" в руководстве по установке.

- Теперь, если при выполнении запроса create stream одна или несколько указанных аналитик недоступны, возвращается код состояния 422 (Unprocessable content) вместо 400 (Bad/incomplete input data).

# v.5.105.0

Изменения

- Добавлена ​​переменная окружения `VL_SETTINGS_NESTED_DELIMITER`.

  Новая переменная позволяет задавать в качестве разделителя любой символ между названиями разделов настроек при указании полей через переменные окружения.

  Ранее единственным допустимым разделителем была точка (".").

  Например, если разделитель был задан `VL_SETTINGS_NESTED_DELIMITER=:`, то команда переопределения настроек будет выглядеть следующим образом:

  `--env=VL_SETTINGS:LUNA_MONITORING:SEND_DATA_FOR_MONITORING=0`.

- В сервис Remote SDK добавлена предварительная проверка доступа к устройству `GPU`, если для работы какого-либо эстиматора требуется его использования.

  Ранее без корректно настроенного доступа к GPU сервис завершал работу с неинформативными сообщениями об ошибках.

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

- Устранена утечка памяти при обработке видеоданных.

- Для ресурса `sender` при отсутствии авторизационных данных теперь возвращается код состояния 401 (Authorization failed) вместо ошибочного 403 (Forbidden. Specified token corrupted).

- Исправлена ​​ошибка, из-за которой lambda (развернутая в кластере Kubernetes, параметр "cluster_location" = internal) могла оставаться в статусе `waiting`, несмотря на успешное создание.

# v.5.103.0

Изменения

- Добавлена валидация длины дескрипторов при создании обобщённых событий "create new general events".

  Теперь при создании обобщенного события вместе с дескриптором, в БД происходит поиск последнего сохраненного дескриптора с таким же типом и версией, как у переданного в запросе:

  - если найден, сравнивается его длина с длиной переданного дескриптора. При совпадении - успешно создается событие, в противном случае возвращается ответ с кодом состояния 409 и ошибкой 12034 "Descriptor has incorrect length";
  - если не найден, переданный дескриптор становится эталоном для последующих проверок.

  Например, если в БД ранее был сохранен дескриптор с "type_1", "version_1" и "lenght_1" и при попытке создать событие с дексриптором, у которого параметры:

  - "type_1", "version_2", "lenght_1" - событие будет создано (разные версии);
  - "type_2", "version_1", "lenght_1" - событие будет создано (разные типы);
  - "type_1", "version_1", "lenght_2" - событие не будет создано (та же пара тип+версия, но разная длина) и вернется ошибка с кодом состояния 409.

  Примечание. Проверка выполняется только при создании обобщенного события вместе с новым дескриптором. Если дескриптор уже существует в БД или не передаётся в запросе - валидация не применяется.

- Добавлена ​​поддержка шифрования дескрипторов для обобщенных событий.

  См. раздел "Descriptors encryption" в руководстве разработчика.

- Добавлена новая настройка `LUNA_API_CORS`, управляющая списком заголовков, разрешённых к чтению через `Access-Control-Expose-Headers` в соответствии с `CORS`.

  По умолчанию разрешены: `X-Luna-Meta-Rescale` — параметры масштабирования изображений, и `X-Luna-Expiry-Date` — срок хранения данных.

  Это позволяет клиентским приложениям, работающим в браузере, получать дополнительные данные, которые могут быть полезны для обработки ответов от сервера. См. подробнее о настройке и принципах работы CORS.

- Добавлен новый тип лямбды `agent`.

  Тип Agent-lambda предназначен для создания агентов с пользовательскими видеоаналитиками. Таким образом, это даёт возможность использовать не только стандартные аналитики (отслеживание людей и подсчет количества людей), но и собственные алгоритмы для видеоанализа, написанные на основе различных моделей нейронных сетей.

  Agent-Lambda не может обрабатывать любые пользовательские запросы напрямую и функционирует исключительно в сочетании с сервисом Video Manager, который является обязательным компонентом для его работы. Также во время своей работы может взаимодействовать со следующими сервисами LUNA PLATFORM:

  - Faces
  - Sender
  - Events
  - Image Store

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

  Для создания лямбды с типом `agent` нужно предварительно перенести базовый образ `dockerhub.visionlabs.ru/luna/lpa-lambda-agent-base:<lambda_version>` в свой регистри по аналогии с другими типами лямбд.

  См. подробную информацию и примеры кода для Agent-lambda, в разделе "Agent lambda development" руководства разработчика сервиса Lambda.

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

- Исправлена ​​проблема, связанная с эстиматором Deepfake, у которого по умолчанию был включен упрощенный режим работы при отправке запросов к ресурсу `/sdk`. Теперь данный эстиматор по умолчанию использует режим работы 2 (с предварительной проверкой изображения), что соответствует документации.

  Для подробной информации о режимах работы эстиматора см. раздел "Deepfake".

- Исправлено некорректное поведение при котором завершенным потокам (со статусами `done`/`failure`), ошибочно присваивался статус `pending` после остановки агента, обрабатывающего эти потоки. Теперь система сохраняет исходный статус завершенных потоков.

- Исправлено поведение, которое приводило к появлению ошибки с кодом состояния 500 при выполнении запроса "create stream", когда функция лицензии `analytics streams limit` была отключена.

- Аналитика отслеживания людей `human_tracking` теперь может корректно работать, если агент был запущен во "внешнем режиме".

  Ранее попытка запустить работу аналитики приводила к ошибке вида "Connect call failed".

  Также исправлена ​некорректная работа аналитики `human_tracking`, при которой не удавалось создать поток, если параметр `rate`, задающий частоту обработки кадров, отличался от значения по умолчанию.

- Исправлена ​​ошибка, из-за которой различались ответы в зависимости от типа содержимого (`application/msgpack` или `application/json`), при отправке запросов на сравнение ("matching faces", "human body matching", "general events matching").

  Ранее при отправке одного и того же запроса с некорректными полями возвращались разные ошибки:

  - для `application/json` — ошибка с кодом 12022 и детализированным описанием проблемного поля.
  - для `application/msgpack` — ошибка с кодом 12047 и общее сообщение без конкретики.

  Теперь в этом случае для обоих типов содержимого возвращается единый код ошибки и одинаково детализированное сообщение (как было для `application/json`).

# 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 пикселей.

# v.5.98.0

Изменения

- Добавлена поддержка автоматического определения ориентации видео.

  Добавлено поле `orientation_strategy`, которое определяет источник данных для коррекции поворота видео:

  - `static` – ручная настройка угла (установлено по умолчанию). Пользователь может, как раньше, задать угол поворота видео на 90, 180 и 270 градусов перед его обработкой: в поле `angle` (для видеофайла) и в `rotation` (для потока).
  - `videoinfo` – угол поворота определяется по метаданным видеофайла или потока.

  Расположение `orientation_strategy`:

  - для ресурса "/videosdk" в секции `orientation`;
  - для операций с потоками ("create stream"/"put stream") в секции `data`.

  Примечание. Если в видеофайле встречаются кадры с разными углами поворота, то система использует метаданные последнего кадра.

- Версия аналитики `people_count` обновлена ​​до `2` и включает в себя следующие изменения:

  - теперь для аналитики подсчета людей `people_count` можно задать верхнюю и нижнюю границы значений количества людей:

    - `people_count__lte` - нижний порог количества людей. Событие создается в случае, если людей меньше или равно указанному значению. Должно быть меньше, чем `people_count__gte`.
    - `people_count__gte` - верхний порог количества людей. Событие создается в случае, если людей больше или равно указанному значению.

    Примечание. Необходимо установить хотя бы одно из значений.

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

  - добавлен параметр `event_delay`, задающий задержку (в секундах) перед регистрацией события. По умолчанию установлено значение `0`. Это позволяет игнорировать временные изменения количества людей в кадре, не соответствующие заданным условиям. Система начинает отсчет только когда количество людей соответствует указанным параметрам (`people_count__lte`/`people_count__gte`). Например, при заданных `people_count__gte` = 3 и `event_delay` = 30 событие будет зарегистрировано, только если в кадре присутствует не менее 3-х человек в течение 30 секунд.

  В запрос "put analytic" была добавлена новая ошибка с кодом 44016 и описанием "Unable to update analytic. 'people_count' analytic version is too low", которая возвращается при попытке обновления аналитики с версией ниже уже зарегистрированной в Video Manager.

- Добавлен новый запрос "delete analytics", который позволяет удалять аналитики в соответствии с фильтром "account_id".

- Добавлена возможность работы сервиса Video Agent во внешнем режиме.

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

  Для запуска сервиса Video Agent во внешнем режиме необходимо использовать аргумент `--run-external`. Также требуется авторизация через один из способов:

  - токен (рекомендуется) - переменная окружения `LUNA_API_TOKEN`;
  - логин/пароль - переменные `LUNA_API_USER` и `LUNA_API_PASSWORD` (при наличии токена логин/пароль игнорируются).

  Пример команды запуска:

      docker run \
        ...
        --env=LUNA_API_TOKEN="token" \
        --env=EXTEND_CMD=--run-external \
        --name=luna-video-agent \
        ...

  Примечание. Используемый токен должен быть предоставлен с минимальным набором разрешений:

  Название разрешения | Описание разрешения | Права
  --- | --- | ---
  event | права на использование событий | creation
  image | права на использование изображений | creation
  video_stream | права на использование потоков | creation
  video_analytic | права на использование аналитик | creation, view, modification
  video_agent | права на использование агентов | creation, deletion

  Ограничения при запуске сервиса Video Agent во внешнем режиме:

  - ресурс `/videosdk` недоступен;
  - сервисы API и Licenses должны быть доступны и включены.

  Поскольку Video Agent во внешнем режиме может взаимодействовать только с сервисом API, были добавлены следующие запросы:

  - "post agent streams" - позволяет получать потоки по идентификатору агента, обработку которых необходимо начать.
  - "post streams feedback" - позволяет оставить обратную связь об обработке потока.
  - "create analytic" - запрос на создание аналитики.
  - "put analytic" - запрос на обновление существующей аналитики.
  - "register agent" - позволяет зарегистировать аналитику.
  - "remove agent" - запрос на удаление агента по идентификатору.
  - "publish general event" - позволяет отправлять (публиковать) в систему события, созданные пользователем.

> Самописные агенты также поддерживают данный функционал. См. руководство разработчика сервиса Video Manager для более подробной информации.

- В спецификацию сервиса Video Manager:

  - добавлен новый запрос "get stream agent" для получения детальной информации об агенте, обрабатывающем видеопоток. Возвращаемые данные включают: идентификатор агента, статус, количество активных потоков, время создания и др.
  - в запрос "register agent" для регистрации аналитики в сервисе Video Manager добавлено поле `host` (IP-адрес сервера, на котором запущен агент).

- Обновлены разрешения, задаваемые в токене:

  Название разрешения | Описание разрешения | Права
  --- | --- | ---
  video_analytic | права на использование аналитик | creation, view, modification, deletion
  video_agent | права на использование агентов | creation, deletion

  См. запросы "create token", "replace token", "get tokens", "get token".

- Добавлена ​​поддержка альтернативного, настраиваемого пользователем подхода к шифрованию дескрипторов на уровне базы данных.

  Теперь пользователю доступна возможность автоматического шифрования/дешифрования дескрипторов в PostgreSQL с помощью триггеров, выполняющих шифрование при вставке и обновлении записей, и функции `vlconvert` для прозрачного дешифрования при чтении данных.

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

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

- Добавлена поддержка 67-ой версии модели нейронной сети извлечения биометрических шаблонов лиц.

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

- Версия Python обновлена до 3.13 в контейнерах всех сервисов кроме Video Manager и Video Agent.

  Поддержка более старых версий Python прекращена (в сервисах Video Manager и Video Agent поддерживается версия Python 3.12).

- Скрипт `start_platform.sh` по разворачиванию Docker Compose теперь поддерживает новый аргумент `--gpu`, который позволяет включить использование GPU в сервисах Video Agent и Remote SDK. Может использоваться как самостоятельно, так и в комбинации с флагами `--common` и `--extra`.

  Для получения информации о поддержаных аргументах в скрипте `start_platform.sh` см. раздел Запуск сервисов.

- В клиент LUNA Python Matcher в Lambda добавлены функции для работы со сравнением по обобщенным событиям.

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

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

- Исправлена ​​ошибка, из-за которой поля даты не проверялись во время выполнения запросов на сравнение.

  Ранее при выполнении запросов "matching faces" и "human body matching" могла возникнуть ошибка типа "Internal server error" с кодом состояния 500 из-за некорректного формата даты в фильтрах (например, "202-08-11T09:11:41.674Z" вместо "2023-08-11T09:11:41.674Z").

- Исправлено сообщение об ошибке при создании задачи garbage collecting task с таргетом `event_descriptor` для некорректного `descriptor_type`.

  Ранее сообщение могло вводить в заблуждение, поскольку указывало на неизвестный тип `general`. Теперь при неверном значении `descriptor_type` система четко указывает на допустимые варианты — `face` или `body`.

- Уменьшен итоговый размер собираемого образа для лямбды, которая использует `poetry` в качестве установки зависимостей.

# v.5.96.0

Изменения

- Теперь по умолчанию используется 65-ая версия нейронной сети для извлечения биометрических шаблонов лиц (настройка "DEFAULT_FACE_DESCRIPTOR_VERSION" сервиса Remote SDK).

  При выполнении миграции настроек сервиса Configurator последней версии, настройка "DEFAULT_FACE_DESCRIPTOR_VERSION" не будет автоматически обновлена. Для продолжения работы с существующими биометрическими шаблонами лица с новой 65-ой версией нейронной сети необходимо вручную изменить значение настройки "DEFAULT_FACE_DESCRIPTOR_VERSION", предварительно выполнив повторное извлечение существующих биометрических шаблонов с помощью 65 модели, используя задачу "Additional extraction. Если изменить дефолтную версию без выполнения задачи, то старые биометрические шаблоны станут недоступны.

  См. раздел "Подготовка к смене версии нейронной сети" для более подробной информации по обновлению настройки "DEFAULT_FACE_DESCRIPTOR_VERSION".

- Добавлен механизм разделяемых потоков.

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

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

  - Запрос "create stream" теперь поддерживает параметр `splittable`, который разрешает распределять обработку потока на более чем одного агента в случае, если ни один агент не поддерживает все указанные наборы аналитики.

  - Обновлены ответы на запросы "get stream" и "get streams":

    - поле `status`: для неразделяемых потоков изменений нет, а статус разделяемого потока — это общий статус всех его частей. Добавлены новые статусы состояния разделяемых потоков: `unknown` - разделяемый поток имеет разные статусы на каждом агенте и `handler_lost` - служебный статус, означающий, что данные от обрабатывающего поток агента не были получены и такой поток будет заново перераспределен в обработку (в логах потока появляется в комбинации `handler_lost-restart-pending`).
    - поле `autorestart` перемещено в поле `analytics`: для неразделяемого потока оно будет одинаковым для каждой его части (элементов массива `analytics`) и может быть разным для каждой части разделяемого потока в зависимости от их состояния.
    - в поле `analytics` было добавлено поле `status`, описывающее статус каждой части разделяемого потока.

  - Теперь для запроса "stream events ws handshake" доступен новый параметр `analytic_index`, который предоставляет информацию только для аналитики с указанным индексом, который соответствует индексу аналитики из запросов "create stream" или "get stream(s)". Параметр не является обязательным и по умолчанию параметр принимает значение `0`, что соответствует первому элементу массива `analytics`.

- В сервис Image Store добавлена поддержка S3-совместимых хранилищ, не имеющих встроенной функциональности тегирования.

  Также для данных хранилищ была добавлена поддержка политики TTL (Time To Live - автоматическое удаление файлов по истечении заданного срока).

  При создании бакета в него помещается специальный файл, содержащий значение `ttl` по умолчанию для хранящихся в нем объектов; если значение не указано, оно устанавливается на None, что означает, что у объектов не будет автоматически назначенного срока действия. Чтобы включить этот механизм, необходимо указать параметр `TAGGING` = 0 в настройке `S3`. При включении дата удаления объекта будет сохранена в метаданных для объектов, для которых параметр `ttl` был указан при создании или изменении. Если у объекта нет явно заданного `ttl`, будет применено значение `ttl` бакета по умолчанию.
  Однако если значение TTL по умолчанию не настроено, объект останется в хранилище на неопределенный срок. Чтобы явно предотвратить удаление объекта, ему следует назначить значение ttl, равное -1.

- Обновлена логика запроса получения функций из лицензии с целью поддержки гибкого лицензирования.

  Теперь запрос "get license" сервиса Licenses поддерживает любой таргет, указанный пользователем, для получения функции из лицензии, если она включена в лицензию.

  Ранее были доступны только следующие таргеты: `expiration_time`, `faces_limit`, `liveness`, `iso`, `index`, `people_counter`, `body_attributes`, `streams_limit`, `lambdas`. Теперь любые другие функции, доступные в лицензии, также доступны в качестве таргетов.

  Если указанная пользователем функция не включена в лицензию, будет возвращена ошибка с кодом 33008 и описанием `License problem. Unknown feature: {feature_name}.`.

- Добавлено периодическое удаление логов, регулируемое настройкой `LUNA_VIDEO_MANAGER_LOGS_CLEAR_INTERVAL`.

  Эта функция помогает автоматически очищать базу данных сервиса Video Manager от устаревших логов, предотвращая их накопление. Периодическое удаление логов настраивается с помощью нижеописанных параметров из группы параметров `LUNA_VIDEO_MANAGER_LOGS_CLEAR_INTERVAL`:

  - "interval" - задает интервал удаления логов. Логи, старше чем данный интервал, будут удалены. Значение по умолчанию - 7;
  - "interval_type" - задает тип интервала (недели, дни, часы, минуты, секунды). Значение по умолчанию - `days`;
  - "check_interval" - задает частоту проверки логов на удаление (секунды). Значение по умолчанию - 180;
  - "active" - включает/выключает автоматическое удаление логов потоков. По умолчанию параметр в выключен.

  При включенном параметре "active" значения по умолчанию запускают автоматическое удаление с проверкой логов потоков в базе данных каждые 180 секунд и удаляют логи старше 7 дней.

- База данных `Oracle` больше не поддерживается в сервисах Lambda и Video Manager.

- В скриптах `start_platform.sh` и `start_logging.sh` добавлена поддержка автоматического выбора между docker-compose (отдельный бинарный файл) и docker compose (встроенная команда в docker).

  Ранее при попытке выполнить скрипты с `docker compose`, если `docker-compose` не был установлен, возникала ошибка.

  Также из документации была удалена инструкция по установке Docker Compose в виде бинарного файла.

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

- Исправлена ошибка при аутентификации Redis Sentinel с использованием логина и пароля.

  Ранее сервис Tasks не работал с конфигурацией Sentinel, где был указан недефолтный пользователь и обязательная аутентификация. Возникала ошибка `MasterNotFoundError` с сообщением `Authentication required`, так как система не передавала логин/пароль при подключении к Sentinel.

- В спецификацию запросов "create stream" и "put stream" был добавлен отсутствующий паттерн для имени потока.

  Паттерн имени потока: `^[a-zA-Z0-9_\-]{0,128}$`, из которого следует, что имя потока может содержать только: - латинские буквы (a-z, A-Z); - цифры (0-9); - нижнее подчёркивание (_) и дефис (-). Паттерн допускает: длину от 1 до 128 символов — для осмысленных имен (например, stream_1) или пустую строку ("") — как крайний технический случай, но это не рекомендуется для реального использования.

- Исправлена ​​ошибка, которая позволяла передавать неиспользуемый параметр `ttl` в `image_retain_policy` для аналитики `people_count` и `human_tracking`.

  Это применимо только к ресурсу "/videosdk", поскольку там не сохраняются данные, в отличие от потоков, где данные сохраняются.

- В спецификацию аналитики People count добавлено отсутствующее описание поля `source` в "callback request".

- Исправлено дублирование логов при запросе "get streams logs" к удаленному потоку.

- Обновлена логика обработки потока при отсутствии ответа от агента в Video Manager.

  Если поток был отправлен на обработку, но агент не подтверждает его статус (например, из-за сбоя или недоступности), то теперь потоку последовательно присваиваются статусы: - handler_lost – служебный статус, означающий, что данные от обрабатывающего поток агента не были получены. - restart – поток помечается для перезапуска. - pending – статус потока изменяется на "ожидание" для повторного распределения на другого агента.

  Ранее в таких случаях в логах фиксировалась только такая последовательсть "restart-pending".

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

- Раздел "Проверки": Добавлена возможность загружать видеофайлы для проверки на Liveness, Deepfake, а также оценки атрибутов лица и тела.

# v.5.95.0

Изменения LP

- Сервис Remote SDK теперь относится к необязательным и регулируется в группе параметров "ADDITIONAL_SERVICE_USAGE".

  При отключении сервиса Remote SDK:

  - будет недоступен весь функционал, связанный с нейронными сетями, а именно: обнаружение лиц и тел на изображениях, оценка параметров изображений, а также извлечение базовых атрибутов и биометрического шаблона;
  - будет отсутствовать возможность работы с задачей Additional extraction, а задача Estimator будет работать только в том случае, если обработчик, который используется этой задачей, не требует сервиса Remote SDK.

  Также в запрос "get platform features" добавлен новый компонент "remote_sdk", позволяющий отслеживать состояние сервиса Remote SDK (включен/выключен).

- Добавлен новый ресурс `/groups/{group_id}/streams`, позволяющий управлять потоками, которые принадлежат определенной группе.

  Добавлен запрос `patch streams in group`, который приводит все потоки группы в желаемое состояние (запуск/остановка). Изменения применяются только к тем потокам, которые находятся в отличном от целевого состоянии. Например, если необходимо запустить все потоки в группе, но некоторые из них уже запущены, то операция будет применена только к тем потокам, которые находятся в состоянии `stop`. Потоки, которые уже находятся в целевом состоянии (например, уже запущены `pending`), не будут изменены.
  Если в группе есть хотя бы один поток, который можно перевести в новое состояние (например, из `stop` в `pending`), запрос будет выполнен. Однако, если ни один поток нельзя изменить (например, все стримы уже находятся в целевом состоянии или их состояние нельзя изменить по другим причинам), будет возвращена ошибка с кодом 44015 и описанием `Unable to patch streams. No streams suitable for patching`.

  Добавлен новый запрос `remove all streams in the group`, позволяющий удалить все потоки из группы, без удаления самой группы.

  В запрос `remove group` добавлен параметр `with_streams`, позволяющий гибко управлять удалением: - при значении 0 (по умолчанию) удаляется только группа, а потоки остаются без изменений; - при значении 1 удаляются как группа, так и все связанные с ней потоки.

  Также представлена ​​возможность использования `group_id` в качестве фильтра для запроса `get streams` для получения всех потоков, принадлежащих указанной группе.

- Добавлен функционал сравнения по обобщенным событиям, который реализуется через новый запрос `general events matching`.

  Этот функционал позволяет сравнивать заданные эталоны — обобщенные события или дескрипторы в двоичном формате — с кандидатами, представленными в виде обобщенных событий.

  Результаты сравнения возвращаются в виде списка совпадений для кандидатов в соответствии с указанными фильтрами или пустого списка, если совпадений не найдено.

- Теперь можно запускать обработку видео как фоновую задачу, используя новый параметр `deferred_task` в запросе к ресурсу `/videosdk`.

  При выполнении запроса на обработку видео с включенным параметром `deferred_task` задача будет выполняться в фоновом режиме, при этом будет выдан `task_id` для отслеживания её статуса.

  Отследить статус задачи и получить URL-адрес результата (в случае успешного завершения) по `task_id` можно с помощью нового запроса `get task`.

  Теперь сервис Video Agent использует БД Redis для хранения задач фоновой обработки видео. В связи с этим введена новая группа настроек `LUNA_VIDEO_AGENT_REDIS_DB_ADDRESS`, которая включает следующие параметры: - "user" и "password" — параметры авторизации в Redis; - "host" — IP-адрес Redis; - "port" — порт, на котором работает Redis; - "number" — номер базы данных Redis (от 0 до 15).

  Также добавлен новый параметр `max_active_tasks` в настройке `LUNA_VIDEO_AGENT_SETTINGS`, позволяющий регулировать максимальное количество одновременно выполняемых задач в фоновом режиме одним агентом. По умолчанию установлено значение 2. Созданные задачи будут выполняться в порядке очереди, если количество активных задач достигнет указанного лимита.

- Теперь в настройках создания потока доступен новый параметр `notification_policy`, позволяющий отправлять уведомления об изменениях статуса обработки потока с помощью механизма Callback'ов.

  Например, когда поток взят в работу его статус принимает значение "pending", в процессе обработки агентом меняет статус на "in_progress", при успешной обработке становится "done" и др.

  Для отправки уведомлений доступны два типа callback'ов: - http — уведомления отправляются на указанный URL-адрес; - telegram — уведомления отправляются в Telegram-чат. Для этого требуется указать идентификатор чата `chat_id`, и токен авторизации `token` для Telegram.

  См. запрос `create stream`.

- В сервис Lambda добавлена возможность использования Poetry в качестве установки зависимостей.

  Использование Poetry улучшает процесс управления зависимостями, позволяя точно контролировать, какие версии пакетов будут установлены (благодаря `poetry.lock`), а также делает обновление зависимостей более предсказуемым и управляемым.

  Классический способ установки зависимостей через `pip install` и файл `requirements.txt` остается доступным, однако если в архиве с Lambda будут и файл `requirements.txt`, и файлы Poetry (например, `pyproject.toml` и `poetry.lock`), то приоритет будет отдан Poetry.

  См. подробную информацию в разделе "Lambda requirements" в руководстве разработчика сервиса Lambda.

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

- В разрешении токена `resources` на использование одного или нескольких ресурсов теперь доступен выбор ресурса `/videosdk`. См. запрос `create token`.

- Исправлена проблема некорректной работы параметра аналитики `rate` при использовании серверного времени в качестве источника временных меток для обработки потоков.

  Параметр `rate`, отвечающий за частоту обработки кадров, теперь корректно работает даже при использовании серверного времени в качестве источника временных меток.

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

# v.5.94.0

Изменения LP

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

  В данной версии LUNA PLATFORM:

  - обновлен эстиматор DeepFake до версии 7;
  - обновлен эстиматор OneShotLiveness до версии 9;
  - удалена поддержка 54-ой модели нейронной сети;
  - в контейнеры Remote SDK и Video Agent добавлена 65-ая модель нейронной сети для извлечения биометрических шаблонов лиц.

  Примечание. Обратите внимание, что добавленная сеть уже есть в контейнерах указанных сервисов и ее не надо добавлять вручную.

  Важно! Если на момент обновления используется 54-ая модель нейронной сети (настройка "DEFAULT_FACE_DESCRIPTOR_VERSION"), то без следующих действий сервис Remote SDK не запустится:

  - Выполнить задачу "Additional extraction" перед началом обновления, а затем указать новую версию в настройке "DEFAULT_FACE_DESCRIPTOR_VERSION" перед запуском сервиса Remote SDK, тем самым сохранив возможность использования старых биометрических шаблонов;
  - Указать новую версию в настройке "DEFAULT_FACE_DESCRIPTOR_VERSION" перед запуском сервиса Remote SDK. Если не будет выполнена "Additional extraction", то использовать уже существующие биометрические шаблоны будет невозможно.

- Сервис Python Matcher теперь относится к необязательным и регулируется в группе параметров "ADDITIONAL_SERVICE_USAGE".

  Для обеспечения возможности выполнения запросов на матчинг требуется, чтобы хотя бы один из сервисов, Python Matcher или Python Matcher Proxy, оставался включенным; если же оба сервиса будут отключены одновременно, это приведёт к следующим последствиям:

  - станет невозможно использовать политику сравнения "match_policy" обработчика;
  - будет отсутствовать возможность выполнять запросы к ресурсу "/matcher";
  - создание задач Clustering, ROC-curve calculating и Cross-matching будет недоступно.

  Также в запрос "get platform features" добавлен новый компонент "human_matching", статус которого зависит от состояния сервисов Python Matcher и Python Matcher Proxy.

  Компонент принимает значение "true", если включен хотя бы один из сервисов, и "false", если оба сервиса в выключенном состоянии.

- В обобщенные события добавлена поддержка работы с дескрипторами.

  В запрос `create new general event` добавлено новое поле `descriptors`, которое представляет собой набор дескрипторов разных типов.

  Также был добавлен новый запрос "get general event descriptors", с помощью которого можно получить дескрипторы обобщенных событий.

  Обратите внимание, что в обобщенные события можно записать не только дескрипторы лиц или тел. Главное, чтобы дескрипторы были в формате SDK.

- Для повышения скорости выполнения запросов таблицы `general_event_location` и `general_event` сервиса Events были объединены в одну.

  Теперь информация о местоположении, а именно `city`, `area`, `district`, `street`, `house_number`, `geo_position`, хранится в таблице `general_event`.

  Несмотря на данные изменения, структура запросов и ответов сервера не изменилась.

- Был модифицирован процесс записи данных в таблицу "general_events" с целью оптимизации БД.

  Ранее данные полей "event_id", "track_id", "stream_id", "source" и "location" записывались дважды: в поле "event" в JSON-формате и как самостоятельные поля в таблице.
  Теперь дублирование устранено, и данные записываются исключительно в отдельные поля таблицы "general_events".

- Добавлена ​​возможность использовать значение потока `last_processed_frame_time` в качестве фильтра для запроса `get streams logs`.

  `last_processed_frame_time` - это время последнего обработанного кадра с момента запуска потока. Если не было обработано ни одного кадра, параметр принимает значение `null`.

- Добавлена возможность задания пользовательской схемы для баз данных PostgreSQL, генерируемых с помощью утилиты Storages.

  Схема задается с помощью передачи переменной окружения `LUNA_PG_SCHEMA` во время запуска контейнера Storages с целью подготовки окружения (аргумент `prepare`).

  `LUNA_PG_SCHEMA` задает имя схемы PostgreSQL при создании таблицы. Значение по умолчанию - `luna`. Если значение `LUNA_PG_SCHEMA` отсутствует, то эта схема по умолчанию будет использоваться для новых таблиц, что делает ее схемой по умолчанию для соответствующего пользователя.

  Ранее для пользователя `luna` была возможность работать только со схемой с именем `public`.

  Это позволяет лучше организовывать данные и изолировать их для разных пользователей.

  Важно! Если имя схемы отличается от имени пользователя, таблица будет создана в схеме `public`.

  См. пример команды в разделе "Задание пользовательской схемы для баз данных".

- Добавлен функционал котороый позволяет использовать lambda для раздачи статического контента, например, пользовательских интерфейсов, HTML-страниц, JavaScript-скриптов или изображений.

  Для этого нужно поместить файлы в директорию "static" в архив с lambda.

  См. пример работы lambda с файлами в разделе "Standalone lambda examples".

- Теперь можно добавлять кастомные эндпоинты в любые типы лямбд.

  Например, можно создать энпоинт `/parameters/{UUID}`, который позволит сохранять и проверять уникальные параметры, или добавить другие эндпоинты для обработки специфичных запросов внутри лямбды.

  См. подробную информацию и примеры в разделе "Additional routes".

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

- В спецификацию аналитики `human tracking` был добавлен параметр "image_retain_policy", который ранее не отображался.

- В спецификацию сервиса API добавлен ​​отсутствующий запрос `stream events ws handshake`.

- Исправлена ошибка, возникающая при отправке запроса "get statistics on events" с использованием агрегатора `count` для таргетов из содержимого `meta` с нечисловым типом данных.

  Ранее в этом случае получение статистики событий приводило к ошибке с кодом `10020` (несовместимость заданных пользователем фильтров).

- Устранена утечка памяти в сервисе Video Agent, возникающая в процессе декодирования видео на GPU.

# v.5.92.0

Изменения LP

- Теперь в настройках создания потока доступен новый параметр `timeout`, позволяющий управлять временем ожидания при чтении видеопотока или обработке видеофайла.

  Для видеопотока параметр задает максимальное время ожидания загрузки сегмента потока. Если данные не получены за указанное время, процесс чтения прерывается. Значение по умолчанию — 3000 мс (3 секунды).

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

  См. запрос "create stream" или "get streams".

- Сервис Faces теперь относится к необязательным и регулируется в группе параметров "ADDITIONAL_SERVICE_USAGE".

  При отключении сервиса Faces:

  - работа с лицами, атрибутами и списками станет недоступна;
  - политика "storage_policy" > "face_policy" (и, соответственно, "link_to_lists_policy") обработчика/верификатора станет недоступна;
  - станет невозможно указывать лица в качестве кандидатов для сравнения в политике "match_policy" обработчика;
  - будет отсутствовать возможность работы с задачей Linker, а задачи Clustering, Reporter, Exporter, Cross-matching, Garbage Collection, Additional extraction и ROC-curve calculating во всех сервисах не смогут работать с лицами и атрибутами.

- Теперь параметр `droi` поддерживает текстовый формат представления геометрических объектов Well-known text (WKT) для определения зоны интереса относительно исходного кадра.

  Новый формат позволяет задавать области интереса в ранее недоступных формах. Например, теперь можно определять сложные полигоны с вырезами. Пример WKT для простого полигона: `POLYGON ((30 10, 20 40, 40 40, 10 20))`.

  См. запрос "videosdk" и описание параметров в спецификациях аналитик People count и Human tracking.

- Теперь можно вручную создать обобщенное событие через новый запрос "create new general event".

- Для параметра видеоаналитики `image_retain_policy` было добавлено значение `ttl`, которое отвечает за время существования сохраненных изображений. См. ресурс "/videosdk".

- В логах сервиса Handlers теперь фиксируется время начала и конца работы обработчика/верификатора и время выполнения их политик.

- Теперь при нескольких обнаружениях на одном кадре источник изображения загружается в Image Store только один раз для всех детекций, если включена политика "image_origin_policy".

  Это позволяет предотвратить многократную загрузку одного и того же изображения.

- Проверка работоспособности Kubernetes (runtime check) в сервисе Lambda теперь использует уже установленные соединения и конфигурацию, а не инициализирует новый клиент каждый раз.

  Это позволяет избежать лишней нагрузки и повысить стабильность работы, так как старые соединения и конфигурации могут быть уже настроены и корректно работать. Прежнее поведение, когда каждый раз создавался новый клиент, могло приводить к сбоям или неправильной работе, особенно если текущие соединения были некорректно закрыты или повреждены.

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

- В клиент LUNA Events в Lambda добавлены функции для работы с обобщенными событиями.

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

- Теперь при возникновении неожиданных исключений в lambda, трассировки ошибок (traceback) будут записываться в логи.

# v.5.91.0

Изменения LP

- Теперь если создается поток в котором указан набор аналитик, который не поддерживается целиком ни одним из агентов, зарегистрированных в Video Manager, то будет выдана ошибка 44014 с сообщением `Unprocessable content. Failed to find agent that supports all analytics associated with the stream`.

  Раннее такой поток просто никуда не отправлялся.

  Важно! Каждый поток должен содержать только тот набор аналитик, которые поддерживаются определенным агентом. Например, можно создать один поток с аналитиками отслеживания людей и подсчета количества людей т.к. сервис Video Agent поддерживает обе эти аналитики. Но нельзя создать один поток с аналитикой подсчета толпы (агент Video Agent) и другой аналитикой, поддерживаемой другим агентом. В таком случае нужно создавать два отдельных потока.

- Идентификатор обрабатываемого потока теперь включается в идентификатор запроса в логах сервиса Video Agent.

- Теперь в Handlers-lambda можно получить `handler_id`, с которого был сделан запрос с типом обработчика `lambda`. См. пример кода в разделе "Handlers lambda examples".

  Во все виды Lambda также добавлена возможность выполнять соответствующие запросы к сервису Handlers.

- Теперь в Handlers и Standalone лямбдах доступны query-параметры из пользовательского запроса. Ранее они не передавались, теперь же лямбда может их получать и использовать.

  Например, можно выполнить запрос через лямбду в другой канонический обработчик, чей идентификатор будет передан через query-параметр.

  См. пример кода в разделе "Handlers lambda examples".

- В Lambda добавлена возможность проверки статуса дополнительных сервисов (включен/выключен) через простые параметры. Теперь можно использовать такие свойства, как `eventsEnabled`, `senderEnabled`, `handlersEnabled` для получения статуса соответствующих сервисов. Подробнее см. в разделе "Luna client services", а также см. "пример для Standalone-lambda".

- В руководство администратора в раздел "Сервис Streams Retranslator" добавлено описание масштабирования сервиса.

  Примеры масштабирования доступны в руководстве разработчика Streams Retranslator в разделе "Scaling".

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

- Исправлена ошибка с кодом 500, возникающая при отправке запросов "get statistics on events" и "get statistics on general events", если в запросе передавался нулевой интервал `group_by` (например, `0m`).

- Обновлены несколько примеров Lambda, в частности пример Handlers-lambda.

  В примере поддержана передача полей `detectTs`, `detectTime`, `eventCreateTime` и `eventEndTime` из заголовка. Теперь пользователь может либо отправлять их вручную, либо оставить пустыми — в этом случае они будут заполнены значениями по умолчанию. Ранее же всегда поля заполнялись значениями по умолчанию.

- Исправлена валидация поля `detect_ts` в Handlers-lambda.

  Ранее оно передавалось как строка, теперь корректно обрабатывается как число.

- Исправлена инициализация клиентов в случаях, когда некоторые сервисы были отключены с помощью настройки "ADDITIONAL_SERVICES_USAGE".

- В спецификацию аналитики People count добавлено отсутствующее описание для некоторых параметров.

# v.5.89.0

Изменения LP

- Добавлен новый сервис Streams Retranslator, предоставляющий функционал ретрансляции потокового видео.

  Основное предназначение сервиса — преобразование входящих видеопотоков в формат HLS (в дальнешем список форматов может быть увеличен), что упрощает их воспроизведение в пользовательских интерфейсах, веб-браузерах и др.

  Основные возможности:

  - Гибкое управление качеством трансляции: возможность указать разрешение потока (высота кадра в пикселях), чтобы адаптировать его к различным сценариям использования.
  - Защита доступа: использование JWT-токенов для авторизации доступа к HLS-потоку.
  - Автоматическое управление ретрансляцией: поток автоматически завершается, если не востребован в течение времени, заданного параметром "LUNA_STREAMS_RETRANSLATOR_IGNORED_RESTREAM_TTL".

  Сценарий использования:

  1. Пользователь отправляет запрос на ретрансляцию потока через сервис API.

  2. Сервис Stream Retranslator запускает конвертацию потока с помощью FFmpeg и MediaMTX.

  3. В ответе пользователь получает ссылку на HLS-поток и токен для доступа.

  4. Ссылка на поток и токен интегрируются в интерфейсы для просмотра.

  См. подробную информацию в разделе "Сервис Streams Retranslator".

- Потеря соединения во время чтения стрима больше не приводит к запрету перезапуска видеопотока. Данное изменение позволяет улучшить работу с нестабильными видеопотоками.

  При этом ошибка недоступности видеофайла всё ещё остаётся критической ошибкой и запрещает перезапуск.

- Добавлено сохранение коэффициента масштабирования для исходного карта. Коэффициент высчитывается на основе параметра `max_size` для `image_retain_policy` и используется в качестве значения для заголовка `X-Luna-Meta-Rescale` в Image Store. Если значение `image_retain_policy` задано равным 0, то для полного кадра масштабирование не будет применено.

  Изменение позволяет прозрачно работать с масштабированием исходных кадров.

- Расширен вывод информации об ошибках таймаута в агентах видеоаналитик. Теперь вместо `TIMEOUT` в лог выводится более информативное сообщение `An error occurred during stream/video decoding around 123.456 second: TIMEOUT`.

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

- Версии сервисов LUNA Video Manager и LUNA Video Agent были добавлены в ресурс /version.

- Поле `source` для general events было перенесено в структуру `event` из корня JSON get general events .

- Исправлена проблема, при которой некорректно обрабатывался лимит на количество эталонов. Если в разделе "PLATFORM_LIMITS" в Configurator в параметре "match.reference_limit" было задано 30 кандидатов, то при указании 30 кандидатов в запросе возвращалась ошибка.

- Исправлено описание параметра `interval` в документации API для видеоаналитик, теперь он указан как required. Ошибка, которая возвращается при отсутствии параметра, заменена на более информативную.

- Исправлена проблема, когда уведомления отправлялись даже при выключенной аналитике human tracking.

- Исправлена проблема с распределением стримов при использовании OracleDB.

# v.5.88.0

Изменения LP

- Добавлена поддержка 65 сети извлечения биометрических шаблонов лиц.

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

- Теперь Redis в поставке LUNA PLATFORM запаролен.

  Пароль передается при запуске контейнера Redis в скрипте Docker Compose. Также в документации в команду запуска контейнера Redis добавлено пробрасывание дефолтного пароля.

  Поскольку часть настроек LUNA PLATFORM требует аутентификации к Redis, а Redis теперь по умолчанию запаролен, то при обновлении необходимо обязательно добавить пароль к следующим настройкам:

  - LUNA_ATTRIBUTES_DB
  - REDIS_DB_ADDRESS
  - TASKS_REDIS_DB_ADDRESS
  - BACKPORT3_EVENTS_DB_ADDRESS

  В противном случае сервисы не запустятся

  Для первичной установки добавлять пароль не обязательно, если выполняется загрузка дамп-файла `platform_settings.json` из комплекта поставки (в скрипте Docker Compose она выполняется).

  Все вышеописанное также распространяется на поставку в Kubernetes.

- В general events добавлено поле `source`, позволяющее отражать информацию об источнике.

- В general events добавлена фильтрация по stream_ids, и локации (`geo_position`, `cities`, `areas`, `districts`, `streets`, `house_numbers`).

- Параметры `handler_id` и `source_type` аналитики `human_tracking` были перемещены в раздел `parameters`.

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

- Добавлены фильтры по полю `insert_time` для событий в ресурсы "events" и "general events".

- Исправлена проблема, когда сервис Admin не запускался при выключенных сервисах Handlers и Image Store.

- Исправлена проблема, когда Video Manager возвращал дубликаты агентов при их получении в запросе get agents.

# v.5.86.0

Изменения LP

- SDK обновлён до версии 5.24.0.

  В данной версии SDK обновлена версия Deepfake Detector до версии 6.

- Реализован механизм обобщенных событий, позволяющий сохранить событие с какой-либо пользовательской структурой, сгенерированной видеоаналитикой, плагином или каким-либо клиентским приложением в БД Events.

  Сохранить обобщенное событие можно с помощью запроса "create new general events" к сервису Events. Соответственно, если пользователь пишет собественную видеоаналитику, плагин или приложение, то он должен отправлять данные в вышеописанный эндпоинт.

  При сохранении события требуется задать обязательные параметры "event_type" , "event_create_time", "account_id", "event_id". Можно задать дополнительные параметры, такие как "location", "stream_id" и пр., для эффективного поиска по БД Events.

  Поиск по БД Events можно выполнить с помощью запросов "get general events" и "get general event".

  Также можно получить статистику по обобщенным событиям с помощью запроса "get statistics on general events".

  Также добавлен новый таргет `general_events` для задачи Garbage Collection, позволяющий выполнять очистку обобщенных событий по заданным фильтрам. В качестве фильтров можно выбирать тип события.

  При работе с механизмом обобщенных событий необходимо помнить о некоторых правилах для корректной работы. См. подробную информацию в разделе "Обобщенные события".

- В видеоаналитики People count и Human tracking добавлен новый тип Callback'а `luna-event`, позволяющий сохранять обощенные события в БД Events с помощью механизма обобщенных событий (см. выше).

  Получить такие события можно с помощью запросов "get general events" и "get general event", указав в качестве фильтра полученный идентификатор "stream_id".

- Теперь спецификации аналитик People count и Human tracking расположены в комплекте поставки по пути "docs/ReferenceManuals".

- Теперь использование сервиса Video Agent регулируется в настройке "ADDITIONAL_SERVICES_USAGE".

  В скрипте Docker Compose из комплекта поставки при флаге `--extra videoanalytics` теперь также включается сервис Video Agent.

- Теперь фильтр `event_type` в запросе "ws handshake for general events" не является обязательным и для него можно указать несколько значений.

- В ресурс `/sdk` добавлена возможность оценки перекрытия зон лица `estimate_face_occlusion` и фильтрации на основе перекрытия зон лица `face_occlusion_states`.

  Проверки `face_quality` в handler detect policy и verifier расширены набором проверок для перекрытия лица:

  - `face_occlusion` - перекрытие зоны лица;
  - `lower_face_occlusion` - перекрытие нижней части лица;
  - `forehead_occlusion` - перекрытие зоны лба;
  - `nose_occlusion` - перекрытие зоны носа.

- Добавлена возможность смены пароля администратора через ресурс `/patchAccount` сервиса Admin.

- Увеличено значение по умолчанию для параметра `PLATFORM_LIMITS.CROSS_MATCH.GENERAL_LIMIT` до 100000000.

  Значение будет обновлено только при установке с нуля. При миграции значение обновляться не будет.

  Параметр "general_limit" задает общее ограничение на количество перекрестных сравнений. Он применяется к произведению количества кандидатов и эталонов, которые участвуют в операции сравнения с учетом фильтров. Если произведение превышает значение "general_limit", запрос завершится ошибкой.

Обновления интерфейса

- Исправлена проблема, когда в интерфейсе не отображались события, созданные для типа "advanced_user".

- Раздел Мониторинг: Добавлен столбец "Проверка работоспособности" с отображением времени ответа системы в секундах. Теперь можно получить более точную информацию о доступности сервисов.

- Разделы Последние события, Архив событий, Детали события, Поиск: Теперь можно быстрее узнать, прошло ли лицо проверки Liveness и Deepfake: результаты проверок вынесены на иконки-карточки. Добавлено поле "Видеопоток" для отображения текущего названия источника, зафиксировавшего событие. Название источника в момент фиксации события теперь отображает поле "Источник".

- Разделы Сценарии, Верификация: Обновлены названия параметров в формах настройки проверок Liveness и Deepfake.

- Общее: Обновлён шрифт для текстовых элементов в интерфейсе.

- Разделы Сценарии, Верификация: Удалено поле "Порог качества изображения" для настройки порога качества Liveness.

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

- Исправлена проблема при попытке сохранения события с помощью запроса "save event", возникавшая в случае, если событие содержит лицо, не прикреплённое ни к одному списку.

- Исправлена ошибка запуска Python Matcher при выключенном сервисе Events.

# v.5.84.0

Изменения LP

- SDK обновлен до версии 5.23.0.

  - Эстиматор Deepfake обновлён до версии 5;
  - Эстиматор OneShotLiveness обновлён до версии 8;
  - Удалена поддержка 52-ой версии нейронной сети биометрического шаблона лиц;
  - Из комплекта поставки удалена 110-ая версия нейронной сети дескрипторов тел. Теперь по умолчанию используется 116-ая для извлечения биометрических шаблонов тел (настройка "DEFAULT_HUMAN_DESCRIPTOR_VERSION" сервиса Remote SDK).

  Важно! Если на момент обновления используется 110-ая модель нейронной сети (настройка "DEFAULT_HUMAN_DESCRIPTOR_VERSION"), то без дополнительных действий сервис Remote SDK не запустится.

  Необходимо выполнить одно из дополнительных действий ниже:

  - Запросить отсутствующую модель у VisionLabs и самостоятельно добавить в контейнер Remote SDK.
  - Выполнить задачу "Additional extraction" перед началом обновления, а затем указать новую версию в настройке "DEFAULT_HUMAN_DESCRIPTOR_VERSION" перед запуском сервиса Remote SDK, тем самым сохранив возможность использования старых биометрических шаблонов.
  - Указать новую версию в настройке "DEFAULT_HUMAN_DESCRIPTOR_VERSION" перед запуском сервиса Remote SDK. Эта настройка не будет автоматически обновлена при выполнении миграции. Если не будет выполнена "Additional extraction", то использовать уже существующие биометрические шаблоны будет невозможно.

- Добавлен новый эстиматор проверки лиц - "Face Occlusion", который позволяет автоматически определять наличие перекрытия зон лица.

  Эстиматор позволяет определить наличие перекрытия всего лица или его отдельных зон.

  Эстиматор возвращает информацию о перекрытии:

  - Всего лица
  - Зоны лба
  - Зоны глаз
  - Зоны носа
  - Зоны рта
  - Нижней части лица

  Ресурсы, в которых выполняется оценка:

  - "/handlers"

    Название оценки — "estimate_face_occlusion".

  - "/verifiers"

    Название оценки — "estimate_face_occlusion".

  Пороги перекрытия

  Возможно задать допустимый процент перекрытия всего лица или каждой отдельной части лица на уровне всей системы в Configurator. Кроме того, пороги можно переопределить при создании обработчика или верификатора.

  Возможно задать порог для перекрытия волосами. Порог указывает допустимый процент перекрытия волосами, при котором волосы не учитываются в качестве перекрытия. Всё перекрытие, которое превышает указанный порог, учитывается в общем перекрытии лица и перекрытии каждой из зон лица.

  - Если порог перекрытия волосами задан равным 0, то волосы любой длины будут считаться перекрытием.
  - Если порог перекрытия волосами задан равным 1, то перекрытие волосами не учитывается.

  Пороги могут быть изменены в соответствии с бизнес задачами.

  Примечание. Зона усов и бороды никогда не считаются перекрытием лица.

  Фильтрация

  Доступна фильтрация. Имеется возможность указать список зон, которые не должны быть перекрыты.

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

- В сервис Video Agent добавлена поддержка видеоаналитики трекинга людей.

  Возможно указывать в качестве источника для обработки с помощью видеоаналитики видеопоток или видеофайл.

  Для трекинга людей используется фильтрация по AGS и положению головы.

- В сервис Configurator добавлена возможность использования авторизации типа BasicAuth для запросов, логически требущих авторизации.

  Примечание. Данный функционал находится в стадии бета-тестирования.

  Для включения авторизации нужно задать следующие настройки из новой секции "LUNA_CONFIGURATOR_AUTHORIZATION" сервиса Configurator:

  - "USE_AUTHORIZATION" - включение/выключение авторизации
  - "LUNA_CONFIGURATOR_USER" - логин, который будет использоваться другими сервисами для авторизации
  - "LUNA_CONFIGURATOR_PASS" - пароль, который будет использоваться другими сервисами для авторизации

  Задать настройки можно двумя способами:

  - передача настроек через переменную окружения `VL_SETTINGS` при старте сервиса. Например:

      env "VL_SETTINGS.LUNA_CONFIGURATOR.USE_AUTHORIZATION=1"
      env "VL_SETTINGS.LUNA_CONFIGURATOR.LUNA_CONFIGURATOR_USER=luna"
      env "VL_SETTINGS.LUNA_CONFIGURATOR.LUNA_CONFIGURATOR_PASS=root"

  - передача настроек в конфигурационный файл сервиса Configurator. Конфигурационный файл сервиса Configurator расположен по следующему пути в поставке `example-docker/luna_configurator/configs/luna_configurator_postgres.conf`

  Для того, чтобы остальные сервисы LUNA PLATFORM могли выполнять запросы к сервису Configurator нужно передать им логин и пароль. Это можно сделать с помощью следующих способов:

  - передача настроек "LUNA_CONFIGURATOR_USER" и "LUNA_CONFIGURATOR" через переменную окружения `VL_SETTINGS` при старте сервиса (см. пример выше)
  - передача настроек "LUNA_CONFIGURATOR_USER" и "LUNA_CONFIGURATOR" в конфигурационный файл сервиса

  Использование авторизации позволяет обеспечить дополнительную степень безопасности и защиту от несанкционированного доступа. Для обеспечения шифрования необходимо использовать SSL-сертификаты или проксирование через Nginx.

- В запрос `videosdk` для видеоаналитики отслеживания людей добавлен параметр `rate`, с помощью которого можно настроить частоту обработки кадров (например, обрабатывать каждые 3 секунды или каждые 3 кадра).

  Значение параметра`rate` по умолчанию - 1 кадр.

  Раньше данный параметр был доступен только для аналитики подсчета количества людей.

- В сервис Remote SDK добавлена группа параметров `LUNA_REMOTE_SDK_HUMAN_TRACKER_SETTINGS`, которая позволяет настроить параметры TrackEngine.

  Доступны следующие параметры:

  - `runtime_settings > device_class` — задает тип устройства ("cpu", "gpu" или "global");
  - `runtime_settings > optimal_batch_size` — задает размер батча;
  - `estimator_settings > detector_step` - задает частоту детектирования лиц и тел на кадрах. На остальных кадрах выполняется редетекция;
  - `estimator_settings > scale_result_size` - определяет, до какого размера (в пикселях) масштабируется кадр перед тем, как он будет отправлен на детекцию. Изображение масштабируется по максимальному измерению (ширина или высота);
  - `estimator_settings > skip_frames` - определяет количество кадров, на протяжении которых система не завершает трек в ожидании повторного объекта. Если трек не был продлён ни детектором, ни редетекцией, трек завершается.

- В запрос `videosdk` для видеоаналитики трекинга людей добавлена поддержка задания области интереса DROI относительно исходного кадра.

  См. описание DROI в разделе "droi".

- Запросы на кросс-матчинг с использованием сервиса Python Matcher Proxy были ускорены за счет реализации пакетной обработки.

- Теперь в запросе `videosdk` для видеоаналитики трекинга людей биометрические шаблоны лиц фильтруются по AGS, а не по степени достоверности детекции (Detection score), что позволяет отсекать некачественные детекции.

  Если эстиматор AGS недоступен, то будет использоваться фильтрация по степени достоверности детекции.

- В запрос `get platform features` добавлен параметр `video_analytics`, позволяющий отслеживать состояние сервиса (включен/выключен).

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

- В спецификацию OpenAPI сервиса API добавлен лимит на загружаемые лица для запроса "attach/detach faces to the list".

- Исправлена ошибка, которая возникала при отправке запроса `generate stream events` из-за чего возникало несоответствие количества биометрических образцов числу переданных детекций.

- Исправлена ошибка, из-за которой нельзя было создавать потоки с несколькими аналитиками одного типа, но с разными параметрами.

- Исправлена ошибка, из-за которой сервис Video Manager некорректно обрабатывал потоки с несколькими аналитиками.

- Исправлена ошибка в запросах `generate stream events` и `generate events` из-за которой создавалось новое лицо если детекция лица не была выполнена.

- Исправлена ошибка при которой значения параметров "RESPONSE_TIMEOUT" групп "LUNA_MATCHER_PROXY_HTTP_SETTINGS" и "LUNA_PYTHON_MATCHER_HTTP_SETTINGS" не обновлялись должным образом и всегда применялось дефолтное значение в 600 секунд.

# v.5.81.2

Изменения LP

- Добавлена отдельная лицензируемая функция, определяющая максимальное количество потоков, которые могут быть взяты единовременно в обработку из сервиса Video Manager.

  Сервис Video Manager проверяет наличие лицензии каждый раз при создании потока, а также проверяет отчеты (если они есть) для определения количества обрабатываемых потоков сервисом Video Agent.

  В запрос "get system info" сервиса Admin также добавлена секция "analytics_streams_limit", определяющая максимальное одновременное количество обрабатываемых потоков.

  Важно! При обновлении на новую версию LUNA PLATFORM нужно заново выписать лицензию Guardant если включена функция на проверку ISO. Если же функция на проверку ISO не включена, то старая лицензия Guardant будет работать корректно при обновлении.

- В сервис API добавлен новый запрос `stream events ws handshake`, позволяющий установить веб-сокет соединение для получения результатов обработки эстиматоров в реальном времени с помощью указания "stream_id".

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

- В группы параметров "LUNA_REMOTE_SDK_VIDEO_SETTINGS" и "LUNA_VIDEO_AGENT_VIDEO_SETTINGS" добавлены параметры "frame_pool_size" и "ffmpeg_thread_count", предназначенные для работы с декодированием видео.

  Параметр "frame_pool_size" задает количество кадров, которые надо заранее выделить для обработки потока. Это ускоряет процесс декодирования, особенно на графическом процессоре (GPU), за счёт того, что кадры уже зарезервированы и не нужно каждый раз выделять память для нового кадра.

  Параметр "ffmpeg_thread_count" задает количество потоков (threads), которые будут использованы FFmpeg для выполнения декодирования видео. Значение 0 означает, что система будет использовать автоматическое количество потоков, которое выберет сам FFmpeg в зависимости от конфигурации устройства.

- Реализована отправка данных для мониторинга из сервиса Video Agent в InfluxDB.

  См. подробную информацию в разделе "Monitoring" в руководстве разработчика.

- В мониторинг сервиса Remote SDK добавлена серия `human_track`, предназначенная для мониторинга работы TrackEngine. Также из мониторинга удалены повторящющиеся и ненужные данные из серии `node_human_tracking`.

  См. подробную информацию в разделе "Monitoring" в руководстве разработчика.

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

- Исправлено появление ошибки `S3 is unknown setting`, возникавшее в некоторых случаях при подготовке окружения для S3-подобного бакета.

- Исправлена ошибка в сервисе Backport 4, при которой несовместимое событие с типом события `top_match`, сгенерированное сервисами LUNA PLATFORM, вызывало ошибку `Internal server error` в ответе на запрос `get events request`.

- Устранена утечка памяти при использовании ресурса `videosdk`.

- Исправлена ошибка, которая возникала при миграции базы данных Video Manager с ревизии `4a8f1dcb4b5b`.

# v.5.78.0

Изменения LP

- Значение настройки "ALLOW_LUNA_ACCOUNT_AUTH_HEADER" теперь по умолчанию установлено в `false`.

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

  Это изменение связано с тем, что данный метод авторизации давно объявлен устаревшим.

  Важно! В ближайшее время поддержка метода "LunaAccountIdAuth" будет окончательно прекращена. Рекомендуется перейти на использование "BasicAuth" и "BearerAuth", если переход еще не был выполнен.

- Теперь биометрические шаблоны лиц и тел, возвращаемые в теле ответа на запрос "videosdk" с аналитикой трекинга людей, возвращаются в формате SDK, а не Raw-формате.

  Благодаря этому можно использовать биометрические шаблоны, получаемые из запроса "videosdk", как кандидаты в запросах на сравнение.

- Добавлена поддержка 115 версии нейронной сети для извлечения биометрических шаблонов тел.

- Использование порога Quality для Liveness теперь считается устаревшим.

  Параметр "quality_threshold" удален из группы параметров "LUNA_REMOTE_SDK_LIVENESS_ESTIMATOR_SETTINGS", а в спецификации OpenAPI параметр помечен как Deprecated. Для обратной совместимости поле `quality` сохраняется в ответе, но всегда принимает значение 1.

- Теперь при выполнении запроса "perform verification" добавляется тег "verifier_id" в InfluxDB.

  См. подробную информацию о мониторинге сервиса Handlers в разделе "Monitoring" руководства разработчика сервиса Handlers.

- В руководстве разработчика Lambda обновлен пример Standalone-lambda, которая реализует функционал сравнения лиц из видео с лицами из списка.

  Теперь в примере используются биометрические шаблоны в формате SDK вместо устаревшего Raw-формата.

- В скрипте "start_platform.sh" по разворачиванию Docker Compose теперь используется Storages для подготовки окружения.

  Теперь скрипт поддерживает следующие аргументы:

  - `--common` - подготовка окружения с профилем `common` и запуск LUNA PLATFORM без Backport'ов и сервисов Video Manager и Video Agent
  - `--extra backport3` - при активации вместе с `--common` будет использован профиль `backports` при подготовке окружения, а также запущен сервис Backport3 и его пользовательский интерфейс
  - `--extra backport4` - при активации вместе с `--common` будет использован профиль `backports` при подготовке окружения, а также запущен сервис Backport3 и его пользовательский интерфейс
  - `--extra videoanalytics` - при активации вместе с `--common` будет включено использование сервиса Video Manager и Video Agent в настройке "ADDITIONAL_SERVICES_USAGE", а также запущены сервисы Video Manager и Video Agent
  - `--help/-h` - вывод справочной информации

  Комбинирование флагов `--extra backport3`, `--extra backport4`, и `--extra videoanalytics` вместе с `--common` позволяет включить сразу несколько дополнительных сервисов.

  Использование флагов `--extra` без флага `--common` невозможно.

  Если аргументы не заданы, скрипт выполнит развертывание LUNA PLATFORM аналогично аргументу `--common`.

  Обратите внимание, что скрипт "start_platform.sh" является примером разворачивания LUNA PLATFORM с помощью Docker Compose в минимальной рабочей нагрузке и не предназначен для использования в продуктивном контуре.

- Теперь при развертывании Storages в кластере Kubernetes с помощью манифестов из комплекта поставки, поды Storages не будут автоматически перезапускаться в случае ошибки выполнения.

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

- Исправлена ошибка миграции `lis_bucket` в Storages при даунгрейде в случае, когда сервис Image Store еще не поддерживал TTL.

- Исправлена ошибка миграции `influx_bucket` в Storages при обновлении со старой версии, где была настройка "LUNA_MONITORING".

- Исправлено отсутствие проверки соединения с БД для сервиса Video Manager.

# v.5.76.4

Изменения LP

- Обновлена версия спецификации Docker Compose в комплекте поставки с 3.6 до 3.9.

  Для использования спецификации версии 3.9 требуется Docker Compose версии 1.25.0 или новее.

- В руководство разработчика Lambda добавлен пример Standalone-lambda, которая реализует функционал сравнения лиц из видео с лицами из списка.

- Теперь однотипные ошибки для каждого потока будут отправляться в качестве фидбека в сервис Video Manager не чаще, чем раз в 5 секунд.

  Изменение способствует упрощению логов, снижая частоту повторяющихся ошибок и улучшая их восприятие.

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

- Исправлена ошибка из-за которой скрипт `influx2_cli.py`, включающий сбор агрегированной статистики в InfluxDB, не игнорировал ошибки существования объектов по умолчанию.

  Это приводило к тому, что если во время первичной настройки LUNA PLATFORM уже был включен сбор статистики (создан бакет `luna-admin` в InfluxDB), то повторное выполнение скрипта при обновлении завершалось ошибкой. Теперь в скрипт добавлен флаг игнорирования существования объектов `--ignore-integrity`, который включен по умолчанию.

- Исправлено появление ошибки "ContentLengthError: Not enough data for satisfy content length header", возникающей при выполнении запроса на кросс-матчинг с использованием сервиса Python Matcher Proxy с большим количеством биометрических шаблонов.

- Исправлена ​​обработка ошибок декодирования.

  Ранее сервис Remote SDK возвращал ошибку `Internal server error` при выполнении запроса "videosdk", если во время декодирования видео возникала ошибка.

  Теперь в этом случае сервис возвращает ошибку с кодом 43004 с описанием "Error occurred while decoding video" и кодом состояния 400.

- Исправлена ошибка получения некорректных временных меток при обработке некоторых видео без указания парамтера "pts" в запросе "videosdk".

# v.5.76.0

Изменения LP

- В запрос "create stream" добавлены параметры "downloadable" и "timestamp_source", улучшающие управление загрузкой видео и выбор источника временных меток, обеспечивая более гибкую и точную обработку видео.

  Параметр "downloadable" определяет необходимость предварительного скачивания видеофайла перед его обработкой. Предварительная загрузка необходима для:

  - Успешного декодирования видеофайлов. Для некоторых файлов могут возникнуть ошибки декодирования, если файлы не будут предварительно сохранены.
  - Длительных процессов обработки. Если обработка видео занимает значительное время, хранение предотвращает проблемы, связанные с разрывом соединения.

  Обратите внимание, что иногда политики безопасности запрещают сохранение видеофайлов. В таких случаях предварительное скачивание может быть не применимо.

  Параметр "timestamp_source" определяет, откуда будут браться временные метки для видеоанализа. Доступны следующие значения:

  - "pts" - Использует временные метки видео, если они существуют, для точного отображения времени воспроизведения. Метки не всегда могут быть корректными (см. ниже).
  - "server" - Применяет серверное время для видеопотока, что гарантирует единообразие и синхронизацию с другими событиями.
  - "frame_rate" - Применяет частоту кадров для видеофайлов, что помогает приблизительно определить временные метки.
  - "auto" (по умолчанию) - Автоматически выбирает источник времени, сначала проверяя временные метки ("pts"), а затем переключаясь на серверное время ("server") или частоту кадров ("frame_rate"), если метки некорректны.

  Корректные метки для видеофайла означают, что временные метки (PTS) должны быть близки к нулю, то есть время от начала видео до метки должно быть относительно небольшим (абсолютное значение не должно превышать 10^5 секунд).

  Корректные метки для видеопотока означают, что время видеопотока отличается от времени сервера менее чем на 1 день.

- Добавлена возможность задать пользовательское смещение для временных меток видео (PTS) в запросе "create stream".

  Указание смещения позволяет синхронизировать начало обработки видео с конкретным моментом времени. Это может быть полезно, например, если видео обрабатывается частями и необходимо, чтобы временные метки новых частей продолжали последовательность с предыдущих. Таким образом, при нарезке большого видео на маленькие фрагменты, временные метки будут отображаться так, как если бы обрабатывалось одно целое видео.

  Смещение задается в параметре "pts" > "start_time" тела запроса.

- Группа параметров "INFLUX_MONITORING" переименована в "LUNA_MONITORING".

  В группу добавлен параметр "storage_type", определяющий тип хранилища данных мониторинга. В настоящее время доступен только тип "influx".

  Важно! При обновлении окружения с помощью Storages с указанием разных сущностей (например, "luna_prepare configs", "luna_prepare database" и др.), необходимо выполнять обновление окружения для InfluxDB (аргументы "aggregated_influx_bucket" и "influx_bucket") строго после миграции настроек (аргумент "configs"). В противном случае подготовка окружения не будет выполнена корректно. При выполнении всего окружения с помощью аргумента "all_entities" никаких дополнительных действий делать не нужно.

- Уменьшено потребление памяти при выполнении задач кластеризации.

- В текущем релизе обновлен базовый образ Lambda.

  Необходимо выполнить запрос "update lambda" для обновления базового образа пользовательской Lambda.

  См. раздел "Обновление lambda" в руководстве администратора для более подробной иннформации.

# v.5.75.1

Изменения LP

- Теперь сервисы Remote SDK и Video Agent загружают видео напрямую из сервиса Image Store, если оно было загружено через ресурс `/objects` сервиса API.

  Настройки сервисов Remote SDK и Video Agents дополнились настройкой "LUNA_IMAGE_STORE_OBJECTS_ADDRESS".

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

- Исправлена ошибка, не позволяющая выполнять сравнение без инструкции `avx512` на сервере.

  Попытка выполнить сравнение без наличия инструкции завершалась остановкой сервиса Python Matcher.

- Исправлена ошибка, при которой в некоторых случаях невозможно было отменить выполнение задачи с помощью запроса "cancel task".

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

- Общее: Улучшена навигация по страницам выпадающего меню благодаря выделению раздела, в котором находится пользователь.

- Раздел "Проверки": Расширили функционал раздела благодаря оптимизациям в расположении и логике работы элементов.

- Разделы "Последние события", "Архив событий": Теперь стабильно отображаются события с распознаванием тел. Если в событии есть несколько детекций тел, то отображается та детекция, у которой есть фото события.

# v.5.75.0

Изменения LP

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

  Работа сервисов видеоаналитики основана на взаимодействии трех ключевых компонентов: аналитик, агентов и сервиса Video Manager.

  Аналитика

  Аналитика представляет собой набор алгоритмов, которые выполняют определенные задачи по обработке потоков. Для каждой аналитики предусмотрен набор параметров, который может быть настроен пользователем. Video Manager хранит информацию о доступных аналитиках и передает ее агентам, которые реализуют соответствующие алгоритмы.

  Агент

  Агент — это компонент, который реализует алгоритмы видеоаналитики. Он принимает потоки, выполняет заданную аналитику и отправляет результаты через механизм Callback'ов или через веб-сокеты и сервис Sender. Каждый агент может поддерживать выполнение одной или нескольких аналитик, в зависимости от своей конфигурации и возможностей.

  В качестве агента можно использовать сервис Video Agent, либо написать собственного агента.

  В настоящий момент сервис Video Agent предоставляет следующие только одну аналитику - подсчет количества людей. В будущих релизах список аналитик будет расширен.

  Video Manager

  Video Manager выступает в роли координатора между пользователями и агентами. Он содержит информацию о доступных аналитиках и распределяет видеопотоки на обработку среди агентов. Video Manager также отвечает за управление потоками, следит за их статусом и координирует автоматический перезапуск потоков в случае возникновения ошибок.

  Таким образом в LUNA PLATFORM теперь есть два способа выполнения видеоаналитики:

  - с помощью новых сервисов:
    - более гибкий функционал
    - отправка уведомлений в сторонние системы и хранение информации в БД
    - возможность написания собственного агента для обработки пользовательской аналитики
  - с помощью запроса "videosdk":
    - упрощенный функционал
    - результат возвращается только в теле ответа и никуда не сохраняется. В таком случае, пользователь сам может интепретировать результат работы на всем видео, решить где ему хранить данные и пр.

  Аналитика подсчета количества людей, как и в запросе "videosdk", лицензируется отдельно.

  Сервис Video Manager по умолчанию отключен в настройке "ADDITIONAL_SERVICES_USAGE".

  Новые сервисы поддержаны:

  - в сервисе LUNA Dashboards
  - в скрипте Docker Compose из поставки
  - в Helm-чартах из поставки

  См. раздел "Сервисы видеоаналитики" для более подробной информации.

- Добавлена возможность шифрования биометрических шаблонов.

  Шифрование можно включить и настроить с помощью группы параметров `DESCRIPTOR_ENCRYPTION`.

  Поддерживается использование алгоритма `aes256-gcm`. Источник ключа шифрования может быть указан напрямую или получен из хранилища Hashicorp Vault.

  Биометрические шаблоны хранятся в зашифрованном виде в базах данных Events, Faces или Attributes и в том же виде передаются во внешние системы. Если включено шифрование, то на запросы, которые возвращают биометрический шаблон, будет получен именно зашифрованный биометрический шаблон.

  При необходимости можно добавить шифрование для уже существующих биометрических шаблонов, заменить существующее шифрование или выполнить дешифрование биометрических шаблонов в БД Faces, БД Attributes или БД Events. Для этого необходимо выполнить миграцию биометрических шаблонов с помощью скрипта `descriptors_encryption.py`, расположенного в контейнерах сервисов Faces и Events, передав в качестве аргументов скрипта данные о БД Faces/Attributes/Events, и передав в качестве переменных окружения соответствующий ключ и алгоритм.

  Важно! LUNA PLATFORM не предназначена для одновременного использования зашифрованных и незашифрованных биометрических шаблонов. В случае обнаружения обоих видов биометрических шаблонов, сервис Python Matcher не запустится, выдав ошибку "Check is failed, encryption hash is not unique". Поэтому, при включении шифрования, необходимо остановить сервисы, ограничив тем самым все запросы, перевести все биометрические шаблоны на новую версию шифрования и только потом заново запускать сервисы. Крайне рекомендуется выполнения бекапа БД перед манипуляциями с шифрованием.

  Примечание. Шифрование добавляет дополнительные вычислительные затраты, что приводит к замедлению процессов, таких как сравнение по базе, сравнение с использованием LUNA Index Module и синхронизация кеша в Cached Matcher. LUNA Index Module поддерживает работу с зашифрованными биометрическими шаблонами.

  Примечание. Плагины для сравнения также необходимо обновить в соответствии с логикой шифрования.

  См. подробную информацию о шифровании биометрических шаблонов в разделе "Шифрование биометрических шаблонов" руководства администратора.

  См. подробную информацию о добавлении шифрования к уже существующим биометрическим шаблонам в разделе "Управление шифрованием биометрических шаблонов" руководства по обновлению.

- Добавлена возможность задать пользовательское смещение для временных меток видео (PTS) в запросе "videosdk".

  Указание смещения позволяет синхронизировать начало обработки видео с конкретным моментом времени. Это может быть полезно, например, если видео обрабатывается частями и необходимо, чтобы временные метки новых частей продолжали последовательность с предыдущих. Таким образом, при нарезке большого видео на маленькие фрагменты, временные метки будут отображаться так, как если бы обрабатывалось одно целое видео.

  Смещение задается в теле "pts" > "start_time", указываемого в теле запроса.

- В запрос "videosdk" добавлена возможность выбрать действие при возникновении ошибки декодирования видео (параметр "error_handling" > "action").

  Доступно два действия:

  - `stop` — прекратить обработку видео и сгенерировать ответ на основе части видео, обработанной до возникновения ошибки
  - `fail` — прекратить обработку видео и завершить запрос ошибкой

  Также в теле ответа на запрос добавлены группы параметров `error_count`, `processed_parts`, отображающие количество ошибок во время обработки и массив обработанных фрагментов.

- Изменен формат ответа запроса "videosdk"

  - для аналитики "people_count" добавлено поле "track_id", содержащее идентификатор трека
  - для аналитики "people_count" переименовано поле "max_people_count" в "people_count"
  - поля "start_frame_offset" и "last_frame_offset" удалены из данных о видео сегменте (секция "video_segment"). Теперь в секции "video_segment" содержатся только поля "start_time_offset" и "end_time_offset".
  - поле "frame_offset" удалено из результата оценки кадра аналитики (секция "frames_estimations"). Поле "time_offset" по-прежнему доступно.
  - поле "overview" перемещено из секции "aggregated_estimations" в секцию с информацией о событии ("result" > "" > "events")

- Для встроенного плагина "luna-streams" добавлена возможность выполнения запросов как к API первой версии, так и к API второй версии сервиса LUNA Streams без изменения конфигурации.

  Для этого нужно использовать заголовок `LUNA-STREAMS-API-VERSION` следующим образом:

  - если заголовок `LUNA-STREAMS-API-VERSION` не указан, будет автоматически выбрана первая версия API
  - если значение заголовка `LUNA-STREAMS-API-VERSION` равно "1", будет выбрана первая версия
  - если значение заголовка `LUNA-STREAMS-API-VERSION` равно "2", будет выбрана вторая версия API
  - в противном случае вернется ошибка

- Для встроенного плагина "luna-streams" добавлена возможность проксировать запросы к ресурсам `/groups` и `/linker` сервиса LUNA Streams.

- В сервис Sender добавлен новый ресурс `/general/events`, который предназначен для принятия абстрактных событий через POST запросы.

  Обязательные поля:

  - `event_type` — тип события
  - `events` — сами события

  Также в сервис API добавлен ресурс `/general/ws` для подписки на абстрактные события через веб-сокеты. При подписке обязательно указывать тип события и опционально можно указать `account_id`. Поддерживается фильтрация событий по типу, аккаунту и пользовательским фильтрам.

- В запросы на получение биометрических шаблонов лица добавлена возможность получения биометрических шаблонов в формате `sdk`.

  Биометрические шаблоны в таком формате можно передавать в различные запросы (например, запросы на выполнения сравнения).

  Для этого в параметры запроса добавлен параметр "descriptor_format", позволяющий выбирать формат возвращаемых биометрических шаблонов - `sdk` или `raw`.

  При этом теперь форматы `raw` и `xpk` считаются устаревшими.

  См. следующие запросы:

  - "create face"
  - "create temporary attribute"
  - "get face attribute"
  - "put face attribute"

- Улучшено описание возвращаемой ошибки `43001`, возникающей при ошибке загрузки видео. Теперь сообщение содержит статус код и описание неудачного запроса.

- Теперь для параметра "min_face_size" используется режим, при котором строго соблюдается указанное значение.

  Данный режим был добавлен в SDK 5.22.0. В этом режиме лица, размер которых меньше указанного в параметре "min_face_size", не детектируются. Ранее система старалась искать лица, размер которых не меньше указанного. Однако иногда могла найти и меньшего размера.

- В группу настроек "LUNA_REMOTE_SDK_VIDEO_SETTINGS" добавлены таймауты сохранения видео ("connect", "request", "sock_connect", "sock_request").

- В примере развертывания сервисов LUNA PLATFORM в Kubernetes из комплекта поставки теперь используется утилита Storages.

  Основное преимущество Storages перед классической подготовкой окружения в том, что утилите известны ревизии настроек сервиса Configurator и сценарии миграции баз данных сервисов LP, что значительно упрощает процесс обновления и даунгрейда LUNA PLATFORM. Кроме того, с помощью утилиты можно оценить текущее состояние окружения LUNA PLATFORM и определить что именно будет нужно обновить.

  Новый подход подразумевает подготовку окружения с помощью отдельных манифестов Storages и последующий запуск Helm-чартов.

  Важно! С текущего релиза использование утилиты Storages является приоритетным способом подготовки окружения. Документация по ручной подготовке окружения с помощью скриптов "db_create.py" считается устаревшей и будет удалена из комплекта поставки в ближайших релизах.

  См. обновленный документ по разворачиванию LUNA PLATFORM в Kubernetes для более подробной информации о процессе разворачивания.

  См. руководство по утилите Storages для более подробной информации об использовании утилиты.

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

- В запросы "get face attribute", "put face attribute", "get temporary attributes", "get temporary attribute" добавлена отсутствующая схема ответа для типа содержимого запроса `application/msgpack`.

- Исправлена ошибка при которой в некоторых случаях не закрывались соединения к БД Redis.

- Исправлено отсутствие сохранения биометрического образца в случае, когда в запрос "generate stream events (beta)" передавались и детекция с биометрическим образцом лица и детекция с биометрическим образцом тела.

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

  Ранее сервис возвращал ошибку `SQL error` с кодом `10015` и статусом `500`.

- Для некоторых видео исправлена генерация неверного значения метки времени видеокадра в ответе запроса "videosdk".

- Обновлено дефолтное значение параметра "redetect_score_threshold" группы настроек "LUNA_REMOTE_SDK_FACE_DETECTOR_SETTINGS" с "0.3" до "0.5".

  В релизе LUNA PLATFORM v.5.67.0 обновился порог "redetect_score_threshold" до "0.5", но при установке LUNA PLATFORM версий 5.67.0 и 5.72.1 с нуля, значение порога все равно равнялось "0.3".

  См.примечания к выпуску для версии v.5.67.0 для более подробной информации.

Изменения пользовательского интерфейса сервиса API

- Раздел "Проверки": Добавлен новый раздел для проверки изображений на Liveness, DeepFake, соответствие требованиям стандарта ISO/IEC 19794-5:2011, стандарта ICAO, Приказу Минцифры №453.

- Раздел "Сценарии": Обновлена политика хранения изображений. Теперь по умолчанию используется значение, заданное для всей директории хранения изображений, а в параметрах сохранения можно настроить своё время хранения в днях.

- Раздел "Детали события": Теперь можно сохранять лица из события в список: появилась кнопка, при нажатии на которую открывается всплывающее окно для добавления лица.

- Раздел "Списки": Добавлена кнопка для перехода к деталям лица со страницы деталей списка.

- Разделы "Списки", "Архив событий": Теперь можно создавать задачи в разделах, с которыми они связаны. В разделе "Списки" можно создать задачи "Пакетный импорт", "Экспорт лиц", в "Архиве событий" — "Экспорт событий".

- Раздел "Сценарии": Стало проще ориентироваться при редактировании сценария благодаря новой организации параметров на странице.

Исправленные ошибки пользовательского интерфейса сервиса API

- Раздел "Детали лица": Исправлена ошибка, при которой открывалась страница с архивом событий после удаления лица.

- Раздел "Лицензии": Благодаря обновленному адресу, на который ведёт кнопка в разделе, стало удобнее купить или продлить лицензию.

- Раздел "Детали события": Посмотреть биометрический образец в полном размере теперь можно без обновления страницы.

# v.5.72.1

Изменения LP

- SDK обновлен до версии 5.22.1.

  В данной версии LUNA PLATFORM:

  - поддержана 116ая модель нейронной сети для извлечения биометрических шаблонов тел;
  - удалена из контейнера Remote SDK 107ая модель нейронной сети для извлечения биометрических шаблонов тел. Поддержка данной модели не прекращается.

  Важно! Если на момент обновления используется 107ая модель нейронной сети (настройка "DEFAULT_HUMAN_DESCRIPTOR_VERSION"), то без дополнительных действий сервис Remote SDK не запустится.

  Необходимо выполнить одно из дополнительных действий ниже:

  - Запросить отсутствующую модель у VisionLabs и самостоятельно добавить в контейнер Remote SDK.
  - Выполнить задачу Additional extraction перед началом обновления, а затем указать новую версию в настройке "DEFAULT_HUMAN_DESCRIPTOR_VERSION" перед запуском сервиса Remote SDK, тем самым сохранив возможность использования старых биометрических шаблонов.
  - Указать новую версию в настройке "DEFAULT_HUMAN_DESCRIPTOR_VERSION" перед запуском сервиса Remote SDK, тем самым прекратив использование старых биометрических шаблонов.

- В политику "storage_policy" добавлен новый тип callback'a `luna-ws-notification`, позволяющий получать сгенерированные события при подписке на сервис Sender через механизм веб-сокетов.

  Новый тип callback'a пришел на замену политике "notification_policy", которая теперь считается Deprecated. Одновременного использования callback'a и "notification_policy" не предполагается (будет отправлено два уведомления).

  Основным преимуществом механизма callback'ов перед устаревшей "notification_policy" является возможность указания нескольких callback'ов с разными фильтрами в запросе на создание обработчика, в результате чего будет отправлено только одно событие.

- Для скриптов создания бакетов ("lis_bucket_create.py", "s3_bucket_create" и "monitoring_db_create.py") и подготовке БД ("db_create.py") добавлен аргумент `-v`, устанавливающий уровень логирования равным "DEBUG".

  Это позволяет выводить дополнительную информации, которая может помочь в случае возникновения ошибок.

- Ускорено сравнение по списку лиц при включенном кешировании (настройка "cache_enabled" в сервисе Python Matcher).

- В сервис Lambda добавлена новая группа настроек "LUNA_LAMBDA_BUILD_LIMITS", позволяющая настроить ограничения на использование оперативной памяти и CPU-процессора, выделяемых для задач сборки Docker-образа.

- Добавлено новое разрешение токена `verify`, позволяющее указать права на выполнение запроса "perform verification", выполняющего верификацию биометрических шаблонов и изображений.

  Кроме того, аналогично разрешению `emit_events`, можно поместить идентификаторы верификаторов в черный или белый списки. Если идентификаторы "verifier_id" присутствуют в черном списке, то только их использование будет запрещено. Если же идентификаторы присутствуют в белом списке, то только их использование будет разрешено. Максимальное количество идентификаторов в списках — 100.

  Если выдано разрешение "verify", то во время выполнения верификации будут созданы все необходимые объекты независимо от разрешений, задаваемых в токене. Например, разрешение типа "sample" не влияет на создание биометрического образца во время выполнения верификации. Таким образом, при использовании верификатора с параметром "store_sample" и отсутствии права "creation" для "samples", все равно будет создан биометрический образец.

- Теперь скрипт `migrate_ttl_settings.py` выполняет миграцию настроек TTL для объектов в S3 быстрее.

  См. раздел "Добавление TTL для S3 бакетов" в руководстве по обновлению.

- Версия SDK для Handlers-lambda обновлена с версии 5.19.0 до версии 5.21.0.

- Добавлена возможность задания TTL в S3 для архивов с Lambda.

  TTL задается в параметре "archive_ttl" в запросе на создание/обновление lambda.

  См. подробную информацию о настройке TTL в S3 в разделе "Миграция для добавления TTL к объектам в S3" в руководстве администратора.

- В Handlers-lambda добавлена поддержка полей "origin_bounding_box", позволяющих указать координаты bbox с лицом или телом в системе координат исходного изображения.

- Ускорено сравнение по нескольким спискам в одном запросе.

- Изменена точка мониторинга для сравнения в сервисе Python Matcher.

  Ранее точки мониторинга содержали поле `list_id`, необходимое для сравнение лиц по списку. Теперь такие точки содержат поле `list_batch_size`, означающее количество кэшированных списков.

  См. подробную информацию в разделе "Monitoring" руководства разработчика сервиса Python Matcher.

- Документация по миграции с LUNA PLATFORM 3 на Backport 3 и с LUNA PLATFORM 4 на Backport 4 удалена из комплекта поставки и онлайн-документации.

  Данные комплекты документации теперь можно получить по запросу к VisionLabs.

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

- Исправлена ошибка, при которой разрешения токена не учитывались в запросе "detect faces" из-за чего, например, можно было создать биометрический образец даже если в токене нет разрешения "creation".

- Из спецификации OpenAPI сервиса API удален неиспользуемый метод `OPTIONS` для запросе "ws handshake".

- Исправлена ошибка запуска сервисов с указанием переменных окружения для переопределения настроек (префикс `VL_SETTINGS`).

- Исправлена ошибка, из-за которой запросы "ws handshake" с авторизацией по токену могли выполняться без учета прав на просмотр события.

- Исправлена ошибка передачи переменных окружения для скрипта подготовки БД `db_create.py`.

- Исправлена ошибка, при которой GET запросы без каких-либо данных авторизации (например,запрос "get handlers") не учитывали параметр запроса "account_id" в качестве фильтра.

- Исправлена ​​ошибка, из-за которой невозможно было создать токен без установки "visibility_area" для учетной записи типа "user".

  Из-за этой ошибки пользователь типа "user" не имел доступа к пользовательскому интерфейсу сервиса API.

  Теперь для токенов, созданных в рамках аккаунта "user", дефолтное значение "visibility_area" равно "account".

- Улучшена валидация запросов для ресурсов "/liveness" и "/tasks/schedules".

  Ранее могла возникнуть ошибка типа "Internal server error" с кодом состояния 500 из-за недопустимого тела запроса. Теперь возвращаются корректные сообщения.

- Исправлена ошибка, из-за которой скрипт `luna-prepare` с аргументом `--dump-file` утилиты Storages завершался ошибкой `No module named 'configurator_db_tools'`.

# v.5.67.0

Изменения LP

- Добавлена возможность декодирования видео на GPU в запросе на выполнение видеоаналитики.

  Декодирование на GPU включается с помощью указания значения "gpu" в настройке "decoder_device_class" секции "LUNA_REMOTE_SDK_VIDEO_SETTINGS".

- SDK обновлен до версии 5.21.0.

  В данной версии LUNA PLATFORM:

  - обновлен HumanDetector до версии v6
  - обновлен DeepFakeDetector до версии v3

  Важно! Также обновился дефолтный порог для редетекции детектора FaceDetV3 с "0.3" до "0.5". При обновлении LUNA PLATFORM порог для редетекции в настройке "redetect_score_threshold" группы параметров "LUNA_REMOTE_SDK_FACE_DETECTOR_SETTINGS" не будет обновлен автоматически. Необходимо вручную обновить порог до "0.5" для использования стандартной логики редетекции. Если ранее было установлено пользовательское значение, то необходимо самостоятельно обновить значение порога.

  При установке LUNA PLATFORM с нуля значение порога "redetect_score_threshold" по умолчанию также будет равно "0.3". Необходимо использовать дамп-файл "platform_settings.json" из комплекта поставки, либо обновить значение порога после установки. В следующем релизе при установке с нуля будет автоматически устанавливаться значение "0.5".

- Добавлен механизм указания доверенных детекций, позволяющий явно указать для каких детекций не нужно выполнять редетекцию.

  Предполагается, что доверенные детекции были получены с помощью алгоритмов VisionLabs. Если отметить стороннюю детекцию как доверенную, то это может повлиять на результаты оценок.

  Указать является ли детекция доверенной можно с помощью схемы "application/json" (параметр "trusted_detections") или схемы "multipart/form-data" (заголовок "X-Luna-Trusted-Detections") в следующих запросах, где детекции явно указываются вместо изображений:

  - "detect faces"
  - "sdk"
  - "iso"
  - "generate events"
  - "perform verification"
  - "generate stream events (beta)"

- В запрос "generate stream events (beta)" с указанием исходного изображения (`sources` > `source_type` > `raw_image`) добавлен опциональный параметр `origin_bounding_box`, позволяющий указать координаты bbox с лицом или телом в системе координат исходного изображения, сохраняемого в поле `image_origin` генерируемого события.

  Это позволяет учесть различные сценарии использования, такие как обработка обрезанных (crop-изображений) или иных модифицированных изображений. Таким образом, старый параметр `bounding_box` отвечает за координаты на изображении, на котором выполняются оценки, в то время как новый параметр `origin_bounding_box` отвечает за координаты на исходном изображении.

  Это также позволяет более гибко управлять обработкой изображений, включая возможность обрезки или изменения размера исходного изображения перед нанесением bbox.

  Также параметр `sources` > `source` > `face/body` > `bounding_box`, доступный при указании детекций в запросе (`sources` > `source_type` > `detections`), переименован в `origin_bounding_box`.

- Добавлена поддержка задания области интереса DROI относительно исходного кадра.

  Если ROI предназначен для оптимизации эстимации соответствующих свойств, то DROI работает как фильтр после выполненной эстимации и предназначен для реализации бизнес-логики. Можно использовать DROI как вместе с ROI, так и отдельно. Например, если после обработки по области ROI количество людей на кадре было равно N, то после выполнения дополнительной фильтрации по области DROI количество людей на кадре может быть уменьшено до M.

  Область интереса DROI на исходном кадре задается следующими параметрами:

  - "area" — геометрия области интереса. Параметр представлен в виде массива полигонов. Каждый полигон представлен массивом объектов, где каждый объект содержит координаты вершины полигона (x и y). Так, например, можно задать треугольную область интереса.
  - "mode" – режим указания "x", "y". Доступно два режима:
    - "abs" — параметры "x", "y" задаются в пикселях;
    - "percent" — параметры "x", "y" задаются в процентах от текущего размера
  - "form" — формат области интереса. В текущей реализации имеет только одно возможное значение "common". В будущих реализациях помимо полигонов будут поддержаны другие форматы.

- Во все задачи добавлена возможность задания времени жизни (TTL) результатов задач.

  TTL задается в параметре `result_storage_policy` > `ttl` в запросах на создание задачи или расписания.

  Добавить TTL результатов задач к уже созданным и выполненным задачам невозможно.

  Добавить TTL результатов задач к уже созданному расписанию можно с помощью запроса "replace tasks schedule". Для созданных или запущенных на момент запроса задач TTL результатов задач применен не будет.

- Добавлена автоматическая отправка заголовка `Set-Cookie: LUNA_AUTH_TOKEN=""; Path=/; Max-Age=0` клиентскому приложению при получении им ошибки 401 от сервиса API из-за протухшего токена авторизации, размещенного в Cookie.

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

- Исправлена миграция настроек Configurator с ревизией `c51cdfac`.

  Данная миграция завершалась с ошибкой, если в настройке `S3` сервиса Image Store не было поля `bucket`.

  Поле `bucket` было удалено из группы настроек "S3" сервиса Image Store в версии 5.45.4.

- Удалена ненужная авторизация для запросов "get version", "get health", "set login cookie" и "clear login cookie".

# v.5.64.0

Изменения LP

- Добавлена возможность задать время жизни (TTL) для объектов в бакетах (как локальных, так и S3).

  TTL для объектов рассчитывается относительно формата времени GMT.

  TTL для объектов задается в днях следующими способами:

  - во время создания бакета для всех объектов сразу (основная политика TTL бакета)
  - после создания бакета для конкретных объектов с помощью запросов к соответствующим ресурсам

  Количество дней выбирается из списка в соответствующих запросах (см. ниже).

  Кроме количества дней параметр может принимать значение "-1", означающее, что нужно хранить объекты вечно.

  Настройка основной политики TTL бакета

  Основную политику TTL бакета можно настроить следующими способами:

  - с помощью аргумента `--bucket-ttl` для скрипта `lis_bucket_create.py`. Например, "python3 ./base_scripts/lis_bucket_create.py -ii --bucket-ttl=2".
  - с помощью запроса к сервису Image Store. Например, "curl -X POST http://127.0.0.1:5020/1/buckets?bucket=visionlabs-samples?ttl=2".

  Настройка TTL для конкретных объектов

  TTL для конкретных объектов можно настроить с помощью параметра "ttl" в следующих местах:

  - в политиках "storage_policy" > "face_sample_policy", "body_sample_policy" и "image_origin_policy" обработчика
  - в запросах "create object", "create images" и "save sample"

  Если параметр "ttl" не задан, то будет применена основная политика бакета, в котором находится объект (cм. выше).

  Поддерживаемые облачные провайдеры

  Поддерживаются облачные провайдеры Amazon S3, облачное хранилище Яндекса и MinIO.

  Добавление TTL к существующим объектам

  Добавить TTL для существующего конкретного объекта можно с помощью PUT-запросов к ресурсам `/objects`, `/images`, `/samples/{sample_type}` сервиса Image Store.

  Добавить TTL к основной политике бакета (ко всем существующим объектам в бакете) можно с помощью PUT-запроса к ресурсу `/buckets` сервиса Image Store.

  Для бакета, расположенного в S3, необходимо выполнить миграцию с помощью скрипта "base_scripts/migrate_ttl_settings" сервиса Image Store. Это связано с тем, что для TTL объектов в S3 применяется через фильтры, связанные с тегами. Команда выполнения миграции бакетов в S3 приведена в руководстве по установке. См. подробную информацию о миграции бакетов S3 в разделе "Миграция для добавления TTL к объектам в S3" в руководстве администратора.

  Окончание TTL

  Когда TTL объекта подходит к концу, то он помечается для удаления. Для локальных бакетов выполняется задача очистки 1 раз в день (в 01:00 утра). Для бакетов S3 используются внутренние правила настройки TLL.

  Обратите внимание, что между датой истечения срока действия и датой фактического удаления объекта может возникнуть задержка. Как для локального хранилища, так и для S3.

  Поиск истекающих объектов

  Чтобы узнать, когда срок действия объекта истекает, можно использовать запросы с методами HEAD к ресурсам `/objects` и `/images`. Эти запросы возвращают заголовки ответов `X-Luna-Expiry-Date`, в которых указана дата, когда объект больше не подлежит сохранению.

  См. подробную информацию в разделе "TTL для объектов" в руководстве администратора.

- Теперь сервис Handlers будет отправлять только одно уведомление, если у пользователя есть два callback-а с одинаковыми настройками.

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

  Например, если настроено два callback-а в одну стороннюю систему с различием только в том, что у одного callback'a установлены фильтры по прохождению Liveness, а у другого по достижению определенного уровня "similarity", то при генерации события, удовлетворяющего обоим фильтрам, во внешнюю систему придет только одно уведомление.

  Это позволяет легче реализовывать логику отправки уведомлений при соблюдении определенных фильтров.

- Добавлена возможность отправки уведомлений о состоянии задач и подзадач в Telegram.

  Отправка уведомлений в Telegram реализована за счет добавления нового типа callback'ов `telegram` в политику "notification_policy" каждой задачи.

  Для отправки уведомлений необходимо указать параметры `chat_id` и `token`.

  Отправку уведомлений в Telegram также можно настроить при создании расписания для задач.

- Во контейнерах всех сервисов обновлена версия Python до 3.12.

  Поддержка более старых версий Python прекращена.

- В параметры запроса "video analytics (beta)" добавлен параметр "video" > "orientation" > "angle", отвечающий за возможность поворота видео на угол 90, 180 или 270 градусов перед его обработкой.

- Добавлена возможность использовать более безопасный алгоритм для генерации JWT токенов.

  По умолчанию сервис Accounts использует алгоритм HS256 для подписи JWT-токенов. При необходимости можно использовать асимметричное криптографическое шифрование с помощью алгоритм ES256.

  Для этого необходимо: - сгенерировать закрытый ключ ECDSA - закодировать закрытый ключ в формат Base64 - установить переменные окружения "ACCOUNTS_JWT_ECDSA_KEY" и "ACCOUNTS_JWT_ECDSA_KEY_PASSWORD"

  Важно! Переключение алгоритма подписи с HS256 на ES256 (или наоборот) оказывает значительное влияние на проверку токенов. Все существующие токены, подписанные предыдущим алгоритмом, станут недействительными после внесения изменений. Это происходит потому, что механизм проверки подписи токена ожидает, что структура и криптографическая база токена будут соответствовать новоуказанному алгоритму.

  См. раздел "Алгоритмы JWT-токенов" в руководстве администратора.

- Добавлена возможность шифрования паролей и токенов, передаваемых в задаче Estimator и в политике "notification_policy"

  Для этого необходимо при старте контейнера сервиса Tasks передать пользовательские значения переменным окружения `FERNET_PASSPHRASE` и `SALT`.

  - `FERNET_PASSPHRASE` — пароль или ключ, используемый для шифрования данных с помощью алгоритма Fernet.
  - `SALT` — случайная строка, добавляемая к паролю перед его хешированием.

  Важно! Когда контейнер запускается с указанием вышеописанных переменных окружений, то старые пароли и токены перестают работать. Необходимо в команде миграции БД Tasks указать переменные окружения, после чего необходимо запустить новый контейнер Tasks с указанием переменных окружения для возможности использования шифрования при создании новых объектов.

  См. подробную информацию в разделе "Дополнительная защита паролей и токенов" в руководстве администратора.

- Добавлена группа параметров "FACE_QUALITY_DEFAULT_THRESHOLDS" сервиса Remote SDK, содержащая стандартные пороги для группы проверок "face_quality", политики "detect_policy", ресурсов "/handlers" и "/verifiers".

  В данной группе параметров есть два типа стандартных порогов:

  - пороги из поля "threshold", определяющие при каком значении LUNA PLATFORM будет считать, что проверка пройдена. Данные пороги аналогичны порогам в группе проверок "face_quality" в соответствующих запросах. Задание порогов в запросах переопределяет стандартные пороги, задаваемые в группе параметров "FACE_QUALITY_DEFAULT_THRESHOLDS".
  - пороги из поля "config", определяющие как интерпретировать ответ эстиматоров Natural Light, Fish Eye, Color Type и Red Eyes. Ранее данные пороги были недоступны.

  Пример настройки порогов для эстиматора Red Eyes:

      "red_eye": {
          "threshold": 0,
          "config": {
              "estimator": {
                  "threshold": {
                      "min": 0.5
      }    }    }    }

  Здесь:

  - поле "threshold" определяет значение "0" или "1", при котором LUNA PLATFORM будет считать, что проверка пройдена. Аналогично параметру "threshold" в запросах на выполнение "face_quality"
  - секция "config" > "estimator" > "threshold" определяет ответ эстиматора Red Eyes от "0" до "1".

- Добавлена проверка доступности пользовательского Docker registry и базовых образов Lambda во время запуска сервиса.

- Теперь не требуются никакие дополнительные права для выполнения запросов к ресурсу `/lambdas/{lambda_id}/proxy` сервиса Lambda.

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

- Исправлена некорректная работа Cached Matcher с 64 версией нейронной сети для извлечения биометрических шаблонов лиц.

  Cached Matcher не кэшировал биометрические шаблоны 64 версии и выполнял сравнение используя данные из БД.

- Исправлен некорректный формат поля "url" для лиц и атрибутов, генерируемый запросом "generate events".

  Например, адрес расположения лица мог возвращаться как `'url': 'http://127.0.0.1:5030/faces/359c8c12-b67d-4645-96dc-d8f1627f360f'`.

  Правильный адрес: `'url': 'http://127.0.0.1:5030/3/faces/426542d6-5509-4e5b-8a01-e2abd5c0a8c6'`

- Запрос "stream events (beta)" теперь генерирует значение поля `image_origin` на основе детекции, если в теле запроса не указан параметр `image_origin`, но указан биометрический образец лица или тела.

# v.5.62.3

Изменения LP

- SDK обновлен до версии 5.19.1.

  В данной версии LUNA PLATFORM:

  - поддержана 64ая модель нейронной сети для извлечения биометрических шаблонов лиц;
  - дефолтная модель была изменена с 59ой на 62ую (настройка "DEFAULT_FACE_DESCRIPTOR_VERSION" сервиса Remote SDK).

  При выполнении миграции настроек сервиса Configurator последней версии, настройка "DEFAULT_FACE_DESCRIPTOR_VERSION" не будет автоматически обновлена. При необходимости использования 62ой версии нейронной сети необходимо вручную изменить значение настройки "DEFAULT_FACE_DESCRIPTOR_VERSION", предварительно выполнив повторное извлечение существующих биометрических шаблонов с помощью 62 модели, используя задачу "Additional extraction.

- В комплект поставки добавлены Helm чарты для разворачивания LUNA PLATFORM в кластере Kubernetes.

  Администратор должен иметь развернутый и настроенный кластер Kubernetes для использования Helm чартов. Предполагается, что в пользовательском кластере Kubernetes:

  - запущены СУБД PostgreSQL/Oracle и базы данных InfluxDB и Redis
  - имеется доступ к объектному хранилищу S3-подобного типа для хранения бакетов

  См. пример команд для разворачивания LUNA PLATFORM в кластере Kubernetes с использованием Helm чартов в новом руководстве (документ "LP_Kubernetes_Helm_Deployment_Example" в комплекте поставки) или на сайте с онлайн-документацией.

- Для LUNA PLATFORM добавлен пользовательский интерфейс, реализованный в качестве веб-интерфейса для сервиса API.

  Пользовательский интерфейс доступен по адресу `<host:5000/ui>`.

  См. описание пользовательского интерфейса в новом руководстве (документ "LP_User_Interface_Manual" в комплекте поставки) или на сайте с онлайн-документацией.

- В запрос "videosdk" добавлена возможность трекинга людей на видео и оценки их атрибутов как контексте всего видео, так и на отдельных кадрах.

  Для видеоаналитики трекинга людей ключевым понятием является трек. Трек — объект, содержащий информацию о положении одного человека на последовательности кадров. Трек создается тогда, когда на последнем кадре из указанного количества подряд идущих кадров (параметр "probe_count") появляется детекция лица, тела или тела с лицом (зависит от типа детектора в параметре "detector_type"). Треков может быть столько, сколько людей было обнаружено на кадре. Вместе с треком начинается событие видеоаналитики.

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

  Например, если "probe_count" = "3" и на двух подряд идущих кадрах есть детекции, а на третьем нет, то трек и событие не начнутся. Если в какой-то момент трекинга человека на двух подряд идущих кадрах были детекции, а на третьем кадре детекция отсутствует, то трек и событие закончатся.

  Во время трекинга человека доступна возможность выполнить оценку атрибутов лиц, тел, изображения (перечень оценок задается в параметре "targets"), а также получить изображение, в котором была лучшая детекция. Оценка может быть выполнена по одному лучшему снимку из трека или по нескольким (параметр "face_samples"/"body_samples" > "count"). При необходимости можно фильтровать лучшие снимки по параметрам "score", "head_pitch", "head_roll", "head_yaw". Все оценки, задаваемые в поле "targets" зависят от типа используемого детектора.

  При необходимости можно включить повторную идентификацию тела (ReID). Функция ReId используется для повышения точности трекинга путем объединения различных треков одного человека.

  Для такой видеоаналитики также доступна возможность настроить прямоугольную область интереса ROI (параметр "roi") на кадре (координаты "x", "y", ширина, высота, единицы измерения — проценты или координаты). Принцип работы области интереса ROI аналогичен FaceStream.

  В каждом событии видеоаналитики подсчета количества людей содержится следующая информация:

  - "event_id" — идентификатор события
  - "track_id" — идентификатор трека
  - "video_segment" — информация о сегменте видео (время начала события, время конца события, номер первого кадра, номер последнего кадра)
  - "frames_estimations" — массив с информацией об оценках на каждом кадре, содержащий следующую информацию:
    - номер кадра
    - время, соответствующее кадру
    - координаты bbox и степень достоверности ("score")
  - "aggregated_estimations" — результат оценки, задаваемой в параметре "targets" в теле запроса
  - "track_count" — количество треков

  См. подробную информацию в спецификации OpenAPI.

- В видеоаналитику подсчета количества людей добавлена возможность получения координат людей и изображений с максимальным количеством людей.

  Для этого в тело запроса был добавлен новый параметр "targets", принимающий следующие значения:

  - "coordinates" — вычисление координат людей
  - "overview" — получение изображения с максимальным количеством людей

  Можно задать как оба значения, так и ни одного. Если значения не заданы, то будет выполнен базовый анализ, содержащий только информацию о видеозаписи, количестве людей и кадрах, связанных с ними.

  Координаты людей возвращаются в теле ответа в поле "events" > "aggregated_estimations" > "overview" > "people_coordinates".

- Переработана структура запроса "generate stream events (beta)".

  Поля "sources" > "source" > "face_bounding_boxes" и "body_bounding_boxes" (доступны при "source_type" = "raw_image") переименованы в "face_detection_data" и "body_detection_data" соответственно и переработаны следующим образом:

  - Параметры "height", "width", "x", "y" перемещены в поля "face_detection_data"/"body_detection_data" > "bounding_box".
  - Поля "face_detection_data"/"body_detection_data" теперь содержат новые опциональные поля "score", "angles" (содержит параметры "pitch", "yaw" и "roll") и обязательное поле "bounding_box" (см. выше).
  - В поля "face_detection_data"/"body_detection_data" добавлена возможность указания пользовательских ключей со значениями.

  Поле "sources" > "source" > "face" (доступно при "source_type" = "detections") теперь содержит новые опциональные поля "score" и "angles". Также в поле "face" добавлена возможность указания пользовательских ключей со значениями.

  Также в поле "sources" > "source" добавлена возможность указания пользовательских ключей со значениями.

- Расширено описание поля "cron" в запросах "create tasks schedule", "replace tasks schedule", "get tasks schedules" и "get tasks schedule".

- Статистика запросов в формате Prometheus дополнена временем выполнения запроса.

  Данные представлены в формате гистограммы, которая позволяет анализировать распределение времени выполнения запросов и выявлять потенциальные проблемы производительности. Каждый интервал времени (бакет) в гистограмме отображает количество запросов, время выполнения которых попадает в соответствующий диапазон.

  См. подробную информацию в разделе "Экспорт метрик в формате Prometheus".

- Добавлена возможность установки меток для запуска lambda с использованием конкретных узлов Kubernetes с помощью параметра "deploy_parameters" > "selector".

  Это позволяет более детально контролировать развертывание lambda, позволяя администраторам указывать узлы, на которых должны быть размещены lambda в зависимости от их потребностей в ресурсах. Применяя метки к узлам Kubernetes и используя параметр "selector", администраторы могут управлять выделением ресурсов не только для отдельных lambda, но и для групп lambda с аналогичными требованиями к ресурсам.

  См. запросы "create lambda", "put lambda", "get lambda", "get lambdas".

- Уведомление, отправляемое во внешнюю систему с помощью механизма callback'ов, расширено параметром "result_url", содержащим внешний адрес к сервису API с результатом задачи или подзадачи.

- Версия SDK для Handlers-lambda обновлена с версии 5.17.0 до версии 5.19.0.

- Добавлена возможность указания количества подов для lambda.

  Количество подов задается в параметре "pod_count" секции "deploy_parameters" запроса "create lambda". Можно задать от 1 до 32 подов.

  Для каждого пода lambda также можно установить ограничения на процессор и память с помощью новых параметров "cpu_limit", "ram_limit", "cpu_request", "ram_request" в секции "deploy_parameters" > "resources".

  Кроме того, в запросах "get lambda status" и "get lambda status" обновился выходной формат. Теперь логи возвращаются как словарь, что позволяет отобразить информацию о нескольких подах lambda.

  Задать количество подов и ресурсы для существующей lambda можно с помощью запроса "put lambda".

- В сервис Lambda добавлена поддержка использования пространств имен (namespace) Kubernetes, обеспечивающих изоляцию групп ресурсов внутри единого кластера.

  Namespace задается в параметре "namespace" секции "deploy_parameters" запроса "create lambda". См. рекомендации к названиям namespace в описании параметра соответствующего запроса.

  Задать namespace для существующей lambda можно с помощью запроса "put lambda".

- Неиспользуемый параметр "landmarks17_threshold" удален из группы параметров "LUNA_REMOTE_SDK_BODY_DETECTOR_SETTINGS".

- Новый ресурс `/metrics` добавлен в создаваемые lambda, позволяющий собирать и сохранять метрики в формате Prometheus в виде данных временных рядов, которые можно использовать для трекинга поведения lambda.

  См. подробную информацию в разделе "Экспорт метрик в формате Prometheus".

- Переработана структура документации в комплекте поставки.

  Системные требования LUNA PLATFORM вынесены в отдельный документ в комплекте поставки.

  Руководства по установке перенесены в директорию "InstallationManuals".

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

- Исправлена ошибка, из-за которой некоторые параметры не отображались, когда фильтр "show_all" был включен в поле "Service name" на странице "Settings" пользовательского интерфейса сервиса Configurator.

Кроме того, фильтр "show_all" теперь установлен как значение по умолчанию.

- Исправлена ошибка, при которой в некоторых случаях обработка расписания задач не перезапускалась должным образом после временной недоступности среды (например, базы данных).

- Исправлена ошибка в сервисе Backport 3, из-за которой не происходила очистка списка закрытых веб-сокет соединений в случае, когда веб-сокеты были недоступны или не инициализированы.

# v.5.59.0

Изменения LP

- Примечание. В следующем релизе будет обновлено дефолтное значение нейронной сети для извлечения биометрических шаблонов лиц с 59 версии на 62 версию. Версия 59 будет удалена из контейнера Remote SDK.

- Разработана утилита Storages, позволяющая проверить и/или подготовить окружение для сервисов LUNA PLATFORM v.5.46.1 и выше перед их непосредственным запуском.

  В качестве подготовки окружения понимается следующее:

  - Подготовка бакетов в InfluxDB для работы мониторинга
  - Подготовка бакетов для сервиса Image Store, позволяющих хранить пользовательские данные (изображение, метаданные, архивы и пр.)
  - Подготовка БД Influx для сбора агрегированной статистики сервисом Admin (см. раздел "Подсчет статистики выполненных запросов и оценок" в руководстве администратора)
  - Подготовка баз данных, добавление функций VLMatch, создание сценариев миграции для баз данных LUNA PLATFORM (PostgreSQL или Oracle) и управление ими
  - Выполнение миграции/загрузка настроек в БД Configurator
  - Загрузка дамп-файлов в БД сервиса Configurator

  Основное преимущество Storages перед ручной подготовкой окружения в том, что утилите известны ревизии настроек сервиса Configurator и сценарии миграции баз данных сервисов LP, что значительно упрощает процесс обновления и даунгрейда LUNA PLATFORM. Кроме того, с помощью утилиты можно оценить текущее состояние окружения LUNA PLATFORM и определить что именно будет нужно обновить.

  Утилита поставляется в Docker-контейнере и может быть использована в качестве инструмента подготовки окружения LUNA PLATFORM, разворачиваемой в Docker-контейнерах, скриптом Docker Compose, системой оркестрации Kubernetes и др. Основная задача администратора - указать утилите Storages адреса баз данных, бакетов и пр.

  В комплект поставки и на сайт с онлайн-документацией добавлен новый документ "Руководство по утилите Storages", описывающий принципы использования утилиты и примеры использования. Также добавлено два новых руководства по развертыванию LUNA PLATFORM - "Руководство по установке с помощью утилиты Storages" и "Руководство по обновлению с помощью утилиты Storages". Документы аналогичны обычным руководствам по установке и обновлению, за исключением того, что вся подготовка окружения выполняется с помощью утилиты Storages.

  Важно! Утилита Storages находится в состоянии бета-тестирования. См. подробную информацию об утилите в руководстве по утилите Storages.

- SDK обновлен до версии 5.18.0.

- В политику "notification_policy" каждой задачи добавлена возможность включить отправку уведомлений о состоянии подзадач (группа параметров "subtask_callbacks").

  Состояние подзадачи содержит следующую информацию:

  - идентификатор подзадачи
  - статус подзадачи ("in_progress", "failed", "cancelled", "done")
  - количество выполненных подзадач

  В ответах на запросы "get task notification policy" и "replace task notification policy" также содержится вышеописанная информация.

  Уведомления о состоянии подзадач также доступны при использовании политики "notification_policy" в расписании.

- Во все сервисы LUNA PLATFORM добавлен новый ресурс `/metrics`, позволяющий собирать и сохранять метрики в формате Prometheus в виде данных временных рядов, которые можно использовать для трекинга поведения сервиса.

  По умолчанию сбор метрик отключен. Сбор метрик включается в параметре "enabled" в группе "LUNA_SERVICE_METRICS". Если сбор метрик отключен, то запрос к ресурсу `/metrics` вернет ошибку с кодом "12049" и сообщением "Forbidden, Resource is disabled".

  Доступно два типа метрик:

  - `request_count_total` — общее количество запросов
  - `errors_count_total` — общее количество ошибок

  Каждый из них имеет как минимум два лейбла для сортировки:

  - `status_code` (или `error_code` для метрик ошибок)
  - `path` — путь, состоящий из метода запроса и маршрута конечной точки

  При необходимости можно добавить пользовательские типы меток, указав пару `label_name=label_value` в параметре "extra_labels" в группе "LUNA_SERVICE_METRICS".

  См. подробную информацию в разделе "Экспорт метрик в формате Prometheus".

- Добавлена возможность получения X и Y координат людей при выполнении оценки количества людей.

  Возможность получения координат добавлена в запросы "sdk" и политику "detect_policy" запроса "create handler". Для этого необходимо включить параметры "people_count_coordinates" и "people_coordinates" соответственно.

  Структура генерируемого события также обновлена.

- В спецификацию OpenAPI добавлены примеры для запроса "generate stream events (beta)".

- Добавлена возможность запускать lambda GPU.

  Для использования GPU необходимо включить параметр "deploy_parameters" > "enable_gpu" в запросе создания lambda.

  Есть некоторые требования и ограничения при использовании GPU в Kubernetes. См. подробную информацию в разделе "Создание lambda с поддержкой GPU" руководства администратора.

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

- Исправлено отсутствие поддержки метода `OPTIONS` для ресурса `/plugins`.

- Исправлено появление ошибки "Internal server error", возникавшей при выполнении задачи Garbage collection с включенным фильтром `events` и параметром `remove_image_origins`, когда в событии отсутствовало исходное изображение (значение `None`).

- Исправлена ошибка `value too long for type character varying(512)`, возникавшая при выполнении даунгрейда настроек Configurator с ревизии `d718e5954caf`.

  Изменения, внесенные в ревизии `d718e5954caf`, привели к увеличению длины строки значения настроек токенов с 512 символов до бесконечности. При выполнении даунгрейда с ревизий, где в соответствующей настройке значение длины уже было больше 512 символов, возвращалась ошибка `value too long for type character varying(512)`.

  Теперь при выполнении даунгрейда с ревизии `d718e5954caf`, значение настройки, превышающее 512 символов, будет удалено. Необходимо заново задать значение токена для соответствующей настройки.

- Исправлена ошибка `Key (name)=(<setting>) is not present in table "limitation"`, возникавшая при выполнении даунгрейда настроек Configurator с ревизии `dd2641137b42`.

  Изменения, внесенные в ревизии `dd2641137b42`, привели к обязательной привязке каждой настройки к определенному шаблону. Для этого была добавлена новая таблица `limitation`, содержащая ограничения. Ошибка возникала при выполнении даунгрейда из ревизий, где в базе данных Configurator уже присутствовали данные об ограничениях в таблице `setting` и невозможно было установить связь между удаляемой таблицей `limitation` и существующей таблицей `setting`.

  Теперь при выполнении даунгрейда с ревизии `d718e5954caf`, все записи из таблицы `setting` будут удалены при удалении таблицы `limitation`.

# v.5.58.0

Изменения LP

- Примечание. Через один релиз будет обновлено дефолтное значение нейронной сети для извлечения биометрических шаблонов лиц с 59 версии на 62 версию. Также будет прекращена поддержка 52 версии нейронной сети.

- Добавлена поддержка использования токена (Bearer-авторизации) через Cookies для упрощенного процесса аутентификации в веб-браузерах.

  Для сохранения Cookies нужно выполнить запрос "set login cookie", указав токен в качестве авторизации. Затем Cookies отправляется обратно в браузер пользователя. Последующие запросы, отправленные браузером пользователя, автоматически включают эти Cookies, позволяя серверу распознавать авторизацию пользователя, без необходимости явно отправлять токен в каждом запросе.

  При необходимости можно очистить Cookies с помощью запроса "clear login cookie".

- Во все сервисы добавлена новая переменная окружения "LUNA_SKIP_CHECK_CONNECTION".

  Переменная позволяет отключить проверку соединения (значение "1") до всех основных сервисов (Image Store, Faces и т.д.), выполняющуюся по умолчанию при старте сервиса.

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

  Переменную окружения можно передать с помощью аргумента `--env` при старте контейнера.

- Добавлена поддержка запуска сервисов с использованием протокола HTTPS.

  Для использования этой возможности необходимо передать следующие аргументы командной строки соответствующего сервиса:

  - `tls_cert` — путь к SSL-сертификату
  - `tls_key` — путь к SSL-закрытому ключу
  - `tls_key_pass` — пароль для SSL-закрытого ключа (необязательно)

  Пример команды: `python3 /srv/luna_<service>/run.py --tls_cert /srv/my_certificate.crt --tls_key /srv/my_private_key.key --tls_key_pass my_password`

  Обратите внимание, что сертификат и ключ должны быть примонтированы к Docker-контейнеру в указанные директории.

  Список всех доступных аргументов можно получить с помощью следующей команды: `python3 /srv/luna_<service>/run.py -h`

- Во все сервисы LUNA PLATFORM добавлена возможность указания переменной окружения `--EXTEND_CMD`, позволяющей передать аргументы, для которых не предусмотрена переменная окружения, в команду запуска сервиса.

  Например, можно явно задать тегированные настройки при запуске сервисов: `--env=EXTEND_CMD="--LUNA_MONITORING=TAG_1 --LUNA_EVENTS_DB=TAG_2"`

  См. подробную информацию о переменных окружения и аргументах в разделе "Аргументы сервисов" в руководствах по установке.

- В тела запросов "create lambda" и "put lambda" добавлен новый параметр "workers", позволяющий выделить количество "рабочих процессов" на указанный экземпляр Lambda.

- Версия SDK для Handlers-lambda обновлена с версии 5.16.0 до версии 5.17.0.

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

- В описаниях запросов "create handler", "validate handler policies" и "generate events" исправлено отсутствие информации о допустимой длине символов в параметрах политики "callbacks".

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

- Исправлено появление ошибки "Internal server error", возникавшей при попытке обращения к ресурсам `/1/buckets/{bucket}/objects/{object_id}` и `/1/buckets/{bucket}/objects` сервиса Image Store не поддерживаемыми методами.

  Теперь возвращаются корректные ошибки.

- Исправлена ошибка, из-за которой при создании задачи Estimator с несуществующим обработчиком, в базе данных Handlers все равно создавалась соответствующая запись.

# v.5.57.0

Изменения LP

- Во все задачи добавлена политика "notification_policy", которая позволяет отправлять уведомления об изменении статуса задач с помощью механизма callback'ов.

  Callback'и позволяют отправлять данные в стороннюю систему по указанному URL.

  Параметры из новой политики аналогичны параметрам, задаваемым в соответствующей политике обработчика ("authorization", "content_type", "timeout" и пр.).

  Также можно настроить отправку уведомлений для задач в настройках расписания.

  При необходимости можно получить информацию о текущем состоянии расписания или обновить его с помощью ресурсов get task notification policy и replace task notification policy .

- В запросе "create token" добавлена возможность указать разрешение "account" > "view" для возможности получить данные аккаунта, к которому выдан сам токен.

- Для Tasks-lambda добавлен клиент "luna-handlers", позволяющий отправлять пользовательские события в сервис Handlers.

  См. подробную информацию про клиенты в разделе "Luna services clients" руководства разработчика.

- В сервис Lambda добавлена возможность создания пользовательских точек мониторинга для экземпляров Lambda-tasks.

  См. подробную информацию про мониторинг в разделе "Lambda monitoring" руководства разработчика.

- Добавлена офлайн версия сайта с онлайн-документацией в комплект поставки LUNA PLATFORM вместо предыдущих документов в формате HTML.

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

- Теперь при выполнении запросов "generate events" и "generate stream events (beta)" с биометрическими образцами, в сервис Remote SDK не будут отправляться ограничивающие прямоугольники, т.к. они не используются.

- Из группы параметров `LUNA_REMOTE_SDK_LIMITS` удалены неиспользуемые параметры `raw_event_detections_limit`, `raw_event_arrays_limit` и `result_candidate_limit` . Остался только параметр `received_images_limit`.

- Исправлена ошибка, при которой сервис Python Matcher Proxy использовал 100% CPU при включенном плагине "indexed_matcher" (при использовании LIM).

- Исправлена ошибка, из-за которой при незаполненных query-параметрах геопозиции в запросах "generate events", "save event", "generate stream events (beta)", в базу данных Events все равно записывались значения "null".

  Теперь если ни один параметр геопозиции не задан, то в таблице "location" не будет создано никакой записи.

# v.5.56.0

Изменения

- Добавлена возможность выполнения видеоаналитики с помощью нового ресурса "videosdk".

  Важно! На данный момент ресурс находится в статусе бета-тестирования. Входные и выходные схемы могут быть изменены в будущих релизах без поддержки обратной совместимости.

  Видеоаналитика — это набор функций, которые обрабатывают кадр за кадром и оценивают полезные данные.

  Для выполнения видеоаналитики необходимо указать внешнюю ссылку на видеофайл, не превышающий размер 1 Гб.

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

  Важно! Событие в видеоаналитике никак не связано с событиями, генерируемыми по обработчикам.

  В группе настроек "LUNA_REMOTE_SDK_VIDEO_SETTINGS" сервиса Remote SDK можно задать настройки обработки видео, такие как количество рабочих процессов декодера, временная директория для хранение видео пр.

  Примечание. В текущей версии видео декодируется только на CPU. В будущих релизах будет добавлено декодирование на GPU.

  В настоящий момент поддерживается только видеоаналитика подсчета количества людей.

  Видеоаналитика подсчета количества людей

  Событие видеоаналитики подсчета количества людей начинается тогда, когда на последнем кадре из указанного количества подряд идущих кадров (параметр "probe_count") появляется указанное число людей (параметр "people_count_threshold"). Например, если минимальное количество людей равно 10, а количество подряд идущих кадров равно 3, то в случае наличия на 3 кадрах 10 человек начнется событие с 3го кадра. Если на 2 кадрах 10 человек, а на 3 кадре 9 человек, то событие не начнется.

  По умолчанию обрабатываются каждые 10 кадров. При необходимости можно настроить частоту обработки кадров с помощью параметра "rate" (например, обрабатывать каждые 3 секунды или каждые 3 кадра).

  Для такой видеоаналитики также доступна возможность настроить прямоугольную область интереса ROI (параметр "roi") на кадре (координаты "x", "y", ширина, высота, единицы измерения — проценты или координаты). Принцип работы области интереса ROI аналогичен FaceStream.

  В каждом событии видеоаналитики подсчета количества людей содержится следующая информация:

  - "event_id" — идентификатор события
  - "max_people_count" — максимальное количество людей, обнаруженное на обработанном сегменте видео
  - "video_segment" — информация о сегменте видео (время начала события, время конца события, номер первого кадра, номер последнего кадра)
  - "frames_estimations" — массив с информацией об оценках на каждом кадре, содержащий следующую информацию:
    - номер кадра
    - время, соответствующее кадру
    - количество людей

  См. подробную информацию о новом ресурсе в спецификации OpenAPI.

- SDK обновлен до версии 5.17.0.

  В данной версии SDK обновлен эстиматор LivenessOneShotRGB.

- В сервис API добавлен встроенный плагин, позволяющий выполнять часть запросов к сервису LUNA Streams через сервис API.

  Перед использованием плагин необходимо включить и настроить (опционально).

  Плагин "luna-streams.py" расположен в контейнере сервиса API по пути `/srv/luna_api/plugins` и включается с помощью настройки "LUNA_API_ACTIVE_PLUGINS".

  Плагин можно настроить в настройке "LUNA_API_PLUGINS_SETTINGS". В настройке можно задать адрес и версию API запущенного сервиса LUNA Streams, а также таймауты соединения.

  Пример содержимого настройки "LUNA_API_PLUGINS_SETTINGS" для плагина "luna-streams.py":

      {
          "luna-streams": {
              "luna-streams-address": {
                  "origin": "http://127.0.0.1:5160/1",
                  "api_version": 1
              },
              "luna-streams-timeouts": {
                  "request": 60,
                  "connect": 20,
                  "sock_connect": 10,
                  "sock_read": 60
              }
          }
      }

  Для разграничений прав доступа для запросов к LUNA Streams добавлена возможность указывать пользовательский ключ для токена. Для этого нужно создать новый или обновить существующий токен, передав пользовательский ключ "streams" с разрешениями для токена.

  > Для проксирования запросов из сервиса LUNA API к сервису LUNA Streams нужно указывать разрешение с именем "streams". Другие пользовательские названия ключей не подходят. Использование пользовательского ключа в иных случаях не приведет ни к какому результату.

  Можно задать следующие разрешения:

  - "creation" (POST-запросы)
  - "view" (GET-запросы)
  - "modification" (PUT-запросы и PATCH-запросы)
  - "deletion" (DELETE-запросы)

  См. раздел "Plugins" руководства разработчика для получения перечня возможных запросов.

  Информация также будет добавлена в руководство администратора FaceStream в ближайший релиз.

- Во все сервисы LUNA PLATFORM добавлен новый запрос "get list of plugins", позволяющий получить список импортированных плагинов и их статус.

- В сервис Lambda добавлен новый тип Tasks-lambda, предназначенный для реализации дополнительных пользовательских длинных типов задач.

  Примеры возможного функционала длинных задач:

  - открепить лица от списка, если лица не похожи на указанное лицо
  - удалить дубликаты лиц из списка
  - рекурсивно найти события, похожие на указанное изображение

  Lambda-tasks создается аналогично остальным типам с запроса "create lambda".

  После создания lambda необходимо выполнить запрос "lambda task" для создания задачи Lambda. Результаты задачи/подзадачи можно получить с помощью стандартных запросов сервиса Tasks.

  Задача Lambda создается согласно общему процессу создания задач, за исключением того, что вместо "рабочего процесса" Tasks используется сервис Lambda.

  См. дополнительную базовую информацию в разделе "Tasks-lambda" руководства администратора.

  См. подробную информацию и примеры кода в руководстве разработчика сервиса Tasks.

  Также для задач Lambda доступна возможность создания расписания.

- Улучшено описание ошибок для некоторых случаев валидации тела запроса "generate events" при использовании схемы "multipart/form-data".

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

- Исправлена генерация некорректного времени истечения токена при его создании/обновлении в случаях, когда установлено локальное время сервера ("STORAGE_TIME" = "LOCAL").

- Исправлена ошибка, из-за которой при создании задачи Linker с большим количеством лиц происходило избыточное открытие соединений с базой данных, что приводило к зависанию задачи.

- Исправлена ошибка, из-за которой невозможно было выполнить запрос "create new events" к сервису Events с ненулевыми полями "location".

  Попытка выполнить подобный запрос заканчивалась ошибкой с кодом "12047" и описанием "Failed to validate input msgpack. Path: '[0].location.', message: '[0].location. must be string''".

- Исправлена ошибка `'a coroutine was expected, got None`, возникавшая при использовании плагина отправки событий с большим количеством аргументов.

  См. подробную информацию и пример плагина отправки событий в разделе "Plugins" руководства разработчика сервиса Handlers.

- Исправлена ошибка отсчета текущего времени ("now-time") для фильтров "create_time__lt" и "create_time__gte", указываемых в политике "match_policy" > "candidates" при создании обработчика.

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

- Исправлена проверка лицензии на функцию ISO.

  Ранее, если лицензируемая функция ISO была отключена, то запросы на выполнение любых оценок завершались ошибкой с кодом "11055" и описанием "License problem: ISO feature is disabled".

- Исправлена обработка детекций в запросе generate stream events (beta).

  Теперь если биометрические образцы передаются с типом "sources" > "source_type" > "detections", то будет выполнена детекция и экстракция этих биометрических образцов.

- Исправлена ошибка отсутствия поля "unknown" в описании запроса liveness в спецификации OpenAPI cервиса Backport3.

# v.5.54.0

Изменения

- В запросы "create token" и "replace token" добавлен query-параметр "grant_all_permissions", позволяющий создать токен со всеми разрешениями или добавить все разрешения уже к существующему токену.

- Добавлен новый запрос "get accounts".

  В запросе можно указать query-параметр "targets" для фильтрации аккаунтов по полям "account_id", "login", "account_type", "description", "create_time", "last_update_time".

  Фильтрация по вышеописанным полям также добавлена в запрос "get account".

- В сервисах Admin и Tasks при выполнении задачи Additional extraction теперь поле "options" не является обязательным, если параметр "extraction_target" установлен в "basic_attributes".

- В сервис Events добавлен новый запрос "get list of plugins", позволяющий получить список импортированных плагинов и их статус.

  В следующем релизе данный запрос будет добавлен во все остальные сервисы.

- В руководство администратора добавлен раздел "Use tagged settings", описывающий запуск сервисов с настройками, отличными от стандартных.

  Также в руководство по установке добавлен раздел "Service arguments", описывающий основные аргументы сервисов и способы их передачи.

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

- Исправлено отображение пути (строка "Path") при валидации некоторых тел запросов с некорректной структурой JSON.

- Исправлена ошибка, при которой запросы к ресурсу "/features" завершались ошибкой "Internal server error", когда лицензия не содержала какую-либо лицензируемую функцию.

- Исправлена некорректная обработка биометрического образца или бинарного изображения, передаваемых в качестве исходного изображения, в запросе generate stream events (beta).

- Исправлена ошибка, связанная с отсутствием проверки наличия функции VLMatch сервисом Python Matcher при подключении к базам данных Faces и Events.

# v.5.53.0

Изменения LP

- Обновлен образ VisionLabs для PostgreSQL с 12 версии на 16 версию.

  Если ранее использовался данный образ, то для перехода на новую версию необходимо самостоятельно выполнить миграцию согласно официальной документации. При необходимости можно продолжить использовать PostgreSQL 12, указав образ "postgis-vlmatch:12" в команде запуска контейнера.

  Монтирование данных PostgreSQL 12 из директории "/var/lib/luna/postgres" в контейнер для PostgreSQL 16 приведет к ошибке.

  В документацию по обновлению добавлен раздел "Миграция с PostgreSQL 12 на PostgreSQL 16", содержащий напоминание о необходимости миграции.

- | Добавлена возможность обнаруживать подмену лиц с помощью технологии DeepFake на фотоизображениях.

  Параметр "estimate_deepfake" добавлен в запросы "create handler", "create verifier" и "sdk".

  В структуру события добавлено поле "deepfake". Данное поле может быть использовано в качестве значения для поля "target" или в качестве фильтра для получения события с помощью GET-запросов.

  В результате оценки Deepfake могут вернуться следующие результаты:

  - "prediction" = "fake" — человек не является реальным;
  - "prediction" = "real" — человек является реальным;
  - "score" = [0...1] — степень достоверности выполнения оценки.

  В запросах "create handler" и "create verifier" доступна возможность задать порог "real_threshold" и режим работы "mode". В запросе "sdk" будут использованы значения данных параметров по умолчанию без возможности явного указания.

  С помощью порога "real_threshold" можно задать значение в диапазоне [0...1], ниже которого система будет считать, что человек не является реальным.

  Доступно два режима работы:

  - "mode" = "1" — упрощенный режим работы;
  - "mode" = "2" (по умолчанию) — режим работы с использованием дополнительной модели нейронной сети для предварительной оценки. Если результат предварительной проверки определил, что лицо является поддельным, то в теле ответа будет возвращен результат "score" = "0" и "prediction" = "fake".

  Для выполнения оценки также необходимо выполнить следующие требования к изображению:

  - положение головы: "pitch" = [-20...20]
  - положение головы: "yaw" = [-30...30]
  - ширина лица: "face_width" > 150

  Фильтр "deepfake" также можно использовать в запросах на сравнение.

  В обработчик и верификатор также добавлен параметр "deepfake_states", позволяющий отфильтровать события по предполагаемому результату оценки Deepfake.

  Поле "deepfake" также добавлено в фильтры для задач Clustering, Exporter, Cross-matching и Linker. Для задач Exporter и Reporter поле поддержано в качестве колонки.

  Поле "deepfake" также поддержано в качестве фильтра в запросе "ws handshake".

- В сервис API добавлен новый запрос "get list of plugins", позволяющий получить список импортированных плагинов и их статус.

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

  Фактически, callback'и представляют собой аналог отправки уведомлений через веб-сокеты, но с ключевым отличием в том, что они используют принципы HTTP-вебхуков, что предоставляет более гибкий и настраиваемый механизм для отправки уведомлений в сторонние системы. Можно настроить тип протокола, адрес внешней системы, параметры запроса и данные авторизации.

  События, отправленные с помощью поля "callbacks" имеют формат, соответствующий формату запроса "generate events".

  См. подробную информацию в запросах "create handler" и "create verifier".

- Обновлена структура входящих данных Handlers-lambda.

  Это означает, что все существующие lambda должны быть переработаны и пересозданы в соответствии с новой структурой.

  Все примеры также были обновлены.

  Пример старой структуры входящих данных: `{"body": getImage("empty.jpeg"), "filename": "empty.jpeg", "source_type": 0}`

  Пример новой структуры входящих данных: `{"source": {"body": getImage("empty.jpeg")}, "filename": "empty.jpeg", "source_type": "raw_image"}`

- Теперь образ Kaniko executor (образ для построения lambda) должен находиться в registry, указанном в настройке "LAMBDA_REGISTRY".

  В руководство по установке добавлена инструкция по переносу образа Kaniko executor из registry VisionLabs в пользовательский registry.

- Добавлены новые настройки соединения с Redis и Redis Sentinel.

  В группы настроек "REDIS_DB_ADDRESS", "TASKS_REDIS_DB_ADDRESS", "LUNA_ATTRIBUTES_DB", "BACKPORT3_EVENTS_DB_ADDRESS" добавлен параметр "user".

  В секцию "sentinel" вышеперечисленных настроек добавлены параметры "user" и "password".

- Обновлен Guardant с версии 3.15 до 3.21.

# v.5.51.6

Изменения

- Добавлена поддержка формата логирования ECS.

  Для использования нового формата необходимо задать значение "ecs" в настройке "format" секции "LUNA_service_LOGGER".

  При использовании значения "ecs" в логах будут возвращаться следующие поля:

  - "http.response.status_code" — содержит код состояния ответа HTTP (200, 404, 500 и т.д.);
  - "http.response.execution_time" — содержит информацию о времени, затраченном на выполнение запроса и получение ответа;
  - "http.request.method" — содержит метод HTTP-запроса (GET, POST, PUT и т.д.);
  - "url.path" — содержит путь в URL-адресе запроса;
  - "error.code" — содержит код ошибки, если запрос завершается с ошибкой.

- Добавлена возможность создавать расписание для задачи Reporter.

- В запросы "create lambda" и "update lambda" добавлен новый параметр "base_image", позволяющий явно указать имя базового образа для построения Docker-контейнера.

  Ранее можно было использовать только два заранее перенесенных на пользовательский regisry образа — "lpa-lambda-base" (базовая функциональность) и "lpa-lambda-base-fsdk" (базовая функциональность и функциональность для использования FSDK).

  Пользовательский образ lambda предназначен для сложных lambda, которым не хватает возможностей, реализованных в базовых образах "lpa-lambda-base" и "lpa-lambda-base-fsdk" (например, многоэтапное создание Docker-контейнера или включение больших библиотек или данных в Docker-контейнер).

  Для пользовательского образа lambda должны соблюдаться следующие условия:

  - образ должен быть основан на образах "lpa-lambda-base" или lpa-lambda-base-fsdk"
  - образ не должен удалять или изменять какие-либо установленные зависимости (`python3`, `gcc` и т. д.)
  - образ должен находиться в том же registry, что и другие базовые лямбда-образы.

- В сервис Lambda добавлена возможность создания пользовательских точек мониторинга для экземпляров lambda.

  Например, можно отправить данные о том, сколько времени потребовалось для загрузки или обработки изображений.

  См. подробную информацию в разделе "Monitoring" руководства разработчика сервиса Lambda.

- Обновлена логика обработки ограничивающих прямоугольников в запросе generate stream events (beta).

  Теперь исходное изображение тела (параметр "body") не требуется для сохранения ограничивающих прямоугольников лица/тела (поле "events" > "detections" > "samples" > "face"/"body" > "detection" > "rect").

- В руководство по активации лицензии LUNA PLATFORM добавлен раздел "Смена вендора" с инструкциями по переходу с вендора HASP на Guardant и наоборот.

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

- Удален неиспользуемый параметр "FETCH_EXTERNAL_IMAGE_TIMEOUTS" из настроек сервиса API.

- Исправлено появление ошибки "Internal server error" при выполнении запроса "get system info", когда в базе данных Influx отсутствовали требуемые измерения.

# v.5.51.4

Изменения

- Добавлена возможность создавать расписание для задач Estimator, Clustering, Exporter, Cross-matching, Roc-curve calculating и Additional extraction.

  При создании расписания задачи Estimator невозможно указать ZIP-архив в качестве источника изображений.

- В мониторинг сервиса Python Matcher добавлена новая серия "Matching-Process", содержащая информацию по выполнению сравнения — время сравнения, время получения кандидата из БД и пр.

  См. список всех полей и тегов новой серии в разделе "Monitoring" руководства разработчика сервиса Python Matcher.

- Добавлен мониторинг запросов и ошибок для сервиса Lambda.

  См. подробную информацию в в разделе "Monitoring" руководства разработчика сервиса Lambda.

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

- Исправлена ошибка, при которой запросы к ресурсу "/features" завершались ошибкой "Internal server error" при использовании бессрочной лицензии.

- Исправлена ошибка, которая в некоторых случаях приводила к разрыву соединения через веб-сокет.

- Исправлена ошибка в спецификации OpenAPI, при которой в телах запросов "matching faces", "human body matching" отображались лишние типы кандидатов.

- Исправлена ошибка, приводившая к ошибке "Internal server error", если в теле запроса "generate stream events" (запрос в состоянии бета-тестировании) передавался некорректный msgpack.

- Исправлена ошибка, при которой в ответе на запрос "human body matching", содержащий различные типы кандидатов и эталонов в фильтрах, возвращалась ошибка с кодом "12022" с описанием "message: 'filters.origin must be one of ['faces', 'events', 'attributes']".

  Теперь ошибка содержит не список всех типов, а конкретный тип, который должен быть указан в фильтре.

# v.5.51.0

Изменения

- SDK обновлен до версии 5.16.0.

  В LUNA PLATFORM добавлена поддержка новой 62-ой модели нейронной сети для извлечения биометрических шаблонов лиц.

- Добавлен новый сервис Lambda, предназначенный для работы с пользовательскими модулями, имитирующими функционал отдельного сервиса. В настоящий момент функционал находится в бета-тестировании.

  Полноценная работа с сервисом Lambda возможна только при разворачивании сервисов LUNA PLATFORM в Kubernetes. Для использования необходимо самостоятельно развернуть сервисы LUNA PLATFORM в Kubernetes или обратиться за консультацией к специалистам VisionLabs. При необходимости можно использовать Minikube для локальной разработки и тестирования, обеспечивая таким образом Kubernetes-подобную среду без необходимости управления полноценным продакшн Kubernetes-кластером.

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

  Сервис создает образ Docker на основе ZIP-архива с кодом разработчика, а затем запускает его в кластере Kubernetes. Пользовательский модуль, запущенный в кластере Kubernetes, называется lambda.

  Для работы с сервисом Lambda нужна отдельная лицензируемая функция. В запросы "get platform features", "get system info" и "get license" добавлены поля "lambdas", отображающие статус лицензируемой функции.

  В токен добавлено новое разрешение "lambda", регулирующее права "creation", "view", "modification", "deletion" для lambda.

  Для запуска и работы с сервисом требуется:

  - наличие запущенных сервисов Licenses и Configurator*;
  - наличие бакета S3 для хранения архивов с кодом разработчика;
  - наличие Docker registry для хранения Docker-образов;
  - наличие кластера Kubernetes.

  * во время своей работы, lambda будет дополнительно взаимодействовать с некоторыми сервисами LUNA PLATFORM. Перечень сервисов зависит от типа lambda.

  Кроме вышеперечисленных требований к окружению, необходимо соблюдать требования к написанию кода и архива, а также правильно настроить сервис. См. дополнительную информацию в документации.

  Lambda создается с помощью запроса "create lambda", где указывается архив, имя и её тип (см. ниже).

  Lambda может быть двух типов:

  Handlers-lambda

  Такой тип предназначен для замены функционала классического обработчика. Lambda-обработчик может использоваться в двух случаях:

  - как пользовательский обработчик, который имеет свою собственную схему ответа, которая может отличаться от ответа классических обработчиков и не может быть должным образом использована в других сервисах LUNA PLATFORM (например, `{"similarity": 0.123}`);
  - как пользовательский обработчик, который имитирует ответ классического обработчика (например, `{ "images": [ { ... } ], "events": [ { ... } ] ... }`). Такой обработчик должен соответствовать схеме ответа запроса на генерацию события и правильно обрабатывать данные, чтобы другие сервисы могли его использовать.

  В связи с добавлением Handlers-lambda была переработана схема тела ответа запроса "create handler". В тело запроса добавлен новый параметр "handler_type", принимающий три значения — "0" (статический обработчик), "1" (динамический обработчик), "2" (обработчик lambda). Для использования значения "2" требуется также указать идентификатор "lambda_id" (см. логику работы ниже). Параметр "is_dynamic" считается устаревшим (Deprecated) и будет проигнорирован при использовании параметра "handler_type".

  Доступно два способа взаимодействия с Handlers-lambda:

  1. С помощью запросов "generate events" или "estimator task". Для использования данных запросов необходимо предварительно создать обработчик, указав "handler_type" = "2" и "lambda_id", полученный на этапе создания lambda. В ответе на генерацию события будет выдан пользовательский результат, формат которого либо совпадает с форматом классического события и позволяет использовать его сервисами LP в дальнейшем, либо не совпадает.

  2. С помощью запроса "proxy post request to lambda", когда не предполагается имитировать ответ классического обработчика, поскольку сервисы LP предполагают строгий формат ответа на запрос генерации события.

  Например, с помощью Handlers-lambda можно реализовать логику отправки, извлечения и сравнения двух биометрических шаблонов в одном запросе. В ответе может быть выдана только схожесть кандидатов без лишней информации. В классическом сценарии использования LUNA PLATFORM пользователь не может выполнить данный сценарий и вынужден писать логику на стороне внешней системы. См. примеры кода в руководстве разработчика.

  Standalone-lambda

  Такой тип предназначен для реализации самостоятельного функционала для выполнения тесной интеграции с LUNA PLATFORM. Для работы с таким типом используется запрос "proxy post request to lambda" с собственной схемой запроса и ответа. Данный тип предназначен для узкой целевой аудитории и достаточно сложен в реализации.

  С помощью Standalone-lambda можно написать сервис, реализующий запись видеопотока в файл и сохраняющий его в сервис Image Store для последующей обработки приложением FaceStream.

  Также в сервис LUNA Dashboards добавлено создание дашборда для сервиса Lambda.

  См. диаграммы последовательности создания и обработки lambda в разделе "Lambda diagrams".

  См. дополнительную информацию для базового ознакомления с функционалом сервиса Lambda в разделе "Lambda service" руководства администратора.

  См. дополнительную информацию для более глубокого погружения в документации разработчика сервиса Lambda. В руководстве приведен набор шагов для быстрого начала работы с сервисом.

- Ответ на запрос "get system info" к сервису Admin расширен дополнительной информацией по статистике использования эстиматоров и изображений.

  Добавлено поле "estimators_performance_stats", отображающее месяц, имя эстиматора, среднее время выполнения эстимации и средний размер батча для каждого эстиматора. Пример:

      "estimators_performance_stats": [
          {
              "month": "2021-09",
              "name": "body_descriptor",
              "execution_time": 0.029135203011156546,
              "batch_size": 1.0952380952380951
          }
      ]

  Добавлено поле "image_processing_stats", отображающее месяц, среднее время декодирования изображения, количество изображений по их размеру и количество изображений по высоте лица. Пример:

      "image_processing_stats": [
          {
              "month": "2021-09",
              "image_load_time": 0.006479793069339647,
              "image_size": {
                  "w_1000_h_1050": 4,
                  "w_1000_h_800": 212,
              },
              "face_detection_size": {
                  "h_100": 2,
                  "h_180": 197
              }
          }
      ]

  Здесь: * "w_1000_h_800": 212 -- 212 изображений с шириной 1000 пикселей и высотой 800 пикселей * "h_180": 197 -- 197 изображений с высотой лица 180 пикселей

  Для изображений применяется округление до ближайших 50 пикселей. Например, если у изображения ширина 105 пикселей, то она будет округлена до 150 пикселей. Все изображения с одинаковыми округленными значениями будут находиться в одном и том же бакете.

  Примечание. Для использования новой статистики необходимо выполнить команду `python influx2_cli.py create_usage_task --luna-config http://127.0.0.1:5070/1` после запуска сервиса Admin (см. руководство по установке)

- В пользовательский интерфейс сервиса Admin добавлена вкладка Schedules, позволяющая управлять расписанием задач и создавать расписание для задачи Garbage Collection.

  Во вкладке отображаются все созданные расписания задач и вся соответствующая информация (статус, идентификатор, Cron-строка и т.д.). Во вкладке также можно создавать, удалять и редактировать расписания, а также управлять отложенным запуском (ставить на паузу и запускать остановленные расписания).

  См. подробную информацию в разделе "Пользовательский интерфейс сервиса Admin".

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

- Исправлено отсутствие следующих параметров сортировки аккаунтов и токенов:

  - фильтров "create_time" и "create_time__gte" в запросе "get tokens";
  - полей "create_time" и "last_update_time" в телах ответов на запросы "get account", "get tokens", "get token".

- Исправлена ошибка, при которой во время запуска сервиса Admin не выполнялась проверка соединения и healthcheck к сервису Remote SDK.

- Исправлена ошибка, при которой во время миграции базы данных сервиса Handlers на версию v.3.0.0 некорректно обновлялось поле "detect_policy" > "estimate_people_count" в существующих обработчиках.

  В результате после обновления при попытке использования обработчиков с таким полем могла возникать ошибка с кодом "12022" и описанием "Failed to validate input json. Path: 'policies.detect_policy.estimate_people_count', message: 'value is not a valid dict'".

# v.5.49.1

Изменения

- Добавлена возможность задать расписание выполнения задач Garbage collection и Linker.

  С помощью расписания можно гибко управлять временем начала выполнения задач. Например, можно настроить регулярное расписание для очистки событий старше одного месяца каждую пятницу в ночное время.

  Расписание создается с помощью запроса "create tasks schedule" к сервису API, в котором указывается содержимое создаваемой задачи и временной интервал её запуска. Для указания временного интервала используются Cron-выражения.

  При необходимости можно создать отложенное расписание, а затем активировать его с помощью параметра "action" = "start" запроса "patch tasks schedule". Аналогично можно остановить работу задачи по расписанию с помощью "action" = "stop". Для удаления расписания можно воспользоваться запросом "delete tasks schedule".

  Права на работу с расписаниями задаются в токене разрешением "task". Это означает, что если у пользователя есть разрешение на работу с задачами, то он также сможет воспользоваться расписанием.

  В руководство по установке и по запуску с помощью Docker Compose добавлен пример CURL-запроса для запуска ежедневного расписания для задачи Garbage collection для событий старше 30 дней с удалением БО и исходных изображений.

  В базу данных Tasks добавлена новая таблица "schedule", содержащая всю информацию о расписании выполнения задач. Получить информацию из БД о созданном расписании можно с помощью запросов "get tasks schedule" и "get tasks schedules".

  См. подробную информацию в разделе "Запуск задач по расписанию" руководства администратора.

- Теперь если формат запроса равен "application/msgpack" и входные данные не соответствуют формату MessagePack, то будет возвращена ошибка с кодом "12047" и описанием "Failed to validate input msgpack. Path: '{}', message: '{}'".

  Ранее возвращался код ошибки "12022" с описанием "Failed to validate input json. Path: '{}', message: '{}'".

- В запрос "generate events" добавлена поддержка указания пользовательских метаданных для изображения, передаваемого с помощью схемы "multipart/form-data" в поле "image".

  Ранее указание пользовательских метаданных было доступно только для исходных изображений (поля "image_origin"). Также исправлена ошибка, из-за которой в описании запроса "generate events" не отображалось описание про указание пользовательских метаданных для исходных изображений.

  Если метаданные будут предоставлены одновременно в обоих полях, то будет использовано значение из поля "image_origin".

  Метаданные передаются с помощью заголовков вида "X-Luna-Meta-:", которые отправляются в сервис Image Store при сохранении изображения во время генерации события.

- Обновлен сервис LUNA Dashboards до версии 0.0.8.

  В этой версии добавлен отсутствующий дашборд для сервиса Remote SDK.

  Также в комплект поставки добавлен архив с плагином "grafana-piechart-panel", предназначенным для ручной установки дашбордов.

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

- Исправлен ряд следующих ошибок при запросах к сервису Events:

  - Исправлено появление ошибки с кодом состояния 500 при запросе к ресурсу "/events/stats" с параметром "filters" > "value", имеющим тип "bool".
  - Исправлено появление ошибки с кодом состояния 500 при запросе к ресурсу "/events/stats" и использовании недопустимых операторов в фильтре, который был равен "null".
  - Исправлено появление ошибки с кодом состояния 500 при запросе к ресурсу "/events", когда в JSON-запросе содержалось число, превышающее предел "int64".
  - Исправлена ошибка с некорректной фильтрацией статистики событий по "null" с использованием операторов "neq" и "nin".

- Актуализирована схема тела запроса для задачи Estimator для типа источника "zip" в спецификации OpenAPI сервиса API.

- Исправлена ошибка, при которой загрузка значений настроек сервиса API из переменных окружения не работала для:

  - вложенных ключей настройки, например, "VL_SETTINGS.LUNA_SERVICE_NAME_DB.DB_SETTINGS.CONNECTION_POOL_SIZE=10"
  - значений типа массива, например, "VL_SETTINGS.OTHER.LUNA_SERVICE_NAME_ACTIVE_PLUGINS=[logger]"

- Исправлена ошибка в запросе "save event" спецификации OpenAPI сервиса API, при которой параметр "detections" > "samples" > "face" > "detection" > "face_quality" > "checks" > "check_face_properties_request" > "max" отображался как обязательный.

# v.5.47.4

Изменения

- Настройки баз данных `<service_name>_DB` всех сервисов расширены новым опциональным параметром "dsn", в котором задается строка DSN, которая может содержать различные настройки для управления подключением к базе данных, такие как множественные хосты, аутентификационные данные, порт и другие (настройки зависят от типа БД).

  За счет внедрения новой настройки, классические настройки для подключения к БД ("db_host", "db_port", "db_name", "db_user" и "db_password") во всех настройках всех сервисов стали опциональными.

  При необходимости можно комбинировать строку DSN и классические настройки, однако строка DSN является более приоритетной. Можно частично заполнить строку DSN (например, "postgres01,postgres02/luna_handlers"), и тогда недостающие параметры будут заполнены из значений параметров "db_host", "db_port", "db_name", "db_user" и "db_password".

  После выполнения обновления на новую версию LUNA PLATFORM, параметр "dsn" не появится во вкладке "Settings" в Configurator. Для использования DSN, необходимо вручную указать соответствующий параметр. Ниже приведен пример указания параметра "dsn" в группе параметров "LUNA_FACES_DB":

      {
      "dsn": "luna:luna@postgres01:5432,postgres02:5432/luna_faces?some_option=some_value"
      "db_settings": {
          "connection_pool_size": 5
          }
      }

  См. подробную информацию в разделе "Подключение к БД использованием DSN" руководства администратора.

- Теперь в ответе на запросы "get system info" и "get license" в поле "expiration_time" будет отображаться значение "perpetual" для бессрочной лицензии.

- Теперь для плагина сравнения "Thin faces" можно настроить максимальный размер списка для выполнения сравнения. Если список превышает установленное количество, то для сравнения будет использован Python Matcher или LIM Indexed Matcher.

  Максимальный размер списка устанавливается с помощью указания переменной окружения "VL_SETTINGS.THIN_FACE.MAX_LIST_LENGTH" при запуске сервиса Python Matcher.

  Пример указания переменной при запуске сервиса Python Matcher через Docker: `docker run \ -e VL_SETTINGS.THIN_FACE.MAX_LIST_LENGTH=100`.

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

- Исправлено появление ошибки 31006 "Unexpected behavior of the {matcher_type} matcher: {plugin_error_description}" при выполнении сравнения с использованием атрибута-эталона и плагина сравнения.

# v.5.47.1

Изменения

- Обновлен внутренний механизм взаимодействия сервиса Tasks с "рабочими процессами".

  Теперь вместо отправки HTTP-запросов "рабочим процессам", сервис Tasks будет взаимодействовать с ними с помощью Redis.

  В настройки сервиса Tasks добавлена новая группа настроек "TASKS_REDIS_DB_ADDRESS", где:

  - "host" — IP-адрес Redis
  - "port" — порт Redis
  - "password" — пароль для авторизации в Redis
  - "number" — номер базы данных Redis (от 0 до 15). Каждый номер соответствует отдельной базе данных, что позволяет разделить данные.

  При обновлении на текущую версию LUNA PLATFORM, значения вышеописанных настроек будут заполнены в соответствии с группой настроек "LUNA_ATTRIBUTES_DB" сервиса Faces. Это позволит использовать для сервиса Tasks тот экземпляр Redis, который используется для сервиса Faces. При необходимости разделения данных сервисов Faces и Tasks в Redis, можно указать пользовательские настройки в группе настроек "TASKS_REDIS_DB_ADDRESS" после запуска сервиса (например, указать номер базы данных текущего экземпляра Redis или указать адрес другого экземпляра Redis).

  Также "рабочие процессы" сервиса Tasks теперь не имеют доступа в БД Tasks.

  См. обновленную диаграмму последовательности работы сервиса Tasks в разделе "Tasks diagrams".

- В контейнерах сервисов Events и Licenses обновлена версия Python до 3.11.

  Поддержка более старых версий Python прекращена.

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

- Исправлена ошибка в сервисах Python Matcher, Handlers, Sender и Backport 3, из-за которой проверка подключения к Redis Sentinel не проходила с первого раза.

- Исправлена ошибка, из-за которой сервис Sender не восстанавливал соединение с Redis после перезагрузки.

# v.5.46.1

Изменения

- Функционал для работы с нейронными сетями (детекция, эстимация и извлечение) перенесен из сервиса Handlers в новый сервис Remote SDK. Это позволило сделать сервис Handlers опциональным и отключать его в настройке "ADDITIONAL_SERVICE_USAGE", когда нет необходимости работы с обработчиками.

  Теперь при работе с обработчиками, сервис Handlers перенаправляет запросы на детекцию, эстимацию и извлечение к сервису Remote SDK, а затем обрабатывает полученный результат.

  Если сервис Handlers отключен, то:

  - запуск сервиса API приведет к отсутствию возможности использования следующих запросов: "detect faces", "extract attributes", "estimator task", все запросы на ресурс "/handlers", все запросы на ресурс "/verifiers";
  - запуск сервиса Tasks приведет к отсутствию возможности выполнения задач "Additional extraction" и "Estimator";
  - запуск сервиса Admin приведет к отсутствию возможности выполнения задачи "Additional extraction";

  Все нейронные сети и настройки, связанные с детекцией, эстимацией и извлечением, также перенесены в сервис Remote SDK. Теперь для выбора таких настроек необходимо в пользовательском интерфейсе Configurator вводить в поле "Service name" значение "luna-remote-sdk" вместо "luna-handlers".

  Запросы к ресурсам "/iso", "/sdk", "/liveness" теперь выполняются напрямую к сервису Remote SDK без участия Handlers.

  Отключение неиспользуемых нейронных сетей теперь выполняется с помощью передачи соответствующей переменной окружения (например, `--env=EXTEND_CMD="--enable-all-estimators-by-default=0 --enable-face-detector=0`) в команде запуска контейнера Remote SDK, а не контейнера Handlers.

  Теперь вместо запуска Handlers на GPU необходимо запускать Remote SDK на GPU (флаг `--gpus device=0`).

- SDK обновлен до версии 5.15.0. Основные изменения SDK, затрагивающие LUNA PLATFORM:

  - поддержаны 109ая и 110ая модели нейронной сети для извлечения биометрических шаблонов тел;
  - 105ая, 106ая, 107ая модели нейронной сети для извлечения биометрических шаблонов тел считаются устаревшими;
  - встроен эстиматор CrowdEstimatorV2.

  В данной версии LUNA PLATFORM:

  - 105ая модель была удалена из контейнера Remote SDK;
  - дефолтная модель была изменена со 107ой на 110ую (настройка "DEFAULT_HUMAN_DESCRIPTOR_VERSION" сервиса Remote SDK).

  Обновление с версии, где использовалась 107ая модель (модель по умолчанию с версий 5.34.0 и выше)

  Если выполняется обновление с версии, где использовалась 107ая модель, то рекомендуется при обновлении указать 110ую модель нейронной сети в настройке "DEFAULT_HUMAN_DESCRIPTOR_VERSION" и выполнить задачу "Additional extraction" после запуска сервиса Admin (см. раздел "Launch Additional extraction task" в руководстве администратора) для продолжения сравнения по старым биометрическим шаблонам тел.

  Обновление с версии, где использовалась 105ая модель

  Если выполняется обновление с версии, где использовалась 105ая модель, то запуск сервис Remote SDK завершится ошибкой если не выполнить одно из следующих действий перед запуском контейнера Remote SDK:

  - вручную изменить значение настройки "DEFAULT_HUMAN_DESCRIPTOR_VERSION" c "105" на "110". После изменения версии нейронной сети извлечения биометрических шаблонов тел необходимо выполнить задачу "Additional extraction" после запуска сервиса Admin (см. раздел "Launch Additional extraction task" в руководстве администратора). В противном случае, поиск и сравнение по старым биометрическим шаблонам будут недоступны;
  - выключить использование нейронной сети для извлечения биометрического шаблона тела с помощью передачи аргумента `--enable-body-descriptor-estimator=0` при старте контейнера Remote SDK;
  - запросить у VisionLabs 105ую модель нейронной сети и перенести её в контейнер Remote SDK по инструкции, описанной в разделе "Use non-delivery neural network model" руководства администратора.

  Вся вышеописанная информация добавлена в руководство по обновлению в раздел "Change the neural network model for extracting descriptors".

  При запуске LUNA PLATFORM с нуля никаких дополнительных действий не требуется.

- В ресурсы "sdk" и "/handlers/{handler_id}/events" добавлен новый параметр "estimate_people_count", позволяющий выполнить оценку количества людей на изображении.

  Данный функционал лицензируется отдельно.

  Необходимо понимать, что такая оценка не может сравниться по точности с отдельными детекторами лиц или тел. Следует использовать её для приблизительной оценки количества людей. См. документацию SDK для более подробной информации.

  В теле ответа результат возвращается в отдельном поле "image_estimations", поскольку данная оценка не относится к лицам или телам события.

- В задачу Estimator для ZIP архива добавлены следующие параметры:

  - "prefix" — префикс ключа файла. Может использоваться для загрузки изображений из определенной директории;
  - "postfix" — постфикс ключа файла. Может использоваться для загрузки изображений с определенным расширением;
  - "recursive" — рекурсивное получение изображений из вложенных директорий.

- Добавлена возможность указать относительное время (формат now-time) в параметрах «create_time__gte», «create_time__lt», «end_time__gte», «end_time__lt», «insert_time__gte», «insert_time__lt» в следующих задачах:

  - Clustering
  - Exporter
  - Linker
  - Garbage collection
  - Additional extraction
  - Cross-matching task

  Это может быть полезно для фильтрации данных за определенный интервал времени относительно текущего времени. Например, можно выполнить задачу "Garbage сollection" за несколько последних дней.

- В контейнерах сервисов API и Admin обновлена версия Python до 3.11.

  Поддержка более старых версий Python прекращена.

- В скрипте Docker Compose "start_platform.sh" закомментированы строки, касающиеся запуска Backport 3, Backport 4, User Interface 3 и User Interface 4.

  Теперь эти сервисы не будут запускаться при выполнении скрипта.

- В руководство по активации лицензии добавлена инструкция по активации лицензии Guardant без графического интерфейса.

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

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

- Исправлена ошибка, из-за которой проверка подключения к Redis Sentinel не проходила с первого раза.

# v.5.45.4

Изменения

- Уменьшена нагрузка на БД Faces при выполнении запросов лицензии на проверку максимально количества лиц с привязанными БШ или базовыми атрибутами.

- В сервис Image Store добавлены новые ресурсы:

  - HEAD "/1/buckets/{bucket}", позволяющий проверить существование бакета
  - GET "/1/buckets/{bucket}", позволяющий получить дату создания указанного бакета

- Из группы настроек "S3" сервиса Image Store удалена неиспользуемая настройка "bucket".

- В контейнерах сервисов Tasks, Accounts, Configurator, Sender, Backport 3 и Backport 4 обновлена версия Python до 3.11.

  Поддержка более старых версий Python прекращена.

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

- Добавлена отсутствующая миграция стандартного значения настройки "score_threshold" в группе настроек "LUNA_HANDLERS_FACE_DETECTOR_SETTINGS" сервиса Handlers.

  При выполнении обновления на текущую версию, предыдущее стандартное значение "0.42" автоматически обновится до актуального стандартного значения "0.5".

  Если значение настройки "score_threshold" отличается от стандартного, то миграция выполнена не будет.

- Некорректная структура поля "face_detections" > "detection" события в сервисе Events приведена к правильному виду, соответствующему спецификации OpenAPI.

# v.5.45.3

Изменения

- В ресурсы "/matcher/faces", "/matcher/bodies" и "/matcher/raw" добавлена поддержка заголовка `Accept`, определяющего MIME-тип ответа, который следует ожидать от клиента.

  Для заголовка доступно два значения: `application/json` (по умолчанию) и `application/msgpack`.

- В контейнерах сервисов Faces, Image Store, Handlers, Python Matcher и Python Matcher Proxy обновлена версия Python до 3.11.

  Поддержка более старых версий Python прекращена.

  Переход на новую версию Python позволил увеличить скорость выполнения сравнения на 10-20% в некоторых случаях.

- В задачу Estimator добавлен параметр "verify_ssl", позволяющий отключить проверку SSL-сертификата для S3-подобного хранилища.

  Это позволяет использовать самоподписанный SSL-сертификат.

- Ускорено выполнение оценки параметров лиц в некоторых случаях, когда в запросе не указаны параметры, отвечающие за фильтрацию ("yaw_threshold", "fd_score_threshold", "liveness_threshold" и др.).

- Ускорено выполнение запросов на сравнение в случае, когда для кандидатов-событий используются поля "target" из нижеописанного списка:

  - "match_result"
  - "body_detections"
  - "face_detections"
  - "attach_result"
  - "tags"
  - "location"

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

- Исправлена ошибка, при которой запрос на создание бакета S3 к сервису Image Store успешно выполнялся, но бакет не создавался, если в настройках сервиса не была указана настройка "region".

# v.5.45.1

Изменения

- SDK обновлен до версии 5.14.0. Основные изменения SDK, затрагивающие LUNA PLATFORM:

  - обновлен детектор лиц FaceDetV3;
  - обновлен эстиматор Eyebrows.

  Значение по умолчанию настройки `score_threshold` в секции "LUNA_HANDLERS_FACE_DETECTOR_SETTINGS" настроек сервиса Handlers изменено с 0.42 до 0.5. Миграция настроек автоматически обновит это значение (см. раздел "Миграция базы данных Configurator" в руководстве по обновлению). Проверьте логику распознавания лиц, если вы используете значение `score_threshold`, отличное от значения по умолчанию.

  Примечание. В ближайших релизах будет изменена версия нейронной сети для извлечения биометрических шаблонов тел по умолчанию. Необходимо будет вручную сменить версию в настройках сервиса Handlers, иначе его запуск завершится ошибкой.

- Раздел по активации лицензии LUNA PLATFORM вынесен в отдельное руководство по активации лицензии "LP_License_Activation_Manual.pdf/html".

- Добавлена возможность лицензирования LUNA PLATFORM с помощью ключей Guardant.

  Такой способ лицензирования требует наличия графического интерфейса системы и доступа к сети Интернет. Если сервер, где планируется использовать LUNA PLATFORM, не отвечает данным требованиям, то можно выполнить часть действий на вспомогательном сервере на ОС Windows или ОС Linux.

  Старый способ лицензирования с помощью ключей HASP остается доступным.

  См. подробную информацию в разделе "Активация лицензии с помощью Guardant-ключа" в новом руководстве по активации лицензии.

- Добавлена возможность фильтрации по значениям `null` (значение означает, что эстимация по атрибуту не выполнялась) для событий-кандидатов в следующих запросах:

  - "matching faces";
  - "human body matching";
  - "create handler";
  - "generate events";
  - "save event";

  Также фильтрация по значениям `null` добавлена для фильтров по событиям для следующих задач:

  - "Clustering";
  - "Exporter";
  - "Cross-matching";
  - "Linker";
  - "Estimator".

  Фильтрация добавлена для следующих атрибутов:

  - `meta`
  - `source`
  - `emotion`
  - `mask`
  - `ethnic_group`
  - `liveness`
  - `gender`
  - `apparent_gender`
  - `headwear_state`
  - `sleeve_length`
  - `upper_clothing_colors`
  - `lower_garment_type`
  - `lower_garment_colors`
  - `shoes_apparent_color`
  - `backpack_state`
  - `city`
  - `district`
  - `street`
  - `house_number`
  - `area`
  - `geo_position`
  - `track_id`

  Фильтрация по `null` позволяет фильтровать события, сгенерированные по разным обработчикам с разными политиками, где в первом выполнялась эстимация определенного атрибута (например, состояния маски равно `occluded`), а во втором не выполнялась эстимация (например, состояние маски равно `null`), но нужно получить оба события.

- Выполнение запросов "get events" и "save event" было ускорено.

- В секцию "S3" настроек сервиса Image Store добавлен новый параметр "verify_ssl", позволяющий отключить проверку SSL-сертификата для S3-подобного хранилища.

  Это позволяет использовать самоподписанный SSL-сертификат.

- Обновлен механизм проверки соединения с сервисом Image Store.

  Ранее сервис Admin выполнял проверку с помощью получения списка всех бакетов, что могло приводить к ошибке из-за отсутствия у пользователя доступа к бакетам. Теперь проверка соединения выполняется без получения списка всех бакетов.

- В группу настроек `DESCRIPTORS_CACHE` сервиса Python Matcher добавлена новая подгруппа `CACHED_DATA`, позволяющая задавать данные для кеширования.

  В поле `face_lists` можно настроить, какие именно списки будут кэшироваться, а какие будут игнорироваться. Для данного поля доступно два значения:

  - `include` — будут кэшироваться только списки, заданные в данном разделе (для отключения нужно задать `null`);
  - `exclude` — списки из этого раздела будут проигнорированы.

- В сервис Python Matcher добавлен новый пример встроенного плагина "Thin face".

  Плагин "Thin face" приводится в качестве примера для быстрого сравнения лиц (объектов) с упрощенными лицами (объектами). Упрощенные лица хранятся в отдельной таблице базы данных "luna_faces" с тремя обязательными столбцами ("face_id", "descriptor", "descriptor_version"). При необходимости можно настроить ряд дополнительных столбцов: "account_id", "lists", "create_time", "external_id", "user_data", "event_id", "avatar".

  См. подробное описание плагина "Thin face" и инструкцию по написанию пользовательских плагинов в документе "PythonMatcherDevelopmentManual" в комплекте поставки.

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

- В нижеперечисленных запросах спецификации OpenAPI сервиса API исправлены значения по умолчанию для некоторых параметров:

  - "create handler";
  - "extract attributes";
  - "iso";
  - "sdk";
  - "create attributes";
  - "get attributes".

  Также исправлено значение по умолчанию для параметра "extract_descriptor" запроса "create descriptors" в спецификации OpenAPI сервиса Backport 3 и значение по умолчанию для параметра "policies" > "create_face_policy" > "set_sample_as_avatar" запроса "create handler" в спецификации OpenAPI сервиса Backport 4.

- Исправлена ошибка в задаче "Estimator", при которой возвращался код состояния 500 при попытке подключения к несуществующей конечной точке (эндпоинту) S3-подобного сервера.

  Теперь выдается код состояния 400 и код ошибки 12031 с содержимым "Specified bucket not available".

- Исправлена ошибка в задаче "Estimator", при которой возвращался код состояния 500 при попытке подключения к серверу Samba без авторизации.

  Теперь выдается код состояния 400 и код ошибки 12031 с содержимым ошибки Samba.

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

  Теперь при подобных ошибках в логах сервиса Licenses всегда будут выдаваться сообщения вида `Failed to init licensing`.

- Исправлено появление ошибки `object of type 'Image' has no len()` с кодом состояния 500 при выполнении эстимации некоторых повернутых изображений с включенным параметром извлечения EXIF-данных `use_exif_info`.

- Исправлена ошибка в сервисе Python Matcher, приводившая к перезагрузке кеша биометрических шаблонов при изменении настроек логирования.

- Исправлена ошибка, при которой невозможно было указать более 36 символов для фильтра `source` для кандидатов в запросах на сравнение.

  Теперь можно указать не более 128 символов.

- Исправлена ошибка, возникавшая при миграции аккаунтов и токенов сервиса Backport 3 при обновлении с версий 5.2.0...5.28.0 на версии 5.30.0 и выше.

# v.5.42.0

Изменения

- Теперь сервис Image Store может хранить любые файлы в качестве объектов (например, видеофайл).

  Ранее были доступны только следующие типы объектов: `json`, `text`, `zip`, `pdf`.

  Загрузить файлы можно с помощью запроса "create objects". Байты файла должны быть указаны в теле запроса, а заголовок `Content-Type` должен содержать MIME-тип файла (например, `video/mp4`). Ответ на запрос "get object" содержит заголовок Content-Disposition. Этот заголовок содержит имя файла объекта вложения (например, `video_1.mp4`). Имя файла генерируется на основе `object_id` и MIME-типа.

  Если MIME-тип файла не получилось определить, то расширение файла будет установлено как `.bin`.

  Теперь заголовок `Accept` игнорируется для запроса "get object". Ранее сервис возвращал ошибку `12023, Content type is unacceptable` со статус-кодом 406, если если тип содержимого объекта не совпадал с MIME-типом файла.

- Теперь при выполнении любого запроса с корректной авторизацией, в логах сервиса API выводится информация о соответствующем аккаунте.

  Данный функционал позволяет определить кто именно выполнил тот или иной запрос. Это может потребоваться для информационной безопасности и администраторов систем.

  Если запрос был выполнен с авторизацией типа BasicAuth или LunaAccountIdAuth, то в логах будет выдано следующее сообщение:

      Request invoked by user (account_id: '270531af-e52e-4538-9181-628d9900a0db')

  Если запрос был выполнен с авторизацией типа BearerAuth, то в логах будет выдано следующее сообщение:

      Request invoked by user (account_id: '270531af-e52e-4538-9181-628d9900a0db' token_id: 'd57e16f5-e243-47d2-aa85-8b200c12d86f')

  Если запрос был выполнен без авторизации, то в логах будет выдано следующее сообщение:

      Request invoked by user (account_id: null)

  В логах сервиса Accounts дополнительно выводится информация о создании токенов конкретными пользователями:

      User with account_id: '270531af-e52e-4538-9181-628d9900a0db' create token: 'd57e16f5-e243-47d2-aa85-8b200c12d86f'

  Логирование информации о создании токенов позволяет отследить откуда появился токен и какому пользователю он принадлежал, даже после его удаления.

- В группы проверок `face_quality` и `iso` добавлена новая проверка `shoulders_position`, определяющая наиболее вероятное состояние положения плеч из следующих состояний:

  - non-parallel (плечи не параллельны)
  - parallel (плечи параллельны)
  - hidden (плечи скрыты)

- Ускорено выполнение запроса "get faces" со всеми полями `target`.

- Уменьшено использование памяти сервисом Tasks в некоторых случаях использования задачи "Cross-matching".

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

- Исправлена ошибка в сервисе Configurator, при которой не работал скрипт `db_create.py` при нестандартных значениях конфигураций сервиса Configurator.

- Исправлена ошибка, при которой прогревался кэш при старте сервиса Python Matcher при выключенной настройке "DESCRIPTORS_CACHE".

- Исправлена ошибка, при которой сервис Python Matcher запускался и продолжал работать в случае, когда некоторые "рабочие процессы" останавливались с ошибкой.

  "Рабочий процесс" — процесс сервиса Python Matcher, обрабатывающий входящие (HTTP) запросы.

- Исправлено поведение, которое могло приводить к удалению одной или всех новых подписок на события, если создание новой подписки и удаление старой происходили одновременно.

- Исправлена ошибка, при которой использование оценки EXIF данных (параметр `use_exif_info`) могло приводить к ошибке вида `Internal server error`.

# v.5.40.0

Изменения

- Начиная с текущего релиза, в командах запуска контейнеров PostgreSQL, InfluxDB и Image Store прописываются пути директорий для монтирования, расположенные в корневом каталоге `/var/lib/luna/<db_or_bucket_folder>`, в отличие от предыдущих версий, где пути прописывались для определенной версии LUNA PLATFORM `/var/lib/luna/current/example-docker/<db_or_bucket_folder>`.

  Это означает, что данные PostgreSQL, InfluxDB и Image Store теперь будут храниться в корневом каталоге и больше не потребуется переносить их в директорию с новой версией LUNA PLATFORM при обновлении.

  Скрипт Docker Compose также обновлен в соответствии с вышеописанной информацией.

  Примечание. При обновлении на текущую версию необходимо перенести старые данные PostgreSQL, InfluxDB и Image Store в корневой каталог, а затем удалить и заново создать контейнеры, прописав новые пути директорий для монтирования. См. раздел "Перенос данных" в руководстве по обновлению.

- Добавлена поддержка работы сервисов LUNA PLATFORM без сервиса Image Store.

  Сервис можно отключить в настройке "ADDITIONAL_SERVICES_USAGE" сервиса Configurator.

  При использовании ресурсов, требующих наличия отключенного сервиса Image Store, будет возвращена ошибка `11070, Luna Image Store service is disabled`.

  При отключении сервиса Image Store, существуют некоторые особенности, перечисленные ниже:

  - Объекты типа `images`, `objects`, `samples` и политики сохранения биометрических образцов в обработчиках/верификаторах будут недоступны.

  - Пропадет возможность использования всех задач, кроме задач Garbage Collection, Linker и Estimator, однако для этих задач есть ряд ограничений:

    - Garbage Collection, Estimator, Linker: результаты задач/подзадач не будут сохраняться
    - Garbage Collection, Estimator, Linker: после завершения подзадачи, статус задачи будет обновлен на `Done` и идентификатор результата задачи будет равен `None`
    - Garbage Collection: удаление биометрических образцов станет недоступным

    Если сервис Image Store отключается после того, как были сгенерированы события с включенной политикой "image_origin_policy", то при использовании задачи Garbage Collection и параметра `remove_image_origins`, сервис Tasks будет по-прежнему пытаться удалять исходные изображения, имеющие внешний URL-адрес.

  При отключении сервиса Image Store, для сервиса Backport 3 БО и портреты станут недоступны, как и ресурсы "get portrait" и "get portrait thumbnail".

  В сервис Backport 3 добавлена новая настройка "BACKPORT3_ENABLE_PORTRAITS", позволяющая отключить возможность использования портретов, но оставить возможность использования остального функционала сервиса Image Store. Если использование сервиса Image Store отключено в настройке "ADDITIONAL_SERVICES_USAGE", то вышеописанная настройка также должна быть отключена.

  См. подробную информацию в разделе "Отключаемые сервисы" руководства администратора.

- Библиотека HASP обновлена до версии 1.7.3.

- Добавлен новый способ активации лицензии с помощью ключа Guardant.

  Для активации данным способом требуется наличие сети Интернет и доступ к графическому интерфейсу системы. Если сервер, где запускается LUNA PLATFORM, не подходит под данные требования, то необходимо использовать вспомогательный сервер. В качестве вспомогательного сервера может выступать как сервер с ОС Linux, так и сервер с ОС Windows.

  Старый способ активации с помощью ключа HASP также остается доступным.

  См. подробную информацию в разделе "Активация лицензии с помощью Guardant-ключа" во всех руководствах по установке и обновлению.

- В запрос "generate events" добавлена поддержка указания пользовательских метаданных для исходного изображения.

  Метаданные передаются с помощью заголовков вида "X-Luna-Meta-:", которые отправляются в сервис Image Store при сохранении исходного изображения во время генерации события.

  Заголовки необходимо указывать в секции `image_origin` при использовании типа содержимого запроса`multipart/form-data`.

  См. подробную информацию об использовании пользовательских метаданных при сохранении изображений в сервис Image Store в разделе "Сохранение исходных изображений".

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

- Исправлена ошибка, при которой при указании в теле запроса "generate events" исходного изображения не в виде URL, оно сохранялось в сервис Image Store независимо от состояния политики `image_origin_policy`.

- Исправлено описание некорректных заголовков ответа "Content-Type" для запросов "detect faces" и "get list count".

- Практически во все запросы сервиса Admin добавлен новый заголовок `Exclude-Header`.

  Благодаря этому исправлена ошибка в пользовательском интерфейсе Admin, из-за которой после перезагрузки страницы происходил выход из учетной записи.

- Исправлена ошибка лицензии, возникавшая при использовании пробной лицензии на указанное количество дней.

# v.5.38.3

Изменения

- SDK обновлен до версии 5.13.0. Основные изменения SDK, затрагивающие LUNA PLATFORM:

  - обновлен детектор тел
  - обновлен эстиматор FishEye

  Значение по умолчанию настройки `score_threshold` в секции "LUNA_HANDLERS_BODY_DETECTOR_SETTINGS" настроек сервиса Handlers изменено с 0.3 до 0.5. Миграция настроек автоматически обновит это значение (см. раздел "Миграция базы данных Configurator" в руководстве по обновлению). Проверьте логику распознавания тел, если вы используете значение `score_threshold`, отличное от значения по умолчанию.

  Значение по умолчанию настройки `redetect_face_target_size` в секции "LUNA_HANDLERS_FACE_DETECTOR_SETTINGS" настроек сервиса Handlers изменено с 45 до 64. Миграция настроек автоматически обновит это значение (см. раздел "Миграция базы данных Configurator" в руководстве по обновлению). Проверьте логику распознавания лиц, если вы используете значение `redetect_face_target_size`, отличное от значения по умолчанию.

- Теперь при первоначальной проверке лицензии проверяется только время окончания действия лицензии, вместо всех проверок лицензии. Остальные проверки теперь выполняются при получении запросов сервисом Licenses.

  Это изменение ускоряет загрузку сервиса Licenses.

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

- В спецификацию OpenAPI добавлено отсутствующее описание для формата `msgpack` в запросы на сравнение "matching faces" и "matching bodies".

- Исправлена ошибка, при которой в мониторинге считывались не все форматы дат и времени. Если был передан непредусмотренный формат, то возникала ошибка чтения.

  Теперь добавлена возможность чтения всех форматов дат из БД Influx.

- Исправлена ошибка сервиса Accounts, при которой некоторые ошибки, связанные с обработкой запросов к базе данных Accounts, не обрабатывались должным образом и не выводились в логи сервиса.

- Исправлена ошибка, из-за которой могли отсутствовать некоторые данные в результате выполнения задач, когда для параметра `tasks_to_faces_requests_concurrency` сервиса Tasks было установлено значение `1`.

- Исправлена маршрутизация запросов к плагину сравнения.

  Если запрос на сравнение содержит значение поля `target`, которое плагин не поддерживает, то сервис добавляет к запросу ключевое значение для поля `target` (`face_id` для сравнения по лицам и `event_id` для сравнения по событиям).

  Ранее плагин не поддерживал поле `face_id` или `event_id` в качестве значения поля `target` и запрос мог завершиться ошибкой или вернуть пустой список кандидатов. Теперь сервис Python Matcher Proxy не будет перенаправлять такие запросы к плагину сравнения.

  См. подробную информацию в разделе "Поля target, выступающие в качестве сравнения" руководства администратора.

# v.5.38.1

Изменения

- Добавлена возможность передачи исходных изображений в формате URL или Base64 в запросе "generate events".

  Исходные изображения можно передать с помощью указания типа содержимого запроса `Content-Type = application/json` или `Content-Type = multipart/form-data`.

- В комплект поставки LUNA PLATFORM добавлен скрипт Docker Compose `start_logging.sh`, запускающий сервис LUNA Dashboards, Grafana Loki и Promtail, позволяющие гибко работать с логами LUNA PLATFORM в Grafana.

  Скрипт расположен в директории `example-docker`.

  В руководство по установке LUNA PLATFORM с помощью Docker Compose добавлена соответствующая информация в раздел запуска основного скрипта Docker Compose.

  См. подробную информацию о визуализации логирования в разделе "Grafana Loki" руководства администратора.

- Ускорена отправка данных в InfluxDB.

- Добавлена возможность фильтрации по значениям `null` (значение означает, что эстимация по атрибуту не выполнялась) для перечисленных ниже атрибутов в запросах "get events" и "get statistics on events":

  - `meta`
  - `source`
  - `emotion`
  - `mask`
  - `ethnic_group`
  - `liveness`
  - `gender`
  - `apparent_gender`
  - `headwear_state`
  - `sleeve_length`
  - `upper_clothing_colors`
  - `lower_garment_type`
  - `lower_garment_colors`
  - `shoes_apparent_color`
  - `backpack_state`
  - `city`
  - `district`
  - `street`
  - `house_number`
  - `area`
  - `geo_position` (поля `origin_longitude` и `origin_latitude` для запроса "get events")
  - `track_id`

  Это позволяет фильтровать события, сгенерированные по разным обработчикам с разными политиками, где в первом выполнялась эстимация определенного атрибута (например, состояния маски равно `occluded`), а во втором не выполнялась эстимация (например, состояние маски равно `null`), но нужно получить оба события.

- В настройки каждого сервиса добавлена группа настроек вида `<service_name>_HTTP_SETTINGS`, содержащая настройки, отвечающие за обработку HTTP-подключений.

  Доступны следующие настройки:

  - `request_timeout` — продолжительность времени между моментом, когда новое открытое TCP-соединение передается на сервер. Значение (в секундах) — целое число, по умолчанию 60.
  - `response_timeout` — продолжительность времени между моментом, когда сервер передает HTTP-запрос приложению, и моментом, когда HTTP-ответ отправляется клиенту. Значение (в секундах) — целое число, по умолчанию 600.
  - `request_max_size` — насколько большим может быть запрос. Значение (в байтах) — целое число, по умолчанию 1 Гб для всех сервисов кроме Image Store и ~130 Гб для сервиса Image Store.
  - `keep_alive_timeout` — тайм-аут поддержания активности HTTP. Значение (в секундах) — целое число, по умолчанию 15.

  См. подробную информацию по следующей ссылке: https://sanic.dev/en/guide/deployment/configuration.html#builtin-values

- Улучшена производительность запроса "get faces" с фильтрами по `list_id` и `face_id__gte/lt`.

- Добавлена возможность переопределить настройки сервисов при их старте с помощью переменных окружения.

  Для переопределения настроек используется префикс `VL_SETTINGS`. Примеры:

  - `VL_SETTINGS.LUNA_MONITORING.SEND_DATA_FOR_MONITORING=0`. Использование переменной окружения из данного примера установит значение настройки `SEND_DATA_FOR_MONITORING` для секции `LUNA_MONITORING` равным `0`.
  - `VL_SETTINGS.OTHER.STORAGE_TIME=LOCAL`. Для несоставных настроек (настроек, которые расположены в секции `OTHER` в конфигурационном файле) необходимо указать префикс `OTHER`. Использование переменной окружения из данного примера установит значение настройки `STORAGE_TIME` (если сервис использует данную настройку) на значение `LOCAL`.

  Переменная окружения может быть указана с помощью аргумента `ENV` при запуске сервисов в Docker-контейнерах.

- В запрос "get license" сервиса Licenses добавлена возможность получить значение определенной функции лицензирования с помощью нового поля `targets`.

- Добавлена поддержка дашбордов для LIM.

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

- В примерах ответов запросов "get events", "get event", "get task result" и "ws handshake" в спецификации OpenAPI исправлено описание полей с `body_basic_attributes` на `basic_attributes`, с `upper_body_attributes` на `upper_body`, с `lower_body_attributes` на `lower_body` и с `body_accessories` на `accessories` .

- Исправлена ошибка, из-за которой не освобождалась память после выполнения задачи "Exporter".

- Исправлена ошибка, при которой задача "Exporter" продолжала выполняться с неполными данными даже если при её выполнении возникала ошибка.

  Теперь при возникновении ошибки при выполнении задачи Exporter будут возвращаться ошибки с кодами 28038 (не удалось загрузить данные) и 28039 (не удалось загрузить данные, но были повторные попытки переподключения к сервисам Faces или Events).

- Исправлена ошибка, из-за которой прерывалась загрузка большого результата задачи.

# v.5.36.5

Изменения

- Теперь адрес сервера лицензирования задается в настройках сервиса Licenses, а не в файле `hasp_30147.ini`.

  Таким образом, больше нет необходимости монтировать данный файл при запуске контейнера Licenses.

  В руководства по установке и обновлению добавлены инструкции по указанию адреса сервера лицензирования с помощью пользовательского интерфейса Configurator перед запуском сервиса Licenses.

  В руководство по установке также добавлена инструкция по указанию адреса сервера лицензирования с помощью файла "platform_settings.json" перед началом процесса установки.

  Примечание. При обновлении с предыдущих версий нужно обязательно задать адрес лицензирования в новой настройке, иначе сервис Licenses не запустится.

- Обновлен внешний вид пользовательского интерфейса сервиса Admin.

  Логика работы с пользовательским интерфейсом осталась прежней.

- Добавлена возможность записывать в генерируемое событие координаты ограничивающих прямоугольников лица или тела при использовании биометрического образца в качестве источника изображения. Координаты можно передать либо с помощью внешнего приложения, либо задать вручную в запросе на генерацию события (например, с помощью схемы "multipart/form-data").

  Указанные координаты сохраняются в поле `face_detections`/`body_detections` > `detection` > `rect` события.

  Задание координат ограничивающих прямоугольников будет игнорироваться в других запросах, где можно указать биометрический образец в качестве источника изображения.

  Ранее в событие можно было сохранять только ограничивающие прямоугольники лица или тела исходных изображений.

- В политику "match_policy" запросов "create handler" и "validate handler policies" добавлена поддержка фильтрации кандидатов по полю `meta` события.

- В задачи "Clustering", "Exporter", "Cross-matching" и "Linker" добавлены фильтры по полю `meta` события.

- Улучшена валидация фильтра по полю `meta` для сравнения. Данный фильтр используется в следующих запросах:

  - "matching faces",
  - "matching bodies",
  - "cross-matching task".

- В запрос "get statistics on events" добавлена поддержка фильтрации и агрегирования по полю `meta` события.

- В сервис API добавлен новый запрос "get platform features", в ответе на который можно получить информацию активна и не истек ли строк действия лицензии, а также информацию о включенных функциях лицензии ("face_quality", "body_attributes" и "liveness") и доступности функционала работы с сервисами Events, Tasks и Sender. Использование данных сервисов включается в настройке "ADDITIONAL_SERVICES_USAGE" сервиса Configurator.

- В задачу "Garbage collection" добавлена возможность выбрать лица в качестве объекта для очистки (поле `target`).

  Также доступны фильтры `create_time__lt`, `create_time__gte`, `user_data`, `list_id`, а также параметры сохранения результатов (поле `store_results`) и удаления биометрических образцов лиц (поле `remove_samples`).

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

- Обновлена логика работы эстиматора проверки динамического диапазона (`dynamic_range`) в группе проверок "face_quality".

- Ресурс `/attributes/batches` сервиса Faces перенесен в `/descriptors/batches`.

- Во всех сервисах LUNA PLATFORM отключена запись логов в файл по умолчанию (настройка `log_to_file` каждого сервиса).

- Обновлена документация в комплекте поставки.

  Переработан раздел "Общие положения" руководства администратора.

  Переработаны разделы "Подготовка к установке/обновлению" всех руководств по установке/обновлению/миграции. Часть информации описательного характера перенесена в раздел "Дополнительная информация", расположенный в конце каждого руководства.

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

- В спецификации OpenAPI сервиса Admin было исправлено перечисление в поле `content > filter > object_type` с "face"/"event" на "faces"/"events" запроса "create additional extract task".

- Исправлена ошибка, выводящая в логи лишнюю информацию при использовании команды включения подсчета статистики `create_usage_task`.

- Исправлена ошибка в спецификации OpenAPI сервиса Python Matcher, из-за которой фильтр `meta` не имел тип `nullable` в запросах "face matching", "human body matching", "cross matching faces" и "cross matching bodies".

- Исправлена ошибка, из-за которой в запросе "face matching" сервиса Python Matcher объект `candidates > filters` не был обязательным.

# v.5.35.0

Изменения

- Прекращена поддержка старых сервисов Индексирования и поиска по индексу.

  Упоминание данных сервисов удалено из документации и настроек сервисов.

  Теперь для построения индекса и поиска по индексу используется только модуль LUNA Index Module.

- Добавлена функциональность для сохранения и получения пользовательских метаданных изображения через настраиваемые заголовки.

  Сохранить изображение с пользовательскими метаданными можно в ресурсе "create images", задав в заголовок "X-Luna-Meta-" с значением "". В бакете исходных изображений в хранилище Image Store, метаданные сохраняются в отдельный файл ".meta.json", который расположен рядом с исходным изображением.

  В ответе на запрос на получение изображения (запрос "get image") нужно указать заголовок `with_meta=1` для получения метаданных изображения в заголовке ответа.

  Чтобы сохранять значения метаданных для нескольких ключей, необходимо задать несколько заголовков.

- Версия LUNA Dashboards обновлена до 0.0.5. Версия Grafana в контейнере LUNA Dashboards обновлена до 8.5.20.

  Теперь не нужно использовать отдельную команду для запуска дашбордов, они создаются автоматически при запуске контейнера LUNA Dashboards.

- Добавлены контейнеры Grafana Loki (система агрегации логов) и Promtail (агент, доставляющий логи LUNA PLATFORM в Grafana Loki).

  Для запуска контейнеров требуется наличие запущенной Grafana и настроенного источника данных "Loki". В контейнере LUNA Dashboards уже создан источник данных "Loki".

  В раздел "Grafana Loki" руководства по установке добавлена инструкция по запуску Grafana Loki и Promtail.

  См. дополнительную информацию в разделе "Grafana Loki" руководства администратора.

- В задачу Estimator (ресурс "/tasks/estimator") добавлена поддержка сетевой файловой системы Samba в качестве источника изображений (параметр "source_type").

  Для такого типа источника в теле запроса доступно задание следующих параметров для соединения с Samba:

  - Параметр "host" — IP-адрес (обязательное поле);
  - Параметр "port" — порт;
  - Параметры "user" и "password" — параметры авторизации. Если нет данных авторизации, подключение к Samba будет осуществляться как гостевое.

  Как и в задачах Estimator с использованием FTP, S3-подобного хранилища или сетевого диска в качестве источников изображений, доступна возможность задания пути до директории с изображениями, рекурсивного получения изображений из вложенных директорий, выбора типа передаваемых изображений, а также указания префикса и постфикса.

  Для получения корректных результатов обработки изображений с помощью задачи Estimator все обрабатываемые изображения должны быть либо в исходном формате, либо в формате биометрических образцов.

  См. соответствующие примеры и дополнительную информацию в спецификации OpenAPI.

- В ресурс "sdk" добавлен параметр "extract_exif", позволяющий извлекать EXIF данные из изображения.

- В ресурс "ws handshake" добавлены фильтры "geo_position" (параметры "origin_longitude", "origin_latitude", "longitude_delta" и "latitude_delta") и "user_data".

- В ресурсы "matching faces", "matching bodies" и политику "match_policy" запроса "create handler" добавлена поддержка фильтрации кандидатов по полю "meta" события.

- В раздел "Информация по обновлению" руководства по обновлению добавлена таблица с ключевыми изменениями предыдущих версий LUNA PLATFORM, которые влияют на процесс установки и работы LUNA PLATFORM. Данная таблица может быть полезна при попытке обновления LUNA PLATFORM не с предыдущей версии.

# v.5.34.0

Изменения

- SDK обновлен до версии 5.12.0. Основные изменения SDK, затрагивающие LUNA PLATFORM:

  - обновлены следующие эстиматоры: LivenessOneShotRGB, FishEye, Orientation, HeadWear;
  - удалены 54-ая, 56-ая и 57-ая модели нейронных сетей извлечения биометрических шаблонов лиц и 104-ая и 106-ая модели нейронных сетей извлечения биометрических шаблонов тел. Поддержка данных моделей остается доступной. При необходимости можно запросить их у специалистов VisionLabs.

  Теперь модель нейронной сети извлечения биометрических шаблонов тел по умолчанию — 107 (настройка "DEFAULT_HUMAN_DESCRIPTOR_VERSION" сервиса Handlers).

  Важная информация по обновлению с предыдущих версий

  Необходимо выполнить одно из следующих действий перед запуском контейнера Handlers:

  - вручную изменить значение настройки "DEFAULT_HUMAN_DESCRIPTOR_VERSION" с "104" или "106" на "107". После изменения версии нейронной сети извлечения биометрических шаблонов тел необходимо выполнить задачу "Additional extraction" после запуска сервиса Admin (см. раздел "Launch re-extraction task" в руководстве администратора). В противном случае, поиск и сравнение по старым биометрическим шаблонам будут недоступны.
  - выключить использование нейронной сети для извлечения биометрического шаблона тела с помощью передачи аргумента `--enable-body-descriptor-estimator=0` при старте контейнера Handlers
  - запросить у VisionLabs 104-ую модель нейронной сети и перенести её в контейнер Handlers по инструкции, описанной в разделе "Use non-delivery neural network model" руководства администратора

  Если не выполнить одно из вышеописанных действий, то запуск сервис Handlers завершится ошибкой.

  Вся вышеописанная информация добавлена в руководство по обновлению в раздел "Changing the model of the neural network of bodies".

  При установке LUNA PLATFORM с нуля никаких дополнительных действий выполнять не требуется.

- В структуру события добавлено новое поле "meta", предназначенное для хранения произвольных пользовательских данных в JSON-формате (не более 2 Мб).

  Предполагается, что с помощью данного функционала пользователь создаст свою модель данных (структуру события) и будет использовать её для хранения этих данных. Обратите внимание, что если планируется хранить несколько структур, то необходимо явно их разделять, чтобы избежать пересечения полей. Например, следующим образом:

      {
          "struct1": {
              ...
          },
          "struct2": {
              ...
          }
      }

  Пользовательские данные можно передать тремя способами:

  - в теле запроса "generate events" с типом содержимого `application/json` или `multipart/form-data`;
  - в теле запроса "save event";
  - с помощью пользовательского плагина или клиентского приложения.

  В теле запроса "generate events" доступна возможность задать поле "meta" как для конкретных изображений, так и для всех изображений сразу (взаимная метаинформация). Для запросов с включенной агрегацией для агрегированного события будет использоваться только взаимная метаинформация, а метаинформация для конкретных изображений будет игнорироваться. См. подробную информацию в теле запроса "generate events" в спецификации OpenAPI.

  Поле "meta" может быть использовано как фильтр в запросе "get events" или в качестве значения для параметра "target" в запросе "get event".

  Колонка "meta" добавлена в задачи Reporter и Exporter.

  Поддержка метаинформации события также добавлена в ресурс "ws handshake".

  При необходимости можно построить индекс для улучшения поиска.

  См. подробное описание и особенности работы в разделе "Events meta-information" руководства администратора.

- Прекращена поддержка сервиса Liveness V1.

  Сервис Liveness V1 удален из документации и настроек сервисов. Liveness V2 переименован в Liveness.

- В аргументы запуска контейнера Handlers добавлен новый аргумент `enable-all-estimators-by-default`, включающий/отключающий инициализацию всех эстиматоров и детекторов по умолчанию.

  Ранее для использования определенных эстиматоров или детекторов приходилось указывать статус каждого эстиматора из всех существующих. Теперь достаточно отключить инициализацию всех эстиматоров `enable-all-estimators-by-default=0` по умолчанию, а затем указать только те эстиматоры или детекторы, которые необходимо включить.

  Пример команды запуска сервиса Handlers с использованием только детектора лиц и эстиматоров биометрического образца лица и эмоций.

      docker run \
      ...
      --env=EXTEND_CMD="--enable-all-estimators-by-default=0 --enable-face-detector=1 --enable-face-warp-estimator=1 --enable-emotions-estimator=1" \
      ...

  См. подробную информацию в разделе "Enable/disable several estimators and detectors" руководства администратора.

- Теперь фильтр по "account_id" не является обязательным для задач Clustering (фильтр в теле запроса), Cross-matching (фильтра в теле запроса для кандидатов или эталона) и Estimator (фильтры сравнения в политиках обработчика). Это позволяет выполнять сравнение по объектам разных аккаунтов.

- Для нижеперечисленных ресурсов в тело ответа добавлен новый параметр "external_url", указывающий абсолютный адрес до объекта:

  - "create account",
  - "create token",
  - "replace token",
  - "create images",
  - "create objects",
  - "extract attributes",
  - "create face",
  - "create list",
  - "save event",
  - "create verifier",
  - "create handler".

  В качестве абсолютного адреса используется адрес сервиса API, указанный в настройке "EXTERNAL_LUNA_API_ADDRESS" сервиса API. Значение настройки по умолчанию — http://127.0.0.1:5000/6/.

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

  Пример относительной ссылки (параметр "url"): "/6/objects/4a870804-0cd6-4c13-9c78-98ad167dc4ec"

  Пример абсолютной ссылки (параметр "external_url"): "http://127.0.0.1:5000/6/objects/4a870804-0cd6-4c13-9c78-98ad167dc4ec"

- В ресурс пакетной выгрузки биометрических шаблонов "get face descriptor batches" сервиса Faces добавлена поддержка заголовка "Accept", принимающего два значения — `application/x-flutbuf` (по умолчанию) и `application/x-msgpack`.

- Из настроек сервиса Handlers удален неиспользуемый параметр "max_face_size" из секции "LUNA_HANDLERS_FACE_DETECTOR_SETTINGS".

  Параметр "max_face_size" рассчитывается как `min_face_size * 32`.

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

- В спецификации OpenAPI сервиса API исправлены и дополнены примеры ответов с кодами 403, 408, 413, 500, 503 и 504. См. примеры ответов в спецификации OpenAPI.

- В запрос "perform verification" добавлен отсутствующий ранее параметр указания типа обрабатываемого изображения "image_type". Для данного параметра доступно два значения — 0 (исходное изображение) и 1 (биометрический образец лица).

- Исправлены некорректные пороги для параметров "mouth_occluded", "mouth_smiling" и "mouth_open" группы параметров "face_quality" в запросах "create handler", "get handlers", "get handler" и "replace handler" в спецификациях OpenAPI сервисов API и Handlers.

  В спецификации было указано, что допустимые пороги для вышеперечисленных параметров равны [-1..1], хотя на самом деле допустимые пороги равны [0..1].

# v.5.33.0

Изменения

- Начиная со следующего релиза прекращается поддержка Liveness V1. Из документации будут удалены команды запуска контейнера и описание.

- В ресурс "sdk" и политику "detect_policy" > "body_attributes" ресурса "/handlers" добавлен новый параметр "estimate_lower_body", позволяющий выполнить оценку следующих атрибутов тел:

  - "lower_garment" — тип нижней одежды (брюки, шорты, юбка, неизвестно), цвет нижней одежды (бежевый, чёрный, синий, коричневый, зеленый, серый, хаки, разноцветный, оранжевый, розовый, фиолетовый, красный, белый, желтый, неизвестно);
  - "shoes" — цвет обуви (черный, белый, прочий, неизвестный).

  Данная оценка по умолчанию выключена в обоих ресурсах.

  Также теперь в параметре "estimate_upper_body" определяется цвет головного убора (параметр "headwear_apparent_color") (цвета аналогичны цветам нижней одежды).

  Новые атрибуты тел добавлены в структуру событий (см. "detections" > "samples" > "body" > "detection" > "attributes").

  В политику "match_policy" ресурса "/handlers" и в ресурс "human body matching" добавлены фильтры атрибутов тел "lower_garment_types" (тип нижней одежды), "lower_garment_colors" (цвет нижней одежды), "shoes_apparent_colors" (цвет обуви) и "headwear_apparent_color" (цвет головного убора), указываемые при использовании событий в качестве кандидатов. Также добавлена возможность задать данные атрибуты тела в качестве значений для поля "targets".

  Фильтры данных атрибутов тел также могут быть использованы при отправке событий через веб-сокеты (см. ресурс "ws handshake").

  Соответствующие фильтры для событий добавлены в задачи Cross-matching, Clustering, Reporter, Exporter и Linker. В задачи Reporter и Exporter добавлены соответствующие колонки.

  Поддержана возможность указания данных атрибутов тел при создании нового обработчика в задаче Estimator.

  Структура события в запросах "generate events"/"save events" также расширена данными атрибутами тел. Кроме того, в данных запросах и запросе "sdk" доступна агрегация по данным атрибутам тел. Агрегированные значения атрибутов отображаются в полях "aggregate_estimations" соответствующих ресурсов.

- Обновлены настройки сервиса Handlers.

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

  Глобальные настройки задаются в секции "LUNA_HANDLERS_RUNTIME_SETTINGS" и содержат в себе три настройки:

  - global_device_class — тип устройства ("cpu" или "gpu") для всех эстиматоров/детекторов, у которых значение параметра "device_class" = "global" (см. ниже);
  - num_threads — количество потоков "рабочего процесса" для всех эстиматоров/детекторов;
  - num_compute_streams — количество потоков для всех эстиматоров/детекторов.

  Индивидуальные настройки задаются в секции вида "LUNA_HANDLERS__SETTINGS.runtime_settings" и содержат в себе три настройки:

  - device_class — тип устройства для выполнения оценки ("cpu", "gpu" или "global");
  - optimal_batch_size — размер батча для выполнения оценки;
  - worker_count — количество "рабочих процессов" для выполнения оценки.

- В сервисе Handlers добавлена возможность включения/выключения использования отдельных эстиматоров и детекторов. По умолчанию все эстиматоры включены.

  Ранее можно было включать/выключать только все эстиматоры сразу.

  Возможность включения отдельных эстиматоров позволяет экономить оперативную память или память GPU, поскольку при старте сервиса Handlers выполняется проверка возможности выполнения указанных оценок и загрузка данных в память. При отключении эстиматора или детектора можно также удалить его нейронную сеть из контейнера Handlers.

  Отключение эстиматоров или детекторов возможно с помощью передачи аргументов с названиями эстиматоров или детекторов в команду запуска сервиса Handlers. Аргументы передаются в контейнер с помощью переменной "EXTEND_CMD". Перечень всех аргументов и пример запуска контейнера добавлены в руководство администратора LUNA PLATFORM 5.

- Добавлена поддержка изображений со схемой CMYK.

- В сервис Backport 3 добавлен ресурс "ws handshake" для возможности получения событий через веб-сокеты.

  Данный функционал аналогичен функционалу сервиса "Event & Statistic Service" LUNA PLATFORM 3.

- Обновлены настройки сервиса API.

  Секция "LUNA_HANDLERS_LIVENESS_SETTINGS" удалена из настроек сервиса API, т.к. она не использовалась.

  Параметр "LIVENESS_THRESHOLD" переименован в "LIVENESSV1_THRESHOLD".

- В политику "detect_policy" ресурсов "create handler" и "create verifier" добавлен параметр "estimate_glasses", позволяющий выполнить оценку типа очков (очки, солнечные очки, нет очков).

- Параметр "estimate_attributes" в запросах "create descriptors" и "search" сервиса Backport 3 расширен возможностью оценки типа очков (очки, солнечные очки, нет очков). Теперь при выполнении оценки атрибутов будут определяться пол, возраст и очки.

  В ресурсе "ws handshake" доступны фильтры "glasses__gt" (нижний порог) и "glasses__lt" (верхний порог).

- Фильтр по "account_id" добавлен в параметры запросов большинства ресурсов с методами GET, которые возвращают в ответе несколько объектов.

  Использование данного фильтра позволяет получать данные (токены, лица, атрибуты и др.), принадлежащие конкретному аккаунту.

  Исключениями являются ресурс "get accounts", сервисные ресурсы ("get health", "get configs" и т. д.) и ресурс "ws handshake".

  Также параметр запроса "account_id" был добавлен в ресурсы "face matching" и "human body matching".

  Данные параметры запроса будут работать только в том случае, если для параметра "visibility_area" токена установлено значение "all". В противном случае будет возвращена ошибка.

- Добавлена возможность использования пользовательской SQL-функции для сравнения.

  Данная функция может быть полезна если нет возможности использовать С-расширения (C-extensions) базы данных PostgreSQL. Функция может понадобиться, например, для разворачивания LUNA PLATFORM 5 в AWS и использования Amazon Aurora PostgreSQL.

  См. подробное описание в главе "Alternative matching options" в файле комплекта поставки "luna_v.5.33.0/extras/VLMatch/postgres/readme.md".

- В контейнерах сервиса API и Licenses обновлена версия Python до 3.10.

- Обновлена база данных Redis до версии 7.0.5-alpine3.16.

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

- Исправлена ошибка, из-за которой в запросе на получение статистики по событиям (ресурс "/events/statistic") всегда передавался фильтр с текущим "account_id", из-за чего статистика выдавалась только по данным аккаунта пользователя, который выполнял запрос.

  Это приводило к тому, что пользователи с типом аккаунта "admin" и "advanced_used" не могли получать статистику по другим пользователям.

- Исправлена ошибка, из-за которой в запросе "get handlers" невозможно было получить одновременно и динамический и статический обработчики с помощью фильтра "is_dynamic". Теперь если не указывать данный фильтр, то будут возвращены обработчики обоих типов.

- Исправлена ошибка в запросе "detect face" спецификации API, где в теле ответа на запрос отображалось несуществующее поле "liveness".

- Исправлена ошибка, из-за которой при выполнении запроса к ресурсу "/3/attributes/{attribute_id}/samples" сервиса Faces не учитывался фильтр по "account_id".

- Исправлена ошибка, при которой в ответе на запрос "clear authorization" сервиса Admin возвращалась ошибка "Internal server error" при отсутствии куки.

  Теперь возвращается ошибка "Cookies for current session not found".

- Исправлено появление ошибки "Internal server error", возникавшее при загрузке изображения с цветовой схемой, которую не поддерживает SDK.

  Теперь если будет совершена попытка загрузить изображение с неподдерживаемой цветовой схемой, то будет возвращена корректная ошибка под номером 18003.

- Исправлена ошибка в сервисе Python Matcher с включенным кешем, при которой могли возникать непредвиденные ошибки в логах после изменения настроек в сервисе Configurator.

  Теперь при остановке сервиса обеспечивается закрытие открытых соединений и не появляются ошибки в логах.

- Исправлена ошибка фильтра по "account_id" в сервисе Python Matcher.

  Если в запросах "face matching" и "human body matching" с указанным фильтром "account_id" значение поля "account_id" события-эталона отличалось от значения поля "account_id" кандидатов, то выдавалось некорректное сообщение, что отфильтрован только кандидат. Теперь выдается корректное сообщение, что указанный эталон не найден.

- Исправлена ошибка в сервисе Python Matcher, которая возникала в запросах "face matching" и "human body matching" с Basic-авторизацией и пользователем типа "user" при указании идентификатора аккаунта в поле "candidates" > "filter" > "account_id", отличающегося от идентификатора по которому выполняется запрос.

  Теперь при попытке использовать чужой "account_id" в фильтрах при типе аккаунта "user", будет выдано корректное сообщение.

- Исправлена ошибка в запросе "upgrade attribute" сервиса Handlers, когда при ошибке обработки изображения (например, если вместо БО лица указать БО тела) возвращалось пустое поле, либо ошибка "Internal server error". Теперь при ошибках обработки изображения будет возвращаться корректная ошибка 11043.

# v.5.32.0

Изменения

- Добавлена возможность выполнять сравнение по биометрическим шаблонам тел при генерации события.

  Политика "match_policy" обработчика расширена новым фильтром "descriptor" > "descriptor_type", позволяющим явно указать по какому типу биометрического шаблона будет происходить сравнение — по БШ лица (значение "face") или по БШ тела (значение "body").

  Если выполняется сравнение по лицам, но тип биометрического шаблона указан как "body", то будет выдана ошибка.

  БШ лиц привязываются к объекту "face", а БШ тел привязываются к объекту "event". Если пользователем не был написан специальный плагин сравнения, то сравнение по событиям может занимать длительное время.

  Обратите внимание, что сравнение по телам не такое точное, как сравнение по лицам. При большом количестве событий-кандидатов, вероятность ложных определений лучших совпадений выше, чем при большом количестве лиц-кандидатов.

- Контейнеры сервисов теперь именуются одинаково при ручном запуске и при запуске с помощью Docker Compose.

  Например, раньше контейнер для сервиса Configurator создавался под именем `example-docker_configurator_1`, а теперь будет создаваться под именем `luna-configurator`.

- В контейнерах сервисов Faces, Image Store, Accounts, Tasks, Events, Configurator, Sender, Handlers, Backport3 и Backport4 обновлена версия Python до 3.10.

  В документации обновлены все команды, связанные с использованием Python внутри контейнеров, а именно, команды вида `python3.9` заменены на `python3`.

- В ресурс "healthcheck" сервиса Faces добавлен параметр "include_luna_services", с помощью которого можно включать и отключать проверку healthcheck для сервисов LUNA PLATFORM, от которых зависит данный сервис. Если опция включена, то отправляются дополнительные запросы на ресурсы "/healthcheck" этих сервисов.

- Добавлена поддержка нейросети 60 в сервисы Построения индекса и поиска по индексу.

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

- В тела ответов ресурсов "get tasks", "get task" и "get task result" спецификации OpenAPI добавлена отсутствующая информация о задаче "Additional extract".

  Как и раньше, задача "Additional extract" должна выполняться с помощью сервиса Admin.

- Параметр "tasks" > "content" > "filters" > "account_id" в телах ответа ресурсов "get tasks", "get task" для задачи "Garbage collection" теперь не является обязательным, поскольку "account_id" может отсутствовать если задача была запущена из сервиса Admin.

- Параметр "tasks" > "content" > "target" в телах ответа ресурсов "get tasks", "get task" для задачи "Garbage collection" расширен параметрами "event_descriptors" и "face_descriptors" для случаев удаления биометрических шаблонов лиц и тел по версии и типу.

- Из тел ответа ресурсов "get tasks", "get task" удален параметр "tasks" > "content" > "options" > descriptor_version" для типа задачи "Additional extract" для случая, когда в качестве извлечения использовались базовые атрибуты ("extraction_target" = "basic_attributes").

- В ресурсы "create account", "patch account", "create token", "replace token" и "verify credentials" спецификации OpenAPI добавлены отсутствующие заголовки "Content-Type".

- Исправлена ошибка, при которой сервис Image Store не запускался и не выдавал никаких логов если не указывалась схема URL-адреса хранилища S3. Теперь при подобной ошибке будет выданы соответствующие логи.

LUNA Index Module

Начиная с этой сборки для LUNA PLATFORM 5 доступен новый модуль LUNA Index Module (LIM), значительно ускоряющий сравнение большого количества биометрических шаблонов лиц. Модуль предварительно строит индексы по набору списков лиц и выполняет сравнение по ним. Пользователь либо сам указывает списки для обработки, либо выставляет автоматическую обработку всех существующих в LP списков.

LIM повторяет основной функционал ранее существовавших Сервисов формирования индекса и поиска по индексу, при этом его производительность выше. В отличие от старых сервисов, в LIM не требуется подключение через SSH за счет переработки механизма доставки индексов. На данный момент в LIM отсутствует функционал достроения индексов, доступный в существовавших ранее Сервисах формирования индекса и поиска по индексу, т.е. если лицо прикрепилось к списку уже после того, как индекс начал строиться, то оно не появится в результатах сравнения. Данный функционал находится в работе и будет доступен в ближайших релизах. Если данный функционал является критичным, то рекомендуется дождаться его выхода в ближайших релизах.

LIM поставляется в качестве отдельного дистрибутива, содержащего руководство администратора с информацией о новых сервисах и их работе, инструкции по установке (ручной и с помощью Docker Compose), спецификации OpenAPI и скрипты запуска. Более подробную информацию о комплекте поставке можно найти в документе "LIM_Quick_Start_Guide.pdf" из комплекта поставки LIM.

Для использования LIM требуется отдельный параметр в лицензионном ключе LUNA PLATFORM 5. Необходимо связаться с VisionLabs возможности добавления нового параметра для работы с LIM в существующий лицензионный ключ.

LIM работает со всеми версиями нейронных сетей извлечения биометрических шаблонов лиц.

Предыдущие сервисы Построения индекса и поиска по индексу остаются доступными до 2023 года, после чего будет прекращена поддержка и сервисы будут убраны из поставки.

Для дополнительной информации см. руководство администратора LIM в соответствующем комплекте поставки.

# v.5.31.0

Изменения

- SDK обновлен до версии 5.10.0.

- Добавлена поддержка 60 нейронной сети извлечения биометрических шаблонов лиц и 105, 106, 107 нейронных сетей извлечения биометрических шаблонов тел. По умолчанию используются версии 59 и 104.

  Нейросеть 60 не поддерживается при использовании сервисов для построения индекса и поиска по индексу.

  В целях уменьшения размера контейнера Handlers в ближайших сборках LP 5 из поставки будут удалены нейросети извлечения биометрических шаблонов лиц 54, 56, 57 и нейросети извлечения биометрических шаблонов тел 102, 103 и 104. Для их использования потребуется отдельно скачать необходимую нейросеть и поместить в контейнер сервиса Handlers. Данная процедура описана в разделе "Использование модели нейросети не из поставки" руководства администратора LP 5.

- Добавлена поддержка детектора HumanFace для одновременной детекции лица и тела в кадре.

  Детектор используется автоматически при выполнении запросов POST на ресурсы "/handlers/{handler_id}/events" и "/tasks/estimator", если в обработчике указаны обе опции "detect_face" и "detect_body". При этом значительно повышается скорость обработки изображений по сравнению с использованием отдельных детекторов.

  В связи с этим в сервисе Handlers обновлены названия полей в БД Influx, используемых при мониторинге:

  - detection_width -> face_detection_width (серия face_detection);
  - detection_height -> face_detection_height (серия face_detection);
  - detection_width -> body_detection_width (серия body_detection);
  - detection_height -> body_detection_height (серия body_detection).

- Сервис Accounts добавлен в инструмент визуализации данных мониторинга LUNA Dashboards.

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

- Исправлена ошибка, из-за которой сервис Handlers в некоторых случаях не возвращал соединение в пул соединений БД Postgres и мог выводить ошибку с кодом 10017 (Database connection timeout error) пока сервис не был перезапущен.

- Из скрипта миграции БО "migrate_4_to_5.py" удалена зависимость "logbook", отсутствие которой приводило к ошибке "ModuleNotFoundError: No module named ’logbook’".

- Исправлено отсутствие описания поля "remove_image_origins" в запросе "create gc task" в OpenAPI документации сервиса Admin.

- Исправлена ошибка, при которой в запросе на создание аккаунта к сервису Backport4 в теле ответа возвращалась неправильная версия API.

# v.5.30.0

Изменения

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

  Теперь для большинства запросов требуется обязательное наличие аккаунта, кроме запросов, не предполагающих авторизации.

  Все аккаунты, созданные с помощью сервиса Admin будут автоматически мигрированы. Для сохранения возможности работы с ранее созданными с помощью заголовка "Luna-Account-Id" данными нужно создать новый аккаунт, указав при создании использованный ранее "account_id". Для сервиса Backport 3 необходимо отдельно запустить скрипт миграции.

  См. подробное описание о новой системе авторизации и о миграции аккаунтов ниже или в разделе "Аккаунты, токены и способы авторизации" руководства администратора.

  Аккаунты

  Аккаунт необходим для разграничения областей видимости объектов для конкретного пользователя. Каждый созданный аккаунт имеет свой собственный уникальный идентификатор "account_id". Все данные аккаунтов сохраняются в БД сервиса Accounts под этим идентификатором.

  Аккаунт можно создать с помощью POST запроса "create account" к сервису API, либо с помощью запроса "register account" к сервису Admin, либо с помощью пользовательского интерфейса Admin. При создании аккаунта необходимо указать следующие данные: login (email), password и account type (тип аккаунта).

  Тип аккаунта определяет, какие данные доступны пользователю. Существует три типа аккаунтов:

  - user — тип аккаунта, с помощью которого можно создавать объекты и использовать только данные своего аккаунта.
  - advanced_user — тип аккаунта, для которого доступны права, аналогичные "user", а также есть доступ к данным всех аккаунтов. Доступ к данным других аккаунтов означает возможность получать данные (запросы GET), проверять их наличие (запросы HEAD) и выполнять запросы на сравнение по данным других аккаунтов.
  - admin — тип аккаунта, для которого доступны права, аналогичные "advanced_user", а также есть доступ к сервису Admin (см. "Сервис Admin" ниже)

  С помощью заголовка "Luna-Account-Id" в запросе "create account" можно задать желаемый идентификатор аккаунта. Также его необходимо использовать в случае, если необходимо сохранить возможность работы с данными, созданными в версиях LP до 5.30.0 (см. "Миграция аккаунтов с предыдущих сборок LP 5" ниже).

  Токены

  Токен привязывается к существующему аккаунту любого типа и позволяет наложить расширенные ограничения на выполняемые запросы. Например, при создании токена можно дать пользователю разрешение только на создание и изменение всех списков и лиц, или можно запретить использование определенных обработчиков, указав их идентификатор.

  Токен и все его разрешения сохраняются в БД и привязываются к аккаунту по параметру "account_id".

  При создании токена доступно задание следующих параметров:

  - expiration_time – время окончания действия токена в формате RFC 3339. Можно указать бесконечное время действия токена с помощью значения "null"
  - permissions – разрешения, которые доступны пользователю
  - visibility_area – видимость токеном данных других аккаунтов (см. раздел "Просмотр данных других аккаунтов" в руководстве администратора)

  См. список всех разрешений и подробную информацию по токенам в разделе "Разрешения, задаваемые в токене" руководства администратора.

  Типы авторизации для доступа к ресурсам

  В LUNA PLATFORM доступно три типа авторизации:

  - BasicAuth. Авторизация по логину и паролю (задаются во время создания аккаунта).
  - BearerAuth. Авторизация по JWT токену (выдается после создания токена).
  - LunaAccountIdAuth. Авторизация по заголовку "Luna-Account-Id", в котором указывается сгенерированный после создания аккаунта "account_id" (данный способ был принят за основной до версии 5.30.0).

  Авторизация LunaAccountIdAuth имеет наименьший приоритет по сравнению с другими способами и может быть отключена с помощью настройки "ALLOW_LUNA_ACCOUNT_AUTH_HEADER" в секции "OTHER" настроек сервиса API в Configurator (по умолчанию включена). В спецификации OpenAPI заголовок "Luna-Account-Id" помечен словом Deprecated.

  Сервис Admin

  Аккаунтом по-прежнему можно управлять с помощью сервиса Admin. Пользовательский интерфейс сервиса был обновлен. Теперь диалог создания аккаунта содержит расширенный набор полей.

  Старый аккаунт администратора преобразован в аккаунт с типом "admin". Логин по умолчанию теперь root@visionlabs.ai вместо root.

  При установке с нуля для сервиса Admin больше не создается БД. Теперь данные аккаунтов хранятся в БД Accounts (см. ниже "Миграция БД Admin").

  Миграция аккаунтов с предыдущих сборок LP 5

  Ранее аккаунт создавался с помощью ресурса "/accounts" сервиса Admin или пользовательского интерфейса сервиса Admin.

  Все аккаунты, созданные до текущей версии будут автоматически мигрированы при обновлении на актуальную версию. Аккаунту администратора будет присвоен тип "admin", а аккаунтам, создаваемым при запросе к ресурсу "/accounts" будет присвоен тип "advanced_user". В качестве логина и пароля будет использован почтовый адрес. Имя организации будет записано в поле "description".

  Также ранее можно было выполнять запросы к сервисам LP 5 с помощью указания идентификатора "account_id" в заголовке "Luna-Account-Id". Для того, чтобы сохранить возможность работы с данными, созданными ранее с помощью указания идентификатора "account_id" в заголовке "Luna-Account-Id", необходимо в запросе создания аккаунта "create account" указать "login", "password", "account_type" и старый идентификатор "account_id" в заголовке "Luna-Account-Id" запроса. Таким образом, старый "account_id" привяжется к создаваемому аккаунту.

  Миграция БД Admin

  Ранее данные об аккаунтах хранились в БД Admin.

  Если LP разворачивается впервые, то будет создана БД Accounts с которой взаимодействует сервис Accounts. Если LP обновляется с версии 5.28.0 и меньшей, то БД Admin будет преобразована для работы с аккаунтами, а сервис Admin больше не будет взаимодействовать с базой данных Admin.

  В руководство по обновлению LP 5 с предыдущей версии добавлен раздел "Преобразование БД Admin", а также раздел "Создание аккаунта с помощью сервиса API", где приведен пример CURL-запроса для создания нового аккаунта и миграции аккаунта, если его "account_id" использовался в заголовке "Luna-Account-Id" без создания аккаунта в сервисе Admin.

  Миграция аккаунтов с предыдущих версий Backport 3

  При обновлении с предыдущей версии Backport 3 для миграции аккаунтов нужно дополнительно запустить скрипт миграции после миграции базы данных Backport 3 (см. раздел "Миграция аккаунтов и токенов" в руководстве по обновлению LP 5 с предыдущей версии).

  Миграция аккаунтов с LP 3.3.8

  При обновлении с LUNA PLATFORM 3.3.8 миграция аккаунтов будет выполнена при запуске скрипта "start_migration.py" (см. раздел "Описание скрипта миграции" в руководстве по миграции с LUNA PLATFORM 3.3.8).

  Миграция аккаунтов с LP 4.5.4

  При обновлении с LUNA PLATFORM 4.5.4 миграция аккаунтов выполняется аналогично описанию из пунктов "Миграция аккаунтов с предыдущих сборок LP 5" и "Миграция БД Admin" выше. В руководство по миграции с LUNA PLATFORM 4.5.4 добавлен раздел "Преобразование БД Admin", а также раздел "Создание аккаунта с помощью сервиса API", где приведен пример CURL-запроса для создания нового аккаунта и миграции аккаунта, если его "account_id" использовался в заголовке "Luna-Account-Id" без создания аккаунта в сервисе Admin.

  Сервис Backport 4

  В API Backport 4 добавлена возможность авторизации по логину и паролю (BasicAuth) и по индентификатору аккаунта (LunaAccountIdAuth). Авторизация по токену (BearerAuth) невозможна.

  Для сервиса User Interface 4 теперь используется авторизация по логину и паролю (параметр "BASIC_AUTH" в .env-файле) вместо "account_id" (параметр "LUNA_ACCOUNT_ID" в .env-файле). Логин и пароль нужно указывать в формате login:password в Base64.

- Количество получаемых и удаляемых лиц, задач, обработчиков, событий и настроек LP, задаваемых в параметрах "page_size" различных ресурсов и сервисов, увеличено с 100 до 1000.

- Обновлена обработка входящих URL-адресов в запросе на создание задачи Estimator с ZIP-архивом в качестве источника изображений. Eсли в указанном URL-адресе содержится адрес сервиса API, заданный в новой настройке "EXTERNAL_LUNA_API_ADDRESS" в сервисе Configurator, объекты будут загружаться с помощью сервиса Image Store напрямую, а не отправлять запрос в сервис API с последующим перенаправлением в сервис Image Store.

- В настройки сервисов Handlers и Tasks добавлена новая секция "EXTERNAL_LUNA_API_ADDRESS", предназначенная для корректной обработки ссылок на объекты, созданные с помощью ресурсов "/images" и "/objects" в сервисе API. В данной секции задается адрес и версия API сервиса API.

  Если в качестве входных данных для ресурсов "/detector", "handlers/{handler_id}/events", "/iso", "/sdk" и "verifiers/{verifier_id}/verification" указывается URL-адрес и версия сервиса API объекта типа "images", совпадающие с адресом и версией API из секции "EXTERNAL_LUNA_API_ADDRESS" сервиса Handlers, то данные объекты будут загружаться с помощью сервиса Image Store напрямую, а не отправлять запрос в сервис API с последующим перенаправлением в сервис Image Store.

  Если параметре "content" > "source" > "reference" ресурса "/tasks/estimator" указывается URL-адрес и версия сервиса API до объекта типа "object" (ZIP-архив), совпадающие с адресом и версией API из секции "EXTERNAL_LUNA_API_ADDRESS" сервиса Tasks, то данный объект будет загружаться с помощью сервиса Image Store напрямую, а не отправлять запрос в сервис API с последующим перенаправлением в сервис Image Store.

  Пример формата: `http://10.15.3.144:5000/6/images/141d2706-8baf-433b-82eb-8c7fada847da`, где значение `http://10.15.3.144:5000` должно совпадать со значением из настройки "origin", а значение `6` должно совпадать со значением настройки `api_version` секции "EXTERNAL_LUNA_API_ADDRESS".

  Для избежания ошибок необходимо настроить данную секцию в настройках Handlers или Tasks перед использованием URL-адресов до объектов типа "objects" или "images" в качестве источника входных данных.

- Обновлены библиотеки вендора для HASP ключа и HASP утилита.

  Теперь вместо библиотек `haspvlib_x86_64_111186.so` и `haspvlib_111186.so` используются библиотеки `haspvlib_x86_64_30147.so` и `haspvlib_30147.so`, а вместо HASP утилиты `aksusbd-8.23-1.x86_64.rpm` используется утилита `aksusbd-8.43-1.x86_64.rpm`.

  При обновлении на новую сборку LP требуется удалить старые библиотеки и утилиту HASP и установить новые. Сервис Licenses не запустится, если использована утилита и библиотеки предыдущих версий.

  Требуется обратиться в техническую поддержку для перевыпуска ключа LUNA PLATFORM 5.

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

- Исправлена ошибка, при которой на запрос к ресурсу "4/healthcheck" возвращалась ошибка "Internal server error" при отключенном сервисе Tasks в секции ADDITIONAL_SERVICES_USAGE сервиса Configurator.

- Исправлена ошибка, при которой на запрос к ресурсу "/luna_sys_info" возвращалась ошибка "Internal server error", если в лицензионном файле отсутствовала функция выполнения проверок изображений на соответствие стандартам в ресурсах "/iso", "/detector", "/handlers" и "/verifiers".

- Исправлена ошибка в спецификации OpenAPI, при которой в схемах ответа на запросы "get task result" и "generate events" отображался тип `Nullable` для некоторых порогов "face_quality".

# v.5.28.0

Изменения

- SDK обновлен до версии 5.9.0. Основные изменения SDK, затрагивающие LUNA PLATFORM 5:

  - Обновлен Liveness V2
  - Обновлен детектор лиц FaceDetV3

  Значение по умолчанию настройки "score_threshold" в секции "FACE_DETECTOR_V3" сервиса Configurator изменено с 0.89 до 0.42. Миграция настроек автоматически обновит это значение (см. раздел "Миграция базы данных Configurator" в руководстве по обновлению). Проверьте логику распознавания лиц, если вы используете значение "score_threshold", отличное от значения по умолчанию.

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

- Исправлена ошибка, при которой игнорировался порог "real_threshold" при проверках Liveness в ресурсах "/liveness" и "/sdk". Ошибка могла приводить к неожиданному поведению системы при оценке Liveness.

# v.5.27.0

Изменения

- В ресурс "/detector" добавлен новый параметр запроса "estimate_face_quality", позволяющий выполнить все проверки "face_quality" из ресурсов "/handlers" и "/verifiers" с порогами по умолчанию.

  Проверки в данном ресурсе можно выполнять с помощью соответствующей лицензируемой функции.

- В группу проверок "face_quality" ресурсов "/handlers" и "/verifiers" и в ресурсы "/iso" и "/detector" добавлены новые проверки — "background_lightness" и "background_uniformity".

  Проверка "background_lightness" позволяет определить осветлённость фона от 0 до 1, где:

  - [0...0.1] — черный фон
  - [0.1...0.3] — темный фон
  - [0.3...0.97] — светлый фон
  - [0.97...1] — белый фон

  Проверка "background_unformity" позволяет определить степень однородности фона от 0 до 1, где 0 — фон неоднородный, 1 — фон однородный.

  Новые проверки также добавлены в поле "face_quality" структуры события в ресурсе "ws handshake".

  Для использования данных проверок требуется соответствующая лицензируемая функция.

- Появилась возможность изменить порог "quality_threshold" для Liveness V2, заданный в системе по умолчанию. Для этого используется соответствующая настройка в секции "LUNA_HANDLERS_LIVENESS_SETTINGS" сервиса Configurator. Ранее этот порог невозможно было изменить для ресурсов "/sdk" и "/liveness".

  Значение порога по умолчанию — 0.5.

  Ранее данный порог находился в настройке "config.py" сервиса Handlers и имел название "LIVENESS_V2_QUALITY_THRESHOLD".

  При использовании ресурсов "/handlers" или "/verifiers" значение порога из Configurator будет переопределено соответствующей настройкой в параметре запроса.

- В тело запроса на получение статистики по событиям ("/events/statistic") добавлена возможность указания атрибутов тел в поля "filters" и "targets".

- Расширен мониторинг сервиса Handlers. Теперь кроме трекинга запросов (Requests series), запросов, выполненных с ошибкой (Errors series), количества выполненных оценок SDK (Usages_statistic series) и лицензирования (Licensing series) фиксируются данные о каждой выполненной оценке SDK.

  Например, для каждой оценки наличия маски на лице фиксируется время выполнения этой оценки в секундах.

  См. подробную информацию и перечень оценок по которым собираются данные в разделе "Monitoring" руководства разработчика сервиса Handlers.

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

- Исправлена ошибка, из-за которой URL-адреса БО лиц и атрибутов возвращались в неправильном формате при запросе к ресурсу "perform verification".

- В спецификации OpenAPI исправлена схема ответа поля "stats" в теле ответа на запрос "get statistics on events".

  Ранее было указано, что в качестве значений для поля "stats" могут возвращаться массивы из типов "string", "number", "integer", "boolean", "Array of any" и "object". Теперь для поля "stats" указано, что может возвращаться непустой массив, содержащий массивы из типов "integer", "number" и "string".

- Исправлено появление ошибки "internal server error", возникавшей при обработке изображений, у которых в полях координат EXIF данных содержалось значение NaN.

# v.5.26.0

Изменения

- SDK обновлен до версии 5.8.0.

- Обновлена оценка определения состояния масок. Помимо трёх основных статусов теперь определяются следующие дополнительные свойства:

  - "correct" — маска присутствует на лице, рот и нос закрыты маской
  - "mouth" — маска присутствует на лице и закрывает только рот
  - "clear" — на лице нет маски
  - "chin" — маска присутствует на лице и находится под подбородком, не перекрывая зону от глаз до рта
  - "partially" — лицо частично перекрыто, но не медицинской маской и не маской с полным перекрытием лица
  - "full" — маска присутствует на лице, при которой полностью закрыто лицо, например, балаклава/лыжная маска

  Каждому основному статусу маски соответствует одно из двух свойств. Наиболее вероятное свойство возвращается в поле "predominant_occlusion":

  - статусу "medical_mask" соответствует свойство "correct" или "mouth"
  - статусу "missing" соответствует свойство "clear" или "chin"
  - статусу "occluded" соответствует свойство "partially" или "full"

  Для каждого из свойств возвращается вероятностная оценка в диапазоне [0..1].

  Дополнительные свойства маски не записываются в БД и по ним не выполняется фильтрация.

  Обратите внимание, что наличие маски на подбородке с этой версии относится к состоянию "missing". В предыдущих версиях оно относилось к состоянию "medical_mask".

  Дополнительные свойства возвращаются при оценке состояний маски в ресурсах "sdk" и "detect faces", а также при создании событий (запросы "save event" и "generate events") и выполнении верификации (запрос "perform verification"). Дополнительные свойства маски также учитываются при отправке событий через веб-сокеты (запрос "ws handshake")

  Пример определения обновленного состояния маски в ресурсе "/sdk":

      "mask": {
          "predominant_mask": "occluded",
          "estimations": {},
          "face_occlusion": {
              "predominant_occlusion": "correct",
              "estimations": {
                  "full": 0.019,
                  "clear": 0.02,
                  "correct": 0.6108324766,
                  "partially": 0.31,
                  "mouth": 0.0209,
                  "chin": 0.019097
              }
          }
      },

- В структуру отчета в формате CSV (см. задачи "Reporter" и "Exporter") добавлены колонки атрибутов тел "apparent_gender", "apparent_age", "headwear_state", "sleeve_length", "upper_clothing_colors" и "backpack_state".

- Для параметров "num_threads" из настроек "LUNA_HANDLERS_HUMAN_EXTRACTOR_RUNTIME_SETTINGS", "LUNA_HANDLERS_WARP_ESTIMATOR_RUNTIME_SETTINGS", "LUNA_HANDLERS_EXTRACTOR_RUNTIME_SETTINGS", "LUNA_HANDLERS_DETECTOR_RUNTIME_SETTINGS" и "LUNA_HANDLERS_HUMAN_DETECTOR_RUNTIME_SETTINGS" изменено значение по умолчанию с 4 до 6. Данное изменение повышает производительность по умолчанию для серверов с большим количеством ядер CPU.

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

- Исправлена ошибка, при которой в задачах можно было задать пустые значения для фильтров `handler_ids`, `masks`, `face_ids` и др., что приводило к фильтрации по всем соответствующим объектам.

- Исправлено отсутствие ошибки при вводе неправильного логина/пароля в пользовательском интерфейсе сервиса Admin.

- Теперь при отсутствии лицензируемой функции, в логах сервиса Licenses явно прописывается название отсутствующей функции.

# v.5.25.0

Изменения

- В ресурс "sdk" и политику "detect_policy" ресурса "/handlers" добавлена возможность определения атрибутов тел (см. дополнительную информацию об атрибутах тела в документации SDK).

  Доступно определение следующих атрибутов:

  - пол (мужской, женский, неизвестно) и возраст по изображению тела. Определение пола и возраста таким способом является менее точным, чем по лицу.
  - наличие головного убора, тип рукавов (длинные рукава, короткие рукава, неизвестно), цвет верхней одежды (чёрный, синий, зеленый, серый, оранжевый, фиолетовый, красный, белый, желтый, неизвестно). В будущих обновлениях будут добавлены следующие цвета: коричневый, розовый, хаки, бежевый, разноцветный.
  - наличие рюкзака.

  Для использования нового функционала требуется отдельная лицензия. Получить информацию о статусе лицензии можно запросом к ресурсу "/luna_sys_info" (поле "license_info" > "body_attributes").

  Новые атрибуты тел добавлены в структуру событий (см. "detections" > "samples" > "body" > "detection" > "attributes").

  Пример определения атрибутов тел в сгенерированном событии, с включенными параметрами "estimate_upper_body", "estimate_accessories" и "estimate_basic_attributes" в обработчике:

      "attributes": {
          "basic_attributes": {
              "apparent_age": 25,
              "apparent_gender": 0
          },
          "upper_body": {
              "headwear": {
                  "state": 0
              },
              "sleeve": {
                  "length": "short"
              },
              "upper_clothing": {
                  "colors": [
                      "white",
                      "black"
                  ]
              }
          },
          "accessories": {
              "backpack": {
                  "state": 0
              }
          }
      }

  В политику "match_policy" ресурса "/handlers" и в ресурс "human body matching" добавлены фильтры атрибутов тел "apparent_gender", "apparent_age__gte", "apparent_age__lt", "headwear_states", "sleeve_lengths", "upper_clothing_colors" и "backpack_states", указываемые при использовании событий в качестве кандидатов. Также добавлена возможность задать атрибуты тела в качестве значений для поля "targets".

  Фильтры атрибутов тел также могут быть использованы при отправке событий через веб-сокеты (см. ресурс "ws handshake").

  Соответствующие фильтры для событий добавлены в задачи Cross-matching, Clustering, Reporter, Exporter и Linker.

  Поддержана возможность указания атрибутов тел при создании нового обработчика в задаче Estimator.

  Для атрибутов тел доступна возможность агрегации при генерации/сохранении событий и выполнении оценки в ресурсе "sdk". Агрегированные значения атрибутов отображаются в полях "aggregate_estimations" соответствующих ресурсов.

- Теперь для проверки состояния запущенного контейнера сервиса при старте с помощью start_platform.sh выполняется запрос на ресурс "/healthcheck".

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

- Исправлена проверка событий, генерируемых запросом "save event". Если в событии были заданы проверки из группы параметров "face_quality", то событие могло быть отправлено в сервис Sender в неправильном формате.

- Исправлена ошибка, при которой можно было задать непустые значения для фильтров `emotions`, `masks` и `liveness` при указании событий в качестве кандидатов в политике "match_policy" ресурса "/handlers".

- Исправлено падение скрипта start_platform.sh при изменении значения переменной "DATA" в .env файле.

# v.5.24.2

Изменения

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

- Настройка "reference_limit" сервиса Python Matcher теперь учитывается при сравнении с кандидатами типа "event_external_id". Игнорирование данной настройки приводило к ошибке "Database connection timeout error", возникавшая при сравнении большого количества лиц с одинаковым "external_id".

- Исправлено логирование в сервисе LUNA Handlers, связанное с инициализацией, эстимированием и другими событиями.

- Исправлено логирование модуля MatcherLib сервиса Python Matcher. Ранее логи не записывались на уровне INFO.

  Также при включенном Cached Matcher, модуль MatcherLib сохранял логи в директорию "/tmp" и данное поведение не отключалось с помощью настройки "LUNA_PYTHON_MATCHER_LOGGER.LOG_TO_FIE=false".

- Исправлена работа модуля MatcherLib сервиса Python Matcher с 52 версией нейронной сети.

# v.5.24.1

Изменения

- В тела ответов запросов, выполненных с ошибкой, добавлено поле "link", содержащее ссылку на онлайн-документацию с подробным описанием полученной ошибки. Ссылки на описания ошибок также добавлены в примеры ответов в документации OpenAPI (поле "Response samples").

  Для перехода по ссылкам необходимо подключение к сети Интернет.

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

- Удалено сообщение `sanic.error: <ApiRequest: OPTIONS /6/objects> body not consumed` из логов сервиса LUNA API. Сообщение выводилось если в запросе OPTIONS `/6/objects` было непустое тело.

- Обработка пустых ZIP-архивов и директорий из S3-подобных хранилищ с помощью задачи "Estimator" больше не возвращает никаких ошибок. Ранее при таких обработках возвращалась ошибка "Unsupported media type".

- Исправлена ошибка при сохранении события со значением поля "detect_ts=0". При попытке получить событие с таким значением, возращалось значение "detect_ts=null".

- Исправлена ошибка, при которой обновление ограничения или настройки с пустой строкой в поле "description" в сервисе Configurator приводило к выставлению значения "null" в поле "description". Ошибка возникала при использовании базы данных Oracle.

- Исправлена ошибка "Internal server error", возникавшая при сохранении события (запрос "save event") со значением "predominant_mask": "medical_mask".

- Исправлена ошибка, при которой все эстиматоры (DETECTOR, EXTRACTOR, WARP, HUMAN_EXTRACTOR, HUMAN_DETECTOR) использовали значения параметра device_class ("gpu" или "cpu") из настройки "LUNA_HANDLERS_DETECTOR_RUNTIME_SETTINGS", игнорируя остальные соответствующие эстиматорам настройки, что приводило к запуску всех эстиматоров только на GPU или только на CPU.

  Известная проблема: Настройки `num_threads` и `num_compute_streams` по-прежнему определяются для всех эстиматоров в секции "LUNA_HANDLERS_DETECTOR_RUNTIME_SETTINGS". Соответствующие настройки в остальных секциях игнорируются.

# v.5.24.0

Изменения

- В задачу Estimator (ресурс "/tasks/estimator") добавлена поддержка FTP-сервера в качестве источника изображений (параметр "source_type").

  Для такого типа источника в теле запроса доступно задание следующих параметров для соединения с FTP-сервером:

  - Параметр "host" — IP-адрес или имя хоста FTP-сервера (обязательное поле);
  - Параметр "port" — порт FTP-сервера;
  - Параметр "max_sessions" — максимальное количество разрешенных сеансов на FTP-сервере;
  - Параметры "user" и "password" — параметры авторизации (обязательные поля).

  Как и в задачах Estimator с использованием S3-подобного хранилища или сетевого диска в качестве источников изображений, доступна возможность задания пути до директории с изображениями, рекурсивного получения изображений из вложенных директорий, выбора типа передаваемых изображений, а также указания префикса и постфикса.

  Для получения корректных результатов обработки изображений с помощью задачи Estimator все обрабатываемые изображения должны быть либо в исходном формате, либо в формате биометрических образцов.

  См. соответствующие примеры и дополнительную информацию в спецификации OpenAPI.

- Для событий добавлен новый параметр "detect_ts", позволяющий хранить временную метку (timestamp) относительно чего-либо, например, относительно начала видеофайла (см. тело ответа запроса generate events).

  Значение параметра "detect_ts" также задать вручную с помощью запроса "save event".

- Значительно снижено потребление памяти для задач Clustering, ROC-curve calculating и Cross-matching, а также для сервисов Python Matсher и Image Store.

  Также для увеличения производительности работы в ресурсах "cross matching faces" и "cross matching bodies" сервиса Python Matcher заменен Content-Type тела ответа с `application/json` на `application/msgpack`.

- В ресурсы "cross matching faces" и "cross matching bodies" сервиса Python Matcher добавлен новый параметр запроса "sorting", позволяющий отключить сортировку результатов сравнения в лексикографическом порядке.

- Прекращена поддержка БД Vertica для сервиса Events. Настройки смены БД на Vertica удалены из настроек сервиса Configurator, а также удалена соответствующая информация из документации.

- Добавлена проверка наличия инструкций avx2 на процессоре при старте контейнеров с помощью скрипта Docker Compose. Если процессор не имеет поддержки avx2, то при старте контейнеров будет выдана ошибка `avx2 not supported`.

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

- Исправлена ошибка, при которой для некоторых параметров запроса с типом "number" обрабатывались только вещественные числа. При вводе целых чисел возникала ошибка `Failed to validate input json`.

# v.5.23.1

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

- Исправлена ошибка, из-за которой при выполнении некоторых оценок с использованием 8-битных png изображений выдавались некорректные результаты.

  Актуально для следующих ресурсов:

  - detect faces
  - iso resource
  - generate events
  - perform verification
  - sdk

- Исправлена ошибка в сервисе Python Matcher. Сервис не перезагружался после ввода некорректных параметров в настройки сервиса Configurator, если тип базы данных `oracle` был указан как `db_type` в разделе "LUNA_FACES_DB".

- Исправлена ошибка в примере плагина "Thin Event", приводившая к двойной инициализации плагина.

- Теперь сервис Handlers не проверяет соединение с сервисом Events, если второй отключен в настройке "ADDITIONAL_SERVICES_USAGE" в сервисе Configurator.

# v.5.23.0

Изменения

- В задачу Estimator (ресурс "/tasks/estimator") добавлена поддержка сетевого диска в качестве источника изображений (параметр "source_type").

  Для такого типа источника в теле запроса доступно задание следующих параметров:

  - Параметр "path" — абсолютный путь к директории с изображениями в контейнере (обязательное поле);
  - Параметр "follow_links" — включение/выключение обработки символических ссылок (symlink);
  - Параметр "prefix" — префикс ключа файла. Может использоваться для загрузки изображений из определенной директории;
  - Параметр "postfix" — постфикс ключа файла. Может использоваться для загрузки изображений с определенным расширением.

  См. пример использования префиксов и постфиксов в описании ресурса "/tasks/estimator".

  При использовании такого типа источника и запуске сервисов Tasks и Tasks Worker через Docker-контейнеры необходимо смонтировать директорию с изображениями с сетевого диска в локальную директорию и синхронизировать её с указанной директорией в контейнере. Смонтировать директорию с сетевого диска можно любым удобным способом. После этого можно синхронизировать смонтированную директорию с директорией в контейнере с помощью следующей команды при запуске сервисов Tasks и Tasks Worker:

      docker run \
      ...
      -v /var/lib/luna/current/images:/srv/images
      ...

  /var/lib/luna/current/images — путь к предварительно смонтированной директории с изображениями с сетевого диска.

  /srv/images — путь к директории с изображениями в контейнере, куда они будут перенесены с сетевого диска. Этот путь должен быть указан в теле запроса задачи Estimator (параметр "path").

  Как и в задаче Estimator с использованием S3-подобного хранилища в качестве источника изображений, доступна возможность рекурсивного получения изображений из вложенных директорий бакета (параметр "recursive") и выбора типа передаваемых изображений (параметр "image_type"). Для получения корректных результатов обработки нужно использовать однотипные изображения (исходное изображение, биометрический образец лица/тела).

  См. соответствующие примеры и дополнительную информацию в спецификации OpenAPI.

- В группу проверок "face_quality" ресурсов "/handlers" и "/verifiers" сервисов API и Handlers добавлены две новые проверки изображения на соответствие стандарту ICAO — "illumination_uniformity" и "dynamic_range".

  Проверка "illumination_uniformity" позволяет проверить равномерность освещения лица на изображении. В соответствии со стандартом ICAO рекомендуется использовать цветные изображения. При использовании черно-белых изображений результаты могут быть неожиданными. Рекомендуется использовать эту проверку при необходимости получения результатов, соответствующих стандарту ICAO. В остальных случаях можно использовать алгоритм VisionLabs для проверки равномерности освещения лица на изображении (проверка "illumination_quality").

  Проверка "dynamic_range" позволяет проверить динамический диапазон тона кожи лица.

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

  См. подробное описание проверок в главе "Параметры лиц и изображений" в руководстве администратора.

- Обновлены пороги по умолчанию (рекомендуемые) для следующих проверок в группе проверок "face_quality" и ресурсе "/iso":

  Наименование проверки | Старые значения порогов | Новые значения порогов
  --- | --- | ---
  mouth_occluded | min=0, max=0.3 | min=0, max=0.5
  mouth_open | min=0, max=0.64 | min=0, max=0.5

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

- Ускорено выполнение запросов на сравнение тел, когда в качестве эталона указано событие.

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

- Исправлена ошибка, при которой в теле ответа результата задачи Estimator в поле "filename" группы "detections" возвращалось значение "raw image" вместо имени файла.

# v.5.22.0

Изменения

- SDK обновлен до версии 5.6.0.

- В политику "detect_policy" ресурсов "/handlers" и "/verifiers" сервисов API и Handlers добавлена группа проверок "face_quality", позволяющая настраивать проверку входящих изображений и лиц на этих изображениях в соответствии с предварительно заданными условиями. С помощью "face_quality" возможно проверять изображения лиц на соответствие требованиям стандарта ISO/IEC 19794-5:2011 или схожих.

  Доступные проверки

  Доступны следующие проверки лиц и изображений:

  - Положение головы: "head_yaw", "head_pitch", "head_roll"
  - Направление взгляда: "gaze_yaw", "gaze_pitch"
  - Наличие улыбки: "mouth_smiling"
  - Наличие перекрытого рта: "mouth_occluded"
  - Наличие открытого рта: "mouth_open"
  - Тип улыбки, который определяется при наличии улыбки (нет улыбки, улыбка с закрытым ртом, улыбка с открытым ртом): "smile_properties"
  - Статус глаз для каждого глаза (открыты, закрыты, перекрыты): "left_eye", "right_eye"
  - Наличие эффекта красных глаз: "red_eyes"
  - Расстояние между центрами глаз: "eye_distance"
  - Статус бровей (нейтральный, подняты, опущены, нахмурены): "eyebrows_state"
  - Естественность освещения: "natural_light"
  - Наличие бочкообразной дисторсии (эффект Fisheye): "radial_distortion"
  - Отсутствие бликов: "specularity_quality"
  - Размытость: "blurriness_quality"
  - Контраст и насыщенность (недостаточная или слишком большая экспозиция): "dark_quality", "light_quality"
  - Тип цвета по лицу (цветное, черно-белое, инфракрасное (ближний инфракрасный диапазон)): "face_color_type"
  - Положение центральной точки лица на фотоизображении по горизонтали и вертикали: "head_horizontal_center", "head_vertical_center"
  - Вертикальный и горизонтальный размер головы относительно размера фотоизображения: "head_width", "head_height"
  - Ширина и высота лица: "face_width", "face_height"
  - Отступы лица от краёв фото: "indent_upper", "intent_lower", "intent_left", "intent_right"
  - Размер изображения в байтах: "image_size"
  - Ширина и высота изображения: "image_width", "image_height"
  - Соотношение сторон изображения: "aspect_ratio"
  - Формат изображения (JPG, JPG2000, PNG): "image_format"
  - Наличие и тип головного убора (нет, кепка, шапка, фуражка, шарф, ушанка, шлем/каска, капюшон, шляпа, другое): "headwear_type"

  Описание каждой из проверок приведено в главе "Параметры лиц и изображений" в руководстве администратора.

  Включение проверок face_quality

  Проверки выполняются для каждой детекции лица, найденного на фото. Результаты перечисленных выше проверок не агрегируются. Можно включать и отключать обработку изображений с несколькими лицами с помощью опции "multiface_policy".

  Для включения проверок необходимо указать значение "1" в поле "estimate" для "face_quality". По умолчанию проверка изображений отключена.

  Для включения фильтрации по результатам проверок необходимо указать значение "1" в поле "filter". При провале одной или более проверок для детекции лица дальнейшие политики для данной детекции выполнены не будут. При этом результаты, полученные в соответствии с политикой "detect_policy" для данной детекции, будут возвращены в ответе.

  Параметры группы проверок "face_quality":

      "face_quality": {
          "estimate": 0,
          "filter": 0,
          "checks": {}
          }

  Выполняемые проверки и их параметры перечислены в группе "checks".

  Каждую из проверок можно включать или отключать. Это позволяет задать набор проверок, необходимых для конкретного сценария.

  Для отключения проверки требуется выставить "estimate": 0 для конкретной проверки. По умолчанию все проверки включены и будут выполнены при включении "face_quality".

  В зависимости от типа проверки пользователь может указать минимальное и максимальное значения порога или допустимые значения для этой проверки. Для этого используется поле "threshold".

  Пример задания параметров проверок:

      "checks": {
          "image_format": {
              "estimate": 1,
              "threshold": [
                  "JPEG",
                  "JPEG2000",
                  "PNG"
              ]
          },
          "illumination_quality": {
              "estimate": 1,
              "threshold": {
                  "min": 0.3,
                  "max": 0.9
          }},
      }

  Возвращаемый ответ

  Название проверки ("name"), определённое значение ("object_value"), заданные значения порогов/допустимые значения ("threshold_value") и итоговый вердикт ("result") выводятся в ответе на запрос \«/handlers/{handler_id}/events\» в "events" > "detection" > "samples" > "face" > "detection" > "face_quality".

  По результатам всех проверок выводится общий вердикт (поле "status"), который равен "1" при успешном прохождении всех проверок и равен "0" при провале хотя бы одной проверки.

  Результаты проверок не сохраняются в БД, они возвращаются только в ответе.

  Пример ответа системы для двух проверок:

      "face_quality": {
          "status": 1,
          "checks": [
              {
                  "name": "image_format",
                  "object_value": "PNG",
                  "threshold_value": [
                      "JPEG",
                      "JPEG2000",
                      "PNG"
                  ],
                  "result": 1
              },
              {
                  "name": "illumination_quality",
                  "object_value": 0.5182177424430847,
                  "threshold_value": {
                      "min": 0.3,
                      "max": 1.0
                  },
                  "result": 1
              }]

  Лицензирование

  Данный функционал лицензируется отдельно, в ключе должна быть прописана опция ISO estimation. Для группы параметров "face_quality" и ресурса "/iso" используется одна и та же лицензия.

  Если в лицензии отсутствует опция ISO estimation, то при "face_quality" > "estimate": 1 вернётся ошибка "License problem: 'ISO license feature is disabled.'".

  Отличие проверок для "face_quality" и ресурса "/iso"

  Набор проверок для "face_quality" и ресурса "/iso" отличается. См. раздел "Проверка изображений" в руководстве администратора. В главе приведена таблица сравнения доступных проверок.

- В ресурс "/iso" добавлены следующие новые проверки:

  - Статус бровей ("eyebrows_state")
  - Наличие головного убора ("headwear_type")
  - Тип улыбки, который определяется при наличии улыбки ("smile_properties")
  - Проверка естественного освещения ("natural_light")
  - Наличие бочкообразной дисторсии (эффект Fisheye) ("radial_distortion")
  - Наличие эффекта красных глаз ("red_eyes")
  - Тип цвета по лицу ("face_color_type")

  Данные проверки проводятся в соответствии со значениями порогов по умолчанию, заданными в системе. Если требуется изменить порог или отключить проверку, необходимо воспользоваться группой проверок "face_quality" в ресурсах "/handlers" и "/verifiers".

  Описание каждой из проверок приведено в главе "Параметры лиц и изображений" в руководстве администратора.

- Обновился внутренний механизм эстимаций для сервиса Handlers, что значительно сократило потребление ресурсов (CPU, GPU, RAM) для выполнения вычислений. Теперь можно запускать больше экземпляров сервиса Handlers или увеличить количество "рабочих процессов" для одного экземпляра на тех же мощностях, что приводит к ускорению выполнения запросов.

  В некоторых случаях данное изменение может приводить к снижению производительности при старой конфигурации Handlers. В таком случае требуется увеличить количество экземпляров или "рабочих процессов" Handlers для повышения производительности.

- Было ускорено сравнение по большому списку (более 100 000 лиц) при большом количестве одновременно выполняемых запросов. Скорость выполнения таких запросов в некоторых случаях увеличена до двух раз.

- В примерах спецификации OpenAPI, поле "exif" расширено информацией об ориентации для всех ресурсов, поддерживающих извлечение exif.

# v.5.21.0

Изменения

- SDK обновлен до версии 5.5.1.

- В задачу пакетной обработки "/tasks/estimator" добавлена поддержка S3-подобного хранилища в качестве источника изображений (параметр "source_type").

  Для такого типа источника доступно задание следующих параметров:

  - Имя бакета/Access Point ARN/Outpost ARN (обязательное поле);
  - Endpoint (только при указании имени бакета);
  - Bucket region (только при указании имени бакета);
  - Префикс ключа файла. Также может использоваться для загрузки изображений из определенной директории, например, "2022/January".

  Для настройки авторизации предназначены следующие параметры:

  - Public access key (обязательное поле);
  - Secret access key (обязательное поле);
  - Signature version ("s3v2"/"s3v4").

  Также доступна возможность рекурсивного получения изображений из вложенных директорий бакета (параметр "recursive") и сохранения исходных изображений (параметр "save_origin").

  См. соответствующие примеры и дополнительную информацию в спецификации OpenAPI.

- Улучшена производительность обработки лиц в задаче прикрепления лица к списку.

  Ранее сервис Tasks запрашивал у сервиса Faces полный набор целевых полей, что уменьшало производительность обработки лиц. Теперь сервис запрашивает только необходимое ему целевое поле "face_id".

- Увеличено количество подключений к БД LUNA Admin по умолчанию с 1 до 5 (настройка "connection_pool_size", секция "LUNA_ADMIN_DB" в сервисе Configurator).

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

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

- Исправлена ошибка подключения к базам данных сервисов, при которой в некоторых сценариях работы подключения не возвращались в пул подключений, что приводило к возвращению кода состояния 500 и ошибке 10017 (превышен лимит времени подключения к базе данных).

# v.5.20.0

Изменения

- В задачу сборки мусора (garbage collection task) добавлена возможность удаления исходных изображений, связанных с событием. Для этого используется параметр "remove_image_origins", который задаётся в теле запроса.

  Опция добавлена в следующие ресурсы:

  - "/tasks/gc" сервиса API.
  - "/tasks/gc" сервиса Admin.
  - "/tasks/gc" сервиса Tasks.

  Возможность удаления исходных изображений также добавлена в пользовательский интерфейс сервиса Admin: "Tasks" > "Garbage Collecting tasks" > "start descriptors gc" > "Remove image origins".

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

- В ответе на запрос "delete events" сервиса Events теперь может возвращаться поле "image_origins", содержащее URL всех исходных изображений, связанных с удаляемым событием. Эти URL могут быть использованы для последующего удаления исходных изображений.

  В ресурс добавлен параметр запроса "tagret". В нём можно указать следующие целевые поля:

  - "face_samples".
  - "body_samples".
  - "image_origins".

  В зависимости от указанных целевых полей после удаления события в ответе вернётся информация о связанных с этим событием объектах: ID биометрических образцов лиц/тел, URL исходных изображений.

  По умолчанию в теле ответа отображается информация обо всех связанных с событием объектах: "face_samples", "body_samples" и "image_origins".

  Если оставить поле "tagret" пустым, то вернётся только "event_id" удаляемого события.

- Для ресурсов "face matching" и "human body matching" добавлены новые типы эталонов:

  - "event_track_id" позволяет выполнить сравнение с каждым событием, содержащим указанный "track_id".
  - "external_event_id" позволяет выполнить сравнение с каждым событием, содержащим указанный "external_id".

  Использование данных типов позволяет выполнять поиск сразу по нескольким событиям, связанным с одним телом или лицом, чтобы снизить влияние условий съёмки (освещения, расположения относительно камеры и т. д.) на точность распознавания.

  Для каждого события, которое используется в качестве эталона, в ответе возвращается "event_id".

- В руководство администратора добавлен раздел "Продвинутая настройка PostrgeSQL" с информацией о конфигурации PostrgeSQL для работы с LUNA PLATFORM.

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

- В сервисе Events исправлена ошибка, при которой в запросе "create new events" неправильно обрабатывались специальные символы, введенные в полях "label" ("matches" > "label") и "external_id" ("matches" > "candidates" > "face"/"event" > "external_id").

- Исправлена ошибка агрегирования результатов оценки Liveness V2 для ресурса "/liveness". При отправке в ресурс одного фотоизображения низкого качества, для которого система возвращала "prediction" = 2, в агрегированных результатах для того же фотоизображения возвращалось иное значение "prediction".

# v.5.19.0

Изменения

- Максимальный размер архива, передаваемого в задачу пакетной обработки "/tasks/estimator", был увеличен с 1 Гб до 100 Гб. Не рекомендуется передавать архивы большего размера, так как это может повлиять на производительность системы.

- В сервисе Faces ускорено выполнение запросов получения лиц (ресурс "/faces") и получения количества лиц (ресурс "/faces/count") при фильтрации по списку.

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

- Исправлена ошибка, когда при отключённой функции Liveness в логах сервиса Handlers выводилось сообщение, что количество транзакций Liveness является безлимитным.

# v.5.18.0

- В сервисы API и Handlers добавлен новый ресурс "/iso". Ресурс выполняет оценку фотоизображения лица на соответствование требованиям стандарта ISO/IEC 19794-5.

  В ответе ресурса возвращается вердикт по каждой проверке (1 — фотоизображение соответствует стандарту, 0 — полученное значение не соответствует стандарту) и общий вердикт на основании всех выполненных проверок. Общий вердикт равен 1, если фотоизображение успешно прошло все проверки.

  Для каждой проверки возвращается полученное значение и порог/значение с которым выполняется сравнение. Пороги заданы в системе в соответствием с требованиями стандарта ISO/IEC 19794-5 и не изменяются пользователем.

  Пример:

      {
       "name": "head_roll",
       "object_value": 5.434040069580078,
       "threshold_value": {
         "min": -8,
        "max": 8
       },
      "result": 1
      },

  Сейчас доступны следующие проверки:

  - Качество фотоизображения: контраст и насыщенность (недостаточная или слишком большая экспозиция), фокусировка, засветы и зеркальность, равномерность освещения.
  - Статус рта (открыт, закрыт, перекрыт).
  - Наличие очков (нет очков, обычные очки, солнцезащитные очки).
  - Статус глаз (для каждого глаза: открыт, закрыт, перекрыт).
  - Направление взгляда.
  - Углы поворота головы (угол поворота, наклона и отклонения).
  - Положение центральной точки лица на фотоизображении по горизонтали и вертикали.
  - Вертикальный и горизонтальный размер головы относительно размера фотоизображения.
  - Расстояние между центрами глаз.
  - Формат изображения.

  Требования можно найти на официальном сайте: https://www.iso.org/obp/ui/#iso:std:iso-iec:19794:-5:en

  В запросе можно дополнительно включить извлечение EXIF данных фотоизображения.

  По умолчанию проверки выполняются для фотоизображений, на которых присутствует одно лицо. Можно включить оценку для нескольких лиц на фотоизображении с помощью параметра "multiface_policy". Для каждого из найденных лиц вернутся оценки и координаты найденного лица. Следует учитывать, что многие проверки по стандарту ISO предполагают наличие одного лица в кадре, поэтому не все проверки для нескольких лиц будут выполнены успешно.

  Порядок возвращаемых ответов после обработки соответствует порядку передаваемых фотоизображений.

  Если одно или несколько передаваемых в запросе изображений повреждено, то вернётся ошибка. Остальные изображения в запросе будут обработаны в обычном режиме.

  Данный функционал лицензируется отдельно. Если в лицензии отсутствует опция iso, то при использовании ресурса "/iso" вернётся ошибка.

  См. дополнительную информацию в разделе "Проверка изображений по стандарту ISO/IEC 19794-5" в руководстве администратора и в документации OpenAPI.

- Удалены опции `profile` и `limitations-file` для скрипта `db_create.py`. Опция profile использовалась для заполнения базы данных сервиса Configurator настройками на основе профиля по умолчанию. Limitations-file использовалась для загрузки шаблонов настроек из файла.

  Сейчас для создания пустой базы рекомендуется использовать команду db_create.py без дополнительных параметров, затем загружать необходимые настройки из файла с помощью флага dump-file или выполнять миграция настроек командой `python3.9 -m configs.migrate --config /srv/luna_configurator/configs/config.conf --profile platform head`.

- В комплект поставки и в документации была добавлена библиотека вендора для HASP ключа haspvlib_x86_64_30147.so.

# v.5.17.0

Изменения

- Добавлен функционал для подсчёта статистики по выполненным запросам. Полученная статистика позволит проводить анализ использования LP для дальнейшего улучшения системы. Подсчитываются:

  - количество запросов на ресурсы LP, например, 'POST: "handlers/handler_id/events"'.

  - суммарное количество оценок одного типа (например, "estimate_liveness").

  - количество успешных запросов и запросов, завершившихся с ошибкой.

  Статистика ведётся для каждого кода ошибки по каждому ресурсу для каждого сервиса. Статистика сортируется по месяцам.

  Сбор статистики работает только при включённом мониторинге и установленной InfluxDB версии 2.0.8 и более поздних версий.

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

  Для получения статистики следует отправить запрос на ресурс "/luna_sys_info" сервиса Admin или перейти в GUI сервиса Admin на вкладку "help" и нажать "Get LUNA PLATFORM system info". Необходимая информация содержится в разделе "stats".

  Пример ответа:

      {
          "stats": {
          "estimators_stats": [
              {
                  "count": 1,
                  "month": "2021-09",
                  "name": "body_descriptor_extractor_usages"
              }
          ],
          "routes_stats": [
              {
                  "service": "luna-api",
                  "route": "GET:/version",
                  "month": "2021-09",
                  "errors": [
                      {
                          "count": 1,
                          "error_code": "12012"
                      }
                  ],
                  "request_stats": [
                      {
                          "count": 1,
                          "status_code": "200"
                      }
                  ]
              }
          [...]
          ]
      }

  Статистика подсчитывается в InfluxDB на основе данных из бакета "luna_monitoring" и хранится в бакете "luna_monitoring_aggregated". Бакеты создаются в InfluxDB. Не следует удалять данные из данного бакета, иначе будет невозможно получить статистику.

  Задачи для подсчёта статистики можно найти в GUI InfluxDB на вкладке "Tasks".

  Статистика подсчитывается раз в сутки, поэтому не отображается сразу после запуска LP. Можно вручную запустить выполнение задач на вкладке "Tasks" в GUI InfluxDB.

  Для включения подсчёта статистики следует выполнить команду `python influx2_cli.py create_usage_task --luna-config http://127.0.0.1:5070/1` после запуска сервиса Admin. Соответствующая информация добавлена в инструкцию по установке. Команда автоматически создаёт необходимый бакет "luna_monitoring_aggregated". Если данная команда не выполнена, то в ответе "/luna_sys_info" не будет отображаться статистика.

  При необходимости можно отключить сбор статистики, удалив или отключив соответствующие задачи на вкладке "Tasks" в GUI InfluxDB.

  Подробную информацию "Подсчет статистики выполненных запросов и оценок" в руководстве администратора.

- Прекращена поддержка InfluxDB версии 1. Параметры для этой версии были удалены из конфигурационных файлов. Теперь для мониторинга работы LP используется InfluxDB 2, начиная с версии 2.0.8.

  Если ранее использовался InfluxDB 1, то можно выполнить миграцию на новую версию. Описание миграции дано на официальном сайте InfluxDB:

  https://docs.influxdata.com/influxdb/v2.0/upgrade/v1-to-v2/docker/

- В ресурс "/sdk" добавлена фильтрация по состояниям Liveness (spoof, real, unknown).

- Внесены изменения в лицензирование.

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

  Каждое использование Liveness в запросах уменьшает счётчик транзакций. После исчерпания лимита транзакций будет невозможно использовать оценку Liveness в запросах. На запросы не использующие Liveness или с отключённой оценкой Liveness исчерпание лимита не влияет, они продолжают работать в обычном режиме.

  Утилита HASP обновлена до версии 8.23. При обновлении на новую сборку LP требуется удалить старую утилиту HASP и установить новую. Сервис Licenses не запустится, если использована утилита предыдущих версий.

  При использовании Liveness V2 с транзакциями потребуется обновить лицензию при переходе на новую сборку, т. к. ранее выданные лицензии не поддерживают данную возможность.

  Информация о текущих параметрах лицензии отображается в ответе на запрос GET на ресурс "/license" сервиса Licenses, в ответе на запрос в ресурс "/luna_sys_info" сервиса Admin и в GUI сервиса Admin на вкладке "help".

  Подробную информацию можно найти в разделе "Информация о лицензии" в руководстве администратора.

- Cервис Licenses больше не зависит от других сервисов LP, кроме Configurator (при получении настроек из него), и может запускаться независимо от них. Но сервисы LP, например Faces, теперь зависят от Licenses. В связи с этим был изменён порядок запуска сервисов в документации по установке.

  Сервисы теперь сами пишут данные о лицензии в базу мониторинга:

  - Сервис Faces пишет данные о созданных лицах с прикреплёнными биометрическими шаблонами в базу мониторинга в поле license_faces_limit_rate.

  - Сервис Handlers пишет данные о количестве доступных транзакций Liveness V2 в базу мониторинга в поле liveness_balance.

    Предупреждение об исчерпании количества доступных транзакций отправляется в мониторинг и логи сервиса при достижении 2000 оставшихся транзакций Liveness V2 (данный порог задан в системе).

  - Сервис Licenses пишет данные о сроке истечения лицензии в базу мониторинга в поле license_period_rest. Данное поведение использовалось и в предыдущих сборках.

  Подробную информацию можно найти в разделах "Информация о лицензии" и "Сервис Licenses" в руководстве администратора.

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

- Ускорен запрос на получение лиц с атрибутами в сервисе Faces. Ранее сервис Licenses мог некорректно обрабатывать значение параметра FacesLimit на больших базах данных.

- В сервисе Index Manager исправлена проблема, когда не перестраивался индекс. Индекс был удалён вручную или не был построен из-за падения сервиса, но был указан в базе данных как существующий, поэтому система не перестраивала его.

  Теперь в этих случаях статус списков с отсутствующим индексом будет выставляться как failed. Далее задача на построение индекса будет добавлена в планировщик, и индекс будет построен.

# v.5.16.0

Изменения

- В события добавлено поле "top_similar_external_id", содержащее "external_id" наиболее схожего кандидата (события или лица), с которым выполнялось сравнение лица.

  В ответах на следующие запросы в объект "top_match" событий было добавлено поле "external_id", содержащее "external_id" кандидатов для сравнения:

  - "generate events".
  - "get event".
  - "ws handshake".

  Данные поля позволяют сразу получать "external_id" наиболее похожих лиц или событий после выполнения запросов. Например, ранее событие не содержало "external_id" наиболее схожего лица ни в ответе на запрос, ни в базе данных событий. Требовалось выполнить дополнительный запрос для определения "external_id" лица по его "face_id".

  В перечисленные далее запросы добавлены соответствующие фильтры для сортировки событий по "external_id" наиболее похожего объекта:

  - В политику "match_policy" для событий добавлен фильтр "top_similar_external_ids" (см. описание политики в запросе "create handler").

  - Добавлена фильтрация по значению параметра "top_similar_external_ids" для получения событий в сервисах API и Events (см. запрос "get events").

  - В запрос получения статистики по событиям добавлены target и фильтр "top_similar_external_id" в сервисах API и Events (см. запрос "get statistics on events").

  - Фильтр "top_similar_external_ids" добавлен при указании событий в качестве кандидатов для запросов "match faces" и "match bodies".

  - Фильтр "top_similar_external_ids" добавлен в фильтры событий для задач:

    - прикрепления к списку.
    - кластеризации.
    - перекрестного сравнения.
    - экспорта данных.

  Колонка "top_match" в результатах задачи создания отчёта и задачи экспорта данных теперь содержит "external_id" лучшего кандидата сравнения.

- Для кандидатов в запросах "matching faces" и "human body matching" добавлен параметр "order", определяющий порядок сортировки результатов. Доступна сортировка в порядке возрастания времени создания события (опция "create_time_asc"), в порядке убывания времени создания события (опция "create_time_desc") и по схожести кандидатов (опция "similarity").

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

  Для корректной работы параметров сортировки по времени требуется задать порог по степени схожести объектов. При указании новых параметров сортировки используется матчинг по базе данных. Скорость обработки запроса будет ниже, чем при матчинге по списку с сортировкой по "similarity".

  По умолчанию используется опция "similarity".

- В задачу кластеризации добавлен параметр "limit", позволяющий задать максимальное количество кандидатов, возвращаемых для каждого сравнения. Значение по умолчанию изменено с 5 на 20 000.

  Параметр управляет количеством кандидатов, возвращаемых в ответе. Чем больше кандидатов возвращается, тем лучше. Но при большом размере кластера могут возникать проблемы с производительностью и точностью.

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

- Исправлена ошибка, при которой в результатах запроса в Backport 4 на сравнение по индексированному списку не возвращались указанные параметры "targets", а в качестве "targets" возвращался набор полей по умолчанию. Проблема возникала в сервисе Python Matcher Proxy при выполнении сравнения одного эталона с несколькими кандидатами.

- Изменено поведение при загрузке изображений. Теперь каждое изображение загружается независимо. В случае возникновения ошибки при загрузке одного из изображений загрузка других изображений не прерывается.

- Поле "result" в ответе на запрос "get task result" для задачи пакетной обработки больше не является обязательным в сервисе Tasks.

  Если при выполнении одной подзадачи возникает ошибка, то в теле ответа вернётся только поле "errors" с ошибкой. Ранее вместе с "errors" возвращалось пустое поле "result".

- В сервисе Tasks исправлены ограничения для разметки задачи расчёта ROC-кривой. Теперь максимально можно задать 20 000 элементов.

  Ранее при передаче более 20 000 элементов, в логах сервиса Tasks Worker возвращалась ошибка "Uncaught exception occurred". Теперь возвращается ошибка с уровнем "Error" и описание ошибки.

- Из настроек сервиса Configurator удалена неиспользуемая настройка "CLUSTERING_MATCH_LIMIT".

- Исправлена информация, возвращаемая в секции "LUNA_CONFIGURATOR" в ответе на запрос "get service configuration". Теперь она содержит текущее состояние параметра.

- В документе "EventsReferenceManual.html" в описании для перечисленных полей в схеме запроса "create new events" теперь указано, что поля не являются "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

- В документе "EventsReferenceManual.html" в описании для перечисленных полей в схемах запросов "get event" и "get events" теперь указано, что поля являются "Nullable":

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

- В документе "EventsReferenceManual.html" в описании для перечисленных полей в схемах запросов "face matching" и "human body matching" теперь указано, что поля являются "Nullable":

  - matches/result/event/top_match/event_id
  - matches/result/event/top_match/face_id

- В документе "SenderReferenceManual.html" в описании для перечисленных полей в схеме запроса "ws handshake" теперь указано, что поля являются "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

- В документе "HandlersReferenceManual.html" в описании для указанного поля в схеме запроса "generate events" теперь указано, что поле являются "Nullable":

  - events/matches/candidates/event/match_result/candidates/event/user_data

# v.5.15.0

Изменения

- Добавлена поддержка динамического обработчика для задачи пакетной обработки (см. запрос "/tasks/estimator").

  Ранее ресурс поддерживал работу только со статическими обработчиками. Теперь можно указать ID статического или динамического обработчика в поле `handler_id`.

  Для динамического обработчика можно указать политики для обработки прямо в запросе. Один и тот же динамический обработчик можно указывать в разных задачах estimator и не создавать для каждой задачи новый обработчик.

  Если указать ID статического обработчика и попытаться указать в запросе политики для него, то вернётся ошибка.

- Во все сервисы LP добавлен новый ресурс "/configs". Он позволяет получить используемые настройки соответствующего сервиса.

  Если сервис запущен с опцией автоматического обновления настроек, то в случае их обновления ресурс вернёт актуальные значения, а не те настройки, с которыми сервис был запущен изначально.

  Для получения списка настроек необходимо выставить заголовок `Accept`, принимающий значения `application/json` (настройки будут возвращены в формате JSON для Configurator) или `text/plain` (настройки будут возвращены в формате конфигурационного файла config.conf).

  Пароли и токены, указанные в конфигурационных файлах, будут скрыты в полученном ответе.

- Добавлен новый ресурс "/handlers/validator". Ресурс позволяет проверить корректность указанных политик обработчика.

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

- Добавлен Docker-контейнер с Grafana, который дополнительно содержит все необходимые скрипты создания дашбордов LUNA PLATFORM. Описание запуска контейнера и создания дашбордов приведено в документации по ручному запуску контейнеров LUNA PLATFORM.

- В документацию добавлена инструкция для использования GPU при запуске LUNA PLATFORM с помощью Docker Compose.

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

- Исправлена ошибка, когда при генерации событий возвращалась ошибка с кодом 500. Ошибка возвращалась в случае задания тега без указания фильтров в политике `conditional_tags_policy` (см. запрос "/handlers/{handler_id}/events").

- Исправлено описание параметра "page_size" в запросе "get events" в документации OpenAPI.

  Сейчас указано, что количество объектов не может превышать 1000. Ранее было указано, что количество объектов на странице не может превышать 100.

# v.5.14.0

Изменения

- SDK обновлён до версии 5.4.1.

  - Обновлён алгоритм Liveness V2. Пороги по умолчанию для "liveness_threshold" и "quality_threshold" теперь равняются "0.5". Рекомендуемый порог "liveness_threshold" теперь равен "0.5" вместо "0.88".
  - Исправлена проблема, когда SDK возвращал ошибки "Invalid detection" и "Invalid image size" в случае получения неправильного ограничивающего прямоугольника. Теперь в этих случаях возвращается ошибка "Invalid rectangle".

- В сервис Python Matcher Proxy добавлена поддержка плагинов сравнения.

  Использование плагинов может значительно ускорить выполнение запросов на сравнение. Например, с помощью плагинов возможно организовать хранение необходимых для выполнения операций сравнения данных и дополнительных полей объектов в отдельном хранилище, что позволит ускорить доступ к данным по сравнению с использованием стандартной БД LUNA PLATFORM.

  В документации сервиса Python Matcher Proxy ("ServiceManuals/PythonMatcherDevelopmentManual") в разделе "Plugins" приводится общее описание основных шагов для создания собственных плагинов и приводится пример плагина "Thin event".

  "Thin event" используется для быстрого сравнения дескрипторов лиц с дескрипторами упрощённых событий. Упрощённые события содержат меньше полей по сравнению с событиями из БД "luna_events". Все данные для них хранятся в одной таблице.

  Требования для запуска "Thin event" приведены в его документации. По умолчанию плагин не используется.

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

  Для работы с плагинами должен быть установлен сервис Python Matcher Proxy. Он принимает решение об использовании стандартных механизмов матчинга LP или плагинов на основе сложности запроса (cost). Активацию плагинов следует выполнять в этом сервисе.

  См. общее описание плагинов сравнения в руководстве администратора в разделе "Плагины сравнения" и подробную инструкцию с примерами реализации плагинов в документации Python Matcher Proxy в разделе "Plugins".

- Добавлена возможность указывать время окончания события с помощью заголовка "Luna-Event-End-Time" в запросе "generates events". Если данный заголовок установлен, то все события будут сгенерированы с полем окончания времени события "end_time".

  Поле может быть использовано для передачи времени окончания события из внешних систем.

  Поле окончания времени события "end_time" поддерживается для:

  - задания "target" событий в политике сравнения обработчика (см. запросы "create handler" и "generate events");

  - сохранения события (см. запрос "save event");

  - задания "target" при получении событий и их статистики (см. запросы "get events" и "get statistics on events");

  - события, возвращаемого с помощью веб-сокетов (см. запрос "ws handshake"). Время создания и окончания события будет возвращены в полях "event-create-time" и "event-end-time" соответственно.

  - колонок в документе CSV в задачах создания отчета и экспорта (см. запросы "reporter task" и "exporter task").

  Фильтры события «end_time__gte» и «end_time__lt» доступны для:

  - политики сравнения, когда события заданы как кандидаты (см. запросы "create handler" и "generates events");

  - получения событий (см. запрос "get events");

  - обработки задач привязки, перекрестного сравнения и кластеризации (см. запросы "linker task", "cross-matching task" и "clustering task").

- В сервисы Events, Faces, Tasks, Configurator, Admin, Handlers, Python Matcher и Backport3 добавлена настройка "CONNECTION_POOL_SIZE", позволяющая задавать размер пула соединений к БД.

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

- В документации "APIReferenceManual" исправлено неправильное название поля для указания версии дескриптора в запросах, принимающих на вход дескрипторы. Ранее поле называлось "descriptor_version", теперь поле называется "version".

# v.5.13.0

Изменения

- В ресурсе "/sdk" добавлена агрегация полученных значений статуса маски, эмоций и Liveness. При выполнении запроса с включенным параметром "aggregate_attributes" агрегированные значения данных оценок возвращаются в поле "aggregate_estimations" в теле ответа.

- Добавлена поддержка типа содержимого application/msgpack для запроса на создание лица с атрибутами. См. запрос "create face".

  MessagePack упаковывает данные эффективнее, чем JSON. Это бинарный формат, поэтому не требует декодирования из BASE64.

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

- Из документа OpenAPI сервиса API удалено лишнее описание создания задач удаления биометрических шаблонов указанной версии для лиц и событий. Для задачи сборки мусора в сервисе API доступно только удаление событий. См. запрос "garbage collection task".

  Задача удаления биометрических шаблонов необходимой версии для лиц и событий доступна в API сервиса Admin.

- Исправлена необработанная ошибка, возникавшая при некорректном значении поля "account_id" в политике "match_policy" при отправке запросов POST на ресурс "/handlers" и PUT на ресурс "/handlers/{handler_id}" сервиса Handlers. Ошибка возникала, если "account_id" не был задан в формате UUID.

# v.5.12.2

Изменения

- В сервисе Faces исправлено описание тела запроса на создание лиц с типом содержимого application/msgpack.

# v.5.12.1

Изменения

- В сервисы LUNA PLATFORM добавлен новый ресурс «/healthcheck». Ресурс может использоваться для активной проверки состояния сервиса, а именно, может ли сервис выполнять свои функции в полном объёме или нет. Проверяется возможность подключения данного сервиса к сервисам LP и БД, от которых он зависит.

  - «/healthcheck API»
  - «/healthcheck Admin»
  - «/healthcheck Handlers»
  - «/healthcheck Events»
  - «/healthcheck Backport3»
  - «/healthcheck Backport4»
  - «/healthcheck Tasks»
  - «/healthcheck Image Store»
  - «/healthcheck Python Matcher»
  - «/healthcheck Licenses»
  - «/healthcheck Faces»
  - «/healthcheck Sender»
  - «/healthcheck Configurator»

  Возможно настроить периодическую проверку ресурса с использованием HAProxy, NGINX или иной системы. Это позволит определить, что сервис недоступен, и принять решение о его отключении из контура или перезапуске.

  С помощью опции "include_luna_services" можно включать и отключать проверку healthcheck для сервисов LUNA PLATFORM, от которых зависит данный сервис. Если опция включена, то отправляются дополнительные запросы на ресурсы "/healthcheck" этих сервисов.

  Опция "include_luna_services" отключается, чтобы не выполнять рекурсивную проверку одних и тех же сервисов. Например, когда сразу несколько сервисов, от которых зависит данный сервис, будут отправлять запросы в сервис Faces и тем самым увеличивать нагрузку на него.

  При успешном выполнении проверки healthcheck возвращается только время выполнения подключения в поле "execution_time".

  При недоступности одного или нескольких сервисов возвращается ошибка с кодом 502 "Unhealthy". В теле ответа перечисляются компоненты, статусы проверок и возникшие ошибки.

  Код ошибки 500 в ответе не обязательно означает проблему в работе сервиса. Долгий запрос может завершиться с ошибкой из-за превышения таймаутов, повышенной нагрузки на сервер, проблем в сети или по иным причинам.

  При выполнении запроса на ресурс "/healthcheck" рекомендуется выставлять таймаут в несколько секунд. Если запрос не успевает отработать, это признак того, что при работе системы возникли проблемы.

- При получении изображений из сервиса Image Store для выполнения запросов «detect face», «extract attributes», «generates events» и «perform verification», отправляемых напрямую в сервис Handlers, теперь используется значение параметра "account_id". Изображения получаются из Image Store, если в запросе указан ID биометрического образца или URL хранящегося в Image Store изображения.

- Описания выполнения миграций с LUNA PLATFORM 3 и LUNA PLATFORM 4 исправлены в соответствии с последними изменениями в LUNA PLATFORM 5.

# v.5.12.0

Изменения

- Теперь в обработчиках (handlers) фильтры «create_time__lt» и «create_time__gte» для кандидатов (лиц и событий) матчинга в политике «match_policy» можно задавать относительно текущего времени.

  Например, данный формат фильтра позволит выбирать для сравнения только события, созданные за последний час, что может быть использовано для случаев оплаты по лицу в транспорте для исключения повторной оплаты проезда.

  В этом формате время задаётся по следующему шаблону `'now-(\d+)[smhdwMy]'`, где `[d+]` — число, `[smhdwMy]` — необходимый период: m (минуты), h (часы), d (дни), w (недели), M (месяцы), y (годы).

  Примеры:

  - Запись «create_time__gte»: «now-3h» означает, что будут выбраны все объекты, созданные за последние три часа.
  - Запись «create_time__lt»: «now-4w» означает, что будут выбраны все объекты, созданные раньше, чем четыре недели назад.

- В ресурс ручного сохранения события \«handlers/{handler_id}/events/raw\» сервисов API и Handlers добавлена новая опция «wait_saving», позволяющая включать и отключать ожидание сохранения событий в БД Events перед отправкой ответа.

  При отключённой опции ответ на запрос \«handlers/{handler_id}/events/raw\» возвращается быстрее, т. к. система не будет ждать, пока событие сохранится в базе данных. Но при этом система не присылает никаких уведомлений в случае, если не удалось выполнить сохранение.

  При включённой опции система дожидается сохранения событий перед отправкой ответа. Если сохранение успешно, то будет возвращен код состояния 201. Если же по каким-то причинам событие не сохранилось, вернется код ошибки 500.

  По умолчанию опция включена.

- В запрос на получение файла с текущими настройками LUNA PLATFORM \«/dump\» из сервиса Configurator добавлен новый параметр «version», содержащий версию миграции этих настроек. Версия изменяется при обновлении на новые сборки LUNA PLATFORM.

  Не следует вручную обновлять настройки системы из файла предыдущей сборки, т. к. миграция настроек системы происходит автоматически при обновлении на новую сборку. При попытке использовать dump-файл от предыдущей сборки LP на новой сборке возникнет ошибка, т. к. версия в этом файле будет отличаться.

  Файлы с настройками от предыдущей сборки рекомендуется использовать только для проверки коррекции миграции настроек.

- В OpenAPI документации сервисов Sender и API удалено повторяющееся описание сообщения WebSocket из раздела «Callback».

- Добавлена возможность указывать значение «application/msgpack» в качестве заголовка «Content-Type» для следующих запросов сервиса Events:

  - GET на «/events»
  - PATCH на \«/events/event_id\»

  MessagePack упаковывает данные эффективнее, чем JSON. Это бинарный формат, поэтому не требует декодирования из BASE64.

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

- Исправлена ошибка, при которой лицензия становилась недоступной за день до истечения её срока.

- В сервисе LUNA Events исправлена ошибка с превышением максимального количества клиентов для БД Vertica.

# v.5.11.0

Изменения

- Добавлена новая задача \«estimator\» (\«/tasks/estimator\»). Она позволяет выполнять пакетную обработку изображений с использованием указанных политик.

  Данную задачу можно создать с помощью API сервисов API или Tasks.

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

  В теле запроса можно указать ID уже сохранённого обработчика или задать политики обработки вручную.

  Ресурс принимает для обработки ссылку на ZIP-архив с изображениями.

  В качестве ссылки на архив может использоваться внешний URL или URL до архива, сохранёного в Image Store. Во втором случае архив должен быть предварительно сохранён в LP с помощью POST запроса на ресурс \«/objects\»

  Архив может быть защищён паролем. Пароль можно передать в запросе с помощью параметра \«authorization\» -> \«password\».

  Для получения корректных результатов обработки следует использовать изображения одного типа (исходное изображение, биометрический образец лица, биометрический образец тела). Тип передаваемых изображений задаётся в запросе в параметре \«image_type\».

- В задачу удаления событий (\«/tasks/gc\») добавлен параметр \«remove_samples\», при включении которого вместе с событиями удаляются биометрические образцы лиц и тел.

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

  Данный параметр добавлен в ресурсы сервисов LUNA API, LUNA Admin и LUNA Tasks, а также вынесен в пользовательский интерфейс сервиса LUNA Admin.

- При отправке запросов другим сервисам сервис API теперь может отправлять заголовок accept-encoding с директивами \«identity\», \«deflate\», \«gzip\» (ранее можно было указывать только директивы \«deflate\» и \«gzip\»). Директива \«identity\» позволяет отключить автоматическое сжатие (на стороне других сервисов) и автоматическую распаковку (на стороне сервиса API) для тел запросов с изображениями или ZIP-архивами.

- Теперь сервис API повторно использует подключения к другим сервисам платформы. Это изменение уменьшает количество открытых соединений и ускоряет запросы к другим сервисам.

- В сервисе Events изменен ответ при удалении событий. Ранее ID удалённых биометрических образцов для лиц и тел возвращались в одном массиве — \«samples\«. Теперь в ответе возвращаюся два массива — \«face_samples\» и \«body_samples\». См. ресурс \«event deletion\».

- В скрипт миграции с LP 3 \«start_migration.py\» добавлен параметр skip_missing_descriptors. Параметр позволяет игнорировать отсутствующие в БД LP 3 биометрические шаблоны при выполнении миграции. Информацию о скрипте можно найти в главе \«Migration launch\» руководства \«LP_Migration_from_LP3\».

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

- Внесены изменения в обработку параметра \«external_ids\» для ресурса \«/verifiers/{verifier_id}/verifications\». Ранее значение данного параметра можно было указать только в формате \«uuid\», а теперь используется формат \«string\».

- Исправлена ошибка в сервисе Backport3, которая возникала при автоматическом обновлении настроек сервиса и останавливала его работу.

# v.5.10.0

Изменения

- В набор политик \«storage_policy\» ресурса \«/handlers\» была добавлена политика отправки уведомления о создании событий \«notification_policy\». В ней можно включить или отключить отправку уведомлений о создании событий в сервис Sender, а также настроить фильтры для отправки уведомлений.

  По умолчанию отправка уведомлений включена.

- Группа параметров \«LUNA_HANDLERS_LIMITS\» добавлена в настройки сервиса Handlers.

  Параметры позволяют задать:

  - Максимальное количество изображений, получаемых в запросе.
  - Максимальное количество детекций в событии, создаваемом вручную.
  - Максимальный размер массивов в событии, создаваемом вручную.
  - Максимальное количество кандидатов в результатах сравнения.

  Ранее данные значения можно было изменить только с помощью специального конфигурационного файла в комплекте поставки.

  Следует учесть, что увеличение лимитов может привести к проблемам в работе LP.

- Теперь при включённом параметре \«aggregate_attributes\» в запросе \«/handlers/{handler_id}/events\» выполняется агрегация всех полученных значений для параметров \«mask\» и \«emotions\». Агрегированные значения будут возвращаться в ответе в полях \«mask\» и \«emotions\» в группе параметров \«aggregate_estimations\».

  Значения данных параметров, определённые для каждой отдельной детекции, тоже возвращаются в ответе в группе \«detection\».

  Агрегированные значения этих параметров можно указать в поле \«aggregate_estimations\» при ручном создании события с помощью ресурса \«/handles/{handler_id}/events/raw\».

  Агрегированные значения параметров возвращаются при получении уведомлений о созданных событиях через веб-сокеты с помощью сервиса Sender.

- SDK был обновлён до версии 5.3.0.

  Значение параметра \«redetect_score_threshold\» было задано равным \«0.3\»

- В руководство администратора в раздел \«Плагины\» добавлено общее описание работы с плагинами LP и базовая информация по их добавлению.

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

- Добавлена поддержка работы с \«обрезанными\» JPEG изображениями в сервисе Handlers. У таких изображений отсутствуют последние байты, обозначающие окончание изображения. Ранее при обработке таких изображений возвращалась внутренняя ошибка.

- В GUI сервиса Admin исправлена ошибка с отображением фильтров для задачи GC. При выборе объекта faces отображался лишний фильтр \«descriptor type\».

- Исправлена ошибка с запросом POST на ресурс \«/faces/attributes/descriptors\» в сервисе Faces. Сервис возвращал пустой список лиц, если в нём находилось лицо с биометрическим шаблоном, версия которого равнялась версии, указанной в поле \«missing_version\».

- Исправлена ошибка с проверкой версии биометрических шаблонов при удалении биометрических шаблонов в сервисе Events. Теперь версия биометрических шаблонов не будет проверяться при удалении, что позволит удалять любые указанные версии биометрических шаблонов, в том числе те, которые уже не поддерживаются системой.

- Описание ошибки при получении объекта с неправильным Accept header было исправлено для сервиса Image Store.

- Исправлена схема ответа для ресурса \«luna_sys_info\» сервиса Admin.

- Исправлено падение при автоматическом обновлении настроек сервиса Handlers. Падение возникало при изменении настроек для данного сервиса в сервисе Configurator.

- В документацию сервиса Handlers добавлено отсутствовавшее описание некоторых полей мониторинга.

- Для сервиса Handlers исправлена проверка поля \«mimetype\» для запроса создания событий. Больше не возвращается \«Internal server error\», если указанный в запросе тип изображения отличается от типа передаваемого в запросе изображения.

# v.5.9.0

Изменения

- В поставку добавлены дашборды с информацией о запросах LP и возникающих ошибках.

  Для отображения дашбордов используется Grafana. Доступ к GUI Grafana осуществляется по порту 3000.

  Для создания дашбордов требуется InfluxDB версии 2. Дашборды не работают с версией 1. Теперь InfluxDB 2 версии используется по умолчанию при установке LP. InfluxDB 1 все ещё поддерживается, но рекомендуется использовать версию 2.

  При установке для подключения к InfluxDB 2 используются token и password, заданные по умолчанию. Измените их при необходимости.

  В инструкции по установке добавлены описания запуска контейнеров Grafana и InfluxDB 2, запуска скрипта создания дашбордов.

  Дополнительную информацию о мониторинге и дашбордах можно найти в разделе \«Мониторинг\» в руководстве администратора.

- Добавлены ресурсы для сохранения и получения объектов из Image Store: \«/objects\» и \«/objects/{object_id}\».

  Доступны следующие типы содержимого запроса:

  - \«application/json\»
  - \«application/pdf\»
  - \«application/zip\»
  - \«text/plain\»

  Ресурс \«/objects\» позволяет сохранить объект одного из перечисленных форматов в Image Store под уникальным ID.

  Ресурс \«/objects/{object_id}\» позволяет:

  - получить объект.
  - удалить объект.
  - проверить, существует ли объект с указанным ID.

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

  В качестве \«target\» теперь можно указать \«event_descriptors\». Далее следует указать, какой тип биометрических шаблонов следует удалить для события (face, body) и их версию.

  Важно, что было внесено изменение в тело запроса создания задачи GC \«/tasks/gc\». Теперь для удаления биометрических шаблонов лиц следует указывать \«face_descriptors\» вместо \«descriptors\» в качестве \«target\».

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

  В сервис Events добавлен ресурс \«/events/descriptors\», позволяющий удалять биометрическе шаблоны, прикреплённые к событию.

- В настройки сервисов Tasks и Python Matcher добавлена группа параметров \«PLATFORM_LIMITS\». С их помощью для запросов \«/matcher/face\», \«/matcher/body\», \«/tasks/clustering\» и \«/tasks/cross_match\» можно настроить максимальное количество:

  - эталонов и кандидатов в запросе
  - передаваемых значений для некоторых фильтров
  - возвращаемых в ответе кандидатов

  Ранее данные значения можно было изменить только с помощью специального конфигурационного файла в комплекте поставки.

- В сервисах Python Matcher, Admin и Index Manager теперь используется Python 3.9. Поддержка более старых версий Python для сервисов прекращена.

- Список зависимостей для выполнения скрипта миграции с LUNA PLATFORM 3 на LUNA PLATFORM 5 был вынесен в отдельный requirements.txt файл в контейнере Backport 3. Файл может использоваться при необходимости выполнять миграцию вне контейнера Backport 3.

- Добавлена возможность указывать атрибуты в качестве кандидатов для верификации в ресурсе \«/verifiers/{verifier_id}/verifications\».

  Атрибут имеет ограниченный срок существования и будет удалён по его завершении, поэтому верификация через некоторое время будет невозможна.

  Например, это позволит выписать пропуск на 24 часа (задать соответствующий TTL атрибута) и пропускать человека только в течение этого периода.

- Добавлена следующая информация в OpenAPI документацию сервиса API:

  - в документацию в описание ресурса \«/tasks/{task_id}/result\» возвращены примеры результатов выполнения задач сервиса Tasks.
  - в документацию в описание ответа ресурса \«/tasks/{task_id}/result\» добавлен пример результата выполнения задачи \«exporter\». В описании ответа ресурса необходимо выбрать response schema \«application/zip\».

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

- Исправлена ошибка, когда задача \«Exporter\» выполнялась без учёта разделителя, указанного в запросе в параметре \«csv_delimiter\».

- ID событий без атрибутов теперь возвращаются в упорядоченном виде в ответе ресурса \«/events/attributes/missing\» сервиса Events.

- В сервисе Events исправлена ошибка, когда в ответе на запрос DELETE в ресурс \«/events\» возвращались sample ID со значением \«Null\».

- Исправлена ошибка при смене пароля в сервисе Admin при отправке запроса PATCH на ресурс \«/login\».

- Для сервиса Events исправлена ошибка с попаданием в лог сервиса следующего сообщения `WARNING: sanic.root: Message body set in response on /2/events. A 204 response may only have headers, no body.`. Сервис больше не возвращает тело запроса при указании gzip или deflate в качестве accept-encoding при статус коде 204 или методе HEAD.

- В документации обновлена схема базы данных для сервиса Events.

- Сервис Backport 3:

  - Статус код для успешного ответа на POST \«/handlers/verify/raw\» был обновлён.

  - Была добавлена схема ответа на запрос PATCH \«/storage/persons/{person_id}\» для статус кода 400.

  - Обновлена схема ответа для запроса GET в ресурс \«/version\».

  - Для полей персоны \«user_data\» и \«external_id\» значения по умолчанию были заменены на пустые строки.

# 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\».

# v.5.7.0

Изменения

- Добавлен новый ресурс \«/tasks/exporter\», с помощью можно выгружать данные событий и лиц из LP и сохранять их в CSV файл.

  На вход принимается набор фильтров для определения объектов, которые необходимо выгрузить в файл. На выходе возвращается ZIP архив, в котором будет храниться CSV файл с данными об объектах и изображения для каждого объекта (опционально).

  Возможность поддержана в сервисах API и Tasks.

  См. раздел \«Задача экспорта\» в руководстве администратора.

- Добавлена опция для использования внешнего URL изображения при сохранении исходного изображения.

  В политику сохранения исходного изображения добавлена настройка use_external_references. Она позволяет включить сохранение ссылки на внешнее изображение в поле \«image_origin\», чтобы избежать дублирования одного и того же изображения в базе данных.

  - Eсли в запросе передан внешний URL на изображение, то в поле \«image_origin\» будет указан этот URL.
  - Eсли в запросе передан биометрический образец и он был сохранён в хранилище Image Store, то в поле \«image_origin\» будет указана ссылка на него.

  Если длина URL превышает 256 символов, то вместо него будет сохранено само исходное изображение.

  Возможность поддержана в сервисах API и Handlers.

- Добавлена возможность передавать время детекции вместе с изображениями.

  В запрос создания событий в ресурс \«/handlers/{handler_id}/events\» добавлена возможность явного указания времени детекции лица для каждого из передаваемых изображений. Доступно для схем запроса multipart/form-data и application/json.

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

- Для сервисов API, Configurator, Backport 4 был изменён механизм перезагрузки настроек. Теперь перезагрузка выполняется путём перезапуска соответствующих процессов. Механизм обеспечивает более надёжное обновление настроек сервисов.

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

- При указании несуществующего list_id в задаче кластеризации теперь возвращается две ошибки, вместо одной: \«List with id {ID} not found\» и \«Objects for clustering not found (empty set)\».

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

- Теперь при провале проверки соединения сервисов LP с InfluxDB возвращается сообщение \«Check connection to Influxdb: connection refused\». Ранее вместо ошибки возвращался список вызовов до возникновения ошибки.
- Исправлены замедления работы в сервисе Image Store.
- В сервисе Handlers исправлена ошибка, когда не обрабатывалось значение параметра face_bounding_boxes, передаваемое в запросе в ресурс \«/verifiers/{verifier_id}/verifications\».
- В сервисе Handlers исправлен формат URL аватара лица, создаваемого с помощью обработчика (handler). Ранее он возвращался в формате \«/samples/{sample_id}\». Теперь URL возвращается в формате \«/samples/faces/{sample_id}\».
- В спецификацию OpenAPI сервиса Backport 4 добавлены поля user_data и external_id, которые возвращаются в ответе создания событий с помощью ресурса \«/handlers/{handler_id}/events\».

# v.5.6.0

Изменения

- SDK был обновлён на версию 5.2.0.

- Добавлена поддержка 59 сети для извлечения биометрических шаблонов лиц.

  Начиная со сборки 5.6.0, для новых установок LUNA PLATFORM по умолчанию используется 59 версия сети извлечения биометрических шаблонов.

  Если LUNA PLATFORM уже установлена, то сеть не будет автоматически обновлена на 59. В Configurator останется та сеть, которую уже использует LP. В этом случае для перехода на новую версии нейросети следует выполнить повторное извлечение уже существующих биометрических шаблонов для лиц (faces). Описание данного процесса дано в разделе \«Переключение версии нейросети\» руководства администратора.

  Важно, что повторное извлечение биометрических шаблонов для событий (events) в данный момент невозможно. При переходе на новую версию сети существующие события не могут быть использованы для сравнения.

  Поставка с сервисами индексирования и поиску по индексу не поддерживает 59 версию нейросети, там по умолчанию используется 56 версия.

- Добавлена поддержка 102, 103 и 104 сетей для извлечения биометрических шаблонов тел. Теперь по умолчанию используется 104 сеть для извлечения биометрических шаблонов тела.

  Сеть версии 101, которая была использована в предыдущих релизах, больше не поставляется и не поддерживается. При переходе на сборку LP 5.6.0 существующие биометрические шаблоны тел не могут быть повторно извлечены с использованием 104 версии сети и не смогут быть использованы для сравнения.

- Значения полей \«user_data\» и \«external_id\» в запросах теперь заданы равными \«\«по умолчанию для всех сервисов и не могут иметь значение null.

- Фильтры \«event_id__gte\» и \«event_id__lt\» были добавлены в \«задачу перекрестного сравнения\», \«задачу кластеризации\» и \«задачу привязки\». Фильтры позволяют задать верхнюю и нижнюю границы значений \«event_id\». Последующая обработка будет выполнена для событий, ID которых входят в заданный фильтром диапазон. Например, эти фильтры можно использовать, чтобы разделить обработку большого событий на несколько задач и выполнять эти задачи параллельно.

- Для сервисов Image Store, Tasks, Events, Admin и Backport 3 был изменён механизм перезагрузки настроек. Теперь перезагрузка выполняется путём перезапуска соответствующих процессов. Механизм обеспечивает более надёжное обновление настроек сервисов.

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

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

- В сервисе API исправлена ошибка, когда запись об обработке запроса не добавлялась в лог в случае отключения клиента. Теперь при отключении клиента до получения ответа от него в лог будет записана ошибка со статус кодом 499.

- В ответы сервисов добавлены новые статус коды:

  - Статус код 408 возвращается, если за указанный период сервис не получил полный текст запроса (по умолчанию, 60 секунд).
  - Статус код 501 возвращается, если сервис не выполнил обработку запроса за указанный период (по умолчанию, 600 секунд).
  - Статус код 413 возвращается, если нагрузка на сервис превышает допустимую максимальную нагрузку.

- В спецификации OpenAPI для сервиса API исправлена ошибка с указанием типа SDK биометрического шаблона. Ранее SDK биометрический шаблон отображался как тип object с полями \«descriptor\» и \«version\». Теперь тип данного объекта указан как \«string \».

# v.5.5.0

Изменения

- В сервисы API и Handlers новый ресурс \«/handles/{handler_id}/events/raw\» для ручного создания событий (объект event в LP). Поля события заполняются при отправке запроса.

  Формат создаваемого события аналогичен формату, возвращаемым ресурсом \«/handlers/{handler_id}/events\». При создании события не указываются \«event_id\» и \«url\», они возвращаются в ответе после создании события.

  Для создаваемых вручную событий создаются оповещения с использованием веб-сокетов.

  Ресурс позволяет задать свою логику заполнения полей событий, отличную от логики с использованием обработчиков (handlers). Например, когда требуется извлекать биометрические шаблоны только для части детекций, а не для всех детекций.

- В сервис API добавлен ресурс \«/ws\». Теперь настройка веб-сокетов и проксирование ответов Sender выполняется через сервис API. Это позволяет обеспечить единую точку входа в LP через сервис API и избежать отправки запросов напрямую в сервис Sender.

  Настройка веб-сокетов напрямую через Sender остаётся доступной. Её можно использовать для снижения нагрузки на сервис API, в остальных случаях рекомендуется использовать сервис API.

- В сервисах API и Events в ресурсы \«/events\» для метода GET добавлены фильтры \«event_id__gte\» и \«event_id__lt\».

  С помощью данных фильтров можно выполнять пагинацию, которая:

  - быстрее пагинации по параметрам \«page\» и \«page_size\». Она не замедляется при большом числе событий
  - стабильнее пагинации по параметрам \«page\» и \«page_size\». Изменение количества событий в процессе пагинации не приводят к потере событий или их дублированию в ответе.

- Для сервисов Faces и Python Matcher был изменён механизм перезагрузки настроек. Теперь перезагрузка выполняется путём перезапуска соответствующих процессов. Механизм обеспечивает более надёжное обновление настроек сервисов.

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

- Значения полей \«user_data\» и \«external_id\» в запросах теперь заданы равными \«\» по умолчанию в сервисе Events.

- Общий доступ к кэшу был добавлен для сервиса Python Matcher при запуске нескольких \«рабочих процессов\» (workers) одного сервиса. Теперь каждый из \«рабочих процессов\» использует один и тот же кэш биометрических шаблонов. Ранее при создании нескольких \«рабочих процессов\» каждый из них имел свой кэш биометрических шаблонов.

  Данное изменение может как ускорить, так и замедлить работу сервиса. Если необходимо обеспечить сохранение кэша в каждом из процессов Python Matcher, следует запускать каждый из экземпляров сервиса по отдельности.

- В сервисы LUNA PLATFORM добавлена поддержка InfluxDB OSS версии 2.x для мониторинга. В LP_Administrator_Manual добавлен раздел \«InfluxDB OSS 2\», описывающий настройку LP для работы со второй версией БД. БД в комплекте поставки LP не была обновлена на новую версию.

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

- Для сервиса Faces поддержана возможность обновления поля \«event_id\» значением \«null\» при отправке запроса Patch в ресурс \«/faces/{face_id}\».
- В сервисе Tasks было исправлена проблема с экранированием символа разделителя в колонке отчёта. Если символ разделителя встречается в колонке отчёта, то теперь он экранируется.
- В сервис Tasks добавлена обработка ошибок взаимодействия сервисов, возникших во время выполнения задач. Например, если сервис недоступен или возникли проблемы с соединением, то соответствующие ошибки корректно отображаются в списке ошибок выполнения задачи.

# v.5.4.0

Изменения

- В события были добавлены поля \«detect_time\» и \«image_origin\»:

  - Поле \«detect_time\» содержит время детекции на исходном кадре.
  - Поле \«image_origin\» содержит ссылку на сохранённое исходное изображение, на котором была выполнена детекция.

  Эти поля возвращаются в ответе на запрос POST в ресурс \«/handlers/{handler_id}/events\».

  При сохранении события данные этих полей добавляются в базу данных Events в таблицы \«face_detect_result\» и \«body_detect_result\».

  В связи с добавлением данных полей изменён формат входных (POST \«/events\» ) и выходных (GET \«/events\», GET \«/events/{event_id}\») данных событий в сервисе Events.

  Эти новые поля возвращаются в ответе ресурса \«/ws\» при отправке событий сервисом Sender.

- В запрос POST \«/handlers\» в \«storage_policy\» добавлена политика сохранения исходного изображения.

  Для сохранения исходных изображений следует указать \«store_image\» равным \«1\» для \«image_origin_policy\». По умолчанию сохранение исходных изображений отключено.

- Добавлена возможность указывать атрибуты в качестве кандидатов и эталонов для задачи перекрестного сравнения. См. \«/tasks/cross_match\».

  В сервис Tasks добавлена возможность построения ROC-кривых с использованием атрибутов. См. \«/tasks/roc\».

  Использование атрибутов позволяет проводить эксперименты (например, построить ROC-кривую по заданной выборке) и получать результаты, при этом не сохраняя лишние данные в базу данных.

- В документ \«LP_Administration_manual\» добавлен раздел \«Сохраняемые и оцениваемые данные\», который описывает данные, которые извлекает и хранит LP.

- Добавлена возможность записи логов сервисов LP на сервер при использовании Compose. Ранее при установке с помощью Compose было нельзя сохранять логи на сервер.

  Для сохранения логов на сервер следует предварительно создать директории для хранения логов сервисов и назначить права для этих директорий (см. \«Создание каталога журналов\»). Если права доступа к директориям логов на сервере не назначены, то логи не смогут быть записаны и сервис упадёт. После запуска контейнеров следует обновить настройки логирования в Configurator (вручную или с использованием файла logging.json), чтобы включить логирование в файлы в директорию \«/srv/logs\» в контейнере (см. \«Включение ведения журнала в каталог сервера\»).

  По умолчанию логирование в файлы на сервер выключено.

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

- Исправлена ошибка с отображением полных URL для событий и лиц вместо относительных в ответе на запрос POST в ресурс \«/handlers/{handler_id}/events\».
- В запросе GET \«/events\» отключено автоматическое задание фильтра по времени, если указаны ID событий. Ранее значение по умолчанию для данного фильтра задавалось неявно, если оно не было явно задано в запросе.
- Исправлено создание Docker-контейнера для сервиса Handlers. Размер контейнера уменьшился на 5 гигабайт

# v.5.3.0

Изменения

- Добавлена возможность сохранять исходные изображения. Сохраняемые изображения могут иметь следующие форматы: JPEG, PNG, BMP, TIFF, Portable pixmap.

  Для сохранения изображений используется ресурс \«/images\».

  Для получения существующих изображений и удаления изображений используется ресурс \«/images/{image_id}\».

  Изображения сохраняются в бакет \«visionlabs-image-origin\» в хранилище Image Store.

  URL сохранённого изображения можно указывать при выполнении запросов в ресурсы \«/detector\», \«/handlers/{handler_id}/events\», \«/verifiers/{verifier_id}/verifications\». Значение заголовка \«Content-Type\» такого запроса должно быть \«application/json\».

  Пример URL изображения, сохранённого в LUNA PLATFORM:

      http://<server_ip>:5000/6/images/10bc2cb4-db84-410d-adc7-ff2ac17e4b2d

- Изменена логика запуска сервисов LUNA PLATFORM внутри контейнеров. Теперь приложения запускаются не от пользователя root, а от пользователя luna.

  Данное изменение не коснулось контейнеров UI 3 и UI 4, а также сервисов построения индекса и сравнения по индексу.

- Прекращена поддержка детекторов FaceDetV1 и FaceDetV2.

  Если ранее использовался другой детектор, то FaceDetV3 будет автоматически задан как используемый детектор в настройке \«LUNA_HANDLERS_DETECTOR_TYPE\» после выполнения миграции настроек в сервисе Configurator. Миграция выполняется при обновлении базы данных Configurator.

- В политику сохранения событий (\«storage_policy\» > \«event_policy\») ресурса \«/handlers\» добавлен параметр \«wait_saving\». Он позволяет включать и отключать ожидание сохранения событий в БД Events перед отправкой ответа.

  - При отключённом параметре ответ на запрос \«/handlers/{handler_id}/events\» возвращается быстрее, но при этом система не присылает никаких уведомлений в случае, если не удалось выполнить сохранение. Данное поведение использовалось по умолчанию в предыдущих версиях LUNA PLATFORM.
  - При включённом параметре система дожидается сохранения событий перед отправкой ответа и возвращает код ошибки 500, если сохранение событий не удалось.

  Параметр \«wait_saving\» включен по умолчанию.

  Параметр будет автоматически добавлен в \«storage_policy\» уже созданных обработчиков при выполнении миграции базы данных сервиса Handlers. Для уже существующих обработчиков параметр будет выключен по умолчанию, чтобы не изменять поведение системы. Миграция выполняется автоматически в процессе установки при обновлении базы данных Handlers.

- Добавлена возможность указывать значение \«application/msgpack\» в качестве заголовка \«Content-Type\» для ресурсов:

  - \«/matcher/faces\»
  - \«/matcher/bodies\»

  MessagePack упаковывает данные эффективнее, чем JSON. Это бинарный формат, поэтому не требует декодирования из BASE64.

- Версия CUDA в контейнере сервиса Handlers обновлена до версии 11.1.

- В документе LP_Administration_Manual дополнено описание для использования сетей извлечения биометрических шаблонов версий 46 и 52 (раздел \«Переключение на нейросеть версии 46 или 52\»).
- Увеличена скорость выполнения задач перекрестного сравнения.

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

- Исправлена ошибка при выполнении сравнения с использованием биометрических шаблонов, полученных 58 версией нейросети.
- В сервисе Admin исправлена ошибка при авторизации с использованием cookies. При попытке авторизации возвращался 500 код ошибки.
- В сервисе Admin исправлена ошибка при открытии страницы с аккаунтами.
- Исправлено падение при обработке символа новой строки в запросе в сервис Events при использовании БД Vertica. При наличии в запросе символа \«\n\» теперь возвращается ошибка..

# v.5.2.1

Изменения

- Сервис API:
  - Была исправлена валидация полей даты и времени для ресурсов, использующих фильтры [create_time__gte]{.title-ref} и [create_time__lt]{.title-ref}. При указании даты и времени в формате UTC (в поле использовался суффикс \«Z\») возникала ошибка. Пример ошибки: \«2018-08-11T09:11:41.674Z\».
  - Исправлена валидация для политики \«match_policy\» при задании событий в качестве кандидатов для сравнения. При некорректном задании фильтров для событий возвращалось неправильное сообщение об ошибке: \«unexpected value; permitted: 'faces'\», если фильтры для событий были установлены неправильно.
- Сервис Admin:
  - Исправлена внутренняя ошибка с кодом ответа 500 для запросов без авторизационных данных.
  - При авторизации с использованием неправильной пары логин/пароль теперь возвращается ошибка \«BadAdminAuth\».

# v.5.2.0

Изменения

- Появилась поддержка 57 и 58 сетей извлечения биометрических шаблонов. По умолчанию LUNA PLATFORM использует 56 сеть. Описание смены используемой версии нейросети можно найти в разделе \«Переключение версии нейросети\» документа LP_Administration_Manual.

  В данной сборке 57 и 58 сети не поддерживаются в Сервисах построения индекса и поиска по индексу, т. к. для них не был обновлён SDK.

  Нейросети версий 46 и 52, которые могут потребоваться для обратной совместимости, в дистрибутиве не предусмотрены. Они предоставляются VisionLabs по запросу. См. раздел \«Переключение на нейросеть версии 46 или 52\» в документе LP_Administration_Manual для получения информации о добавлении этих нейросетей в контейнер Handlers.

- Добавлен новый механизм Liveness V2. Теперь его можно использовать в ресурсах \«/liveness\» и \«/sdk\».

  Liveness с использованием отдельного сервиса теперь называется Liveness V1.

  Важно, что Liveness v2 не требует отдельного сервиса, он является частью сервиса Handlers. Поэтому опция \«liveness\» в \«ADDITIONAL_SERVICES_USAGE\» должна быть отключена при использовании Liveness v2.

  В ресурсе \«/liveness\» можно использовать как новый Liveness v2, так и Liveness v1. Liveness V2 доступен для ресурса \«/liveness\» сервисов API, Backport 3 и Backport 4. Запрос (кроме раздела metadata) и возвращаемый результат в данном ресурсе будут иметь одинаковый формат для обоих Liveness. Раздел metadata не используется для Liveness V2.

  Liveness V1 не используется в ресурсе \«/sdk\». Если отправить запрос на этот ресурс и указать \«estimate_liveness = 1\» при включённом Liveness V1, то вернётся ошибка.

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

  - 0 — Liveness не используется
  - 1 — Используется механизм Liveness V1
  - 2 — Используется механизм Liveness V2

  Не требуется обновлять лицензию LUNA PLATFORM, если она у уже есть и не требуется использовать Liveness V2. В противном случае необходимо обновить существующий ключ.

  Описание работы механизмов Liveness дано в разделе \«Описание Liveness\» документа LP_Administration_Manual. Также там приведены таблицы условий работы версий Liveness для ресурсов \«/sdk\» и \«/liveness\».

  См. требования для Liveness V2 в разделе \«Требования к Liveness V2\».

- Поворот изображений:

  - Добавлена возможность автоматического поворота изображения на основе EXIF данных (параметр \«use_exif_info\»). Данная возможность добавлена в ресурсы:

    - \«/detector\»
    - \«/verifiers/{verifier_id}/verifications\»
    - \«/handlers/{handler_id}/events\»
    - \«/sdk\»

    Параметр \«use_exif_info\» включен по умолчанию.

    Если в запросе указано, что обработанное изображение является биометрическим образцом, опция игнорируется.

  - В конфигурации сервиса Handlers добавлена опция \«LUNA_HANDLERS_USE_AUTO_ROTATION\». Она позволяет включить режим автоматического поворота изображения, если оно повёрнуто на 90, 180, 270 градусов.

    Данная сеть потребляет значительное количество ресурсов сервера, поэтому по умолчанию она выключена.

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

  Две вышеперечисленные опции автоматического поворота и поворота на основе EXIF данных можно использовать совместно.

- Прекращена поддержка сервиса CORE Matcher. Все операции для сравнения по спискам теперь выполняются с помощью сервиса Python Matcher.

  Для увеличения производительности настройка \«cache_enabled\» для данного сервиса должна быть выставлена в True (выставлена по умолчанию). В этом случае биометрические шаблоны будут сохраняться в оперативную память и быстрее обрабатываться Python Matcher.

- При использовании внешней СУБД PostgreSQL (не контейнера PostgreSQL из комплекта поставки) следует пересоздать функцию сравнения в БД с добавлением директивы \«PARALLEL SAFE\». Эта директива ускоряет сравнение по базе данных.

  Эта директива будет добавлена автоматически во время базовой установки контейнера PostgreSQL из дистрибутива.

  Пример строки для удаления функции из базы данных: `DROP FUNCTION VLMatch;`.

  Пример строки для добавления функции:

      CREATE FUNCTION VLMatch(bytea, bytea, int) RETURNS float8 AS 'VLMatchSource.so', 'VLMatch' LANGUAGE C PARALLEL SAFE;

# v.5.1.3

Изменения

- Добавлен заголовок Accept для ресурса \«/sdk\», который позволяет указать content-type запроса: JSON или MessagePack. MessagePack упаковывает данные эффективнее, чем JSON. Это бинарный формат, поэтому не требует декодирования из BASE64. См. \«sdk\» > \«sdk resource\».
- В ресурс \«/sdk\» в сервисе API добавлено определение наличия очков. См. \«sdk\» > \«sdk resource\».

- В API в ресурсы \«/lists\» и \«/lists/count\» для метода GET добавлены фильтры "list_id__gte" и "["list_id__lt". Полученные списки сортируются по list_id.

  С помощью данных фильтров можно выполнять пагинацию, которая:

  - быстрее пагинации по параметрам \«page\» и \«page_size\». Она не замедляется при большом числе списков
  - стабильнее пагинации по параметрам \«page\» и \«page_size\». Изменения списков в процессе пагинации не приводят к потере списков или их дублированию в ответе.

  См. \«lists\» > \«get lists\»

  См. \«lists\» > \«get lists count\»

- В сервис Faces добавлен ресурс \«/lists/deletions\», который позволяет отслеживать историю удаления списков. См. \«administration\» > \«get lists deletions\».

  В сервис Faces добавлено ведение лога удалённых списков. См. \«administration\» > \«clear lists deletions log\».

- В сервисе Tasks в ресурсе \«/additional_extract\» добавлена возможность извлекать базовые атрибуты для лиц, для которых доступны биометрические образцы (samples), но нет извлечённых базовых атрибутов. См. \«tasks processing\» > \«additional extract task\».

- В сервисе Events в ресурсе \«/events\» при использовании метода POST добавлен query параметр \«wait_events_saving\». См. \«events\» >\«create new events\».

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

  При выключенном параметре система не ожидает сохранения событий в базу, а отправляет ответ сразу после проверки события и добавления его в буфер.

- В сервисе Python Matcher уменьшено потребление памяти при кэшировании большого числа маленьких списков.

# v.5.1.2

Изменения

- Добавлена возможность задавать количество \«рабочих процессов\» (workers) для сервисов. Запросы автоматически балансируются между активными процессами. Для задания количества процессов в Docker-контейнерах используется настройка WORKER_COUNT.

  Для увеличения количества экземпляров сервисов LUNA на одном сервере рекомендуется увеличивать количество \«рабочих процессов\», а не запускать дополнительные контейнеры сервисов.

  Не рекомендуется увеличивать количество \«рабочих процессов\» для сервиса Handlers при использовании GPU. Могут возникнуть проблемы при недостаточном количестве памяти GPU и \«рабочие процессы\» будут препятствовать друг другу.

  См. раздел \«Рабочие процессы\» в LP_Administration_Manual.pdf.

- Добавлен функционал обновления настроек сервисов без перезагрузки самих сервисов. Настройки могут быть получены как из сервиса Configurator, так и из конфигурационных файлов.

  Для включения данной возможности в контейнерах используется переменная RELOAD_CONFIG.

  Период проверки обновлений настроек задаётся переменной RELOAD_CONFIG_INTERVAL.

  Обратите внимание, что во время изменения важных системных настроек (настроек баз данных, списка плагинов и др.) не следует отправлять в сервис запросы.

  См. раздел \«Автоматическая перезагрузка конфигураций\» в LP_Administration_Manual.pdf и раздел \«Configuration\» в \«ServiceManuals\» каждого сервиса.

- В раздел конфигурации \«ADDITIONAL_SERVICES_USAGE\» добавлена настройка \«Matcher\» для включения и отключения использования CORE Matcher.

- В сервис Faces добавлен функционал `missing basic attributes`. Функциональность позволяет:
  - Получить лица, не имеющие базовых атрибутов \«administation\» > \«get faces without basic attributes\»;
  - Получить количество лиц без базовых атрибутов \«administation\» > \«get face count without basic attributes\»;
  - Получить количество базовых атрибутов, связанных с лицами \«administation\» > \«get basic attributes count info\».
- Добавлен параметр \«DB_CONNECT_TIMEOUT\» в конфигурацию сервиса Events.
- Удален скрипт dump_emails.py из сервиса Admin.

# v.5.1.1

Изменения

- Добавлена возможность указывать атрибуты в качестве кандидатов для сравнения в ресурсе \«/matcher/faces\» в APIReferenceManual.html. Это позволяет выполнять сравнение биометрических шаблонов без создания объекта face или event для кандидата.
- Доступен механизм миграции настроек в сервисе Configurator. Перенос настроек выполняется без изменения пользовательских значений. Для применения этого механизма к LP build 5.1.0 требуются дополнительные действия, которые описаны в руководстве \«LP_Docker_Upgrade_Manual.html\».
- Для событий добавлено поле \«track_id\». Оно позволяет отмечать события, принадлежащие одному и тому же человеку, для последующего анализа. Вы должны вручную указать \«track_id\» в запросе \«/handlers/{handler_id}/events\». Данное поле можно использовать:
  - в качестве фильтра для кандидатов сравнения;
  - Для задач перекрестного сопоставления, кластеризации, компоновщика и репортера. В задаче кластеризации теперь можно указать, следует ли добавлять события с одинаковым \«track_id\» в тот же кластер.
- Вы можете указать настройки из БД Configurator при выполнении миграции с помощью Alembic.

    alembic -x luna-config=http://127.0.0.1:5070/1 upgrade head

- Добавлены примеры для использования ресурса \«ws\» в документацию \«SenderReferenceManual.html\».
- Теперь возвращается ошибка в случае, когда в политике storage_policy указано сохранение событий, но сам сервис не используется. В этом случае возвращается ошибка 403 Forbidden 11040 \«Luna Events service is disabled\».

- Исправлена неправильная ссылка на нормализованное изображение, возвращаемая при генерации событий \«events\» > \«generate events\».

  Ссылка в предыдущей сборке LP:

  «url»: «http://image-store:5020/1/buckets/visionlabs-samples/images/2e8045f2-14cd-4c8b-af3a-7c959e85fe6f\»

  Исправленная ссылка:

  «url»: «/6/samples/faces/939fca8a-753f-4ee4-8450-9c1bb3c1f76c»