Есть ли какой нибудь метод быстрого сравнения двух рисунков, типа if bitmap1 = bitmap2 then Попиксельный метод сравнения 2 bitmap не подходит, очень медленно, да и систему нагружает сильно. Заранее спасибо за ответы 

ScanLine быстрее в делфях не предусмотрено... Можно использовать GDI+, там много быстрее работа с изображениями...
Вобще то тему в алгоритмы, но и в этом разделе вопрос сравнения изображений поднимался не раз...
Проще всего сравнивать не сами рисунки, а например МД5 или ЦРЦ (если это файлы), есть алгоритм PSNR, но это сложно... 

Можно загрузить оба битмапа в TMemoryStream.
Если размер стримов разный, то сразу нет.
Если одинаковый, то сравнить с помощью CompareMem.

Snowy,  Спасибо.  Буду пробовать

Snowy,  Попробовал.  Сравнение стримов и попиксельное сравнение по нагрузке на систему большой разницы не заметил. Кроме того, загрузка в stream также сильно нагружает систему, в зависимости от размера Bitmapa.  Может есть другие методы или компонеты для быстрой работы с графикой, использующие DirectX, например, или еще что. 

  Можно для начала файлы открыть в TFileStream и сравнить размеры, если не совпадают, то перейти к началу растра и подгружать кусками, скажем по 4кб и сравнивать. 
  Вообще, есть решение лучше. Вместо TMemoryStream использовать отображение файлов в память FileMapping, а уже для отображений использовать CompareMem. Функция CompareMem сравнивая будет постепенно подгружать файл. Если файлы одного размера, но с разным контентом, то реально загрузиться лишь небольшой фрагмент от каждого файла, что займет значительно меньше времени.

Alexeis,  Сравниваю не файлы, а картинку с экрана. Принцип такой, при старте программы сохраняю картинку с экрана в bitmap, допустим в PredBMP. Через определенные промежутки времени снимаю экран в CurrBMP. Это делаю методом BitBlt.  Нагрузка почти нулевая при разрешении экрана 1680Х1050
Далее дроблю оба bitmapa на N-ное количество мелких LPredBMP и LCurrBMP , допустим 50х50 пикселей, получаю при таких входных параметрах 714 мелких картинок методом
    LPredBMP.Canvas.CopyRect(Rect(0, 0, LRight-LLeft, LPredBMP.Height),   PredBMP.Canvas,   Rect(LLeft, LTop, LRight, LBottom)); 
и  LCurrBMP.Canvas.CopyRect(Rect(0, 0, LRight-LLeft, LCurrBMP.Height),   CurrBMP.Canvas,   Rect(LLeft, LTop, LRight, LBottom)); Тормоза начинаются уже здесь. Потом сравниваю между собой мелкие картинки. Если разные, сохраняю в StringList порядковый номер картинки и саму измененную картинку записываю в конец результирующего LLongBMP, размером Height =50 и Width = количество измененных картинок * 50. 
StringList с номерами и LLongBMP пересылаются потоками другой программе которая, по номеру вычисляет координаты измененных мест на экране и прорисовывает их. Сравнивать пробовал и попиксельно и с помощью MemoryStream, разницы не заметил. При частоте опроса 10 раз в секунду, процессор грузится до 50%.  Что можно сделать? 

Опиши задачу 

  Ну так количество сравнений будет n^2/2 = 250000 сравнений на 1 кадр и 2,5 млн сравнений в секунду по 250 пикселов. Можно процесс несколько ускорить, если для каждого фрагмента посчитать например сумму цветов всех пикселов (или crc сумму). Если суммы отличаются, то картинки на 100% отличаются, если же суммы совпали, то нужно дополнительно проверить сравнением. 
  Если совпадения кадров явление частое, то можно считать crc32. Случайное совпадение crc32 событие исключительно редкое, так что совпадение crc32 можно считать совпадением картинок. 

  Алгоритм со сложностью n^2 является плохим, но сравнение целых чисел куда быстрее чем картинок + расходы на расчет 714 (это все таки не 250 000). Кроме того, и этот алгоритм можно улучшить, если ключи (хеш суммы) отсортировать при помощи алгоритма быстросорт (сложность алгоритма n * log2 n ).

  Итого вместо жуткого n^2 по картинкам можно дойти до сложности n * log2 n по ключам + сложность n по вычислению хеша

Добавлено через 4 минуты и 3 секунды

  На всякий случай. Чтобы найти одинаковые картинки в отсортированном массиве нужно сравнивать только соседние элементы. Можно оптимизировать быстросорт так чтобы он сразу же исключал повторения и создавал уже готовый массив уникальных ключей.

Alexeis,  Это нужно переварить

Картинки можно сначала уменьшить, а потом сравнивать уменьшенные верии. Это если конечно не интересуют какие-то сверх-мелкие детали.

  Так картинки и так относительно маленькие 50х50. 

естественно тут будут тормоза CopyRect вещь медленная, тут тоже лучше BitBlt использовать (правда не помню умеет ли она куски вырывать, но если нет то 100% есть аналог который умеет)
НО у вас мне кажется неверный подход, зачем изображение сразу дробить?, вы сначала сравните старую большую и новую большую картинку, а дальше уже копируйте только куски с изменившимися данными, а лучше одновременно, то есть сравниваете попиксельно (быстрее невозможно) и как только один пиксель оказался не таким как раньше копируете соответствующий этому пикселю кусок картинки в массив изменившихся и больше пиксели этого куска не трогаете.

xkor, Я вообщето так и делаю. На пальцах трудно объяснять. Если не поленитесь посмотреть код, могу выслать.

Зачем делать лишнюю работу если результат может потом не понадобиться? Сначала нужно проверить, а только потом копировать фрагменты где есть разница.


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


Контрольная сумма считается не по волшебству, в любом случае нужно прочитать и произвести манипуляции с данными каждого из фрагментов, какая в таком подходе польза? Сравнение двух областей памяти займет меньше времени.

З.Ы. ради интереса прикинул затраты на сравнение, в результате на р4-2.4 с размером изображения 1600х1200 и размером блоков 16х16 и с визуализацией, при 10 кадрах в секунду нагрузка на процессор составила ~5%. 

  Речь идет о попарном сравнении всех кусочков 1-2 1-3 .. 1-n, 2-3, 2-4, 2-n,...n-1 - n. Это отнюдь не n сравнений.

x128, Как ты делаешь? У меня не получается меньше 40%. Сравниваю и память и пиксели. Посмотри мой код, что делаю не так? 

Присоединённый файл ( Кол-во скачиваний: 43 )
 RAdmin__.rar 29,38 Kb

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

x128,   Т.е.  попиксельно сравнивать 2 больших снимка, по изменившемуся пикселю расчитать и вырезать фрагмент ?

Это сообщение отредактировал(а) EPaul - 23.9.2010, 13:15

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

x128,  По изменившемуся пикселю, определить фрагмент его местонахождения, если фрагмент уже был замечен как измененный, до конца цикла сранения перескакивать через него, смещая индексы X,Y   если замечен впервые - вырезать. Так наверное будет лучше. Щас буду пробовать.   

и к чему тогда было отвечать:

на моё сообщение:

если только сейчас начали делать так как я написал?

xkor,  Попробовал и Ваше предложение. Результат тот-же. Простой цикл перебора 1680х1050х3 без каких либо операций внутри, 10 раз в сек - до 5%.  Просто снимок экрана единственной процедурой BitBlt -  6-7%. А если поставить в цикл какое-либо условие на сравнение пикселей, расчет фрагмента, в котором находится пиксель, определяние был-ли этот фрагмент уже изменен - плюс еще 25-30%  В итоге меньше 50% не получается. (процессор P4® D-2.66 ОЗУ 3ГБ)   Пришел к выводу - в делфи это сделать невозможно. Жаль. Может на С++ это быстрее будет?   

EPaul, ну может в С++ и выиграешь процентик за счет более навороченного оптимизатора, но в целом один алгорим что на дельфи что на С++, что на другом языке с нативным компилятором будет работать практически с одной скоростью...

Разницы в среде разработки нет! Смотри прикрепленный исходник и думай над своими ошибками...


Присоединённый файл ( Кол-во скачиваний: 57 )
 CompareScreen.rar 166,81 Kb

Разницы в среде разработки нет! Смотри прикрепленный исходник и думай над своими ошибками...


Присоединённый файл ( Кол-во скачиваний: 79 )
 CompareScreen.rar 166,81 Kb

x128,  Спасибо.

Как сделать чтоб она была не черно-белая? А то при этом:

картинка становится серой. О.О

SeeDeeS, оймама. трупокопатель)

Кстати, а что, если реализовать алгортим сравнения/поиска изменившихся областей таким образом:
Сравниваемые картинки отрисовываются друг на друга с пом BitBlt c dwRop = PATINVERT (xor), а затем смотрим, ищем ненулевые триплеты/дворды...
не быстрее ли это будет, чем сравнение через CompareMem и т.п.

Есть возможность предварительной проверки картинок это не попиксельное сравнение картинки, а побайтно, например 32 или 64 битном представлении.
Делаем массив типа int64
(предварительно картинку переводим в формат 1bit)
грузим в этот массив картинку
т.е. в 64 битном 1 елементе мы имеем сразу 64 точки, а далее математика, мы будем знать в каком элементе есть несовпадения и вычисляем
недавно находил пример, жаль сейчас по быстрячку не нашел на каком форуме я видел.
как писал автор, скорость сравнения битмапа выросла в 20 раз, сам не проверял

На два года опоздал,но все равно. 
Вот.
Сравнение 32битных битмапов




Это сообщение отредактировал(а) Чучмек - 26.10.2012, 22:49

Вот, сейчас потестил, для интереса.
32битные битмапы 2000*1500
Проц AMD  AthlonII 3.1ГГц
Число сравнений в секунду, для абсолютно идентичных и для абсолютно различных битмапов. При различных N 


Это сообщение отредактировал(а) Чучмек - 27.10.2012, 15:25