Есть ли какой нибудь метод быстрого сравнения двух рисунков, типа 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%.