Сравнение 2-х изображений

[Demiurg]

valyala
помоему вопрос очень хорошо описывает то, что нужно. Про пятилетних детей там нет ни слова.

 

[Silent]

Зато вопрос ничего не говорит о том, какие трансформации изображения допустимы и должны быть распознаны. Говорилось только про размер. Примерная картинка показывает, что и палитра изображений может отличаться. А как быть с поворотом изображения? А помехи? И так далее. В самой общей постановке эта задача сводится к распознаванию образов, что до сих пор не имеет нормального решения. Так что либо нужно сужать множество допустимых преобразований, либо не искать легких решений.

 

[Demiurg]

Silent
вопрос звучит так:
"как произвести сравнение по алгоритму использующемся в такой то программе?"
Что еще не понятно ?

 

[Crazy]

Автор оригинала: Stewie
Один мой знакомый сказал, что может легко написать такой скрипт на Perl за 60$
Алгоритм выдавать не хочет

Просто цитирую:

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

 

[Silent]

Demiurg

Тебе известен алгоритм, который использует эта программа? Если нет, то такая постановка вопроса не имеет смысла. Нужно найти алгоритм, который делает то же самое, что и данная программа.

 

[Найч]

Автор оригинала: Silent
Зато вопрос ничего не говорит о том, какие трансформации изображения допустимы и должны быть распознаны. Говорилось только про размер.

Вы пробовали предлагаемую автором программу? Вы читали, _для чего_ она предназначена? Заоблачного там ничего нет, но это и непросто реализовать. То, на что вы сделали ударение, описано в работе Image Dupless.

Автор оригинала: Stewie
Один мой знакомый сказал, что может легко написать такой скрипт на Perl за 60$

Только я считаю, что перловый вариант будет задыхаться. Не для этого он писан. По-моему, этот человек не совсем хорошо ознакомился с заданием))
Я бегло просмотрел MSDN на тему работы с изображениями - в лоб эта задача не решаеться, но реализацию сего действа пока вижу только на winAPI.
Кстати, Demiurg, предложенный вами алгоритм сравнения массивов в данном случае не подходит, поскольку дает слишком большую погрешность. Несомненно, для приблизительного сравнения идея хорошая, но в данном случае _алгоритм_ не должен давать погрешности вообще

 

[Найч]

Автор оригинала: Silent
Demiurg

Тебе известен алгоритм, который использует эта программа? Если нет, то такая постановка вопроса не имеет смысла. Нужно найти алгоритм, который делает то же самое, что и данная программа.

Какие у вас есть предложения?

 

[Demiurg]

Silent
мне не известен. Я думаю, что всем отвечающим он так же не известен. Известен он только авторам данной программы, поэтому см. мой первый ответ.

>Нужно найти алгоритм, который делает то же самое, что и данная программа.
хорошо сказано. Осталось только найти такого человека, который составит его.

 

[Silent]

Заплатить автору той программы, чтобы он сделал возможность работать с ней (пусть и не в полной мере) через командную строку.

 

[Найч]

Автор оригинала: Silent
Заплатить автору той программы, чтобы он сделал возможность работать с ней (пусть и не в полной мере) через командную строку.

Почему-то мне такой вариант не нравиться. Что нужно-то? Желательно бесплатная возможность работать с функцией сравнения изображений, но главное - дальнейшая поддержка.
Пусть я заплачу за эту фичу разработчику, и он даст мне либу. Не алгоритм, а именно что-то, прикручиваемое к чему-то. И в дальнейшем должен будет либо продолжать поддержку (я бы не стал - слишком мал круг заинтересованных), либо отказаться от сопровождения (а тут уже зажат в рамки покупатель либы). Как по мне, все это переливание из пустого в порожнее.

 

[zumo]

Тут очень простой алгоритм :
1)Ресайзисм картинки к одному размеру
2)В цикле вычисляем индекс* контрастности
3)Загоняем в массив* все высококонтрастные переходы (восоко или невысоко контрастный он определяем по индексу*)
4)Сравниваем массив* 1 и 2 картинки по углам поворота линий перехода и размерам высоко контрасных областей
если не соответствует то сразу говорим что картинки разные
5) Если подходит то сравниваем цвета пообеим сторонам линий перехода с небольшим допуском с учётом изменения другого цветового канала (rgb)
6) если катит то говорим что картинки одинаковые

ps я такое когдато писал на vb
http://digitall.cpdstudio.com
icq 286800354

-~{}~ 08.02.04 19:48:

дополнение:
Линии высококонтрастных переходв можно описать какимнибудь "языком" напр:
угол примерно 40 грд размер одна треть картинки дальше поворот налево на 70 грд итд
можно ввести "тип данных" дуга окружность итд

вся моя теория основана на том что человек воспринимает в основном не цвета а контрастные переходы

 

[Bermuda]

Есть гораздо более простое решение.
1. Приводим картинки к одному размеру.
2. Инверитруем одну из картинок.
3. Складываем нормальную и инверитрованную картинку. В разультате получим изображение на котором одинаковые части станут черными, а отличающиеся части будут светлее.
4. Считаем количество пикселей отличающихся от черного цвета и умножаем каждый пиксель на процент яркости, взяв за 100% самый якркий пиксель.

Полученный процент и есть математическое различие двух изображений.

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

Еще идея. Перед выполнением вышеописанного алгоритма можно "упросить картинку". Дело в том, что когда мы смотрим на картинку мы не воспринимаем ее как набор пикселей, а воспринимаем как образ. В данном случае нужно немного "заблурить" картинку.

1. Уменьшить разрешение до минимально допустимого (можно найти опытным путем).
2. Уменьшить количество цветов в палитре.

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

 

[slach]

ну потеоретизировали, замечательно, а теперь кто нибудь может сказать ? ЗАЧЕМ это надо человеку ? какая практическая область применения у АВТОРА ВОПРОСА ?

 

[Найч]

Приблизительно та же, что и у Image Dupless.
Да и мало ли какая? Разве можно предусмотреть все варианты?

 

[Alien]

Автор оригинала: slach
ну потеоретизировали, замечательно, а теперь кто нибудь может сказать ? ЗАЧЕМ это надо человеку ?

Да есть, есть.
Я тоже подумываю неспешно что мне такая вещь нужна.
Есть вагон с тележкой картинок, из них много ~одинаковых, хочется оставить уникальные.

 

[Span]

У меня была детская энциклопедия, там была интересная статья о том как "читает" изображение человеческий глаз. Глаз никогда не смотри на одну точку, он все время бегает по изображению. Находит наиболее характерные точки, например темные точке на лице - глаза, рот, ноздри. Я тоак думаю мозг судит об объекте по взаимному расположению точек.

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

 

[Дед Анвирыч]

Я тоак думаю мозг судит об объекте по взаимному расположению точек.

А вы не в ABBYY работаете? ))

 

[Demiurg]

Span
да, надо всего лишь реализовать искуственный интелект.

 

[Span]

Вчера читал статью о нейро сетях. =) До сих пор под впечатлением. Но тут нейросети не нужны, мы же машину обучать не собираемся, просто поиск точек и подобия их расстояний.

 

[Developer]

Вообще на такие темы дисеры пишут.
А использовать нужно статистические методы. Чем более сложные, тем лучше будет результат...
Простейший вариант: сегментируем оба изображения (делим на прямоугольники например 10х10). В каждом маленьком сегменте вычисляем среднюю яркость. Вычитаем яркости соответствующих сегментов одного изображения из другого. В итоге получаем последовательность чисел. Вычисляем ее дисперсию. Сравниваем с пороговым значением. Если дисперсия выше - это разные изображения. Если ниже - одинаковые. Пороговое значение определяет степень похожести ....