1. Найти фон сделать его одноцветным.
2. Найти заливку букв и сделать её одноцветной.
3. ??Попробовать перевести в векторную форму?? - не знаю, как, но может облегчить задачу.

найти фон, заливку мдя, рекурсивная задача -- для того что бы найти изображение надо найти изображение. ТУФТА!

Цитата(cully @ 12.2.2003, 22:04)

найти фон, заливку мдя, рекурсивная задача -- для того что бы найти изображение надо найти изображение. ТУФТА!

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

какая нафиг частота появления цвета при таком рисунке:



Это сообщение отредактировал(а) cully - 2.4.2003, 21:07

Мне кажеься в приведенной функции есть большие резервы для оптимизации даже без поиска каких то более оптимальных алгоритмов.
Известно что обращение к Bitmap через Canvas.Piexels[] операция очень медленная. Поэтому более оптимально сравнивать используя непосредственный доступ к Bitmap через ScanLine.
Получится несколько сложней из за необходимости учитывать формат пикселя но зато гораздо быстрее. По крайней мере у меня в свое время удалось таким образом увеличть скорость в несколько раз.

Цитата(cully @ 14.2.2003, 19:39)

какая нафиг частота появления цвета при таком рисунке:

Я не говорил, что этот алгоритм ловит все ситуации. Он может раскусить многие антиавторег-картинки.

Цитата(December @ 14.1.2003, 00:15)

//Фигуративные точки для данной картинки, 3 шт.        if pixels[i+8,j+6]=gSI.Canvas.Pixels[8,6] then        if pixels[i+10,j+10]=gSI.Canvas.Pixels[10,10] then

Вот вместо Pixels[] неплохобы использовать ScanLine
Часто позволяет ускорить в несколько разы правда придется усложнить процедуру для работы с разными форматами Bitmap.
Возможно и необходимость в сложных алгоритмах отпадет.

Да, я так и сделал (в других местах). Всё круто. От 80 секунд остались 0,8 секунды!

быстрый поиск ИМХО должен быть реализован в виде вложенныйх циклов проверки:
ищем на большой верхний левый пиксел маленькой, если находим то проверяем, на совпадают ли цвета пиксела, находящегося справа, внизу. справа+1, внизу+1, справа-внизу и т.д. по всей маленькой картинке.

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

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

а если бы еще и в однозадачной среде....

Есть такой алгоритм, по поиску картинок в в очень большой картинки(я лично решал - картинка была 100000x1000). Вот суть. Ты берёшь свою маленькую картинку и потсрочно её кодируешь, т.е если у тебя картинка ввиде матрицы:
36 58 12 - (3)
24 59 35 - (6)
86 78 93 - (9)
Откуда я взял числа в скобках. Ты строишь дерево с корнем в нулевой вершине. Если у тебя первый цвет с кодом 36 и из вершины в которой ты находишься нет ребенка с значение 36, то создаешь его и инкрементишь счетчик. Как проходишь одну строчку запоминаешь счетчик за данной строкой. Теперь идя по строкам перемещаешься по дереву в соответствии с кодом нового цвета. Если пути в новый цвет нет, то ты берешь твою последовательность и сдвигаешь влево. И опять ищещь такую вершину в дереве. Полезно значения такой функции запонить в массиве.
Аналогично для вертикального. Кодируешь таким же образом твою картинку в новое дерево(для одной картинки всегда будет одна вершина с номером 1). Тут уже можно и не запоминать(но не желательно) значения функции для каждого значения нового кода строчки. Этот алгоритм при правильной реализации работает на матрице MxN за O(MxN)

Давайте внесем немного ясности:
1)стороны малой картинки паралельный сторонам большой или не обязательно?
2) искомое изображение совпадает полностью с эталоном или возможны шумы/колебания яркости и цвета?
3) искомое изображение полностью присутствует в исходном или возможно наличие только части изображения?
4) искомое изображение встречается только раз в большом или его количество не определено?
5) масштаб искомого изображения неизменен?

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

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

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

Это сообщение отредактировал(а) GePo - 1.4.2003, 22:43

Джентльмены,
вообще-то задача решена, то есть, премного благодарен, если вы мне помогаете, но всё уже позади. Есди же вы обсуждаете данный вопрос как абстрактную задачу, то вот как был поставлен вопрос с самого начала:

Цитата

1)стороны малой картинки паралельный сторонам большой или не обязательно?

Да

Цитата

2) искомое изображение совпадает полностью с эталоном или возможны шумы/колебания яркости и цвета?

Совпадает

Цитата

3) искомое изображение полностью присутствует в исходном или возможно наличие только части изображения?

Полностью

Цитата

4) искомое изображение встречается только раз в большом или его количество не определено?

Не суть важно, где один, там и десять.

Цитата

5) масштаб искомого изображения неизменен?

Да.
Как показала практика, выигрыш в скорости за счёт использования ScanLine на порядок выше выигрыша от хитроумных алгоритмов.

вообще-все это ускоряется трансформом фурье быстрым

Если можно, подробнее.