Nuzhny

Подключи репозиторий opencv_contrib

Можно erode сделать. Но лучше сначала посмотреть на проблему. Или отсеивать уже на этапе трекинга.

Секрет. А вообще зависит от камеры: на такой как у тебя один алгоритм, на скоростных поворотках - другой. Если камера чего-то не умеет, приходится как-то дополнительно калибровать, или вычислять, или менять алгоритмы.

Да, видел. Я же около 8 лет работал в Стилсофте - ваши конкуренты. Но уже N лет как уволился и переехал.

Он ещё продолжается: сегодня, завтра. Потом действо на полигон перейдёт. А "наши" - это кто, если не секрет? Я многих знаю, кого лично, кого так, просто слышал, в этой отрасли уже довольно давно. Может разговаривал на выставке с "вашими", но точно могу сказать, что обошёл все стенды.

Да, либо от Dali, либо от производителя объектива. Короче, смотреть надо. Про калибровку - можно в документации по OpenCV, можно в Гугле поискать. Вот тут хоть и не самая новая статья, но хорошая.

О, я вчера на выставке видел стенд и Бика, и Dali. Конторы известные. Если тепловизор никак зум не даёт получить, то я так сразу и не скажу, как быть. Внутренняя калибровка позволяет узнать параметры камеры: фокусное расстояние, дисторсия и т.д. Позволяет оценивать размер объекта в мире по его размеру в пикселях. Производится по шахматной доске или по доске с кругами. В openCV есть пример. Внешняя калибровка помогает оценить положение камеры в пространстве.

Калибровка - это внешняя и внутренняя калибровка камеры, устоявшиеся понятия, о которых надо почитать. Если ты используешь камеру и платформу от Бик (или только платформу?), то у них и спроси, как получить зум. Ребята нормальные, должны ответить. Если ты сопровождать будешь той камерой, которая у тебя на аватаре, то она должна уметь отдавать зум нормально (хотя это ещё от объектива зависит).

Занимался подобным. В приведённых тобой видео работает следующая схема: 1. Камера находится в обзорном положении, неподвижна, включён детектор движения (например, на основании вычитания фона или анализа оптического потока). 2. Объект сдетектирован, происходит переключение в режим сопровождения. Берётся алгоритм типа particle filter, TLD, KCF (их много), который старается удержать объект. 3. Камера заранее откалибрована, т.е. ей известно на какой угол и с какой скоростью надо повернуться, чтобы при заданном зуме центр изображения сдвинулся, скажем, на 2 метра. 4. Как только объект теряется камерой (сел в машину, например), трекинг прекращается и камера возвращается в положение 1. Есть ещё алгоритм (в старых камерах Bosch видел), когда камера не выделяет конкретный объект, а детектирует только вектор некоторого движения в кадре и сдвигается в направлении него. Что там внутри: оптический поток или банальные motion templates я не знаю. Но такое ощущение, что кроме этого у них ничего нет. Описанный мной алгорим довольно общий, в каждом конкретном случае могут быть свои оптимизации, связанные с возможностью камер. Какие-то умеют повернуться на заданный гол с заданной скоростью, какие-то просто работают по координатам и сопровождать приходится вручную. У некоторых повороты инерциальные, т.е. сначала начинают вращаться медленно, но быстро ускоряются. И так далее. В каждом конкретном случае приходится придумывать своё решение.

Просто запусти профайлер, который вместе с CUDA идёт и уже из него свой код.

В дополнение: сначала посмотрите в кудовский профайлер и посмотрите на источник тормозов.

Я по названию хедера и пути к нему сразу понимаю из какого он модуля. То есть хедер от highgui явно не будет лежать в моделу core.

Если ты нашёл функцию в хедере, то автоматически знаешь и что подключать, нет? Зачем что-то отдельно искать? Я пользуюсь CMake и не парюсь по поводу порядка.

Видимо я совсем не настоящий линуксоид. Для разбора кода OpenCV открываю его в IDE (мой выбор QtCreator). В крайнем случае, использую mc для поиска по файлам и просмотра результата.

Параметр CV_32SC1 означает, что используется целочисленный знаковый тип (int короче), количество каналов равно 1. Вот единицу последним параметром и передавай.

Думаю, сделали немного больше. Также как HOG детектор пешеходов не исчерпывается только linear SVM, так и DMP не исчерпывается исключительно latent SVM. Да, latent SVM там используется, но ведь нужны ещё фичи (это HOG), надо указать число этих самых parts models, надо это обучить.

Можно в исходники заглянуть и подправить при необходимости

FloodFill

Я слабо представляю, чем может помочь скелетизация при распознавании символов.

Разделение часто делают по гистограмме. Есть у нас изображение шириной W строки с текстом. Тогда заводим массив размером W, каждый элемент которого есть сумма пикселей изображения по столбцам. Сглаживаем, ищем минимумы - они примерно будут соответствовать границам символов. Тут тонкость, что минимумы могут быть локальные, соответствующие не границам, а середине символа. Например, в цифре '0', особенно если она написана трафаретом. Все эти неоднозначности решаются в зависимости от ситуации.

Конечно можно. Но для этого надо знать, что конкретно тормозит и почему. Обычно берут в руки профайлер (valgrind это будет судя по всему), смотрят, оптимизируют. Вряд ли получится что-то кардинально улучшить парой опций: либо оптимизировать вручную, либо искать альтернативные оптимизированные под конкретную платформу библиотеки, реализующие необходимый функционал.

Ничего не надо уничтожать. Кстати говоря, если посмотришь в консоль, то увидишь где и почему появилась ошибка. Потом в отладчик.

Ага. Причём inverse compositional метод может быть в разы быстрее и при этом точнее прямого метода. Его в большинстве случаев и надо применять на практике.

Это не совсем тот же самый оптический поток. В смысле, я представляю, как это можно сделать для решения задачи. Но не вижу, как уложить в концепцию parametric motion, о которой мы сейчас говорим.

Вроде, одна из лучших открытых библиотек сейчас - это TheiaSfM.