Nuzhny

Для начала - да. Тут ещё вопрос - сколько ключевых точек будет на снимке и в этом месте на карте. Очень часто делают итеративно (кадр меньше карты, на нём ключевых точек меньше): 1. Находят все соответствия точек кадра к точкам карты, это может быть один ко многим (одно соответствие на кадре может соответствовать 0, 1, 2,... точкам на карте). 2. Находят область на карте, куда выпадает большая часть соответствий. 3. Если область карты по масштабу больше снимка, то повторяются шаги 1-2. 4. Если область карты по масштабу совпадает со снимком, то ищут уже соответствия методом, который ты привёл: один к одному, чтобы совпадали в обе стороны.

Меня всё таки не покидает мысль о ключевых точках. Найти их на карте, хранить. Они же содержат в себе и масштаб также, часто точка+дескриптор - описывают целое озеро. Или вообще что-то типа MODS посмотреть.

1. Нет и никогда им не был. У него другие достоинства. Он быстрый! И может достаточно корректно определить факт пропажи объекта. Также видел проект, где KCF в качестве short-term tracker'а успешно заменил Лукаса-Канаде в составе TLD. И стало только лучше во всех отношениях. Думаю, что топ-трекеры надо искать на VOT. 2. Специально не искал, но должны подойти классические PETS или https://motchallenge.net/

Ммм, что фазовую корреляцию, что Лукаса-Канаде надо применять к исходным снимкам, до сегментации. Они полезны в качестве метода доуточнения позиции, найденной моментами. Про моменты: ты можешь сохранять моменты не только изображений регулярной сетки как сейчас, а ещё и моменты перекрытий? Другими словами, у тебя сейчас есть плавающее окно размером 256х256 с шагом 256 по вертикали и горизонтали - перекрытий нет, вся площадь покрывается. Может стоит сделать окно 256х256 с шаком 128 по вертикали и по горизонтали? Окон получится в 4 раза больше, но моменты же сравниваются всё равно быстро.

Нет, думаю, что в такой формулировке можно обойтись и без этого (хотя не помешает). Я больше занимался универсальным детектором, который для всего. А это и, например, такие видео как отсюда: https://github.com/utkarshtandon/GMCP-Tracker-Python-Implementation/tree/master/www Там можно посмотреть parkinglot.mp4, petsvideolarge.mp4, tudcrossing.mp4. Желательно знать, сколько людей идёт, не путать их. Если видео с вокзала, например как с PETS2007, то надо ещё определять оставленные сумки и чемоданы. Алгоритм вычитания фона на таких видео видит всё больше непрерывное поле с каким-то движением. Кстати, я с содроганием вспоминаю ночные видео с автомобилями, где включённые фары портят всю картину своим конусом света. А для низковисящих камер ещё и засвечивать иногда могут.

1. Я не пробовал, потому что практически всегда программа должна работать на ноутбуках и компах, где видеокарты не будет. А на CPU медленно. 2. В это теме всё таки не трекеры обсуждаются, а детекторы, в состав которых может входить Multitarget tracker, а по ссылке Singletarget tracker наподобие KCF или TLD. На практике это будет ну слишком медленно отслеживать сотни, а то и тысячи объектов. 3. Если говорить о нейросетях, то частью детектора может быть такой подход: Social LSTM. Вот его мне попробовать интересно.

Для меня эта проблема тоже явная. Чаще всего балансировка идёт между скоростью и качеством работы. И всегда скорость приоритетнее. 1. Мой Feintrack - это довольно старый детектор, ещё до появления OpenCV начат. Он ориентирован на работу на слабых процессорах, использовался ещё на Пентиум 4, умеет детектировать оставленные предметы. Но под твои требования не подходит. 2. UrbanTracker - хорошо, отличный подход, объединить неустойчивое вычитание фона и достаточно устойчивые точки. Никак руки до него не дойдут. 4. В Multitarget-tracker самый лучший режим - это включённый Лукаса-Канаде и KCF. Режим не идеальный, но жутко медленный на практике. Там же я экспериментировал с комбинацией: детектор лиц (Хааром) + детектор движения с вычитанием фона. Получилось неплохо! Детектор срабатывает не всегда, но достаточно часто. Получается не терять лица, даже когда они поворачиваются в профиль на несколько секунд и другими системами теряются (тем же dlib). Была надежда на GM-PHD, но она не оправдалась. Вот. Теперь о перспективных вещах. 1. Я уже убедился, что нормально работать получится только зная тип объектов, которые планируется детектировать. То есть автомобили, пешеходы, лица, животные - всё что угодно. Но детектор должен понимать, что это один объект. Ладно ещё машины вдали, едущие параллельно. Но когда они в пробке и вплотную друг к другу? А ещё серые и в пасмурную погоду? Мне кажется, что там только распознавание по типу объекта поможет. Далее люди крупным планом. У них руки, ноги, само тело - всё совершает постоянные движения в разные стороны. Как добиться того, чтобы на том же вокзале они не разделялись на кусочки и не сливались в одно? Я так и не добился от детектора нормальной работы, надо их (людей) распознавать. Этот путь хороший, правильный, но медленный и будет работать только через N лет, когда мощности подтянутся. Чтобы мог детектор движения работать на 20 видеоканалах FullHD на одном сервере. Или по Тегре в каждую камеру и распознавать на них, а не на компьютере. 2. Второй путь - это сегментация всего кадра на регионы. И наложение этой сегментации на маску переднего плана. Вот этот подход мне кажется намного более перспективным. Он быстрее будет распознавания и сработает с любыми объектами, даже неизвестными. Не обязательно даже делать сегментацию какой-то очень точной. Я сейчас посматриваю в сторону суперпикселей, их сравнения и объединения. Возможно, что в ближайшем будущем что-то появится и в Multitarget-tracker'е, если руки дойдут. Это моё личное видение перспектив детектора движения.

Преамбула В пору своей молодости (2005 год) я поступил в аспирантуру, где параллельно с работой занимался разработкой детектора движения для цифровой системы видеонаблюдения. К науке охладел довольно быстро, диссертация оказалось слабой и, как следствие, я её не защитил. В то же время вышла первая версия CUDA, которая хорошо подходила для задач вычитания фона и вообще обработки видео. Я не упустил это событие и попробовал реализовать детектор кроме С++ ещё и на CUDA. Ну и в те давние времена OpenCV был достаточно сырым и слаборазвитым. Поэтому я его не использовал совсем, а получившийся алгоритм превосходил всё имеющееся в OpenCV на тот момент. Что получилось? Вот что получилось. Получился достаточно быстрый детектор, который в то время показывал достаточное качество и скорость. Я решил выложить наработки тех лет: и исходники, и пару статей, и недописанную диссертацию. Вдруг, кому-то будет интересно. Для запуска требуется CMake, Linux|Windows и OpenCV 3.0 (исключительно для захвата видео и вывода результатов). Документации пока нет совсем, комментарии по вполне понятным причинам написаны на русском. CUDA включается опцией в CMake, работоспособность не проверял (точно работало на CUDA 1.0). Есть опции для всякой разной отладки, вывода дополнительных окошек, пока не документированы. P.S. Если кто-то захочет запустить у себя и не получится - пишите сюда или на bitbucked, помогу. Если нужны будут консультации по коду и/или алгоритмам - аналогично. Общее впечатление по алгоритму можно составить на основании статей. Планов на будущее особо нет, возможно буду отшлифовывать, добавлю реализацию на OpenCL - всё для целей исключительно ознакомительных и для показа потенциальным работодателям.

Продолжу рассказ. Собрать всё получилось, но, как мне показалось, на практике применить такую штуку не так и просто. И вряд ли сильно полезно. Вот видео со снегом Видно плохо, но видно, что снежинки могут "сбить" bounding box (а по факту модель из Гауссианов) с автомобиля или пешехода. Когда два пешехода или автомобиля рядом, то модель поначалу на них создаётся одна и она начинает "танцевать" где-то между ними. Понятно, что всё это подбирается и решается правильными порогами, но я на этом исследование темы временно закончу. Во-первых, мне не очевидны плюсы с точки зрения точности. Во-вторых, сам метод отбирает время у трекинга, который ещё будет идти после. На видео я его не включал, это только вычитание фона и его результат фильтруется GM-PHD. Не уверен, что сделанное надо вливать в основную ветку MultitargetTracker'а, это как Smorodov скажет. Если интересно, то оформлю получше и сделаю дополнительной опцией.

Зависит от сети и оборудования. В любом случае сети практически без разницы сколько типов объектов распознавать: 2, 3, 5 или 100. На вход картинка, внутри выделяются признаки, а классифицирует лишь самый последний слой, который может состоять из одного нейрона. Я думаю, что даже смена драйвера может сломать весь подход. Это происходит повсеместно и регулярно: выходит новая ААА-игра, она где-то глючит, неправильно отображается, медленно рендерится. И производители видеокарт оптимизируют драйвера, меняют рендеринг, картинка меняется. Я бы точно не затачивался под точное соответствие.

Гораздо интересней, что она не будет этого делать. В разных вариантах может быть последний слой с 300-ми выходами. На каком выходе значение больше, тот и найден. Либо будет вообще один выход, значение которого будет рассматриваться на попадание в один из 300-т диапазонов. Ещё есть более продвинутые варианты типа Faster R-CNN, которые состоят из 2-х нейросетей: 1-я говорит, что здесь вероятно есть объект, а вторая уже его распознаёт (если он есть). Что-то типа boosting'а.

Я бы на такое рассчитывать не стал. Какая видеокарта как отрендерит - погрешности будут 100%. Предлагаю путь проще, сетка тут и правда не нужна. Что надо: 1. создать датасет из всевозможных значков и картинок, которые надо будет искать; 2. рядом с каждой картинкой создать текстовый документ, в котором указана область изображения, в которой его можно ожидать увидеть. Далее берём картинку и для каждого шаблона делаем matchTemplate. Всё это можно распараллелить по ядрам просто одной командой openMP. По результатам уже смотреть.

Может быть, я на скорую руку делал.

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

Тогда я проиллюстрирую то, о чём говорил. Берём метрики четырёх тайлов из левого верхнего угла, где находится красный квадрат (у меня там только первые знаки). Взвешенные координаты получились 85 и 91. Не точно, конечно, но и не так плохо. Для такого метода надо искать не абсолютный минимум в одном тайле, а минимальную сумму из четырёх тайлов, образующих квадрат. При этом значения, которые больше некоторого порога учитывать в этой сумме не надо, как заведомо ложные. Они не должны участвовать ни в поиске минимума из четырёх квадратов, ни в вычислении взвешенной суммы. Если в моём примере взять такой порог за 0.003, то 4-й тайл учитывать не надо и значения получатся ближе к истине: х = 62, у = 70.

А, сразу не заметил. А где там находится истинное положение объекта? Фазовая корреляция - это хорошо. Ещё как вариант можно брать то, что Szeliski называет Parametric motion в своей книге. Оригинал метода описан в статье Lucas-Kanade 20 Years On: A Unifying Framework и называется Inverse Compositional Algorithm. Отличная штука. Это если фазовая корреляция не подойдёт. Нашёл исходники с Image alignment с помощью инверсного Лукаса-Канаде - вот. И видео с иллюстрацией есть.

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

Обучи нейросеть или возьми готовую, например YOLO.

Непонятный результат. Сделал возможность работать с прямоугольниками, а не просто точками, понастраивал всякие пороги. И... ничего внятного сказать не могу. Отсеивается не только шум, но и реальные объекты. И одновременно продолжает существовать шум, то есть сам фильтр его может оставить на следующий кадр, хотя его там вычитание фона уже и не находит. Возможно, я неправильно выставил какие-то значения или ещё что-то. Мне эта тема ещё интересна, но сейчас времени совсем нет. Если интересно посмотреть на код, то он у меня лежит вот в этой ветке: пример в функции GMPHDTracker. Чувствую, что надо набрать видео с ground truth и проводить полноценное тестирование, а не на глаз, как сейчас.

Я ожидал увидеть значения метрики в каждом из тайлов. Найти минимум, значения метрики в тайлах рядом. Если они совсем большие, то не учитывать. С остальными взвешивать. Например, минимальная метрика равна n1 = 0.001, у соседа справа n2 = 0.002. У остальных соседей больше 0.1, т.е. больше некоторого порога, всех их не учитываем. Тогда получим координаты: x = x1 * (1 - n1 / (n1 + n2)) + x2 * (1 - n2 / (n1 + n2)) y = y1 * (1 - n1 / (n1 + n2)) + y2 * (1 - n2 / (n1 + n2)) Как-то так.

Да, именно это. Можно попробовать за положение тайла брать взвешенное значение окрестных к максимуму тайлов. Веса - как раз твоя метрика.

А ты можешь в каждом тайле нарисовать евклидову метрику, которая получается?

Автор кода GM-PHD мне ответил: То есть GM-PHD не заменяет Кальмана+Венгерский, а используется перед ними, чтобы убрать лишний шум (лишние регионы после вычитания фона). Попробую так его и заиспользовать.

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

Что-то не очень понятно, как конкретно применять эту штуку. В связке Детектор-Венгерский-Кальман она какое место занимает? Замена связки Венгерский-Кальман? Вроде, нет. Просто Кальману? Тоже как-то не очень. В ветке gmphd добавил функцию-пример GMPHDTracker, в которой к детектору прикрутил тестовый фильтр из пример и.. как-то непонятно.