Spok 0 Жалоба Опубликовано September 23, 2011 Здравствуйте! Сам с OpenCV работаю нечасто и в данном случае задумался о переходе на него, если того будет стоить (проект почти закончен, кроме вот такой закавыки). Задача: Надо на скриншоте поискать кое-какие фрагменты (если они там есть). Фрагменты с этого же скриншота или с одного из тысяч предыдущих (возможны минимальные искажения). Набросав несложную программу на одном из общеизвестных языков программирования получил, что картинка порядка 20x20 пикселей ищется на скриншоте (попиксельно, по RGB компонентам, по методу наименьших квадратов) 1280x800 порядка сорока секунд (тестовая машина, в жизни экран будет больше). А надо где-то пару... десятков... тысяч (или больше...) фрагментов в разумное время (секунды... полминуты максимум). Порыскал по нету, узнал о существовании cvMatchTemplate - оно самое сюда, я так понимаю. Насколько она быстро работает? Хватит ли для моей задачи или мне надо что-нибудь оптимизировать, другое придумывать? Буду благодарен за любые подсказки. P.S. Фрагменты - относительно контрастный текст, но часто и значимая полноцветная графика попадается. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
Pavia00 32 Жалоба Опубликовано September 23, 2011 Для ускорения используй отсечения. К примеру считаешь среднюю сумму по окрестности 20х20 пикселей. И сравнивай эталонным значением плюс допуска. другое придумывать? Думаю что да - надо придумывать. ИХМО OpenCv обычно за максимальной скоростью не гонится, но в основном достаточно быстро работает. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
Spok 0 Жалоба Опубликовано September 23, 2011 Мдя. Вот же задачка... Фрагмент никак не 20x20. Вот, самый маленький реальный: 350x60. Я пока додумался только до двух вещей: 1) "критические точки" - количество мест появления фрагментов огромно, но всяко меньше количества точек в скриншоте; 2) наложил все фрагменты друг на друга и для нашёл вероя... эээ... значимость каждого пикселя в этом фрагменте. Теперь как дурак сижу и думаю, что мне это даст. То есть надо как-то последовательно сверять значимые точки... и тут не могу придумать порог, по которому следует переходить от поиска изображения к принятию решения, что это какой-то фрагмент. Причём какой?............ И почему этот, а не иной.... За скоростью я не гонюсь. Но минута и четыре дня (на тестовой выборке - это принципиально). Задумывался о ИНС, но, я так понимаю, это не мой случай. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
Smorodov 579 Жалоба Опубликовано September 23, 2011 А о CUDA не задумывались ? Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
Spok 0 Жалоба Опубликовано September 24, 2011 Ассемблер, MMX, SSE, CUDA - это явления одного порядка, когда уже ничего другое не помогает. Для CUDA видеокарты нет. Я уж скорее буду на кластере считать, программа всё равно должна синхронизировать внутреннюю базу по сети. По-моему, с этими наиболее значимыми точками - наиболее перспективно. Только порог никак придумать не могу. Порог можно определить только после прогона на всей коллекции, что не имеет смысла. И к площади он не привязан. И к количеству точек. Я потом напишу, как решу (ггг, я оптимист!), если кому-то надо. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
Smorodov 579 Жалоба Опубликовано September 24, 2011 Кстати, пирамиду применяли? Можно ведь сначала уменьшить исходные картинки и искомые куски в несколько (десятков) раз. Это поможет отсеять заведомо неподходящие области изображения. А затем увеличить и подробнее посмотреть, еще увеличить, и т.д. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
mrgloom 242 Жалоба Опубликовано September 26, 2011 К примеру считаешь среднюю сумму по окрестности 20х20 пикселей. И сравнивай эталонным значением плюс допуска. мне кажется, что будет не всегда работать. Кстати, пирамиду применяли? Можно ведь сначала уменьшить исходные картинки и искомые куски в несколько (десятков) раз. Это поможет отсеять заведомо неподходящие области изображения. А затем увеличить и подробнее посмотреть, еще увеличить, и т.д. тоже смысл в теории есть, но непонятно как оптимально подобрать кол-во изображений в пирамиде и как это скажется на времени исполнения и точности локализации темплейта. попиксельно, по RGB компонентам, по методу наименьших квадратов если тут имеется ввиду, что подсчитывается сумма квадратов разностей пикселей, то это плохой метод, который зависит от яркости, было доказательство в какой то книжке и надо использовать корреляционный метод(сложность N*N в лоб и NlogN через фурье) есть FFTW http://parallel.ru/cluster/fftw.html (кодировка там коир) попробуйте отпишите, должно быть быстрее опенцвэшной особенно в несколько потоков. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах