Nuzhny

А неизвестно, какие точки каким соответствуют - это проблема. Один из способов решения - алгоритм RANSAC. Ещё один - итеративное приближение перспективного преобразования (или гомографии) методом наименьших квадратов. В примере всем этим занимается функция findHomography, которая из правильных и неправильных соответствий находи матрицу преобразования. Эти алгоритмы тоже не всесильны и могут ошибиться, но не в твоём случае с платами. И уже после того, как отработала findHomography и найдено преобразование ты можешь найти точные соответствия между наборами точек. А именно: умножаешь каждую точку из первого набора на матрицу гомографии, получаешь координаты точки на втором изображении и ищешь точное соответствие из второго набора. Только так.

Если всё как на картинках выше, то совпадение всё равно найдётся. А так да, с точками надёжней.

SURF - да, подойдёт. См. пример из OpenCV. Можно и способ побыстрее, например того же cv::matchTemplate должно хватить.

Про фильтры Кальмана: 1. Обнаружил в opencv_contrib Unscented Kalman filter и Augmented Unscented Kalman filter. У кого-нибудь есть опыт использования? 2. Также существует Square-root cubature Kalman filter (SCKF) - этого зверя кто-нибудь пробовал использовать? Приветствуются отзывы, ссылки на проекты - всё что угодно.

Там, вроде, пульс не считают. Но да, видел. Факт заброшенности настораживает. Большое обсуждение на Reddit. Есть уже приложения и под Андроид с открытыми исходниками, но всё это на уровне баловства. И точность страдает при высокой вычислительной нагрузке. Так что копать есть куда.

Какая-то мешанина из разных версий API и мне как-то не очевидна логика. Но да ладно. Я когда-то интересовался и исходной работой, и исходниками Smorodov'а. Немного их отрефакторил под себя, добавил стороннее motion magnification. Получился очень сырой проект HeartRateMeasure. В планах на правах хобби: 1. Разобраться со скачками, о которых писал выше Smorodov. 2. Добавить вычисление пульса не только по цвету, но и по движению. 3. Сделать нормальный трекинг лица по face features. Для этого можно взять dlib, можно OpenFace. После этого можно будет уже для измерения брать не средний цвет лица или анализировать optical flow, а смотреть на участки кожи, близко к которым расположены крупные артерии. Вот.

Разобраться в исходниках примера или в алгоритмах? Если у тебя скомпилированы примеры, то просто запускай его с различными опциями (они описаны). Если примеры не скомпилированы, то скомпилируй. Так, запуская на своих данных с разными опциями, ты поймёшь что и как влияет на результат. Это самый лучший способ разобраться, только потом есть смысл углубляться в теорию.

Так тебе mrgloom выше ссылку дал на стандартный пример. Это и есть код.

Ну, если можно использовать опенсивишный stitching, то вообще всё это не нужно - просто его использовать и всё.

1. Ты делаешь вывод HSV изображений: imshow("first image11", image3); Imshow("first image12", image4); OpenCV это не умеет и выводит их, считая, что они RGB. Вывод надо делать после конвертации. 2. Я бы сделал как-то так: // Load the images cv::Mat image1 = cv::imread("2.png"); cv::Mat image2 = cv::imread("1.png"); // конвертируем в HSV cv::Mat hsv1; cv::cvtColor(image1, hsv1, CV_BGR2HSV); cv::Mat hsv2; cv::cvtColor(image2, hsv2, CV_BGR2HSV); cv::Scalar v1 = cv::sum(hsv1) / (hsv1.rows * hsv1.cols); cv::Scalar v2 = cv::sum(hsv2) / (hsv1.rows * hsv1.cols); double k1 = (v1[2] + v2[2]) / (2 * v1[2]); double k2 = (v1[2] + v2[2]) / (2 * v2[2]); std::cout << "v_average1 and v_average2: " << v1[2] << " " << v2[2] << std::endl; std::cout << "k1 and k2: " << k1 << " " << k2 << std::endl; for (int y = 0; y < hsv1.rows; ++y) { uchar* p1 = hsv1.ptr(y); uchar* p2 = hsv2.ptr(y); for (int x = 0; x < hsv1.cols; ++x) { p1[2] = cv::saturate_cast(k1 * p1[2]); p2[2] = cv::saturate_cast(k2 * p2[2]); p1 += 3; p2 += 3; } } cv::imshow("first image original", image1); cv::imshow("second image original", image2); cv::Mat image12; cv::Mat image22; cv::cvtColor(hsv1, image12, CV_HSV2BGR); cv::cvtColor(hsv2, image22, CV_HSV2BGR); cv::imshow("first image new", image12); cv::imshow("second image new", image22); // Узнаем, как сильно стали различаться каналы в RGB cv::Mat diff1; cv::absdiff(image1, image12, diff1); cv::Mat diff2; cv::absdiff(image2, image22, diff2); cv::Scalar d1 = cv::sum(diff1); cv::Scalar d2 = cv::sum(diff2); std::cout << "diff1 and diff2: " << d1 << " " << d2 << std::endl;

1. Вместо кода типа: channel1[2].at<uchar>(i, j) *= k1; Лучше писать: channel1[2].at<uchar>(i, j) = cv::saturate_cast<uchar>(k1 * channel1[2].at<uchar>(i, j)); 2. Использование bitwise_and тут в корне неправильное, надо cv::merge вызывать. 3. При конвертации, скорее всего, надо использовать не RGB, а BGR. 4. Если потом захочется ускорить всё это дело, то split/merge можно вообще убрать, а сумму считать через cv::sum.

Вроде как можно перевести обе картинки в HSV, найти среднее по каналу V: v1 и v2 для каждого изображения. Затем найти отношения k1 = (v1 + v2) / 2*v1 и k2 = (v1 + v2) / 2*v2. Далее умножить каналы V обоих изображений на, соответственно, k1 и k2. И преобразовать обратно в RGB.

Да, что-то типа этого. Было несколько лет назад, уже не очень помню. Делал по примеру.

Я ICP использовал когда-то из PCL. Библиотека сейчас выглядит не очень живой, но работало хорошо.

В моей задаче точность требовалась до пикселя. Если снимок делался с большой высоты достаточно плоского куска местности, то, по-большому счёту, такой точности добиться удавалось. Если на снимке были горы - сразу нет. Зависело от ситуации, короче. Фотоскан решает несколько иную задачу.

1. Мне проблема кажется надуманной. Что сложного в подсчёте людей? Сделать плюс и минус? 2. Совсем непонятно, что делают строки shopCountR = shopCountL-1 и shopCountL = shopCountR-1.

Когда я сталкивался с такой задачей, то было примерно так: по телеметрии и GPS известны примерные координаты коптера (который летит высоко). Надо было максимально точно наложить фото с беспилотника на спутниковую карту. Просто по телеметрии это сделать не получается, пробовали по изображениям. А там был ряд проблем типа актуальности карт спутника, их разрешения конкретно в данной местности (это могли быть леса и поля, а не города с картами высокого разрешения), сезонной изменчивости. Если у топикстартера задача аналогичная, то terrapettern ему не поможет.

А в чём проблема? Сделать переменную типа int, которую менять при проходах?

Контуры можно сравнивать и напрямую, без использования моментов. И да: нейронки дадут больше.

Представь, что будет зимой, осенью, в дождь. Я бы начал с ключевых точек и сопоставления их дескрипторов (SIFT, например). В качестве ускорения, дескрипторы для карт тоже можно вычислить заранее. Но и у этого способа есть свои недостатки, если применять его в лоб: найти точки на снимке, найти точке на участке карты и сопоставлять тем же RANSAC. Недостатки: 1. Точек может быть слишком мало. В этом случае надо использовать другой метод, те же контуры (если они есть). 2. Может быть слишком много похожих объектов, у точек будет несколько матчей в обе стороны. Чаще всего такие матчи просто выбрасывают, как недостоверные. Альтернативный способ - представлять точки как биполярный взвешенный граф и искать в нём максимальный поток (кажется так). 3. Часто карта может по времени не соответствовать снимку: появились/исчезли здания, дороги. В данном случае ищут не одну гомографию, а выделяют области точек, для каждой из которых находится неплохая гомография. И уже эти гомографии как-нибудь проверяют на истинность. Я бы использовал несколько методов, выбор в пользу одного из них делал исходя из данных. Зима/лето, город/поле, горы. Всё это очень разные случаи и почти наверняка разные алгоритмы будут показывать себя лучше/хуже в каждом из конкретных случаев.

Иначе. Тут пока не проверишь, не узнаешь.

А что за задача? Если запись видео с ip-камер, то ffmpeg умеет сохранять поток без перекодирования.

О, похоже на искомое направление. P.S. Кстати, только что обнаружил OpenGM - такое ощущение, что на его базе можно было сделать паросочетания лучше. Но пока меня не тянет снова в это влезать.

LSTM - это хорошее направление. Случайно не знаешь пару подходящих статей, с которых можно начать? Фильтр частиц, на первый взгляд, не очень подходит. В чём плюс Кальмана - ему не важен сам объект, он хранит исключительно модель движения. Поэтому использовать его легко и просто. А фильтр частиц уже должен знать, как сравнивать объект с изображением на следующем кадре. Разве нет? И в этом случае весь реалтайм сразу исчезнет: когда 200 объектов на кадре, скажем, 4К начнут применять свой particle filter. Мне бы получить что-то типа уравнения. Я, конечно, могу брать последние пару секунд траектории, аппроксимировать их МНК в виде линейной (практически Кальман) или квадратичной функции. И у меня сразу получится отлавливать поворачивающие машины точнее, чем у Кальмана. Но птиц с их волнами так не поймаешь. Например, в этой статье: https://habrahabr.ru/company/ods/blog/323730/ Последние разделы: Визуализация и Сравнение с ARIMA моделью. Там строятся модели, которая на пару месяцев вперёд предсказывает данные. Не уверен, что они подойдут для трекинга: сезонность, день/ночь и всё такое - этого в трекинге нет. Может, есть аналогичный инструмент для построения модели движения наблюдаемых объектов?

Ещё анонс новинок в Multitarget-tracker. Раньше он был отличной иллюстрацией работы трекинга с помощью Венгерского алгоритма и фильтра Кальмана. Работа в качестве детектора движения была больше иллюстрацией возможностей трекинга. Теперь он становится всё более полноценным детектором. 1. Алгоритмы вычитания фона: встроенный Vibe от BeS, MOG и GMG из opencv_contrib. 2. Матчинг треков и объектов: Венгерский алгоритм или алгоритм поиска паросочетаний в двудольном графе. У Венгерского алгоритма сложность O(n^3), поэтому его есть смысл использовать только при числе объектов не более 200-300. 3. Фильтр Кальмана по координатам или по координатам и размеру объектов. 4. Сомнительная часть: можно использовать локальный трекинг на основе потока Лукаса-Канаде. Он дополняет перечисленные выше алгоритмы, работает на соседних кадрах, позволяя исправлять ошибки работы фильтра Кальмана или неправильное назначение при матчинге. Траектории становятся более гладкими, но замедляется работа. Вот такой получился конструктор. Теперь текущие проблемы и направления развития. 1. Альтернатива фильтру Кальмана, линейному во всяком случае. У меня есть несколько достаточно критических кейсов, когда линейности недостаточно: - Летит в поле зрения птица (практически материальная точка), её траектория близка к прямой, но представляет собой небольшие волны: вверх-вниз-вверх-вниз. Залетает она за дерево, фильтр Кальмана ведёт её по прямой, соответствующей последней волне. Если повезёт, то она вылетит из-за дерева в правильной точке и трекер её поймает. Не повезёт - птица летит всё также прямо, а фильтр Кальмана, потерявший цель на гребне последней волны, уйдёт в небо, птица не затрекается. - Едет автомобиль по прямой, потом начинает поворачивать по плавной дуге, посередине пропадает на секунду, фильтр Кальмана уходит по касательной, а машина продолжает поворачивать по дуге. Есть ли алгоритмы/модели, которые позволяют строить сложные нелинейные траектории? Например, запомнить волновой характер движения птицы и воспроизвести его несколько секунд, когда она скрывается за деревом. Также понять, что машина стала поворачивать, понять, что прямая закончилась и началось движение по дуге с каким-то радиусом. Тут фокус в том, что я не требую определить начало манёвра, что сложно. Мне надо строить модель движения, когда оно уже некоторое время продолжается. 2. Распознавание объекта по его траектории движения. Тут проблематика такого плана. Объекты очень редко детектятся целиком, часто не выделяются ноги-руки пешеходов, автомобили тоже кусочками или вообще детектируются не они, а их тень на асфальте (грязный серый автомобиль на сером асфальте, да ещё и в плохую погоду - сложная вещь для вычитания фона). Хочется делать следующее: когда камера с высоты снимает городскую панораму. Опустим саму картинку и возьмём исключительно треки объектов. Можно ли, скажем, по 2-5 секундам наблюдения определить, что это трек автомобиля, человека или птица полетела? Казалось бы надо собрать датасет с траекториями, обучить классификатор и распознавать. Но какой классификатор, какие признаки? Для меня эта задача новая, не очень понятно в какую сторону копать. HMM, которые используют в распознавании речи? Или трейдинговые алгоритмы? Временные ряды? Буду признателен за пинок в правильную сторону.