 |
|
Модераторы: Snowy, Alexeis, MetalFan |
 
|
|
Быстрое сравнение двух рисунков 
| Alexeis |
|
|||
 Амеба  Профиль Группа: Админ Сообщений: 11743 Регистрация: 12.10.2005 Где: Зеленоград Репутация: 55 Всего: 459 |
Речь идет о попарном сравнении всех кусочков 1-2 1-3 .. 1-n, 2-3, 2-4, 2-n,...n-1 - n. Это отнюдь не n сравнений. -------------------- Vit вечная память. Обсуждение действий администрации форума производятся только в этом форуме гениальность идеи состоит в том, что ее невозможно придумать |
|||
|
||||
Загрузка ...
| EPaul |
|
|||
|
Новичок Профиль Группа: Участник Сообщений: 16 Регистрация: 22.6.2009 Где: Наб-Челны Репутация: нет Всего: нет |
x128, Как ты делаешь? У меня не получается меньше 40%. Сравниваю и память и пиксели. Посмотри мой код, что делаю не так?
Присоединённый файл ( Кол-во скачиваний: 43 ) 
RAdmin__.rar 29,38 Kb |
|||
|
||||
| x128 |
|
|||
|
Шустрый  Профиль Группа: Участник Сообщений: 88 Регистрация: 29.9.2009 Репутация: 5 Всего: 7 |
В принципе все не так... Выполняется много не нужного кода и много бесполезного кода, все затраты в конечном счете суммируются и получаешь тормоза. После получения очередного снимка экрана нужно сначала найти места где есть разница и только после этого производить манипуляции с измененными блоками. У тебя все наоборот, делаешь снимок, потом начинаешь вырезать фрагменты, далее каждый фрагмент пихать в TMemoryStream, только после этого сравнивать, после чего еще раз копировать. Логику в этих действиях я не уловил... |
|||
|
||||
| EPaul |
|
|||
|
Новичок Профиль Группа: Участник Сообщений: 16 Регистрация: 22.6.2009 Где: Наб-Челны Репутация: нет Всего: нет |
x128, Т.е. попиксельно сравнивать 2 больших снимка, по изменившемуся пикселю расчитать и вырезать фрагмент ?
Это сообщение отредактировал(а) EPaul - 23.9.2010, 13:15 |
|||
|
||||
| x128 |
|
|||
|
Шустрый Профиль Группа: Участник Сообщений: 88 Регистрация: 29.9.2009 Репутация: 5 Всего: 7 |
Примерно так, только не на мудри с "по изменившемуся пикселю расчитать и вырезать фрагмент", организуй грамотно цикл так, что бы не нужно было делать лишние вычисления т.е. в момент нахождения блока у тебя должны быть известны все значения (размер блока, положение, где данные и куда они должны попасть). Самое важное избавиться от лишних операций в циклах и других критичных местах.
|
|||
|
||||
| EPaul |
|
|||
|
Новичок Профиль Группа: Участник Сообщений: 16 Регистрация: 22.6.2009 Где: Наб-Челны Репутация: нет Всего: нет |
x128, По изменившемуся пикселю, определить фрагмент его местонахождения, если фрагмент уже был замечен как измененный, до конца цикла сранения перескакивать через него, смещая индексы X,Y если замечен впервые - вырезать. Так наверное будет лучше. Щас буду пробовать.
|
|||
|
||||
| xkor |
|
||||||
 Шустрый Профиль Группа: Участник Сообщений: 51 Регистрация: 8.1.2007 Где: Питер Репутация: нет Всего: 4 |
и к чему тогда было отвечать:
на моё сообщение:
если только сейчас начали делать так как я написал? |
||||||
|
|||||||
| EPaul |
|
|||
|
Новичок Профиль Группа: Участник Сообщений: 16 Регистрация: 22.6.2009 Где: Наб-Челны Репутация: нет Всего: нет |
xkor, Попробовал и Ваше предложение. Результат тот-же. Простой цикл перебора 1680х1050х3 без каких либо операций внутри, 10 раз в сек - до 5%. Просто снимок экрана единственной процедурой BitBlt - 6-7%. А если поставить в цикл какое-либо условие на сравнение пикселей, расчет фрагмента, в котором находится пиксель, определяние был-ли этот фрагмент уже изменен - плюс еще 25-30% В итоге меньше 50% не получается. (процессор P4® D-2.66 ОЗУ 3ГБ) Пришел к выводу - в делфи это сделать невозможно. Жаль. Может на С++ это быстрее будет?
|
|||
|
||||
| xkor |
|
|||
|
Шустрый Профиль Группа: Участник Сообщений: 51 Регистрация: 8.1.2007 Где: Питер Репутация: нет Всего: 4 |
EPaul, ну может в С++ и выиграешь процентик за счет более навороченного оптимизатора, но в целом один алгорим что на дельфи что на С++, что на другом языке с нативным компилятором будет работать практически с одной скоростью...
|
|||
|
||||
| x128 |
|
|||
|
Шустрый Профиль Группа: Участник Сообщений: 88 Регистрация: 29.9.2009 Репутация: 5 Всего: 7 |
Разницы в среде разработки нет! Смотри прикрепленный исходник и думай над своими ошибками... Присоединённый файл ( Кол-во скачиваний: 57 )
CompareScreen.rar 166,81 Kb |
|||
|
||||
| x128 |
|
|||
|
Шустрый Профиль Группа: Участник Сообщений: 88 Регистрация: 29.9.2009 Репутация: 5 Всего: 7 |
Разницы в среде разработки нет! Смотри прикрепленный исходник и думай над своими ошибками... Присоединённый файл ( Кол-во скачиваний: 79 )
CompareScreen.rar 166,81 Kb |
|||
|
||||
| EPaul |
|
|||
|
Новичок Профиль Группа: Участник Сообщений: 16 Регистрация: 22.6.2009 Где: Наб-Челны Репутация: нет Всего: нет |
x128, Спасибо.
|
|||
|
||||
| SeeDeeS |
|
|||
|
Новичок Профиль Группа: Участник Сообщений: 1 Регистрация: 15.5.2012 Репутация: нет Всего: нет |
Как сделать чтоб она была не черно-белая? А то при этом:
картинка становится серой. О.О |
|||
|
||||
| MetalFan |
|
|||
 Аццкий Сотона Профиль Группа: Комодератор Сообщений: 3815 Регистрация: 2.10.2006 Где: Moscow Репутация: 5 Всего: 128 |
SeeDeeS, оймама. трупокопатель)
Кстати, а что, если реализовать алгортим сравнения/поиска изменившихся областей таким образом: Сравниваемые картинки отрисовываются друг на друга с пом BitBlt c dwRop = PATINVERT (xor), а затем смотрим, ищем ненулевые триплеты/дворды... не быстрее ли это будет, чем сравнение через CompareMem и т.п. -------------------- There are always someone smarter than you... |
|||
|
||||
| Signal |
|
|||
|
Новичок Профиль Группа: Участник Сообщений: 1 Регистрация: 24.10.2012 Репутация: нет Всего: нет |
Есть возможность предварительной проверки картинок это не попиксельное сравнение картинки, а побайтно, например 32 или 64 битном представлении.
Делаем массив типа int64 (предварительно картинку переводим в формат 1bit) грузим в этот массив картинку т.е. в 64 битном 1 елементе мы имеем сразу 64 точки, а далее математика, мы будем знать в каком элементе есть несовпадения и вычисляем недавно находил пример, жаль сейчас по быстрячку не нашел на каком форуме я видел. как писал автор, скорость сравнения битмапа выросла в 20 раз, сам не проверял |
|||
|
||||
|
|
| Правила форума "Delphi: Звук, графика и видео" | |
|
|
Запрещено: 1. Публиковать ссылки на вскрытые компоненты 2. Обсуждать взлом компонентов и делится вскрытыми компонентами
FAQ раздела лежит здесь! Если Вам помогли и атмосфера форума Вам понравилась, то заходите к нам чаще! С уважением, Girder, Snowy. |
| 0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
| 0 Пользователей: | |
| « Предыдущая тема | Delphi: Звук, графика и видео | Следующая тема » |
[ Время генерации скрипта: 0.1306 ] [ Использовано запросов: 22 ] [ GZIP включён ]
Реклама на сайте Информационное спонсорство
|
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |