C# Сравнение двух картинок

[noxjoker]

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

Решение
1. По пикселям – долгий вариант.
2. По байтам – проблема, поскольку файлы всегда разные по размеру.


Возможно решение поставить фиксированный размер на скриншот.
:confused:

[scrat]

Что если поделить картинку на зоны, скажем на 4. Потом сравнивать каждую зону с каждой, если они разные, поделить зону ещё раз и сравнить каждую часть.

[noxjoker]

scrat а как сравнивать? По пиксельно долго ...

[scrat]

погугли ещё по запросу «image diff», может найдёшь какую библиотеку.

[scrat]

scrat а как сравнивать? По пиксельно долго ...
вырезать и сравнить md5

[BrainDeaD]

scrat, какое это даст приемущество перед проверкой целой картинки? 1 = 4/4

[noxjoker]

вырезать и сравнить md5

Допустим они разные мне ж, потом нужно что-то заменить в первой картинке!

Например:

Если по пиксельное, то я узнаю какие пиксели разные потом изменяю их в первой картинке и получаю копию второй.

[scrat]

scrat, какое это даст приемущество перед проверкой целой картинки? 1 = 4/4
в том то и дело, что может быть и 3/4 и 2/4 и 1/4.

[Ra$cal]

для чего сравнивать надо? просто узнать о наличии различий(тогда можно обходить попиксельно но с изменяемым шагом до первой разницы, например проверяем каждый сотый пиксел, если совпали, то сдвигаем на один пиксель и заново проходим, и так 100 раз для проверки всей картинки. на худой конец никто не отменял многоядерность, плюс на хабре была тема про медленность попиксельной обработки
http://habrahabr.ru/blogs/net/92016/
http://habrahabr.ru/blogs/net/60085/

Если же обработка пикселов с разными значениями чтобы выравнять картинки - только попиксельный проход.

[BrainDeaD]

в том то и дело, что может быть и 3/4 и 2/4 и 1/4.
а, понял. в смысле, если 1/4 различна, то не нужно продолжать проверку. тогда вопрос в том, сколько частей оптимально? ведь проверить 1/8 быстрее, чем 1/4, и проверка может быть завершена уже после первой зоны. но в худшем случае придётся провести 8 проверок. так же можно уменьшить зону до пикселя, что усугубит ситуацийю для worst case, но сильно улучшит для best case.

[Ra$cal]

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

Интересно все таки узнать, какого рода картинки проверяются - фото, скриншоты, или еще что.

[noxjoker]

а, понял. в смысле, если 1/4 различна, то не нужно продолжать проверку. тогда вопрос в том, сколько частей оптимально? ведь проверить 1/8 быстрее, чем 1/4, и проверка может быть завершена уже после первой зоны. но в худшем случае придётся провести 8 проверок. так же можно уменьшить зону до пикселя, что усугубит ситуацийю для worst case, но сильно улучшит для best case.

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

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

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

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


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

[Ra$cal]

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

[Ra$cal]

Pixel oldPixels[];
Pixel newPixels[];

for(int curPixIndex = 0; i < 1000; curPixIndex++){
if(oldPixels[curPixIndex] != newPixels[curPixIndex])
return false;
return true;
}

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

а md5 имеем

md5(Pixels[] pixels)
{
foreach(Pixel pixel in pixels){
...
}

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

[scrat]

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

[noxjoker]

Сотри.

Есть первая картинка мы просто берем ее скрин.
http://s11.radikal.ru/i184/1006/09/42cbcb4b48e6.jpg
Вторая картинка это скрин с изменением, например, вылезло окно.
http://i061.radikal.ru/1006/de/247a54052d12.jpg
Мы должны узнать, где вылезло это окно, но мы ж не хотим сравнивать попиксельно и не хотим весь скрин кидать. Мы делим вторую картинку, например на 4 части.
http://s45.radikal.ru/i108/1006/3d/7d60d7d39f76.jpg
Узнаем хеши каждой части. Если эти хеши совпадают тогда это не та часть а если ода из частей не совпала тогда эта та часть и ее мы кидаем себе и просто налажуем на первую картинку.

[Ra$cal]

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

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

[scrat]

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

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

[scrat]

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

[GhostOnline]

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

[sn0w]

офф

захват картинки посредством гди это извращнение, на что кстати больше всего времени и тратится

тема - когдато разбивали по сетке и прикладывали к RLE, но результат все равно кальный был