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

cvMatchTemplate - насколько быстро работает?

Recommended Posts

Здравствуйте!

Сам с OpenCV работаю нечасто и в данном случае задумался о переходе на него, если того будет стоить (проект почти закончен, кроме вот такой закавыки).

Задача: Надо на скриншоте поискать кое-какие фрагменты (если они там есть). Фрагменты с этого же скриншота или с одного из тысяч предыдущих (возможны минимальные искажения).

Набросав несложную программу на одном из общеизвестных языков программирования получил, что картинка порядка 20x20 пикселей ищется на скриншоте (попиксельно, по RGB компонентам, по методу наименьших квадратов) 1280x800 порядка сорока секунд (тестовая машина, в жизни экран будет больше). А надо где-то пару... десятков... тысяч (или больше...) фрагментов в разумное время (секунды... полминуты максимум).

Порыскал по нету, узнал о существовании cvMatchTemplate - оно самое сюда, я так понимаю.

Насколько она быстро работает? Хватит ли для моей задачи или мне надо что-нибудь оптимизировать, другое придумывать?

Буду благодарен за любые подсказки.

P.S. Фрагменты - относительно контрастный текст, но часто и значимая полноцветная графика попадается.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Для ускорения используй отсечения. К примеру считаешь среднюю сумму по окрестности 20х20 пикселей. И сравнивай эталонным значением плюс допуска.

другое придумывать?
Думаю что да - надо придумывать.

ИХМО OpenCv обычно за максимальной скоростью не гонится, но в основном достаточно быстро работает.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Мдя. Вот же задачка... Фрагмент никак не 20x20. Вот, самый маленький реальный: 350x60.

Я пока додумался только до двух вещей:

1) "критические точки" - количество мест появления фрагментов огромно, но всяко меньше количества точек в скриншоте;

2) наложил все фрагменты друг на друга и для нашёл вероя... эээ... значимость каждого пикселя в этом фрагменте. Теперь как дурак сижу и думаю, что мне это даст. То есть надо как-то последовательно сверять значимые точки... и тут не могу придумать порог, по которому следует переходить от поиска изображения к принятию решения, что это какой-то фрагмент. Причём какой?............ И почему этот, а не иной....

За скоростью я не гонюсь. Но минута и четыре дня (на тестовой выборке - это принципиально).

Задумывался о ИНС, но, я так понимаю, это не мой случай.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А о CUDA не задумывались ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ассемблер, MMX, SSE, CUDA - это явления одного порядка, когда уже ничего другое не помогает. Для CUDA видеокарты нет. :unsure: Я уж скорее буду на кластере считать, программа всё равно должна синхронизировать внутреннюю базу по сети.

По-моему, с этими наиболее значимыми точками - наиболее перспективно. Только порог никак придумать не могу. Порог можно определить только после прогона на всей коллекции, что не имеет смысла. И к площади он не привязан. И к количеству точек.

Я потом напишу, как решу (ггг, я оптимист!), если кому-то надо.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Кстати, пирамиду применяли? Можно ведь сначала уменьшить исходные картинки и искомые куски в несколько (десятков) раз. Это поможет отсеять заведомо неподходящие области изображения. А затем увеличить и подробнее посмотреть, еще увеличить, и т.д.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
К примеру считаешь среднюю сумму по окрестности 20х20 пикселей. И сравнивай эталонным значением плюс допуска.

мне кажется, что будет не всегда работать.

Кстати, пирамиду применяли? Можно ведь сначала уменьшить исходные картинки и искомые куски в несколько (десятков) раз. Это поможет отсеять заведомо неподходящие области изображения. А затем увеличить и подробнее посмотреть, еще увеличить, и т.д.

тоже смысл в теории есть, но непонятно как оптимально подобрать кол-во изображений в пирамиде и как это скажется на времени исполнения и точности локализации темплейта.

попиксельно, по RGB компонентам, по методу наименьших квадратов

если тут имеется ввиду, что подсчитывается сумма квадратов разностей пикселей, то это плохой метод, который зависит от яркости, было доказательство в какой то книжке и надо использовать корреляционный метод(сложность N*N в лоб и NlogN через фурье)

есть FFTW http://parallel.ru/cluster/fftw.html

(кодировка там коир)

попробуйте отпишите, должно быть быстрее опенцвэшной особенно в несколько потоков.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте учётную запись или войдите для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать учётную запись

Зарегистрируйтесь для создания учётной записи. Это просто!

Зарегистрировать учётную запись

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас


  • Сейчас на странице   0 пользователей

    Нет пользователей, просматривающих эту страницу

×