Перейти к содержимому
Compvision.ru

erly

Пользователи
  • Количество публикаций

    33
  • Зарегистрирован

  • Посещение

Все публикации пользователя erly

  1. У MultiCue тоже проблема с производительностью... похоже, он однопоточный.
  2. Коллеги, поделитесь информацией плиз, если имеется. Встречалась ли кому статья, или может быть тема на форуме, с исследованием отличий OpenCV-методов сегментации фона (Background-Foreground Segmentation Methods)? Или может быть кто-то сам исследовал и сохранил результаты? Готовых методов сегментации в opencv несколько (https://docs.opencv.org/4.1.0/d2/d55/group__bgsegm.html). Но не понятно, в каком случае какой метод предпочтительнее. Так же не получается найти понятного, но не громоздкого описания каждого из реализованных методов. Ссылки на публикации с описанием методов как-то не очень помогают - про каждый написано, что он самый лучший и быстрый, при этом краткого описания сути метода нет. Не хочется изобретать велосипед и городить свой метод, не разобравшись до конца в существующих.
  3. Да, есть там Vibe в библиотеке. Очень быстрый. При этом качество детектирования, как мне показалось, примерно такое же, как у почти всех остальных алгоритмов, работающих с большим накоплением. Но производительность очень высокая. Все алгоритмы попробовал. Особенно понравился MultiCue. Лучше других справляется с "распаданием" объектов. Скорость работы при этом выше среднего.
  4. Отличное видео! Сейчас в основном пытаюсь бороться с проблемой, как на прикрепленном участке. Человека глазами хорошо видно, а детектор выполняет это не надежно. На тот момент, когда сумка стала сереневой, в алгоритме она уже считается фоном? А в общем, спасибо, экспериментирую с bgslibrary. Есть там очень неплохие варианты.
  5. Спасибо за ответ, почитаю. Хочется, чтобы: Учитывался цвет, а не только яркость. Может быть даже, чтобы учитывались контуры и характерные точки, а не только цвет и яркость. Фактура фона и объектов на глаз сильно отличается. При этом, если смотреть только на яркость, то отличие Fg/Bg может быть слабым. Была защита от длительного присутствия объекта. У меня фиксированная установка камеры, фиксированный бекграунд, на котором появляются объекты (их и надо обнаруживать). Объекты могут появиться и задержаться на длительное время. Оконный буфер усреднения фона через какое-то время приводит к восприятию этих объектов, как Bg. Надо, чтобы эти долго неподвижные объекты продолжали детектироваться, как Fg. Была адаптация к изменению освещения, в том числе резкому (выключили половину света). Была защита от краткосрочного изменения яркости (фото вспышка). Я уже пытался сравнивать.. это оказалось не просто сделать. Навскидку, как мне показалось, все алгоритмы работают примерно одинаково. Наверное есть отличия в деталях, вот про них и хотелось прочесть, а не пытаться дойти анализом результатов.
  6. Нашел рабочий вариант. Если кому интересно: Калибровку делал в 2 этапа. 1. Разделил все 3D точки реального объекта на плоскости (Z координаты обнулил), подал их в calibrateCamera отдельными векторами. И 2D точки из плоскости кадра разделил на отдельные векторы тоже. В результате получилось первое приближение cameraMatrix (M) и Distortions (D). Матрицы вращения (R) и положения (T) игнорируются. 2. Второй вызов calibrateCamera. У нее в параметрах Все 3D точки одним общим вектором, 2D точки одним вектором, M и D из первого шага. Вызов функции без флагов. В результате получились уточненные M и D, а также вычисленные R и T. Проверка по отображению других 3D точек объекта в 2D картинную плоскость прошла успешно. Всем спасибо, кто думал над задачей. Ваши мысли, выпущенные в ноосферу, безусловно помогли поиску решения.
  7. Всем привет. Подскажите, пожалуйста, возможно ли откалибровать камеру, если известны 3D координаты нескольких (50) точек из реального мира и соответствующие им 2D координаты на изображении от камеры? Требуется найти как внутренние, так и внешние параметры камеры. Калибровать пытаюсь методом calibrateCamera. Мануалы с туториалами описывают калибровку с помощью шахматной доски нескольких видов. Оно работает нормально, только мне такое не подходит. Надо как-то обойтись настоящими координатами известных реперных точек в пространстве. Камера стоит в фиксированном положении относительно объекта съемки, поэтому по идее после вызова функции ожидаю получить не только Camera Matrix и Distortions, но и корректные Translation и Rotation векторы. Пробовал такие варианты: 1. В параметрах функции указываю реальные 3D координаты единым блоком: vector<vector<Point3f>>. Размерность вектора получается [1][50]. Аналогично для проективных точек: vector<vector<Point2f>>. Вызов функции приводит к ошибке: .. opencv-3.4.2/modules/calib3d/src/calibration.cpp:1468: error: (-5:Bad argument) For non-planar calibration rigs the initial intrinsic matrix must be specified in function 'cvCalibrateCamera2Internal' Ругается, что калибровочный шаблон - не плоскость. А он действительно не плоскость, а набор точек в некотором объеме пространства. 2. То же самое, но с флагом CV_CALIB_USE_INTRINSIC_GUESS. Ошибки нет, все матрицы вычислились. Но проверка не проходит. Пересчет проверочных 3D точек в экранные координаты выполняется не верно, ошибка сильная и бессистемная. Что я делаю не так? Кто-нибудь сталкивался с подобной задачей?
  8. Делал себе такое в целях отладки. Чтобы все время видеть результат обработки видео с удаленного сервера. Программа работает на сервере (Ubuntu) и сохраняет результаты обработки каждого кадра в файл test.jpg, постоянно его перезаписывая. Запуск трансляции с сервера на клиентскую машину: tail -f test.jpg 2> /dev/null | ffmpeg -r 50 -f image2pipe -c:v mjpeg -i - -r 50 -c:v libx264 -sdp_file h264.sdp -f rtp rtp://10.2.0.2:1234 Здесь 10.2.0.2 - адрес клиентской машины. При запуске ffmpeg формирует файлик h264.sdp. Передаем этот файлик на клиентскую машину (Windows) и открываем в VLC Player. Либо, при наличии доступа, открываем файл в VLC Player-е удаленно с сервера.
×