LINUX.ORG.RU
ФорумTalks

может все таки сделаем OCR?


0

0

глянул я тут на движок OCR, который гугл открыл (tesseract), понятное дело, что finereader`a не получится, но приемлимое распознавание прикрутить можно. когда то я помню пробегалу тут такая тема, но что то все затихло.
может все таки сделаем?

Можешь уже начинать - я согласен что некоторым людям оно очень нужно, но большинству оно нафик не впилось

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

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

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

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

divenvrsk
() автор топика

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

:)

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

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

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

// wbr

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

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

divenvrsk
() автор топика

те кто может написать OCR он нафиг не нужен, тем кому он нужен его написать не могут.

Там много гемора, и в основном гуй, просто так писать никто не станет ибр лень да и неинтерестно.

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

> те кто может написать OCR

В холостую работать не будут бо проект сам по себе не на один десяток тонн тянет.

> Там много гемора, и в основном гуй

80 данунах а не персептроника ?

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

>80 данунах а не персептроника ?

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

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

> нихрена ты перцептронами не распознаешь за приемлемое время.

Первое что в голову пришло. Но один хрен тема далеко не для "сел я значит вечером после ужина децл покодить..."

iBliss
()
Ответ на: комментарий от alphex_kaanoken

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

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

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

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

ты слышал про omni font ?

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

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

вменяемая ocr немыслима без спеллчекера как минимум. А вообще желательно ещё и контекстный анализ прикрутить :)

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

> ты слышал про omni font ?

Не самый удачная идея...

شيطان

Это под него не попадет стопудово - ибо символы композитные

iBliss
()
Ответ на: комментарий от Neksys

> http://jocr.sourceforge.net/

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

http://jocr.sourceforge.net/api/

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

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

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

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

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

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

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

>Почему ты так думаешь?

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

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

>то писать плагин для русского языка под эту либу.

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

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

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

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

>т.к. писать модуль анализа (картинка, пятно от кофе, дырка от сигареты, текст) пока не планируется.

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

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

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

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

>а модули по анализу и определению контента - потом.

*потом* придется весь движок переделывать. Это комплексная задача и очень хреново делится на этапы

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

алгоритм -
1. анализ изображения и деление его на блоки (view_this.cpp) (текст, графика, всякая херня);
2. берем тот блок что текст и отправляем на распознование.
.... и так далее.
100.

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

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

элементарное деление на буковки ч/б изображение, масштабирование к паттерну и сопоставление дает 30-40% -ую точность :) При использовании более умных паттернов (где каждому элементу соответствует вес) повышает точность до 50%. Но я особо с весами не заморачивался. Это на факсе хорошего качества без таблиц и картинок и без обработки форматирования - т.е. на выходе поток символов (включая пробелы и переводы строки).

Лучшее качество дает распознавание формы символа - алгоритм достаточно простой, но требует проработки на предмет разрывов. Но! все эти алгоритмы требуют точного отделения глифа от фона. Вот тут и начинаются адские трудности.

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

А без трудностей не интересно :)

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

>Какие?

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

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

Могу только догадываться. Трудности с сегментацией или что-то другое?

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