Jump to content
Compvision.ru

Nuzhny

Пользователи
  • Content count

    1,383
  • Joined

  • Last visited

  • Days Won

    170

Nuzhny last won the day on September 2

Nuzhny had the most liked content!

Community Reputation

229 Эксперт

2 Followers

About Nuzhny

  • Rank
    Эксперт

Profile Information

  • Пол
    Мужской
  • Расположение
    Санкт-Петербург

Recent Profile Visitors

4,027 profile views
  1. Фильтрация облака точек

    Не пробовал, но кажется, что как и для 2D: медианная фильтрация, например.
  2. Smorodov, это то, что называется re-id. Кажется, что оно может плохо работать, ведь сеть обучается не различать отдельные объекты между собой, а отличать типы объектов. Кажется, что все люди будут близки друг с другом, машины друг с другом, а надо ещё и их различать между собой. Впрочем, я тут ещё не экспериментировал, надо попробовать, раз уж YOLO в проект проинтегрировано, благо и образец имеется. Надо ещё из OpenVINO потестить, у них есть обученная модель на "Identify Someone in Different Videos". Но это опять таки же сеть специально обученная различать пешеходов между собой. Также там есть "face reidentification" - различать лица между собой.
  3. У меня в этом вопросе есть нерешённая проблема с расстояниями, а именно с тем, как нормировать расстояние между центрами объектов или как для него выбирать правильный порог, не зная физической модели объектов. Если мы наблюдаем за людьми со стационарной камеры, висящей на потолке помещения, то отличной метрикой будет служить IoU (Жаккара), которое есть отношение площади пересечения прямоугольников к площади объединения и расстояние это будет лежать в интервале [0, 1]. Всё круто: объекты крупные, двигаются медленно, метрика адекватная. Но тут мы вешаем камеру повыше на улицу, объекты становятся меньше, где-то проносятся машины на большой скорости. Пролетела птица возле камеры и каждый её прямоугольник не пересекается с предыдущим. Или птица летит вдалеке и её прямоугольник настолько мал, что пересечения минимальны или также равны нулю. Поэтому мы начинаем измерять не IoU, а расстояние между центрами прямоугольников на текущем и предыдущем кадрах. Расстояние в пикселях и мы берём порог, равный десятой части кадра, например. Типа объект не может двигаться так быстро, чтобы пролететь/проехать слишком далеко. Но тут появляются сразу две проблемы: 1. Почему мы взяли 10-ю часть кадра? Очевидно, что для далёких объектов это слишком много, а для близких может быть и мало. Такое ощущение, что порог должен быть свой для каждого детектируемого объекта в зависимости от его размеров и расстояния до камеры. А если мы распознаём тип объекта, то и для типа: автомобиль может проехать с одной максимальной скоростью, а человек нет. 2. Если мы хотим использовать в качестве расстояния не только расстояние между центрами на текущем и предыдущем кадрах, а ещё и расстояние между, скажем, гистограммами, то получится, что они имеют совершенно разные размерности. Одно в пикселях, а другое относительно. Хочется первое тоже как-то нормировать от [0, 1], но непонятно как. Разделить на диагональ кадра будет слишком круто, значения окажутся черезчур маленькими. Как нормировать расстояние в пикселях? Кажется, что проблему так сходу не решить или решить только костылями. Делать калибровку камеры и считать расстояния не в пикселях, а в метрах. Это может помочь, если бы мы знали тип объекта и его размер, так как посчитать расстояние до него по одной камере не всегда возможно. То есть для людей и машин на одной плоскости это может быть хорошо, а с птицами на расстоянии 10 и 100 метров от камеры будет всё плохо. Да и откалибровать камеру редко когда можно. Хорошее распознавание может помочь: для людей, легковушек, велосипедов и т.п. можно задать средние размеры и средние скорости, строить модели движения и пороги индивидуально. Но это тоже не всегда выход, если нам надо детектировать всё движение и/или маленькие объекты. Нейросети плохо себя чувствуют, когда есть объект в 4-8 пикселей размером, их либо не задетектит, либо будет ооочень медленно. Да и не во всех задачах нейросети применимы. Напрашивается ещё решение: применять сначала какой-то средний порог в зависимости от размера объекта. Типа объект не может сдвинуться дальше, чем, скажем, три его диагонали. А далее брать из фильтра Кальмана его скорость и корректировать этот порог исходя ещё из скорости. соответственно и нормировать можно на него. Вооот. получился не столько вопрос, сколько рассуждения. Если у кого-то есть какие-нибудь мысли или успешный опыт решения проблемы - welcome.
  4. А точно, просто увидел твой текст про опции линковки и пропустил про рантайм. Статья трёхлетней давности, кто его знает, правильно там или нет. Почему ты не собираешь стандартые примеры из репозитория TF? Зачем начинать с левой статьи?
  5. Возможно, что в pip-пакете что-то не так. Ты смотрел таблицу экспорта? Есть там все функции или нет? Я помню, что после сборки запускал стандартные примеры и они работали. Далее для удобства использовал cmake обвязку: то ли эту, то ли ту.
  6. Непонятно, что за эксперименты ты проводил. Я кидал выше ссылку с экспериментом с рукой, он работает и там сказано, что означает каждый из коэффициентов - каждое из расстояний. Разумеется, что 0 не обязательно означает абсолютное совпадение. Например, корреляции совпадение будет равно 1. Далее, похожесть по цвету в RGB выразить трудно или невозможно. Размывать гистограмм у можно, хуже не будет. Но можно просто взять размер бина побольше, что будет равносильно box фильтру. Ну игистограммы не идеальны, тут никто не спорит, но проблема не в OpenCV. На OpenCV проще с ними экспериментировать, потому что почти всё необходимое уже реализовано. Последнее: гистограммы должны быть только частью веса ребра графа, поток в котором мы ищем. Повторюсь, что надо комбинировать признаки.
  7. Надо выбрать правильный размер бина. Если ты знаешь, что яркость картинок может отличаться на 20-30, то и размер бина надо брать не 1, а больше. Рекомендую Евклидово расстояние вообще не использовать, а для начала просто поиграть со встроенными функциями из OpenCV, убедиться, что они подходят или нет, а уже потом писать самому. Почему не использовать Евклидово расстояние? Потому что гистограмма по своей природе больше похожа не на дескриптор, а на выборку из некоторого распределения. Соответственно и проверять насколько одно распределение похоже на другое. Формула там, кстати, очень простая, распределение дискретной, поэтому никаких интегралов: https://docs.opencv.org/3.4/d8/dc8/tutorial_histogram_comparison.html
  8. Да, именно последнее. Если посмотретьна результаты трекинга одного объекта в VOT 2018, то в победителях уже сиамские нейросети. У них свои недостатки, например, их реалтайм - это реалтайм на GT 2080 Ti, что совсем грустно. Реализаций полно на Гитхабе, например тут и тут.
  9. Самый простой и быстрый способ, который используется в том числе в particle filter - это сравнение гистограмм. Построить гистограмму объекта при обнаружении, далее сравнивать с гистограммой объектов на последующих кадрах, при сооттветствии обновить. Рекомендую сравнивать гистограммы методом Бхатачарья (есть в OpenCV) или нессиметричной метрикой из другой области - расстояние Кульбака-Лейблера (нет в OpenCV). Второй, более популярный на данный момент способ - это считать HOG-дескриптор и сравнивать его. Ну и третий способ, самый точный и популярный на сегодняшний день - это сиамские нейросети. Но, думаю, тебе хватит и первых двух. Тут надо заметить, что в классическом смысле метрика может быть абсолютно любой, вплоть до линейной (или нелинейной) комбинацией всех перечисленных и других. Например, взять 3 метрики: расстояние Жаккара (его называют IoU, intersection over union), расстояние между гистограммами и евклидово расстояние между HOG дескрипторами. Тогда итоговое расстояние будет равно: D = w0 * IoU + w1 * HistDist + w2 * HOGDist, где w0 + w1 + w2 = 1. Линейной комбинацией может быть такой вариант: w0=0.5, w1=0.2, w2=0.3. То есть мы требуем хорошего пересечения описывающих прямоугольников, из-за проблем со светом влияние похожести гистограмм сводим на минимум, а похожесть HOG'ов влияет средне. Эти коэффициенты надо подбирать не вручную, а написать тесты, разметить ролики и запустить перебор вариантов на достижение наилучшего качества. Нелинейной комбинацией можно достичь бОльшего. Например, если IoU < 0.1, то уже совсем не считать HistDist и HOGDist, а сразу говорить, что расстояние равно D = 0. Вариантов много, для каждого конкретного случая можно подобрать свою удачную комбинацию.
  10. Это или это не работает?
  11. Глава 12. Сетевые настройки. Эх, приходится советовать открывать паспорт.
  12. Без CUDA тоже будет работать, но медленней. По факту ключевые точки на лице ищутся не методом Виолы-Джонса, им только лицо, а точки уже другими способами: AAM, нйросети (регрессия) и т.д. Возможно, тебе подойдут active shape models, которые до нейростей были лидером по качеству и не требовали видеокарты. Хотя сейчас с OpenVINO многие нейросети и так быстро работают.
  13. Да, всё верно, сегменты привязываются к объектам. Каждый объект может хранить у себя не только последние координаты, но и число-счётчик: на скольких последних кадрах он был найден. Если потеряется в середине кадра и не найдётся, скажем, в течение секунды, то считать потеряным и удалять. Если найдётся, то обнулять счётчик. В реальности его можно ещё и доискивать, если не найден, но это уже может быть не реалтайм. Также можно в каждом объекте хранить его модель движения: в простейшем виде это просто скорость: сколько пикселей за 1 кадр он проходит по Х и по У. Чуть сложнее - линейный фильтр Калмана из OpenCV или самому. Тогда, если 2 человека объединились в 1 объект, один человек станет типа потерян. Но на каждом кадре всё равно изменять его последние координаты с помощью известных скоростей или фильтра Калмана. Получится, что в момент разделения потерянный объект "пройдёт" это расстояние сам по инерции.
  14. Ну, результаты детекции выглядят очень неплохо. Просто применить классический венгерский алгоритм разве не получится? В качестве метрики между объектами использовать расстояние Жаккарда (IoU) - отношение пересечения прямоугольников к объединению. Кажется, что работать будет и быстро, и точно
  15. Мы же не знаем, что ты хочешь получить в итоге. Надо сделать тестовую выборку, с правильным результатом и проверять на ней.
×