1. Введение

То, что ещё пять лет назад уверенно делал только живой наблюдатель, нейросетевые модели сегодня выполняют на сыром видеопотоке. Распознавание утопающего — пример из этого списка. Сложность задачи смещается из самих моделей в инженерное окружение: научить классификатор отличать утопление от плавания — лишь полдела. Вторая половина — это превратить такой классификатор в систему, у которой на каждую камеру приходится не более одного ложного срабатывания в час, реакция занимает считанные секунды, а замена любого нейросетевого блока не тянет за собой переобучения остальных. Настоящая статья — про эту вторую половину: про то, как из готовых моделей и нескольких хорошо подобранных инженерных компонентов собирается рабочая система видеоаналитики.

В литературе подходы к задаче распадаются по линии «один шаг — два шага». В одношаговой схеме

[1][2]

Двухшаговую схему мы развиваем до уровня системно-инженерного решения. Поверх ансамбля «свёрточный детектор + темпоральный классификатор» добавлены три компонента, без которых лабораторный прототип не превращается в эксплуатируемую систему: межкадровый трекинг для ассоциации детекций по кадрам; постобработка с накоплением вероятностей в скользящем окне и пороговым решающим правилом; механизм адаптивной калибровки порога по статистике, набираемой непосредственно на объекте установки. По отдельности каждый из них хорошо известен, но именно их согласованное сочетание решает, окажется ли в итоге сильная сеть нейросетей в руках спасателя или останется презентационной демонстрацией.

2. Системная постановка задачи

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

(c, k, t, p)

Качество распознавания приходится оценивать на двух уровнях, и метрики эти неравноценны. На уровне отдельного объекта (одна последовательность поз, один кадр) работают классические точечные метрики — accuracy, precision, recall, F1 — с целевым порогом

Эксплуатационные характеристики — это стоимость и масштаб. Целевая аппаратная платформа — серийная игровая видеокарта класса NVIDIA RTX 3060 или RTX 4080; один сервер обязан тянуть одновременно 4–8 камер 720p на частоте не ниже 15 Гц без потери качества. Сеть — обычная гигабитная локальная; видеопоток — по штатным RTSP, ONVIF или UVC.

Системная гибкость — это требования к раздельной жизни компонентов. Появилась новая версия YOLO

[3]

Эти три группы требований и определяют форму архитектуры, к описанию которой мы переходим.

3. Двухмодельная ансамблевая архитектура

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

[4][5]

Уровень оценки поз и детекции — главное вычислительное звено. На нём работает YOLOv8m-Pose

[6]

Уровень формирования признаков превращает поток детекций в поток 89-мерных векторов признаков на каждый объект (структура вектора и обоснование выбора компонентов даны в отдельной работе авторов). Параллельно с этим работает межкадровый трекинг, связывающий детекции одного и того же пловца в соседних кадрах в общий трекер; алгоритм описан в Разделе 3. Каждый трекер хранит буфер из 30 последних векторов признаков, готовый к подаче в темпоральную модель. CPU, 0,3–0,8 мс на кадр.

Уровень темпоральной классификации — двухслойная двунаправленная LSTM с аддитивным вниманием, обученная разделять три класса состояний пловца: «активное плавание», «пассивное пребывание в воде», «утопление». Структурно это компактная рекуррентная сеть: последовательность из 30 векторов признаков размерности 89 обрабатывается двумя двунаправленными слоями LSTM по 128 ячеек в каждом направлении (что даёт 256-мерное контекстное представление на каждом временном шаге), поверх которых аддитивный механизм внимания типа Bahdanau взвешивает 30 временных шагов и сворачивает их в единый дескриптор, акцентируя наиболее информативные моменты последовательности; полносвязный слой с softmax преобразует этот дескриптор в распределение по трём классам, а dropout между рекуррентными слоями отвечает за регуляризацию. Когда буфер трекера набирает 30 кадров, его содержимое подаётся на вход модели. Вероятность класса «утопление» уходит в скользящее окно истории длиной 90 значений, около трёх секунд. Темпоральный классификатор на два порядка легче пространственного детектора — порядка 636 тыс. обучаемых параметров против ~25 млн у YOLOv8m

[7]

Уровень постобработки превращает поток вероятностей в поток событий тревоги. Здесь работают три этапа: накопление вероятностей в скользящем окне, усреднение и пороговое решающее правило с периодом «тишины» после срабатывания. Подробности — в Разделе 4. Снова CPU, 0,2–0,5 мс на кадр.

Распределение нагрузки между уровнями для типовой камеры 1280 × 720 на RTX 4080 сведено в таблицу 1.

Из таблицы виден главный инженерный факт: время обработки кадра практически целиком расходуется на втором уровне. Любая работа над производительностью имеет смысл прежде всего там — к этому мы вернёмся в Разделе 6 при анализе режимов вычислений TensorRT

[8]

Архитектура из пяти уровней даёт три практических преимущества. Первое: пространственная и темпоральная модели обучаются раздельно. Темпоральная видит не пиксели, а уже извлечённые векторы признаков, и поэтому её обучение требует на порядок меньшего размеченного корпуса видео, чем у одношаговой схемы. Второе: модели заменяются независимо. Появилась новая версия YOLO — переучиваем уровень 2, темпоральный классификатор остаётся прежним; специфика бассейна изменилась — дообучаем уровень 4, детектор не трогаем. Третье: архитектура естественно масштабируется по числу камер. Каждая камера обрабатывается отдельным потоком, а тяжёлые нейросетевые модели переиспользуются между потоками через общую очередь задач, без дублирования GPU-памяти.

4. Алгоритм межкадрового трекинга

Темпоральный анализ имеет смысл только тогда, когда детекции одного и того же пловца в соседних кадрах оказываются привязаны друг к другу — то есть собираются в траекторию. Это классическая задача multi-object tracking; для неё есть длинный ряд готовых алгоритмов: от простейшего IoU-трекинга в SORT до многокомпонентных решений с фильтром Калмана

[9][10]

Бассейн как сцена для трекинга — относительно лёгкая задача. Одновременно в кадре редко бывает больше восьми– десяти пловцов. Перекрытия — короткие: нырнувший за чужую спину пловец появляется обратно через секунду–три. Купальные принадлежности обычно одноцветны, и градиентное сопоставление по внешнему виду в этих условиях малопродуктивно. Скорости движения умеренные, резкие телепортации возможны разве что при прыжке с трамплина. В таком режиме DeepSORT и ByteTrack дают почти неразличимое улучшение качества ассоциации при существенно более высокой вычислительной стоимости.

Поэтому в качестве алгоритма принят простейший IoU-трекинг. Логика следующая: для каждого нового обнаружения в текущем кадре считаются значения IoU с прямоугольниками всех активных трекеров; обнаружение прикрепляется к тому трекеру, у которого этот показатель максимален и не ниже 0,3; если ни один трекер не подошёл — заводится новый с уникальным идентификатором. IoU для двух прямоугольников

Значение лежит в [0, 1]:

IoU = 0IoU = 1

Трекер закрывается, если в течение пяти секунд (150 кадров при 30 Гц) на него не приходит обновлений. Это значение покрывает основную массу перекрытий: если пловец на это время скрылся за другим, после выхода из перекрытия его трекер восстанавливается. Если же скрытие длится дольше, трекер закрывается окончательно, а после возврата объекта в кадр заводится новый — со следствием, что в течение примерно секунды (пока буфер не наберётся снова) темпоральный анализ для этого объекта не работает. На практике это редкая и не критичная ситуация: устойчивая неподвижность за чужой спиной маловероятна как сценарий начала утопления.

Каждый трекер несёт три буфера и метки времени: последний ограничивающий прямоугольник, метку последнего обновления, 30 последних векторов признаков (вход в темпоральную модель), 90 последних значений вероятности класса «утопление» (для скользящего усреднения — см. Раздел 4) и копию ключевых точек предыдущего кадра, нужную для подсчёта компоненты межкадровых скоростей в векторе признаков.

Сравнение IoU-трекинга с альтернативами проведено на собранном тестовом наборе из 25 видеороликов (142 траектории, 7 ч непрерывной съёмки); результаты — в таблице 2.

Картина типичная: сложные алгоритмы выигрывают в MOTA

[11]

5. Постобработка и адаптивная калибровка порога

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

Решение — трёхэтапная постобработка. На первом этапе каждый трекер ведёт скользящее окно из 90 последних значений вероятности класса «утопление» (около трёх секунд при 30 Гц): новое значение от темпоральной модели поступает в буфер, самое старое выпадает. На втором этапе из буфера берётся арифметическое среднее:

где

[12]

К этим трём этапам добавляется период «тишины» после срабатывания. Следующее событие на том же трекере не может быть сформировано раньше, чем через 30 секунд, либо до явного подтверждения или отклонения предыдущего оператором. Без такого блокировщика длящийся инцидент превращается в десяток повторов одной и той же тревоги, забивающих оператору экран.

Прежде чем остановиться на скользящем среднем, мы перепробовали несколько альтернатив: экспоненциальное скользящее среднее с параметром α, медианное окно вместо арифметического, цепи Маркова

[13]

Главный параметр в этой схеме — порог

Чтобы не возлагать подбор T на эксперта, в систему встроена адаптивная калибровка. На этапе ввода в эксплуатацию администратор включает калибровочный режим длительностью 24–72 часа. В этом режиме система обрабатывает поток обычным образом, но события не формирует — вместо этого она собирает по всем трекерам статистику усреднённых вероятностей класса «утопление». По окончании периода вычисляется эмпирическое распределение этих вероятностей в нормальной (без инцидентов) эксплуатации, и поверх него ищется рекомендованное значение порога

где

PFN(T) PFp(T)WFN, WFPWFN / WFP

Дополнительно алгоритм может подбирать и длину окна сглаживания, опираясь на автокорреляционную функцию вероятностей: медленный спад автокорреляции говорит, что наблюдения сильно коррелированы во времени, и тогда выгоднее короткие окна; быстрый — длинные. Но на практике у большинства обследованных бассейнов оптимальное окно оказывается в одном и том же диапазоне 60–90 кадров, поэтому в текущей версии длина окна фиксирована на 90.

Интерфейс калибровки оформлен отдельным административным модулем в клиентском приложении, доступным ролям «admin». Он показывает гистограмму распределения вероятностей по итогам калибровочного периода, рекомендованное T*, кривую Парето «частота ложных срабатываний — полнота» и таблицу метрик при разных значениях порога. Применить рекомендацию – одно нажатие; повторная калибровка может проводиться регулярно, например раз в квартал.

Над постобработкой надстроена логика обработки одновременных событий и эскалации. Если в течение 15 секунд на той же камере уже зарегистрировано неотработанное событие, новое событие группируется с предыдущим (через общее поле group_id в БД) — это нужно при массовых инцидентах, когда в опасности оказываются сразу несколько человек. Эскалация трёхуровневая. Первый уровень — оповещение оператора через клиентское приложение и звуковой сигнал; второй (если оператор не подтвердил и не отклонил событие за 30 секунд) – push-уведомление администратору объекта; третий (90 секунд без реакции) — автоматическое сообщение дежурной службе спасения через настроенный канал (SMS, push, e-mail). Параметры эскалации настраиваются администратором при развёртывании.

6. Экспериментальное исследование

Свёрточный детектор обучался на публичном наборе «Drowning Detection and Prevention in Swimming Pools» с платформы Roboflow Universe — 5 207 размеченных изображений с двумя классами «swimming» и «drowning», разделённых на обучающую, валидационную и тестовую подвыборки в пропорции 70 : 15 : 15 со стратификацией по классам. Для проверки полного пайплайна и измерения системных метрик дополнительно собран отдельный тестовый набор из 25 видеороликов общей длительностью 1 ч 22 мин, не пересекающийся с обучающими данными ни по источнику, ни по содержанию.

Стартовой точкой обучения детектора послужили предобученные веса yolov8m.pt с COCO. Гиперпараметры подобраны несколькими предварительными запусками: 150 эпох с ранней остановкой по терпению 30, мини-батч 16, размер изображения 640 × 640, оптимизатор AdamW

[14]

Метрики качества детектора на валидационной и тестовой подвыборках сведены в таблицу 3.

Падение метрик на тесте относительно валидации мизерное, существенного переобучения нет. Бóльшая часть ошибок приходится на класс «drowning» (precision 0,754, recall 0,723) — это естественно: примеров утопления меньше, и разнообразие визуальных проявлений у них шире. Часть таких ошибок снимается уже на следующем уровне: темпоральный анализ умеет отличать единичную необычную позу от устойчивого паттерна утопления, и в системных метриках вклад детектора частично «съедается».

Сравнение разных моделей семейства YOLO мы тоже проверили. Меньшие версии (YOLOv8n, YOLOv8s) дают инференс за 5,7 и 8,2 мс/кадр соответственно, но проигрывают 6–9 пунктов mAP@0.5. Большие версии (YOLOv8l, YOLOv8x)

[15]

Полный пайплайн (детекция → оценка поз → темпоральная классификация → постобработка) тестировался на отдельном наборе из 25 видеороликов: 18 нормальных сцен плавания общей длительностью 7 ч и 7 видео с инцидентами утопления, отснятыми спасателями в виде тренировочных имитаций. На этом наборе зафиксировано: 23 истинно положительных срабатывания из 25 размеченных инцидентов, 2 пропуска (FN), 7 ложных срабатываний (FP) за 7 часов нормального плавания. Системные метрики уровня инцидентов: precision = 0,77, recall = 0,92, F1 = 0,84; частота ложных срабатываний ≈1 событие в час на одну камеру; средняя задержка обнаружения — 2,9 секунды (от размеченного экспертом начала инцидента до момента, когда система выдала событие). Целевые системные характеристики из Раздела 1 (FP/час ≤ 1, задержка ≤ 5 с) выполнены. Следует оговорить, что тестовый набор из 25 роликов невелик по объёму – это прямое следствие специфики задачи, в которой реальные инциденты крайне редки, а их этичная и безопасная имитация трудозатратна; путь к расширению валидационной выборки намечен в Заключении.

Чтобы изложение оставалось самодостаточным, напомним ключевые показатели темпорального классификатора, подробно описанного в отдельной работе авторов: на трёхклассовой задаче («активное плавание» / «пассивное пребывание в воде» / «утопление») он даёт точность (accuracy) 0,920 и F1 = 0,924 по ключевому классу «утопление». Системная F1 полного пайплайна оказывается ниже этой точечной оценки. Это закономерное снижение: к ошибкам классификатора добавляются ошибки детектора (часть пловцов теряется в бликах и волнении) и эффекты постобработки (короткие пиковые значения вероятности не успевают пробиться через трёхсекундное усреднение). Подобное расхождение между метриками компонента и метриками системы — типичное свойство многоуровневых пайплайнов и в нашей конфигурации удерживается на разумном уровне.

Систему, которая будет работать в реальном бассейне круглосуточно, имеет смысл проверять не только в стерильных условиях. Шум матрицы, артефакты сжатия, дрожание камеры, неудачно выставленная экспозиция — всё это нормальный фон видеопотока, и качество распознавания на нём не должно проваливаться. Для проверки тестовый набор был пропущен через серию синтетических искажений; результаты — в таблице 4.

Слабые и умеренные искажения (шум до σ = 0,03, снижение разрешения до ×0,5, JPEG quality 50, изменения экспозиции до 25%) почти не задевают качество — точность падает максимум на пункт. Существенная деградация — больше трёх пунктов — наступает только при экстремальных уровнях, которые на нормальном объекте устраняются адекватным выбором и обслуживанием оборудования. Главный практический вывод связан с разрешением: пайплайн уверенно отрабатывает даже на 320 × 180 (то есть на ×0,25 от 1280 × 720), и это означает, что для развёртывания достаточно сравнительно недорогих 720p-камер, а в ряде случаев и 480p — что заметно снижает капитальную стоимость объекта.

Аналогичный анализ зависимости качества от условий освещения и характера сцены— в таблице 5.

В типовых условиях общественного бассейна — хорошее или среднее освещение – система работает уверенно. Существенный провал начинается на сценариях, которые в реальном проекте устраняются грамотной светотехникой и регулярным обслуживанием: сумерки, прямой солнечный свет с бликованием, конденсат на остеклении. Для сумерек рекомендация — добавить инфракрасный канал; для бликующего солнечного света — поляризационные фильтры на объективы.

7. Режимы вычислений и масштабируемость

Время обработки одного кадра – главное, что определяет, сколько камер реально вешается на один сервер. Уровень 2 (YOLOv8m-Pose) занимает порядка 80 % всего бюджета, и работа над ним даёт максимальный выигрыш в пропускной способности. Простейшая реализация на PyTorch FP32

[16]

Оптимальным режимом признан TensorRT FP16: ускорение в 3,1 раза при потере точности всего в 0,3 пункта. Однако эмпирические испытания масштабируемости делались на референсной конфигурации PyTorch FP16 (AMP) — именно по ней в таблице 7 указано максимальное число одновременно обрабатываемых камер. Оценка построена в два уровня. «Наивная» — простое деление пропускной способности GPU (1000 / время кадра) на требуемую частоту обработки одной камеры, без учёта какого-либо параллелизма. «Эмпирическая» — фактически наблюдаемое на стенде число одновременно обрабатываемых камер при включённом батчинге и конвейеризации передачи данных между CPU и GPU. Зазор между двумя оценками — это и есть выигрыш от того, что тяжёлая нейросетевая модель амортизирует постоянные накладные расходы на пакетной обработке. Прямые эмпирические измерения сделаны на RTX 4080; для RTX 3060 и Jetson AGX Orin это прогнозные оценки, полученные масштабированием по числу CUDA-ядер и пропускной способности памяти. При переходе на TensorRT FP16 ожидается дополнительное ускорение в 1,5–1,7 раза и пропорциональный рост числа поддерживаемых камер — примерно до 22–25 на RTX 4080.

Из этого вытекает простая практическая раскладка. Для типового бассейна (4–8 камер) достаточно сервера на NVIDIA RTX 3060 в режиме PyTorch FP16 — это решение за 100–150 тыс. руб. Для крупного аквапарка (12–16 камер) уместна RTX 4080; если нужен запас по числу камер — переходим на TensorRT FP16 и получаем дополнительный кратный прирост (см. таблицу 6). Для распределённого развёртывания, где обработка ведётся прямо у камеры, годится встраиваемая платформа Jetson AGX Orin

[17]

Сетевая нагрузка скромная: одна камера 720p H.264 даёт 2–4 Мбит/с, шестнадцать камер агрегированно — около 64 Мбит/с, что свободно укладывается в типовую гигабитную локальную сеть. Поток исходящих результатов (события, скриншоты, телеметрия) в обычной эксплуатации не превышает 1 Мбит/с.

8. Сравнение с существующими решениями

Чтобы понять, где предложенная архитектура находится относительно известных решений, сравним её с тремя коммерческими системами (Poseidon, AngelEye, MyLifeguard) и двумя академическими работами

[1][2]

По полноте обнаружения утопающих (recall) наша архитектура попадает в диапазон лучших академических работ

[1][2][2][1][2]

Ограничений три, и о них честнее сказать прямо. Первое – отсутствие поддержки подводных камер; добавление планируется через отдельную модель оценки поз, обученную на подводных изображениях с учётом преломления и цветовых искажений. Второе — ограниченная устойчивость в ночных условиях; требуется дополнительная инфракрасная подсветка. Третье — рекомендованное расстояние от камеры до пловца не более 8–10 метров: дальше начинает просаживаться качество оценки поз.

9. Заключение

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

Архитектура устроена как пятиуровневый конвейер: захват, оценка поз и детекция, формирование признаков, темпоральная классификация, постобработка. Главная инженерная идея — раздельность пространственного и темпорального анализа: пиксельную работу делает YOLOv8m / YOLOv8m-Pose, поведенческий анализ — двунаправленная LSTM с аддитивным вниманием, обучаемая отдельно. Из такого разделения следуют три полезных свойства: модели обновляются независимо, темпоральная часть требует на порядок меньшего размеченного корпуса видео, а архитектура естественно масштабируется по числу камер.

Межкадровый трекинг — простой IoU-трекинг с порогом 0,3 и временем жизни трекера 5 секунд. По MOTA он отстаёт от DeepSORT/ByteTrack/BoT-SORT на 1,5–2,4 пункта, но выигрывает в скорости в 20–40 раз. В нашей конструкции это оправдано: подмена идентификатора не превращается в ложноотрицательное срабатывание, поскольку 90-кадровый буфер усреднения на пятом уровне инерционен и поглощает одиночные сбои трекинга.

Постобработка трёхэтапная: накопление вероятностей класса «утопление» в скользящем окне 90 кадров, их арифметическое усреднение и пороговое решающее правило с 30-секундной «тишиной» после срабатывания. Поверх работает адаптивная калибровка порога T*, минимизирующего взвешенную сумму вероятностей ошибок FN и FP по эмпирическому распределению, набираемому в калибровочный период. Этот механизм позволяет настроить систему под конкретный объект, не переобучая нейросети.

Свёрточный детектор YOLOv8m, обученный на 5 207 размеченных изображениях, на тестовой подвыборке даёт mAP@0.5 = 0,809 и F1 = 0,802. На отдельном наборе из 25 видеороликов полный пайплайн зафиксировал 23 истинно положительных срабатывания и 2 пропуска при 7 ложных срабатываниях за 7 часов нормального плавания. Это соответствует системным precision = 0,77, recall = 0,92, F1 = 0,84, частоте ложных срабатываний ≈1 событие в час на камеру и средней задержке обнаружения 2,9 секунды. Целевые системные характеристики из постановки задачи – FP/час ≤ 1 и задержка ≤ 5 с – выполнены.

Испытания на устойчивость показали, что пайплайн уверенно держит умеренные синтетические помехи: при гауссовом шуме σ ≤ 0,03, снижении разрешения до ×0,5, JPEG quality 50 и изменениях экспозиции до ±25% падение точности не выходит за один процентный пункт. Особенно полезен результат по разрешению: пайплайн работает даже при 320 × 180, и это означает, что для развёртывания достаточно сравнительно недорогих 720p- и 480p-камер. Анализ режимов вычислений выделил TensorRT FP16: ускорение в 3,1 раза при потере точности всего в 0,3 пункта. По эмпирическим испытаниям в режиме PyTorch FP16 одна RTX 4080 тянет 14–16 одновременных камер при 30 FPS; при переходе на TensorRT FP16 пропускная способность кратно растёт.

Сравнение с существующими решениями выглядит так: по recall (≈92 %) наша архитектура попадает в диапазон лучших академических работ; по частоте ложных срабатываний — ≈1 событие в час против 5–10 у коммерческих аналогов и ≈2 у

[2]

Дальнейшее развитие архитектуры мы видим по четырём направлениям. Первое – поддержка подводных камер: для этого нужна отдельная модель оценки поз, обученная на подводных изображениях с учётом преломления и цветовых искажений. Второе — добавление тепловизионного канала как параллельного источника, который выручит в сумеречных и ночных условиях, где видимый канал проседает. Третье — переход к более серьёзному алгоритму трекинга, например на основе фильтра Калмана, для сценариев с большим числом одновременных пловцов и значительной долей перекрытий: это особенно актуально для аквапарков и водных аттракционов. Четвёртое — расширение и диверсификация валидационной выборки: использованный тестовый набор из 25 роликов ограничен по объёму в силу самой природы задачи (реальные инциденты редки, а их безопасная имитация трудозатратна), и наиболее ценным его пополнением станут записи, накопленные на действующих объектах эксплуатации, — они позволят оценить систему в реальном многообразии сцен, оборудования и режимов освещения.

The additional file for this article can be found as follows: