LINUX.ORG.RU

софт для распознавания текста


0

0

Предложение: Правильная ОСR для Linux Суть: OSS не хватает свободной системы распознавания текста. надо её написать. это не коммерческое предложение, вопросы "сколько заплатите" не рассматриваются. Впрочем, если будет хорошо работать, можно её будет коллективно втюхать какому нибудь РБК по цене такой, чтоб им вышло раза в 2-3 дешевле чем промт, но разработчикам вышло до фига все равно

Условия: 1)Нет ни большого колва времени, ни значительного колва программистов для написания СЛОЖНОЙ OCR. Кроме того в этом нет смысла. Программа должна быть простой. 2)Для упрощения отладки программа должна быть модульной. Под модульностью понимается не столько возможность отрезать от нее кусок - такая модульность не требуется. Нужно реализовать конвейер из модулей - прием изображения(см далее), фильтрация изображения, разбиение изображения на силуэты, поиск в каждом силуэте прямых отрезков, сравнение двух наборов отрезков, библиотека описаний символов, и т.д. Программа при этом может оставаться монолитной, но надо иметь спецификации на каждый модуль, и чтоб он тестился отдельно на синтетических входных данных. 3)Не потреблять много памяти! Это закон. Или делаем говно, или качественную систему. Пусть лучше будет настройка память/процессор, чем тупое свопание.

Идеи программы: Существующие OCR работают с использованием различных хитрожопых мат. методов, и очень сложны. Лучше скопировать давно известную систему OCR - алгоритм распознавания букв человеков. Человек(***) распознаёт слова по буквам. Известно, что в мозгу есть нейроны опознающие вертикальную линию, горизонтальную линию и пр. Короче линии. Опознавание символа, как нам тоже известно, привязывается к какому либо направлению, например самому длинному отрезку. С другой стороны, буквы принято записывать как набор отрезков и кривых(обычно второго порядка. Предлагается представляя буквы как наборы таких отрезков и кривых, искать в векторном изображении похожие комбинации. *** набирая опыт, человек учится распознавать целые слова предложения и даже абзацы(см соотв статьи по скорочтению). это факт, но таких сложных алгоритмов нам не надо.

Реализация: Блок 1: реализовать приложение, способное вводить файл изображения. Если файл содержит заголовок его считывают. Данные считываются(если это возможно) по мере необходимости, все сразу только если иначе нельзя. Это требуется для сокращения пожирания памяти огромными сканами. Считайте, что у вас есть 8Мб и ни байтом больше, либо задано пользователем. Должно быть предоставлено API для чтения прямоугольного куска изображения в формате YUV888(каждый пиксель описывается 32битным целым(страшие 8бит равны 0)). Размеры кратны 16ти или 32м. Этот параметр обсуждается. Если не хватило изображения до кратности 16(картинка длиной 258х233 например), подставляются пиксели 0xff000000.

Блок 2: Фильтрация изображения. Предполагается, что входными параметрами были dpi и минимальный размер элемента который следует различить. Все меньшее следует усреднить..Вход такой же как у блока 1, фактически блок 3 будет запрашивать блок 2 а тот блок 1.

Блок 3: С использованием сущесвующих OSS библиотек для векторизации, получить из заданного куска(размеры кратны 16 или 32) набор связных областей одного цвета(силуэтов).. Цвета объединяются при условии что разность яркости не выше пороговой, и разность оттенка не выше пороговой. Помнить что применительно к текущей части картины, координаты верхнего левого угла не всегда 0, 0. Точное следование контуру НЕ ОБЯЗАТЕЛЬНО, мы не дефекты в картинке выискиваем.

Блок 4: Объединить силуэты относящиеся к разным частям картинки. выбирая части картинки, мы ведь её разрезали? теперь склеиваем обратно. Всё это делается потому, что память не резиновая! у кое кого её 256, 128мб или вообще 64. помните что возможно прога будет юзаться на серверах, и 10-20 запросов по 200мб там приведут к включению OOM-киллера или ошибкам. Блок 5: Ищем линии. Силуэты могут быть невыпуклыми, если например две линии пересекаются. Следует разбить границу силуэта на более менее прямые отрезки или части окружностей. Точные линии необязательны -малые отклонения по сравнению с длиной линии игнорировать(параметр настраиваемый)

Блок 6: продолжение предыдущего блока. в списке линий находим такие которые идут почти параллельно, и недалеко в сравнении с их длиной(максимальной). При этом должны быть рядом. Найдя, в другой лист добавляем самый обычный отрезок(х1,у1-х2,у2). Аналогично хоть и посложнее с кривыми второго порядка. больший порядок не рассматриваем вообще. если не получилось нифига - пытается описать точкой с диаметром(клякса, конец линии на истертой бумаге. Также надо группировать наборы близлежащих штрихов по буквам. допустимо для одного штриха принадлежать двум буквам.

Блок 7: Библиотека. Хранит код букв в юникоде, и описание СТАНДАРТНОГО начертания буквы(или нескольких)..

Блок 8: Сравнивает данные от блока 6 с данными от блока 7. TODO: надо реализовать позднее тут фильтр для того чтоб потертые буквы(потерявшие часть штрихов) еще как то распознавались. Это будет самый сложный блок. Сравнив с библиотекой заданный символ, получают список совпавших с вероятностями.

Блок 9: Строка: хранит не символы, а списки символов от блока 8. когда все изображение загнано сюда., по возможному списку языков, выбрасываются ненужные языки(можно и в блоке 8). Далее смотрится где между символами есть пропуски и какого рода(шире интервал(пробел)-перенос строки(не добавляется). Также должно быть настраиваемо. Очевидные правила - если в слове буквы, между ними цифор нету. Желательно возможность вывода как конечного текста так и с разметкой. для гуя. например, не понятно: "винда отстой]" или "винда 0тст0й]" -- чтоб можно было вывести(не только в стдоут, но и в ДВА разных файла (конечный и размеченный) тексты. "винда [0o]ост[0o]й\]"

Блок 10: GUI ко всему этому. GUI отдельно, распознавалка только консольная. помним про сервера и про GTK/QT. При использовании GTK/QT никаких KDE/GNOMOбиблиотек. За такое по идее надо башку отрывать. потому что есть еще XFCE. Уважаем юзера, и помним о том, что если винда не идет к линуху, линух идет к винде, приносит проги(чуть ограниченные :)))) под окнами) и предлагает отказаться от платного софта для окон. когда тот сдохнет, всем будет легче отказаться от окон. А потому никаких KDE/GNOME - чтоб шпарило и под виндами тоже.

Блок 0 инициализует все блоки. потом передает управление блокам 7,4,5,6,8 по очереди Зависимости: 7 грузит описание языков Блок 4 управляет блоком 3, отвечает за формирование целостной(или частично челостной картины в векторах) блок 3 управляет блоком 2. Блок 2 блоком 1 когда картина в векторах есть, блок 4 создает список силуэтов. Блок 5 из него создает для каждого силуэта список характерных черт. предыдущая инфа по силуэту удаляется(память экономим) блок 6 создает описание силуэта в более простых примитивах блок 8 управляет блоками 9, 7 и 6 только когда получит управление. блок 9 получив управление тупо (В зависимости от настройки выводит строку в файл или stdout

где формулы друх? это всё слова...
на кой кер цвета объединять... работать надо с бинаризованным изображением(можно с цветным, как с бинаризованным)

ищем линии... ммм... ммм... а что такое линия?

почти параллельно... ммм... а почти, это как?
hint: а сколько букв в алфавите с почти параллельными прямыми?
    юю
   ю  ю
 ю  ю  ю
ю        ю

anonymous
()

Ну ты начинай, мы если что, подтянемся.

anonymous
()

>но таких сложных алгоритмов нам не надо.

Много хороших идей умирало по этой причине...

Перед тем, как браться за такую задачу, полезно почитать что уже сделано, например, интернет-проект, посвященный всем аспектам тематики распознавания рукописного и печатного текста http://www.cr-online.ru/

quickquest ★★★★★
()

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

pacify ★★★★★
()
Ответ на: комментарий от pacify

я это написал с идеей что кто нибудь накидает полезных идей и ссылок. а об опыте программирования - делаю щас декомпилятор х86->блоксхемы. проект дипломный, так что если к концу года не будет вскрывалки кода, мне писец. GTK frontend+console.

проектить что то начал года 3 назад, когда делал свое собсное ядро. ибо линукс в одном месте очень жестко сосёт: у него page fault'ы идут с максимальным приоритетом. Что иногда превращается(ядро 2.6.21.5 извините)в тормоза совсем не причастных к свопингу приложений.

часть кода по данной системе готова (1,2,3), но заброшена по причине дедлайна.

еще вариант замены X11 придумал. мелкий драйвер в ядро, поддержка окон на минимуме(то есть каждое приложение должно само следить чтоб не рисовать лишнего). Вложенная иерархия подключений aka окон/сеансов, то есть можно окно в окне держать прозрачно для вложенных приложений. сделано все на передаче сообщений через ядреный драйвер. в любой точке можно включиться(как оконный менеджер и ловить опр. типы сообщений а также менять положение вложенных окон), послать kill -9, структура в виде дерева получается. можно сделать несколько деревьев(/dev/gui0, /dev/gui1) и присобачить к ним видеоадаптеры. в том числе за счет перехвата сообщений можноничего не собачить, а рендерить в X11. основа рендеринга bitblt и буфера(shared и обычные) Такая вот идея. все выложить спецификацию хочу, но не знаю куда. хочется чтоб кто то более разбирающийся в тонкостях GUI-графики поправил.

skotinka
() автор топика
Ответ на: комментарий от quickquest

вот за ссылку спасибо.

за корявое содержание простите, как всегда ночью, забыл написать концовку, про то что требуются в первую очередь ИДЕИ. а закодать простой код - просто.

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

skotinka
() автор топика
Ответ на: комментарий от skotinka

а ядро то пришлось забросить. спасибо RMSу, он хоть и дядько хороший, но красноглазый.... когда то интел выдвинул идею унифицированных дров. то есть есть спеки по интерфейсу, бинарной совместимости и пр. И все в общем то были непротив. Я в своей оси пишу модуль поддержки проприетарных бинарных дров, и у мну работает ВСЁ. все дрова. А ABI написать за полгода можно.

Но тут (а дело было лет 5 назад) вылез RMS и заорал "поганые проприетарщики украдут наши дрова". На сём дело заглохло. А ведь тогда я вынужденно сидел под мастдаем изза того что под freebsd4.5 не было вменяемого модуля tdfx и даже opengl-glide не было.

Так RMS удавил большинтсво свободных операционок. Еще 3 года назад кроме линуха бзды и офтопа было дофигища стартапов, часто легковесных (skyos -1 дискетка полноценный GUI) спасибо RMSу за наше тяжолое детство

skotinka
() автор топика
Ответ на: комментарий от skotinka

>кто нибудь накидает полезных идей и ссылок

Проект BookScanLib http://djvu-soft.narod.ru/bookscanlib/

>и все равно я за копирование естественных "алгоритмов"

Ссылки на русскоязычные ресурсы по нейросетевой тематике http://www.neuralnetworks.ultranet.ru/sitelist.php

quickquest ★★★★★
()
Ответ на: комментарий от skotinka

Насчет свободы - ты просто уточняй - кто, в чем, и от чего свободен.

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

Richard Stallman наоборот - за зависимость от авторов программ, наработки
которых не должны "вороваться". От производителей "железа" же он хочет
быть независим, и не берет от них даже забесплатно бинарные драйвера.

> когда то интел выдвинул идею унифицированных дров.
Вообщем-то Интел не против и DRM. См. UEFI и гипервизоры от Phoenix.

pacify ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.