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

Nuzhny

Пользователи
 Профиль  Активность

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

    1 427

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

  • Посещение

  • Days Won

    176

Сообщения, опубликованные пользователем Nuzhny

  5. Опубликовано · Report reply

    Можно более формально описать задачу и оставить один работающий способ. При вызове того же matchTemplate указывается метрика, по которой сравнение происходит. Запусти его на всех твоих возможных данных и посмотри итоговые значения, при которых всё находится правильно. Ещё можно посмотреть на результаты в малой окрестности. Так можно определиться с минимальнылм порогом и понять, что это именно он.

    Далее уже самому написать цикл, в котором пробегаться по всей картинке и сравнивать. Причём можно сравнивать не весь кусочек целиком, а делать быстрый выход, если мы превысим порог по метрике на первых пикселях. То есть решать именно твою задачу.

  7. Опубликовано · Report reply

    Ммм, он и правда быстрый, просто у тебя задача по-другому формулируется.

    Мне, например, интересно, что значит "первое нахождение заданного шаблона". Там же куча метрик, совпадение пиксель-в-пиксель в реальных приложениях явно не возможно. В смысле, чтобы значение каждого пикселя совпало и метрика стала нулевой. Также понятно, что минимум врядли будет находиться в одной точке. Скорее всего, будет что-то похожее на параболоид - если визуализировать результат работы сравнения в 3D. И тут вопрос, насколько он пологий. Если сильно пологий, то не исключено, что результат ложный. То есть мало получить значение метрики ниже какого-то порога, надо ещё и проанализировать окрестность, чтобы убедиться в том, что минимум настоящий. У меня был опыт в нахождении таких штук: надо было определиться куда сместились блоки по 16х16 пикселей. Такие блоки на границах объектов, на чистом небе, на регулярных структурах (окна дома вдалеке) давали совершенно неожиданные результаты. Приходилось выдумывать сложные метрики и анализ.

  8. Опубликовано · Report reply

    Понятно. Тогда MatchTemplate просто делает не то, что требуется: ищет не первое вхождение (видимо, по какому-то порогу), а карту всех вхождений. Отсюда и низкая скорость.

    Честно говоря, я не уверен, что подходящая функция в OpenCV есть. Но и реализация не должна быть сложно, разве нет?

  10. Опубликовано · Report reply

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

  13. Опубликовано · Report reply

    Хм. Это не так просто повторить. можешь подсказать с каким-нибудь стандартным примером из поставки? Какие параметра подавать в тот же example_aruco_detect_markers, например. Я как раз засылал им один PR по поводу openmp для 4.0. Если баг в parallel_for, то хотелось бы его убрать, чтобы в других местах не проявилось. Всё таки я использую OpenCV в критических приложениях.

  14. Опубликовано · Report reply

    1 hour ago, fotomer said:

    Не в курсе, про 4.0 написано Our parallel_for can now use the pool of std::threads as the backend. Я собрал традиционно с флагом WITH_OPENMP, как и на предыдущих 3.х. И далее с 4.0 распознавалка Aruco падает где-то внутри либы на потоках. Если собрать без этого флага, то все работает нормально.

    А пример можешь выслать? Я тоже использую openmp, но она в Windows не развивается (поддерживает стандарт 2.0 при существующем 5.0). Поэтому разработчики OpenCV традиционно делают упор на TBB.

  19. Опубликовано · Report reply

    Откуда взялся String?!! Изображение где лежит, в каком виде ты его получаешь, по сети, с диска, rgb, jpeg - где начало цепочки? Изображение - это явно не строка. В этом форуме чаще всего используют библиотеку OpenCV, которая как раз и переводит изображение из какого-то своего формата (например, jpeg на диске) в удобный для обработки порядок байт.

  22. Опубликовано · Report reply

    10 hours ago, mrgloom said:

    В таком случае можно брать и лицевые точки, но тогда мы возвращаемся к проблеме, что они дрожат.

    Дрожат - не страшно, потому что ты всё равно сглаживать будешь. В ссылке из первого поста используют moving average, но можно и экспоненциальное сглаживание, и Кальмана прикрутить. Дрожь это всё будет убирать.

    10 hours ago, mrgloom said:

    Вот кстати похоже показана проблема движущихся объектов и слабовыраженного фона на 24 секунде.

    Да, это известная проблема. Поэтому надо либо сегментировать сразу, либо кластеризовать уже вектора и строить несколько "траекторий" для каждого кластера. Если один кластер станет больше того, по которому строится текущая траектория, то сразу на него не переключаться.

    10 hours ago, mrgloom said:

    А вот этот эффект я не понял почему возникает

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

  23. Опубликовано · Report reply

    Нет, стабилизировать по векторам движения, как обычно (блоки, оптический поток - пофиг). Но брать эти вектора только из правильных областей. Если у тебя это лицо, то на лице. Или ты используешь глобальные методы вычисления движения? Типа фазовой коррреляции или глобального Лукаса-Канаде ( https://github.com/Nuzhny007/image-align )?

  25. Опубликовано · Report reply

    У них алгоритм будет реагировать неправильно. Чтобы было правильно, надо делать сегментацию и искать движение не в целом по кадру, а по сегментам. В твоём случае всё намного проще: детектор лица, можно добавить детекцию кожи внутри найденного лица и всё.

    В OpenCV он всё больше не для реального времени, а для постобработки.

×