findimage в LUA Опции

[apaul]

Еще раз спасибо за модуль - впечатления сугубо положительные, но есть некоторые непонятки (а куда же без них)? (IMG:style_emoticons/default/biggrin.gif)

Иногда может казаться что картинка не ищется потому, что что-то сделано неправильно, а всё дело в значениях параметров поиска.

Пытаюсь бороться со сглаживанием шрифтов, да еще на разных фонах - родились вопросы.
- Какое условие более "мягкое" (при каком будет найдено больше совпадений)?
1. acc=93, dev=15;
2. acc=85, dev=15.
В очередной раз перечитал доки - похоже я неправильно понял параметр acc. Думал - оно по аналогии со стандартом, показывает насколько пиксели шаблона должны совпасть с проверяемым участком с учетом заданного отклонения. Но у Вас он работает несколько по-другому. Хочется осознать как именно, заодно и про dev уточнить (IMG:style_emoticons/default/smile.gif)
Что происходит при {fgr=true, b=255, dev=15}? Мы находим искомый шаблон, если шаблонные пиксели с B=255 попали в пиксели на искомой картинке с B=240-255? Или в качестве шаблонных будут браться пиксели с B=240-255 и затем уже сравниваться с искомой картинкой без каких-то допусков? Или что-то третье?
А как работает {fgr=true, b=255, acc=30} - для меня вообще темный лес. Тут же тоже что-то с чем-то сравнивается. Расскажите пожалуйста что откуда и куда (IMG:style_emoticons/default/rolleyes.gif)

[sutra]

инфо

Код

Начну с ключей для каналов.
Ключи из строчных символов определяют нижнюю границу значений каналов пикселей для формирования шаблона.
Ключи из ПРОПИСНЫХ символов определяют верхнюю границу значений каналов.
Если верхняя граница не указана, она по умолчанию равна нижней.
То есть условие b=200 идентично условию b=200, B=200.
Для ключей, определяющих разность между каналами пикселей, большее значение по умолчанию равно 255.
То есть условия rg=200 и rg=200,RG=255 идентичны (канал RED должен быть больше канала GREEN не менее чем на 200 единиц).

Ключ fgr определяет какие пиксели, соответствующие условию, будут фоновыми, а какие искомыми.
Если ключ fgr определён и не имеет значения false ( if fgr==true ) - это значит, что пиксели соответствующие условию
будут являться искомыми и попадут в шаблон. Например: {{fgr=true, b=0, B=255}} Все пиксели картинки попадут в
шаблон, то есть будет проверяться каждый пиксель картинки функцией поиска. Почему? Да потому, что любой пиксель
удовлетворяет условию.
Если ключ fgr НЕ определён - это значит что пиксели соответствующие условию будут считаться фоновыми и НЕ попадут
в шаблон. Например при условии: {{b=0, B=255}} - шаблон будет пустым, так как ВСЕ пиксели картинки будут считаться фоновыми.
Пример: мы создали картинку закрасив в исходной все "ненужные, лишние" пиксели чёрным цветом RGB=(0,0,0) - они должны быть
фоном. Оставили скажем 5 пикселей красного цвета с RGB=(255,0,0) и 10 пикселей зелёного цвета с RGB=(0,255,0).
Условие формирования шаблона должно быть таким {{r=0,g=0}} , то есть, если пиксели имеют значения каналов RED И GREEN равными нулю,
они будут считаться фоновыми и не попадут в шаблон.
Предположим, что зелёных пикселей в образе НАМНОГО больше чем красных. И чтобы повысить скорость поиска мы хотим сначала
анализировать красные пиксели и только потом зелёные.
Варианты условий для такой задачи:
  1) { {r=255,fgr=true}, {g=255,fgr=true} }
       сначала в шаблон попадают красные пиксели, а потом зелёные пиксели - самый простой и логичный вариант,
       чтобы не запутаться в условиях.
  2) { {r=255,fgr=true}, {r=0,g=0} }
       сначала в шаблон попадают красные пиксели, а потом ВСЕ пиксели у которых канал  RED  ИЛИ  GREEN  НЕ равен нулю,
       то есть оставшиеся зелёные пиксели.
  3) { {r=255,fgr=true}, {g=0} }
       сначала в шаблон попадают красные пиксели, а потом ВСЕ пиксели у которых канал  GREEN  НЕ равен нулю,
       то есть оставшиеся зелёные пиксели.
Во втором и третьем варианте на первый взгляд нарушена логика. НО, УСЛОВИЕ №2 не влияет на первое.
Если пиксель уже в шаблоне, следующие условия не могут его исключить из шаблона и не могут изменить его параметры.


Ключ dev - это допустимое плюс минус отклонение каналов RGB в абсолютных единицах.
Ключ acc - это допустимое плюс минус отклонение каналов RGB в процентах (относительные значения).
Эти два ключа формируют параметры для функции FindImage и не влияют на создание массива искомых пикселей в шаблоне картинки.
Они определяют допустимые отклонения каналов RGB пикселей образа, от каналов RGB соответствующих пикселей шаблона.
Почему они присутствуют в функции CreateFindArray ? Исключительно для уменьшения математики и увеличения скорости
поиска функцией FindImage.


Рассмотрим на конкретном примере. Допустим искомый пиксель шаблона имеет RGB=(100,200,50).
Задаём параметр отклонения каналов: dev=10.
Если на экране (образе) поиска, в требуемой позиции, находится пиксель с RGB от (90,190,40) до (110,210,60), то есть плюс минус 10
единиц от значений каналов пикселя шаблона, то такой пиксель считается приемлемым - поиск даст положительный результат.

Ключ acc ... Я уже пожалел, что сделал его в таком виде, то есть acc=90 - это допустимое отклонение каналов на 10% (100-90),
наверное лучше было задавать его как acc=10, но как сделал, так сделал. Хотя подправить - раз плюнуть.

Итак для рассматриваемого пикселя, при acc=90 на экране будут искаться пиксели с RGB от (90,180,45) до (110,220,55),
то есть плюс минус 10% для каждого канала.

Если одновременно заданы оба ключа: dev=10, acc=90
на экране будут искаться пиксели с RGB от (80,170,35) до (120,230,65), то есть плюс минус 10% и 10 единиц.

Резюме: чем больше dev и (или) чем меньше acc тем шире поиск (мягче).

Зачем нужен ключ acc, если можно однозначно задать любое отклонение ключом dev?
Дело в том, что пиксели картинок "плавают" по вполне определённым правилам. Условно, если пиксель был красным,
то он и будет красным, а не зелёным. А это значит, что каналы пикселей изменяются (плавают) пропорционально,
то есть по идее как раз и нужен параметр acc который и задаёт пропорции в процентах.
Тогда возникает резонный вопрос, а зачем тогда нужен dev?

Рассмотрим на конкретном примере, например мы ищем красный пиксель картинки, в шаблоне он имеет RGB=(200,0,0).
На экране нас устроит красный пиксель и с RGB=(255,0,0) и с RGB=(200,20,10).
Если мы зададим отклонение даже хоть в 40% (acc=60), каналы GREEN и BLUE пикселя шаблона не будут иметь
отклонения, так как нуль на что не умножай, останется нулём.
Поэтому ключ dev нужен для создания диапазона отклонений для каналов RGB с низкими значениями.

Поэтому повторяюсь, если нет 100% уверенности, что пиксель имеет значения каналов не менее чем 70-100 единиц, то
использование ключа dev обязательно. Как уже говорил вполне приемлемое сочетание два 2 к одному:
{dev=5,acc=90}; {dev=10,acc=80}; {dev=12,acc=76} и т.п.

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

Ну и надо помнить, что границы объектов подвержены максимальным искажениям, поэтому пиксели границ нужно
исключать из шаблона поиска. Подразумеваются границы реальных картинок, а не изображения символов и т.п..
Либо при поиске FindImage использовать параметр похожести картинки sim, но он может сильно замедлить поиск,
особенно при больших зонах поиска, поэтому использовать его надо в крайнем случае, когда иначе картинка не ищется.

[apaul]

sutra, продолжаю эксперименты с Вашим модулем. С чем-то удалось разобраться, решил уточнить на всякий случай. Насколько понял, dev и acc по смыслу близнецы/братья, с той лишь разницей, что acc задается в относительных единицах, а dev в абсолютных? На такой вывод намекают формулы типа bgr[0]*acc+dev. Или мои выводы ошибочны?
По принципу поиска {fgr=true, b=255, dev=15} тоже вроде разобрался (по крайней мере результаты тестов пока совпадают с моими ожиданиями (IMG:style_emoticons/default/smile.gif)

ЗЫ: отправил пост, а тут уже есть ответ от Вас. Пошел вчитываться (IMG:style_emoticons/default/smile.gif)
ЗЗЫ: спасибо за столь развернутый ответ, даже есть пояснения на мой невысказанный вопрос "зачем два одинаковых параметра". Теперь вроде все ясно, еще раз благодарю за модуль.

[sutra]

Что можно ещё добавить. Правильно подобрать отклонение несложно. Нужно определить сначала жёсткую границу параметров, когда картинка начинает искаться, скажем ищем цифру 8, при параметрах dev=10, acc=80. Затем расширять диапазон, пока не начнут искаться уже Две картинки, скажем цифра 8 и цифра 5, при параметрах dev=20, acc=60. Соответственно оптимальными будут dev=15, acc=70.

[apaul]

sutra, столкнулся с непонятным для меня поведением поиска. Никак не пойму, с чем оно связано.
Ищу на скриншоте шаблон в ограниченных координатах с параметрами {r=0, acc=70, dev=15} - находит 1 совпадение (на самом деле их должно быть 2). Проверяю функцией подбора точности - показывает разброс точности от 80 до 26. Меняю параметры на {r=0, acc=75, dev=15} - находит оба совпадения. Возвращаю назад - снова одно. Ставлю acc=60 - находит оба. Начинаю играться с acc и получаю чудеса:
acc=60 - 2 совпадения;
...
acc=67 - 2 совпадения;
acc=68 - 1 совпадение;
...
acc=71 - 1 совпадение;
acc=72 - 2 совпадения;
...
acc=75 - 2 совпадения.
И самое досадное, что если даже выбираешь "рабочий" на данном поиске параметр acc, подобные чудеса начинают выплывать на другом скриншоте с другими цифрами.

[Cockney]

Что можно ещё добавить. Правильно подобрать отклонение несложно. Нужно определить сначала жёсткую границу параметров, когда картинка начинает искаться, скажем ищем цифру 8, при параметрах dev=10, acc=80. Затем расширять диапазон, пока не начнут искаться уже Две картинки, скажем цифра 8 и цифра 5, при параметрах dev=20, acc=60. Соответственно оптимальными будут dev=15, acc=70.

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

[sutra]

Конечно лучше бы взглянуть на код, прежде чем давать советы. Уверяю, с параметрами всё в порядке,
там никаких чудес быть не может.
Давайте так, если не сможете сами разобраться что к чему, дайте кусок кода поиска, а если дадите ещё и сами картинки, думаю что смогу дать исчерпывающие рекомендации.
Есть три момента влияющие на результат:
1) Либо шаблон ищется не там где надо;
2) Либо шаблон создан некорректно;
3) Неверно работает скрипт (некорректный код).

Я не совсем понял про совпадения. Два совпадения - это про что? В искомом числе должна быть дважды найдена искомая цифра ??
В общем для начала надо смотреть код.

Будете давать код, заключайте его в теги. Смотри общие правила форума, пункт 1.9

[sutra]

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

[apaul]

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

Так еще вчера отправил в личку тестовый код вместе с картинкой, шаблоном и даже модулем на всякий пожарный (IMG:style_emoticons/default/wink.gif). Там история еще более необъяснимая для моей логики. Не понимаю, как при "ужесточении" рамок поиска может находиться большее количество совпадений.

Код

12:37:09 : найдено 4 совпадений для acc=70
12:37:09 : найдено 4 совпадений для acc=71
12:37:09 : найдено 2 совпадений для acc=72
12:37:09 : найдено 2 совпадений для acc=73
12:37:09 : найдено 2 совпадений для acc=74
12:37:09 : найдено 2 совпадений для acc=75
12:37:09 : найдено 2 совпадений для acc=76
12:37:09 : найдено 2 совпадений для acc=77
12:37:09 : найдено 1 совпадений для acc=78
12:37:09 : найдено 4 совпадений для acc=79
12:37:09 : найдено 4 совпадений для acc=80

[sutra]

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

Сразу на вскидку. Глянул на шрифт. Уверяю 100% всё будет искаться ну просто "ЖЕЛЕЗОБЕТОННО" и легко и просто. Сделаю, но понадобится какое то время, придётся подождать, ленивым я стал.

[apaul]

Сразу на вскидку. Глянул на шрифт. Уверяю 100% всё будет искаться ну просто "ЖЕЛЕЗОБЕТОННО" и легко и просто. Сделаю, но понадобится какое то время, придётся подождать, ленивым я стал.

Ну да, шрифт там такой, что не промахнешься (IMG:style_emoticons/default/smile.gif). Вроде локализовал виновника - это параметры shiX и shiY. Точнее в данном конкретном случае shiY. Ищется "логически правильная" цепь количества совпадений только при shiY=0. Неужели придется дубли лопатить "врукопашную"?
ЗЫ: такое впечатление, что код отсеивает дубли, когда следующее совпадение отличается сразу на ОБА параметра (shiX и shiY), а не на хотя бы один.

[sutra]

Всё верно виновник - это смещения. Вот сижу и смотрю FindImage. Я сам не работал со смещениями, мог чего и напортачить. Сижу разбираюсь - забыл уже сам чего там лепил.


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

[sutra]

Вроде с финдом всё нормально. Насколько я понял, то происходит следующее. Сам шаблон настолько универсален, что ищется там где надо и не надо. При параметре = 80 - отрабатывает как надо, поскольку ордината поиска корректна. Увеличивая диапазон (=75) финд начинает находить некоторые цифры уже в ординате 10, а не в корректной 11, - делает смещение поиска вниз и другие цифры уже не находит. Ещё увеличивая диапазон (acc=70) - начинает находить цифры и ниже, слишком большой диапазон поиска. Поэтому и возникает такая иллюзия.
ВОПРОС?? Если ордината поиска известна, зачем вообще искать везде? Начальную ординату поиска можно жестко задать равной 11 и никаких проблем не будет.

[sutra]

Ваш шрифт имеет абсолютно стандартное выравнивание. То есть, есть ТРИ варианта написания символов. Не надо ничего "красить" в шаблоне. Достаточно задать условие {fgr=true, r=255, dev=5} и будет создан шаблон который будет иметь 100%-ную уникальность и не надо будет вообще использовать смещения при поиске. Нужно просто создать 30 шаблонов. Пример такого цикла поиска я давал. Если будет нормальная скорость, то больше ничего делать и не надо. Хотя я для себя конечно же делал 10 универсальных шаблонов, но там надо контролировать, чтобы все ТРИ варианта написания символа удовлетворяли ОДНОМУ шаблону и 100% исключали совместимость с другими цифрами.
Я вообще сначала вычисляю границы числа, вычисляю количество разрядов, вычисляю позиции для каждого разряда и ищу каждую цифру там, где она должна быть. Позиции для цифр, если лень делать формулу их вычисления, можно грузить уже из ранее сформированного массива, тогда вообще всё ищется мгновенно.

[sutra]

Ну а конкретно в вашем частном случае, либо жестко задавать ординаты поиска, либо, как это не странно - ужесточать поиск, причём dev вообще не нужен - он ещё плюсом даёт диапазон +- 15 единиц. Всё чудесно ищется параметром acc=90, вообще без dev.

[apaul]

делает смещение поиска вниз и другие цифры уже не находит. Ещё увеличивая диапазон (acc=70) - начинает находить цифры и ниже, слишком большой диапазон поиска. Поэтому и возникает такая иллюзия.
ВОПРОС?? Если ордината поиска известна, зачем вообще искать везде? Начальную ординату поиска можно жестко задать равной 11 и никаких проблем не будет.

К сожалению никакие координаты точно не известны - они плавают, впрочем как и фон. Да и шрифт рендерится не всегда как на тестовой картинке. Может "смазаться" в любую из 4х сторон, поэтому и шаблон обрезался до столь "универсальных" границ. По 3 шаблона делать мне как раз не хочется, и раз уж смещения работают так как должны, проще будет искать совсем без них, а после отлопатить дубли (по времени - это копейки).
Спасибо, что помогли разобраться с таким нюансом в поиске, просто у себя привык, что дубли режутся подобной функцией, а тут оказалась немного иная логика (IMG:style_emoticons/default/smile.gif)

дубли

Код

    local clearresult = {}
    for i=1,#rawresult do
            local duplicate=false
            for j=i+1,#rawresult do
                if math.abs(rawresult[i][1]-rawresult[j][1]) < delta then
                    duplicate=true
                    break
                end
            end
            if not(duplicate) then
                clearresult[#clearresult+1]=rawresult[i]
            end
        end

[sutra]

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

[apaul]

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

Вы не поверите, именно так и делаю (IMG:style_emoticons/default/smile.gif). Но пляшу от него по Х в разные стороны, фиксировать же Y по слэшу не рискую - тоже может гульнуть +-пару пикселей.
Ну и для всех, подобно мне, пришедших к необходимости использования модуля финда, подаренного нам sutra, попробую пояснить особенность применения смещений. Надеюсь кому-то поможет обойти исхоженные мной грабли (IMG:style_emoticons/default/wink.gif)
Искомый экран: (IMG:https://i.ibb.co/vhqLwtD/scr.png) (два одинаковых прямоугольника, сдвинутых по высоте на пиксель)
Шаблон: (IMG:https://i.ibb.co/VBQyQZg/tpl.png) (вырезанный с искомого экрана прямоугольник)
Найти оба прямоугольника с shiY, отличным от нуля, при таком шаблоне невозможно с любыми разумными допусками. Поэтому применяем смещения с крайней осмотрительностью.
Код для экспериментов:

Код

--lua
require[[luaPlugins\cif]] -- путь до модуля
path = [[A:\pilot\tests\]] -- путь до картинок

LoadImage (path..[[scr.bmp]]) -- тестовая картинка для поиска
local x1, y1, x2, y2 = 0, 0, CIP[1][0]-1, CIP[1][1]-1 -- область поиска
local tpl = CreateFindArray ({ {nf=path .. "tpl.bmp"}, {r=0, acc=85, dev=15} })
local k,arr = FindImage( x1, y1, x2, y2, tpl,   {nP=-1, shiX=1, shiY=1} )
if k > 0 then
    log("найдено "..k.." совпадений")
else
    log("совпадений не найдено")
end
end_script()

[sutra]

Инфо для apaul

Код

    Всё-таки попробую дать рекомендации, которые на мой взгляд ускорят поиск и улучшат достоверность поиска.
    Итак, шрифт стандартный, плоский (не объёмный, без теней). Фон однородный, без переливов (не инверсионный).
Это позволяет для подавляющего большинства пикселей определить их принадлежность либо к фону, либо как
принадлежащих к каркасу символов, которые значительно ярче фона. Пиксели фона в представленном примере имеют
RGB=(116,67,43). Исходя из предположения, что всё это может очень сильно "плавать", будем считать фоновыми все
пиксели, канал BLUE которых находится в диапазоне от нуля, до 119. То есть "запас прочности" 76 единиц -
этого более чем достаточно. Соответственно пиксели, канал BLUE которых находится в диапазоне от 120 до 255,
будем считать принадлежащими символам, запасик тоже вроде есть (сориентируетесь сами где лучше делать запас).
    Начнём с шаблонов. Предлагаю для достоверности идентификации цифр использовать поиск и фоновых пикселей.
Поскольку задача состоит в создании универсальных шаблонов (для 3-х вариантов изображений) использование
фоновых пикселей сильно облегчит эту задачу. Например, цифра 3 может не так сильно отличаться от цифры 8,
если искать её используя только яркие пиксели каркаса символов. А вот если использовать в шаблоне и пиксели
фона, которые однозначно должны присутствовать у цифры 3 по левой границе изображения цифры, поиск даст
достоверный результат.
    Итак, в шаблоне цифры 3, по левой границе, можно смело добавить скажем 6 пикселей, которые на экране
поиска должны быть фоновыми. Закрасим эти пиксели скажем с RGB=(90,80,58), к ним мы применим параметры
{dev=5, acc=5} что даст пикселям фона огромный диапазон RGB от (0,0,0) до (181,161,119).
Каналы RED и GREEN нас не интересуют и запас по ним ещё больше, поскольку за основу принимаем канал BLUE.
Таким образом можно добавлять "тёмные" пиксели практически в шаблон любой цифры.

    Далее. На мой взгляд можно значительно сузить зону поиска, в первую очередь точно идентифицируя
верхнюю границу символов. Не забываем про мощный инструмент под названием FindColor. Одним её вызовом
мы убьём сразу 2-х зайцев. Определим верхнюю границу символов и определим количество разрядов чисел.
Приведу пример только для числа правее слэша, думаю принцип будет понятен.

    Далее код с комментами, надеюсь будет понятно, никаких смещений не будет.

--\/ Ищем на экране все пиксели, принадлежащие символам (координаты как в вашем примере - границы скрина)
local b,k = FindColor(x1, y1, x2, y2, {b=120,B=255,nP=-1})
if not (b) then  log("Что то пошло не так")  stop_script()  end  -- ничего не нашли
--\/ Верхняя граница символов равна ординате (1) ПЕРВОГО (с индексом нуль) найденного пикселя
--\/ Уверен на 99% , что всё будет работать корректно. Для удобства обзовём её yUp
local yUp=CI[0][0][1]
--\/ абсцисса нижнего пикселя слэша, он будет найден последним, она понадобится для вычисления количества разрядов.
local xS=CI[0][k][0]

--\/ Определяем количество разрядов числа правее слэша
--\/ Сначала ищем правую границу числа - очень приблизительное значение, но его будет достаточно
local xR=0      -- правая граница числа
for i=k-1,0,-1 do  -- цикл анализа найденных пикселей от конца к началу
--\/ если абцисса очередного найденного пикселя более чем на 20 пикселей отличается от абсциссы
--\/ слеша - найден пиксель принадлежащий самому правому символу цифры.
  if CI[0][i][0] - xS > 20 then  xR=CI[0][i][0]  break  end
end
--\/ количество разрядов округляем в большую сторону. 17 - это приблизительно ширина слэша + ширина пробела (5-6 пикселей)
--\/ 11.5 - (на вскидку) расчётная ширина символов цифр - колеблется 11 или 12
local raz = math.ceil((xR - xS - 17) / 11.5)

-- Осталось идентифицировать число. Естественно далее я проверить код не мог.
local number=0  -- значение идентифицируемого числа, пока = 0
local mng=1     -- значение множителя для текущего разряда (для младшего разряда, далее будет увеличиваться на порядок)
for i=1,raz do
  local digit=-1  -- значение очередной цифры (отрицательное значение - пока не определена)
  local xF1=math.floor (xS+17+(raz-i)*11.5 - 1)  -- минус 1 - допуск влево на 1 пиксель
  local xF2=xF1 + 5                              -- плюс 5 - допуск вправо
  local chk=0                                      -- количество найденных цифр (контроль корректности поиска)
  for j=0,9 do                                     -- цикл анализа 10 шаблонов цифр
    for x=xF1,xF2 do                                 -- цикл анализа 6-ти возможных позиций (с запасом)
      if FindImage(x,yUp,x+12,yUp+16,DIG[j]) then    -- 16 - высота цифр минус 1; 12 - условная ширина цифр
        chk=chk+1                                      -- цифра найдена - плюсуем количество найденных
        if chk>1 then                                  -- если нашли уже вторую цифру
          log("Атас! Нашли ДВЕ цифры: ",digit," и ", j)
          -- далее действия, например: сохранение зоны поиска в файл; инициализация ошибки и т.п.
        end
        digit=j
        break
      end
    end
  end
  if digit<0 then
    log("Кердык! Нихрена не нашли")
    -- далее действия, например: сохранение зоны поиска в файл для коррекции или создания нового шаблона
  end
  number=number+digit*mng
  mng=mng*10
end
log(number) -- значение числа.

Ковырял всё на сорую руку, мог и ошибиться - задача была показать логику поиска.
!!!!!!! Ваши шаблоны нужно увеличить по высоте на 2 пикселя, добавив например пустые строки пикселей сверху и снизу
Совсем забыл ... условие для формирования шаблонов нужно дополнить { {r=90,fgr=true,dev=5,acc=5}, {r=0,acc=80} }

[apaul]

sutra , большое спасибо за рекомендации! Очень интересен показался механизм задействования в шаблоне и поиске фоновых пикселей - я как-то даже не сообразил о столь элегантном приеме. В остальном тоже есть чему поучиться (IMG:style_emoticons/default/shtanga.gif) .
Но даже с моими "кондовыми" способами распознавания, основанными чисто на логике (типа, если на одном месте нашлись шаблоны и "1" и "4" - то оставляем "4", а "1" отбрасываем как дубль), ваш модуль работает просто чудесно. Распознавание, которое стандартом длилось 600-800 мс, теперь делается за 25-35мс и при этом распознается в 2 раза больше чисел. Фантастика!