ANTICHAT — форум по информационной безопасности, OSINT и технологиям

scrat очень помог.

Решение для меня такое:

Это сравнение части картинки с другой частью картинки не пиксели, а md5.
В итоге мы получаем. Если md5 1 части 1 картинки != md5 1 части 2 картинки тогда эта часть разная.

Таким образом, можно выйти из ситуации.


Моя задача была сравнение скриншотов.
Так же решение задачи это ставить фиксированный размер на скрины и сравнивать байты но, увы, я не знаю, как это сделать.

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

это вариант без мд5. теперь с мд5
return md5(oldPixels) == md5(newPixels);

а md5 имеем

Итого - два цикла при расчете мд5 вместо одного прямого сравнения. Прямое сравнение прерывается если пиксели не совпали. мд5 же гарантированно досчитает до конца. Считайте профит сами.

Ra$cal, хэш будет браться от байтов сжатого изображения. Но тут ещё затраты на сжатие.

Сотри.

Есть первая картинка мы просто берем ее скрин.

Вторая картинка это скрин с изменением, например, вылезло окно.

Мы должны узнать, где вылезло это окно, но мы ж не хотим сравнивать попиксельно и не хотим весь скрин кидать. Мы делим вторую картинку, например на 4 части.

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

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

ТС, еще раз почитай что я написал про хеш. На личсточке можешь погонять тестовый пример 10х10 например.

Вопрос стоит в том, что будет затратнее: сжатие N-частей и сравнение хешей сжатого, или попиксельное/хешовое сравнение разжатых байтов.

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

Кстати, а что мешает просто проксорить расжатые варианты? Быстро и получится чёрная картинка, кроме разных мест.

вариант предложенный scrat'ом - напоминаеи алгоритм бинарного поиска. ваще-то очень даже тру
далее, ТС как считать хэш собрался?
Стандартными способами?
Тогда если операцию проводить часто, а в твоем случае так и выглядит, то лучше проводить проверку самому, и оптимизировать ее, а иначе смысла нет, т.к. вычисление md5 - такая же долгая операция, которую ты изначально не хотел.