Определение скорости объекта на видеопотоке является актуальной задачей в сфере компьютерного зрения и обработки видео, в частности, в области автономного вождения, контроля на дорогах, видеонаблюдения, спортивной аналитики. Скорость объектов может быть важной информацией в задаче трекинга, определения действий и других задач.
Большая часть имеющихся алгоритмов для вычисления скорости работает в частных случаях: камера неподвижна и требует ручной калибровки относительно объектов на кадре, или же известны параметры движения камеры. Например, системы слежения скорости на дорогах — в них используется калибровка камеры относительно объектов самой дороги. Камера зафиксирована, и скорость вычисляется как отношение фиксированного пути к времени, которое объект затратил на перемещение по данному пути. В случае, если камера сдвинется, вычисленное значение скорости может оказаться некорректным и камеру нужно калибровать заново.
В данной ситуации был бы полезен алгоритм, который мог бы обобщить вычисление скорости при любой скорости камеры. Тогда никакое смещение не будет влиять на итоговые значения скорости.
Самым простым решением было бы предоставить какой-нибудь очень большой и умной модели все возможные данные: кадры, ббоксы вокруг людей, их классы, команды… В общем, все, что было найдено на предыдущих этапах работы, поколдовать над моделью — и магическим образом она научилась бы предсказывать скорость. Однако в реальности все сложнее. Нет такого датасета, в котором для объектов на видео размечена их скорость в каждый момент времени (по крайней мере, в открытом доступе). Значит варианты обучения модели по имеющимся данным отпадают. Нужен алгоритм, который будет работать, не имея никакой заранее подготовленной информации об объектах и их скорости. Более того, иногда запись ведется с подвижных камер с неизвестными параметрами, например, записи футбольных матчей. В этом случае не получится четко сопоставить размер пикселя и размеры в метрах.
Поэтому мы разработали алгоритм, который учитывает движение камеры при помощи оптического потока. Оптический поток определяет движение пикселей между двумя последовательными кадрами. Изменения в потоке являются, смещением пикселей, анализируя которое, можно вычислить относительную скорость движения объекта и скорость фона вокруг него. Из физики известно, что вектор абсолютной скорости является их разностью. Так как смещение в пикселях можно пересчитать в смещение в метрах, то и абсолютная скорость движения в пикселях пересчитывается в скорость в м/с, что требуется для решения задачи.
Что такое оптический поток?
Для начала давайте математически определим, что значит «найти оптический поток»? Оптический поток, по сути своей, это движение пикселя между двумя кадрами. Математическим языком, задача состоит в определении вектора движения каждой точки на изображении. Для пары изображений пиксель в положении в момент времени с интенсивностью сместится на , , . Предполагая, что движения между кадрами мало, разложим функцию интенсивности в ряд Тейлора:
Классические методы решения задачи вычисления оптического потока — решение расписанной выше оптимизационной задачи численными методами. Существуют разные подходы к решению: выполнить суммирование локально на пересекающихся регионах (англ. patch-based или window-based approach), или же добавить сглаживание и искать глобальный минимум. Два самых известных метода (и реализованных в OpenCV) — метод Лукаса-Канаде и метод Фарнербэка. Методы отличаются подходами к решению (метод наименьших квадратов против полиномиального разложения), а также тем, что метод Лукаса-Канаде считает оптический поток для конкретного набора точек на изображении. Метод Фарнербэка считает его для всего изображения (англ. dense optical flow).
Более современный метод — нейронные сети. Вычисление поля происходит при помощи модели, обученной на парах кадров с известным оптическим потоком. В процессе разработки были рассмотрены разные модели, помимо SOTA. Если идти от более простого к сложному, то сначала задача решалась при помощи сверточных сетей, затем началось внедрение трансформерной архитектуры. Дальнейшие шаги направлены уже на поиск архитектуры, оптимальной по времени и памяти.
В итоговом варианте алгоритма использовалась SOTA-модель — Unimatch. Её особенность заключается в том, что она может решать несколько сходных задач — расчет карты глубины, расчет оптического потока и стереосогласование (англ. rectified stereo matching). Они объединены в единую задачу сопоставления пикселей в паре изображений, которая решается напрямую, сравнивая признаки. За счет добавления специфичных слоев самовнимания, а также алгоритмов обработки несопоставленных регионов, модель достигает лучших результатов в популярных бенчмарках.
Алгоритм
Итого, основной алгоритм состоит из следующих частей:
Детекция игроков на кадре
Вычисление матрицы гомографии по ключевым точкам на поле
Вычисление оптического потока для пар кадров
Вычисление скоростей игроков
Объединение полученных на предыдущем этапе координат в треки, аппроксимация скорости по каждому игроку
Сторонние модули — те, которые работают независимо от выполнения данной задачи, используется только результат их работы.
Детекция игроков выполняется при помощи модели YOLOv8. Она была дополнительно обучена для детекции игроков, вратарей, рефери и мяча на собранном нами датасете.
Модуль гомографии рассчитывает матрицу гомографии, которая позволяет пересчитать координаты точки на кадре в точку на футбольном поле. Мы обучили модель семантической сегментации, которая умеет выделять ключевые точки (их 32). Пример работы модели представлен на картинках ниже:
Зная положение ключевых точек в пространстве, можно рассчитать матрицу гомографии. Применяя перспективное преобразование, получим положение всех точек кадра в пространстве, а значит, реальное положение футболистов на поле.
Так как игроков на поле много, то нужно их однозначно идентифицировать для построения графика скорости. Для этого используется трекер SportsTrack (ссылка на arXiv.org, github). Аппроксимация полученного массива скоростей выполняется при помощи фильтра Савицкого-Голея.
Рассмотрим более подробно, как пересчитать оптический поток в скорость.
Вычисление скоростей игроков
Основная идея расчета скорости заключается в том, что нужно отделить оптический поток игрока от потока фона, в качестве движения игрока при неподвижной камере принять разность значений. Затем выполняется конвертация расстояний в единицы измерения пространства (пиксели в метры).
Однако возник вопрос — что принять за оптический поток фона? Камера может двигаться неравномерно по осям и даже поворачиваться в процессе. При анализе оптического потока в ограничивающем прямоугольнике игрока было замечено, что возвращаемые значения на фоне и на изображении игрока достаточно сильно отличаются. Значит, за фон для каждого конкретного игрока можно взять оптический поток вокруг него.
Но как математически понять, где фон, а где сам игрок? Как найти границу между ними? Если построить гистограмму значений по каждой оси, то в идеальном случае видны два пика, но численная граница между ними всегда разная и не может быть унифицирована.
По своей структуре тепловая карта похожа на одноканальное изображение. Для бинаризации изображений с двумя выраженными пиками на гистограмме и неизвестным порогом используется алгоритм Отсу (википедия). Он адаптивным способом ищет порог t таким образом, чтобы минимизировать взвешенную внутриклассовую дисперсию.
Более подробные формулы:
Взвешенная внутриклассовая дисперсия для двух классов с порогом t:
Здесь дисперсия и веса для каждого класса считаются по следующим формулам:
В формулах производится итерация по всем значениям пикселей от 0 до 255. Именно поэтому применить классический алгоритм бинаризации невозможно — у тепловой карты отсутствуют верхний и нижний порог. Можно адаптировать алгоритм — задать число интервалов для построения вероятностей попадания значения в интервал. В качестве количества столбцов гистограммы используется число целых чисел между максимальным и минимальным значением в матрице, если оно больше 20, иначе ровно 20. Вероятности для каждого интервала — количество значений (высота столбца гистограммы), деленное на сумму значений (необходимо для их нормализации на диапазон [0, 1]).
В результате работы алгоритма получается бинарная маска. Также необходимо определить, какая часть маски принадлежит игроку, а какая — фону. Без дополнительного анализа нельзя точно сказать, каким индексом закодирован игрок — 0 или 1. Для определения части с игроком используются ключевые точки игрока, рассчитанные для работы других модулей — плечи, бедра, колени и голова. Кисти и ступни не используются, так как могут быть расположены далеко от тела. Та область, в которую попадает большинство основных точек, считается областью с игроком.
В результате работы алгоритма получены скорости для всех игроков на видео. Пример графика для одного из видео показан на рисунке.
Подводя итог
Безусловно, алгоритм еще требует значительной доработки. Необходимо максимально оптимизировать модели, чтобы алгоритм занимал минимальное время и объем видеопамяти.Также для повышения точности алгоритма необходимо повышать качество работы отдельных частей — детектора, трекера. Также нужны значительные доработки в алгоритм поиска матрицы гомографии, ведь камера бывает расположена таким образом, когда захваченных в поле зрения точек недостаточно для расчета матрицы гомографии. Как еще один вариант улучшения работы алгоритма — дообучить модель расчета оптического потока на синтетическом датасете, созданном специально для конкретной задачи.
В общем и целом, данный алгоритм решает поставленную задачу и может стать основой для более глубокого исследования темы вычисления скорости по видео.
strvv
Да, эти все методы требуют достаточно высоких значений памяти (мультипликативный от разрешения и количества кадров и Н) и производительности процессора.
Делал неспешно на микроконтроллер с 640*480 камеру под большим углом (~70-80) от горизонта, для наблюдения за ближним полем у машины вычисления траекторий.
С него модифицировать видеопоток - указать безопасные и опасные препятствия при плотной городской парковке и этот поток в обычный cvbs в видео вход монитора.
Хотя сама статья очень интересная, благодарю, много полезного, что при выделении объекта использовать как фон захваченный с ним в блок фон, чтобы оценить и движения самого объекта.