Jump to content
Compvision.ru

Nuzhny

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

    1,372
  • Joined

  • Last visited

  • Days Won

    169

Nuzhny last won the day on July 19

Nuzhny had the most liked content!

Community Reputation

225 Эксперт

2 Followers

About Nuzhny

  • Rank
    Эксперт

Profile Information

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

Recent Profile Visitors

3,915 profile views
  1. Без CUDA тоже будет работать, но медленней. По факту ключевые точки на лице ищутся не методом Виолы-Джонса, им только лицо, а точки уже другими способами: AAM, нйросети (регрессия) и т.д. Возможно, тебе подойдут active shape models, которые до нейростей были лидером по качеству и не требовали видеокарты. Хотя сейчас с OpenVINO многие нейросети и так быстро работают.
  2. Да, всё верно, сегменты привязываются к объектам. Каждый объект может хранить у себя не только последние координаты, но и число-счётчик: на скольких последних кадрах он был найден. Если потеряется в середине кадра и не найдётся, скажем, в течение секунды, то считать потеряным и удалять. Если найдётся, то обнулять счётчик. В реальности его можно ещё и доискивать, если не найден, но это уже может быть не реалтайм. Также можно в каждом объекте хранить его модель движения: в простейшем виде это просто скорость: сколько пикселей за 1 кадр он проходит по Х и по У. Чуть сложнее - линейный фильтр Калмана из OpenCV или самому. Тогда, если 2 человека объединились в 1 объект, один человек станет типа потерян. Но на каждом кадре всё равно изменять его последние координаты с помощью известных скоростей или фильтра Калмана. Получится, что в момент разделения потерянный объект "пройдёт" это расстояние сам по инерции.
  3. Ну, результаты детекции выглядят очень неплохо. Просто применить классический венгерский алгоритм разве не получится? В качестве метрики между объектами использовать расстояние Жаккарда (IoU) - отношение пересечения прямоугольников к объединению. Кажется, что работать будет и быстро, и точно
  4. Мы же не знаем, что ты хочешь получить в итоге. Надо сделать тестовую выборку, с правильным результатом и проверять на ней.
  5. работа с 3D объектами

    В OpenCV есть cv::viz, который умеет.
  6. Вариантов много. Ну и реал-тайм - это не требования. Правильное требование: процессор + память + видеокарта, разрешение видео и сколько времени на обработку одного кадра. А то может оказаться, что детекцию нейросетями надо будет делать на слабом CPU и 25 кадров/сек на видео 6МП. Хотя тут тоже можно натренировать tiny YOLO или MobileNet SSD.
  7. На первый взгляд кажется, что можно - мы же глазами видим движение по изображению с этой камеры. Очевидно, что классическое вычитание фона тут не справится, потому что оно смотрит на изменение интенсивности пикселей. Первая мысль - избавиться от цвета, то есть перейти в цветовое пространство типа HSV или Lab, а далее работать исключительно с каналом интенсивности (V или L). Далее использовать dense optical flow, например Farneback, получить поле векторов. Далее это поле уже сегментировать (kmeans или что-то сложнее). Результатом сегментации должны стать уже блобы и фон. Это так, взгляд со стороны.
  8. То есть никакого детектора нет? Есть возможность снимать камерой с датчиком глубины? Или камерой в ИК диапазоне?
  9. А что вообще есть на входе? Обычно трекинг понимается в 2-х ипостасях: 1. Visual objects tracking (VOT). Всё это направление подразумевает, что на первом кадре объект как-то нашёлся (детектором, классификатором или был выделен оператором), а дальше на каждом кадре его ищет исключительно сам трекер. Тут можно посмотреть на модуль tracking из opencv_contrib, в частности на CSRT оттуда. Другой классический метод - это STAPLE, но лидеры на сегодняшний день - сиамские нейронные сети (там и датасет, и результаты, и победители). 2. Tracking by detection. Тут принцип другой: непрерывно на видео работает детектор, объект(ы) находится достаточно регулярно. Если объект не находится, то его траектория интерполируется (фильтр Кальмана), он доискивается с помощью VOT и т.д. Когда объект снова находится, то срабатывает какой-то re-id, чтобы узнать, что найден именно тот самый объект (re-id - это сравнение размеров, гистограмм, нейросети и т.д.). Если используется трекинг сразу нескольких объектов, то необходим алгоритм межкадрового связывания: для двух кадров Венгерский алгоритм или аналоги, но популярнее сейчас поиск максимального потока в графе, например.
  10. Тогда так просто с дивана трудно сказать в чём причина. Реально так и происходит, когда некоторых ресурсов не хватает или есть просадки по времени: в кадре появляется большой объект или движение самой камеры, поток с камеры резко возрастает на P или B frames и они не успевают декодироваться либо теряются. Ведь битрейт - это что-то среднее в секунду, а тут резкое в 1-2 кадра увеличение изменений. Можешь ещё поставить fixed bitrate, если камера это умеет. Кстати, а какая частота I-frames? Обычно он идёт раз в 1-2 fps, то есть у тебя каждый 25-50 кадры.
  11. Неплохо получилось. 1. Ложные срабатывания на качающихся деревьях и проводах можно легко отбросить с помощью простой оценки плотности: N_pix / A_bb > alpha, где * N_pix - число пикселей переднего плана внутри прямоугольника; * A_bb - площадь прямоугольника (width * height); * 0 < alpha < 1, например alpha = 0.3. Физический смысл очень просто: когда качается ветка или провод, то прямоугольник получается большим, а самого объекта в нём очень мало. Если плотность больше некоторого небольшого alpha, то объект реальный. Иначе отбрасывать. 2. NV12, YUV420, YUV422, YUV444 - это нормально для h.264, RGB там не бывавет. 3. Глюки сигнализируют о том, что потерялся кадр. Причин может быть много: - потерялся в сети, тут можно уменьшить битрейт, можно снизить частоту ключевых кадров; - не успевает декодер - можно попробовать другой, лучше аппаратный; - у тебя однопоточное приложение и все действия (декодирование, детекция, отображение) в сумме занимают больше 1000 / fps млсек. Тогда кадры будут время от времени отбрасываться.
  12. Не знаю, что там скроется внутри в шарповом коде, но в OpenCV есть HoughLines (Standard Hough Line Transform) и HoughLinesP (Probabilistic Hough Line Transform). Так второй вариант работает намного лучше. А в opencv_contrib есть ещё и более быстрый вариант FastHoughTransform. Ещё есть cv::LineSegmentDetector, который и быстрый, и может находить короткие отрезки. В общем, я бы сначала поэкспериментировал с тем, что есть.
  13. Формат форума обычно подразумевает описание проблемы, а потом коллективно ищется решение. Такой формат не подходит?
  14. Каскад Хаара

    Лучше 80х80. Далее идёт детекция через cv::CascadeClassifier::detectMultiScale, где можно подобрать правильный коэффициент скейла. Тренироваться может долго, но тут никуда не деться. В плане альтернатив из коробки есть ещё SVM+HOG, но это будет уже медленнее Хаара.
  15. Каскад Хаара

    Если размер объекта у тебя никогда не будет меньше 100 пикселей, то можно ставить минимальный размер и больше, чем 20х20, тут проблем у меня не было. P.S. В OpenCV 4 тренировка каскадов уже depricated, а opencv_createsamples удалена из сборки. Фактически есть, но закомментирована и, если включить, не собирается из-за чистки старого API. Так что надо подумать, насколько необходимо использовать каскады Хаара в будущем.
×