» Распознание текста на картинке скриптовым языком

trotil82
Спасибо за линк, к сожалению там ничего нет о алгритмах взлома, но я уже отписал авторам посмотрим что получится

edogs

Цитата:

Не всегда, зависит от каптчи
...
Другой вариант просто не сработает

Вы не кажется совсем корректно меня поняли, я понимаю что одним скриптом не обойтись, но может есть сборник алгоритмов, к примеру 5-10 которые решают 90% капчей.

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

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

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

Delphi6
Дык, не поняли тогда в чем проблема.
Если у Вас задача распознавать любое количество каптч самых разных наружностей, то по любому это будет нейронная сеть и ей абсолютно по барабану какого типа там шум. Поэтому берем сеть и вперед
Если речь о борьбе с фиксированным набором каптч, то алгоритм надо разрабатывать сугубо индивидуально.
P.S.: Если Вы этим занимаетесь с практическими целями, то вот
http://bash.org.ru/quote.php?num=19875
имхо - человеческая рабочая сила по распознаванию каптч обойдется в итоге дешевле всего, пусть даже к ней придется приложить какое-то приложение.

edogs
Спасибо за совет, с Нероновыми сетями немного сложновато, и зря вы думаете что им шум по барабану, как шум мешает вам (человеку) правильно определить капчу так и Нероновым сетям, это же тоже самое что наши мозги но на низком уровне эволюции Больше месяца разбирал и есть результаты, но как оказалось темя довольно глубокая чем кажется снаружи.

Как я понимаю к сожалению у вас нет конкретного алгоритма или совета? И не надо все сводить к тому что для каждой задачи свое решение. Что бы задачу решить сначала надо знать как решаются задачи, и только потом искать нужное решение. А я понимаю ваш пост так, вы советуете: "У каждой задачи свое решение", так это и так ясно, вы посоветуйте реальное решение конкретной (которую вы встречали и пытались решить или знаете как решить) задачи.

В любом случае спасибо за ваш пост и попытку помочь

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

Спасибо

Delphi6

Цитата:

Спасибо за совет, с Нероновыми сетями немного сложновато, и зря вы думаете что им шум по барабану

Нет, мы не считаем что им шум по барабану.


Цитата:

Что бы задачу решить сначала надо знать как решаются задачи, и только потом искать нужное решение. А я понимаю ваш пост так, вы советуете: "У каждой задачи свое решение", так это и так ясно, вы посоветуйте реальное решение конкретной (которую вы встречали и пытались решить или знаете как решить) задачи.

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


Цитата:

Как я понимаю к сожалению у вас нет конкретного алгоритма или совета?

Лучшее решение (с нашей точки зрения) мы уже посоветовали, задействовать человеческие мозги в распознавании картинок. Это известный, эффективный и проторённый путь.


Цитата:

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

А и не поступит, мы как раз об этом и говорим. Не в сказку попали
Тема распознавания, декодирования, дешифровки, распознавания сигнал/шум, отделение шума более чем известна и более чем сложна. На эту тему написаны "вот такие толстые книжки". Никакого универсального ответа нет, а книжки сюда копи-пастить бессмысленно.
Поэтому если Вы ждете здесь описания алгоритма распознавания любой картинки, то совершенно напрасно. Если хотите конкретики - задавайте конкретные вопросы по конкретным каптчам.

edogs

Цитата:

Лучшее решение (с нашей точки зрения) мы уже посоветовали, задействовать человеческие мозги в распознавании картинок. Это известный, эффективный и проторённый путь.

Уже думал и читал:
http://www.boingboing.net/2004/01/27/solving_and_creating.html
http://petmail.lothar.com/design.html#auto34


Цитата:

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

И снова вы меня не поняли (хотя я понял что вы имеете в виду). Возьмем к примеру, если я задам вопрос как можно определить нарисованный символ? Вы ответите что в каждой капче это уникально. Но я возражу, ибо есть много решений, которые подходят почти к 90% задач, а именно нейронные сети (довольно сложно реализовать), простое соответствие пикселов, или сохранение координат углов символа. Вот видите, не смотря на обширность вопроса есть конкретные советы, куда надо копать.


Цитата:

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

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

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

Delphi6

Цитата:

Вот к примеру о каких "ключевых" местах идет речь?

А это зависит от алгоритма каптчи. Ну например у нюковской каптчи по паре ключевых "жирных" точек можно было определить какое именно число она изображает. То есть не надо анализировать всё изображение.

Цитата:

Или как можно перегнать изображение в векторы и потом эту информацию заюзать?

Пошлем в учебник по высшей математике, раздел не помним.
Потом сравнивать со шрифтами выстроенными в векторе.

Цитата:

А вот самое интересное это "проще не удалять шум а искать сигнал" что подразумевается под сигналом?

Ну, грубо говоря не удалять кучу мелких точек, а добавлять мелкие точки к жирным.
Опять же - сигнал/шум это популярная тема во всяких ТВ и радио фигнях, видеокамерах, поэтому литературы навалом и она достаточно общая.

Наша мысль к чему сводится. Можно решать нейронными сетями (по фиг что), можно решать способами основанными на промахах или стандартности капчагенераторов (частенько бывает, см. пример с нюкой) индивидуально, можно решать математически по хитрым принципам (вектора, сигнал/шум и пр).
С нашей точки зрения 3-ий принцип неразумен по причине адекватной замене его на человеческий решебник. 1-ый способ неплох, но ресурсов тоже требует. А вот 2-ой хорошо из-за малой ресурсоемкости но требует ручного анализа каждой конкретной капчи и ЗАРАНЕЕ Вы вряд ли угадаете способ ее ломания.
И только человеческий годиться для всех При том на минимальных объемах студент за час работы наработает столько граф. кодов, что страшно просто станет, и дешево будет, а при максимальных верно - порнуха.

P.S.: Вот что, попытайтесь найти (пальцем не тыкнем), был такой "человеческий" тест, где была куча картинок показана, и надо было угадать написанное на них число. Задача для фотошоперов была, все картинки решались (очень четко) посредством подкрутки нужных линий, хотя изначально и глазом было не понять. Нам кажется можно взять за основу.

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

В общем идея такая:
Картинка довольно простая там была вплане шума, а вот циферки покалечены неплохо, линии четкие пиксельные (1 – 2 пикселя в толщину). 4 цифры.

Читаем все в массив, приводим в черно-белый путем среднего арифметического

Запихиваем все в одномерный массив, сортируем по убыванию. Находим резкие скачки. Например … 200, 198, 197, 120, 117 … Сразу понятно, где сигнал, где шум. Обнуляем, все элементы исходного массива, которые ниже порога, остальным единички присваиваем.

Получаем черные цифры на белом фоне, зачеркнутые линиями (там такая защита была)

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

Теперь у нас есть массив из единичек и нулей двумерный. Ищем линии и записываем их как группы координат начала и конца, например (2, 10)/(4, 22) Это вертикальная линия немного повернутая по часовой стрелке. Считаем ее вертикальной (Заносим в другой массив, где храним «линии»).

Дальше – ход конем:
1 – вертикальная линия, черти с чем на верхнем конце
2 – горизонтальная + наклонная вправо (наклонные тоже определились в предидущем шаге)
3 – Я уж не помню, но тоже характерно из той картинки получалось, кажется как на почте тройка, где по точкам индекс обводишь 8)
4 – две вертикальных, горизонтальная
И так далее.

Потом перебираем все линии (учитывая взаиморасположение) – все готово.

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

Ну вот. Как-то сумбурно получилось. Могу подробнее раскрыть алгоритм, если нужно.

Chus
Огромное спасибо за хороший информативный пост, вижу несколько довольно интересных подходов к проблеме. Меня заинтересовало как именно вы определяете что это линия? При этом надо учесть что цвет линии полностью соответствует цвету символов Шумы как я заметил вы гасите те что превышают определенный барьер?! Если можно по подробней ту часть в которой вы отслеживаете скачки, и в какой формате у вас фотка при одномерном массиве?

п.с. Я тоже фотку перегнал в массив (черно белый, 000000 и FFFFFF) но в двухмерный, для экономии во времени.

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

Delphi6
Посмотрите еще в фотошопе спецэффекты Sketch=>Photocopy,Stamp,Note-Paper,Plaster.
Посмотрите finereader.

Цитата:

Можно взглянуть на нюковскую капчу.

http://dogsempire.com/modules.php?name=Your_Account&op=gfx&random_num=749842
Последний параметр определяет (косвенно) цифры на каптче (логическая ошибка кстати, на которую можно давить).

Цитата:

И не совсем понятно жирная точка, если можно по подробней.

Ну это лично мы так называем круглые точки от 4 пикселей площадью.

Цитата:

И как это добавить мелкие точки к жирным.

111
101
111
=>
111
111
111

Цитата:

Меня заинтересовало как именно вы определяете что это линия?

От начала элемента 0,0 начинаем искать первую единицу. Когда находим, передаем ее координаты в функцию возвращающую маленький массвчик координат с единицами вокруг первой. И так далее. Кажется это у меня было сделано рекурсивно. Притом нужно кранить все координаты точек, и если они сильно уходят от "первоначального" направления (3 - 4 обработанных точки и направление известно). Заканчиваем обрабатывать линию.

После этого у нас есть массив с координатами всех точек линии - выясняем как линия направлена (по первой и последнй точкам). И вносим ее в финальный массив линий
- 1 (координаты)
/ 2 (координаты)
\ 3 (координаты)
| 4 (координаты)


Цитата:

При этом надо учесть что цвет линии полностью соответствует цвету символов

А у нас цветов уже нет. У нас true и false к этому моменту 8)


Цитата:

Шумы как я заметил вы гасите те что превышают определенный барьер?! Если можно по подробней ту часть в которой вы отслеживаете скачки, и в какой формате у вас фотка при одномерном массиве?

Ну переписать двумерный в одномерный просто же 8)
$k=0;
($i=0;$i<[горизонталь];$i++){
($j=0;$j<[вертикаль];$j++){
$odnomer[$k]=$dvumer[$i][$j];
}
}

//Дурак, можно же foreach сделать 8)))

Сортировку писать надо? 8)))) rsort()

Затем весь массив прогоняем,
разница=0
порог=0
цикл{
tmp=element[i]-element[i+1];
if разница < tmp{
разница = tmp;
порог=(element[i]-element[i+1])/2;
}
}

Потом смотрим, что у нас ниже порога в исходном массиве и обнуляем.

Спасибо за капчу
http://dogsempire.com/modules.php?name=Your_Account&op=gfx&random_num=749842

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


Цитата:

111
101
111
=>
111
111
111

Я так и не понял что такое жирная точка, если вы написали что это 3 точки из них 2 которые одного цвета то еще понятно. Хотя как эти 3 жирные (в суме 9 точек) должны быть расположены к друг другу, по горизонтали, по вертикали или вообще справа и снизу?

Chus

Цитата:

От начала элемента 0,0 начинаем искать первую единицу. Когда находим, передаем ее координаты в функцию возвращающую маленький массвчик координат с единицами вокруг первой.

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


Цитата:

После этого у нас есть массив с координатами всех точек линии - выясняем как линия направлена (по первой и последнй точкам). И вносим ее в финальный массив линий

Вы написали что если точки сильно отходят, но допустим такой пример, первая точка в координате 0,0 а кончается она где-то 10,12 как мне узнать что это линия а не просто символ? Цвета в это время одинаковы. Да и приведенным алгоритмом вы определяете все пиксели "линии", точнее черного объекта который возможно линия.


Цитата:

Ну переписать двумерный в одномерный просто же 8)

Значит вы просто заливаете все а одномерный, без всякого алгоритма.


Цитата:

Затем весь массив прогоняем,
разница=0
порог=0
цикл{
tmp=element[i]-element[i+1];
if разница < tmp{
разница = tmp;
порог=(element[i]-element[i+1])/2;
}
}

Теперь понял, вы просто ищите колебания между смежными пикселями, но вы учитываете только горизонтальные колебания. Я думаю мы получим еще лучше результат если будем проверят и вертикально, не так ли? Ну и как я понимаю на данном этапе element[i] содержит цвет пиксель в градациях серого? (а не просто 1 или 0)

Спасибо вам обоим за такие информативные посты.

Delphi6

Цитата:

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

Ой, ну я не настолько "продвинутый программист". Поэтому иногда изобретаю велосипеды 8)


Цитата:

Вы написали что если точки сильно отходят, но допустим такой пример, первая точка в координате 0,0 а кончается она где-то 10,12 как мне узнать что это линия а не просто символ? Цвета в это время одинаковы. Да и приведенным алгоритмом вы определяете все пиксели "линии", точнее черного объекта который возможно линия.

Ничего я что-то не понял... Нашли первый пиксель (двумерный массив нулей и единиц у нас) от него ищем дальше единички, после четвертого-пятого найденного (всмысле бальше ищем рядом со следущим и так далее) становится ясно направление, если у нас "линия сворачивает" Bs эти пиксели игнорируем. А обработанные пиксели вообще из исходного масива удаляются. Всмысле обнуляются.
если линия (0,0)(10,12) то это линия /


Цитата:

Теперь понял, вы просто ищите колебания между смежными пикселями, но вы учитываете только горизонтальные колебания. Я думаю мы получим еще лучше результат если будем проверят и вертикально, не так ли? Ну и как я понимаю на данном этапе element[i] содержит цвет пиксель в градациях серого? (а не просто 1 или 0)

Почему только горизонтальные?
Ну вот пример было изображение, допустим 2 на 2 пикселя:
[15][179]
[178][16]

Т.е. вот такая / линия

Пишем в одномерный и сортируем: 15, 16, 178, 179
Сразу видно место скачка, вот с него и отрезаем. В данном случае можно даже с 16 обрезать.

Цитата:

так и не понял что такое жирная точка

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

Цитата:

капча сама по себе очень простая

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

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

Спасибо за уделенное мне время

Вот статейка, как ломать капчи. Вроде неплохие результаты 70-80% на простенькой, и 30% на злостной.
http://www.cs.sfu.ca/~mori/research/gimpy/

Turing
ты ее сам читал? статьей это не назовешь, плюс никакого отношения к скриптовому языку, а насчет распознания другими средствами есть темы в других разделах

Turing
Открою секрет, меня даже 90% удачных определений не устраивает Результат должен быть 99% точности и даже тот 1% ошибок нужно предсказывать с высокой точностью, другими словами отказываться от этой капчи и просить выдать новую

Скажу честно результат был получен только после интеграции нескольких алгоритмов, простой алгоритм "УГЛА" не дал результатов для капч вроде той что приведена в конце (1), так как к примеру буква С и О имеет одинаковые углы, разница у этих бук только в вертикальной линии, которая в этом алгоритме не учитывалась.

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

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

Думаю на данный момент это все, если у кого найдется оригинальное решение и его заинтересует добавить его алгоритмами которые я нашел и реализовал всегда пожалуйста, жду ПМ

(1)

(2.1)

(2.2)

(2.3)

(2.4)

п.с. Простые капчи (2.*) взламываются в течении 10 минут (без преувеличений) тем же алгоритмом и с точностью в 100%

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






Добавлено:
Любопытно вообще...




...это возможно???

Delphi6

Цитата:

взламываются в течении 10 минут

А на каком "железе" такой результат?

Добавлено:
есть такая вот Штука
Там на первом этапе определения шрифта как раз происходит распознание. Так вот с самой, на первый взнляд, сложно картинкой 2.3 он справляется лучше всего 8)

Все это интересно, но я немного трансформирую тему. И цели надо сказать очевидно благие.

Есть картинка (диаграмма). Нужно разбить ее на области (сделать map для html).
То есть нужно определить координаты, где проходит разделение областей картинки линиями и сгенерировать код, который потом можно было вставить в HTML-страницу.


Как это лучше сделать?


Я знаю, как с помощью GD определить координаты точек и цвета этих точек. Плюс GD работает только с PNG, а картинки(диаграммы) иногда в GIF бывают. Хотя можно их конквертнуть чем-то типа Ulead Smart Saver и в PNG и работать.



Можно еще дополнительно трансформировать задачу: также вписать в области (в середину области) картинки цифры или текст. Тут опять же нужны будут координаты и алгоритм определения центра каждой области. Как вписать с помощью той же GD я знаю.

ИМХО, немного не в тему диаграммы.
Из описания непонятно как что выглядит - картинку в студию.

В общем, я попарился денек и сделал.

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

Далее нужно составить координаты, которые можно было подставить в Map в HTML-файл.


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

Потом из массива точек ищутся экстремумы. Точки экстремумов заносятся в Map для HTML-файла. Все счастливы.

Предлагаю продолжить тему. Может кто знает по какому принципу работает ABBYY FineReader? По-моему, очень мощный пакет (не реклама) по распознаванию символов.

Добавлено:
Статья из ВиКи: http://en.wikipedia.org/wiki/Optical_character_recognition

Добавлено:
Еще интересные ссылки:
http://en.wikipedia.org/wiki/Raster_to_vector
http://en.wikipedia.org/wiki/CAPTCHA
http://en.wikipedia.org/wiki/Automatic_number_plate_recognition
http://visl.technion.ac.il/projects/2002w02/
http://visl.technion.ac.il/projects/2003w24/
http://vortex.cs.wayne.edu/papers/ijns1997.pdf
http://kullanici.be.itu.edu.tr/~kahraman/License%20Plate%20Character%20Segmentation%20Based%20on%20the%20Gabor%20Transform%20and%20Vector%20Quantization.pdf
http://www.cs.sfu.ca/~mori/research/gimpy/
http://www.ocr-research.org.ua/demo.html
http://sam.zoy.org/pwntcha/
http://bhiv.com/defeating-diggs-captcha/
http://www.brains-n-brawn.com/default.aspx?vDir=aicaptcha
http://www.iopus.com/imacros/irp/
http://captcha.megaleecher.net/

Audciz
Тема всегда была актуальна, но вот с алгоритмами туговато Я не одну неделю провел что ба найти тот который описал несколькими постами выше. Алгоритм ABBYY FineReader вам на халяву точно не найти, хотя у него есть преимущество от обыкновенных капча анализаторов. А именно, у него есть возможность проверять декодированное слово с словарем и плюс проверять грамматику, это дает возможность те 30% ошибок подправить смыслом слов. Кроме всего прочего с мусором (фоновым) легче разобраться, хотя для каждого текста приходится обучать программу отдельно.

Кто-нить читал это: http://visl.technion.ac.il/projects/2002w02/ ?
В самом низу есть исходники для VC++. Что там? Я бы сам проверил, но я сижу с работы.

Добавлено:
Насколько я понял, нужно изучать MatLab.
Кто-нить может посоветовать книги или статьи по Нейронным Сетям?

Еще раз, читаем статью: http://www.cs.sfu.ca/~mori/research/gimpy/#approach (там ссылка на статью из CVPR). Конкретная работа имеено для распознавания капчей.

Чтобы нейронную сеть использовать, надо сначала самим грамотно переживать картинку и вытащить правильные фичи из нее, а это добрые 75% работы.

а на rabotaonline.com за это деньги платят

1$ за 1000 введенных правильно картинок...

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

можно ведь по тексту определить его "границу" (1->2) и простой деформацией довести её до прямоугольного состояния (2->3), а потом уже просто вертикальными разрезами разделить на буквы (3->4), определить среднюю ширину и если какие-то слишком широкие буквы плохо распознаются, попробовать их разделить на две (4->4a)

вот картинка:

vicnaum
Зачет И как вы собираетесь сначала получить 2 вариант, у программы к сожалению нет глаз и она не знает где цифра начинается и где заканчивается (как и само понятие цифра). И как потом еще надо из 2 варианта получить 3? Кто знает какая точка буквы на какой точке волны была? (движение может быть на всей двухмерной плоскости )

А очень просто.

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

Вариант 3 получаем простым распрямлением варианта 2. Левую и правую грань ставим вертикально. Считаем длину верхней и нижней. И проходим сканирующим вертикальным отрезком рамномерно по всей длине - образуется прямоугольник как на стадии 3.

Примерно так.

Цитата:

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

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


Цитата:

Вариант 3 получаем простым распрямлением варианта 2. Левую и правую грань ставим вертикально. Считаем длину верхней и нижней. И проходим сканирующим вертикальным отрезком рамномерно по всей длине - образуется прямоугольник как на стадии 3.

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

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