to post messages and comments.

OCR

В развитие темы #1312603
Скачал примеры автора — png-файл на 300 dpi и два jpg — на 200 и 150. Кюнейформом, как ни странно, распознались все три. Считать процент было лень, но и в лучшем случае до приводимых автором 94% на глазок было далече, хотя 300 и 200 опять же на глаз действительно не различались.
Видать, ну очень хорошая страница автору попалась, ведь наверняка такая на ПСС графа пахаря должна быть просто по теорверу.
А вот с tesseract'ом просто полный облом. Как известно, он окромя tiff ничего не ест, поэтому png и jpg пришлось "переводить" в tiff. Что проделывал и автор — и понимаете ведь, почему в кавычках :)
Так вот, эти, с позволения сказать, tiff'ы tesseract просто отказался открывать.
Закавыченные tiff'ы делались двумя способами: сначала тупо через save as в gThumb (там никаких параметров не запрашивается), потом в GIMP'е с сохранением, по возможности, параметров оригинала, то есть без собственного сжатия и т.д.

OCR

похоже, потребуется новый тэг, старые материалы по этому поводу тоже перетэгирую.
Так вот, на сайте Виктора Костромина большая статья по сравнению различных OCR — rus-linux.net
Впечатление такое, что или я дурак, или автор все результаты в таблице взял из головы, да ещё и с двумя п их написал. Например, один из выводов:
Результаты, приведенные в таблице, показывают, что при хорошем качестве распознаваемого материала все участвовавшие в тестировании программы обеспечивают высокое качество распознавания, причем снижение разрешения с 300 до 200 dpi практически не влияет на результат.Что в корне противоречит и моим наблюдениям, и мнению тех джуйковцев, что в теме и участвовали в обсуждении вопроса ранее.

Недавно обновился у нас audatex, это такая программка для составления расчетов по ремонту автомобилей, и внезапно перестали конвертироваться pdf документы в txt, чтобы потом из них вытаскивать данные — вместо кириллических символов просто пробелы. Для конвертации использовалась тулза pdftotext из пакета xpdf и проблем до этого не было. А тут вдруг. Ну что ж, может аналоги будут поспособней
Попробовали конвертор от verypdf — фейл, та жа картина. Еще ряд других — фейл, тоже самое. Фиг с ними, думаю, попробуем попросить Adobe Reader, он то точно сможет...Фейл. SumatraPdf, однако, вместо пробелов выдала ряды ?, что значило, что все таки тут что-то есть.
Ладно, раз дело явно требует ручной работы, посмотрим что есть для python по работе с pdf. Гугл сообщил о существовании pyPdf. Поковырявшись с ним результат остался тем же — пробелы. Разобраться откуда он их берет не было никакого желания — код просто..нет, раз текст к нам не идет, то мы сами за ним придем.
Из подручных распознавалок оказался tesseract, который умеет русский текст, разрабатывается ребятами из гугла, ну и вроде не должен быть совсем уж плохим. Тем более, вроде как он используется в google docs, но не уверен. Кстати, попытка воспользоваться ocr гуглодоков окончилась все тем же результатом.
Tesseract прекрасно распознал текст, но вот незадача — текст содержит и кириллицу и латиницу, а он умеет использовать только один набор данных за раз! Долгое гугленье только подтвердило этот факт. Возможно, здесь выходом является пересборка traineddata, который будет включать оба языка, но не "взлетело". Так и не понял почему, поскольку Segmentation failure не сильно информативная ошибка. Ладно, фигня война, сделаем два распознавания, будем вести чтение параллельно из двух файлов и в ключевых точках брать слово из нужного файла...Стоп! Это уже напоминает извращения(:
Надо сказать, что все оказалось гораздо проще и все проблемы от незнания — pdf содержал текст в двух кодировках: Ansi и Identity-H(CID). В последней и была вся проблема. Но когда стала известна причина проблемы, быстро нашлось и ее решение: pdfminer. Скрипт pdf2txt.py, поставляемый в комплекте с пакетом, хоть и не смог перевести cid на русский язык, но составить словарь перевода было делом 5 минут.
Мораль: иногда полезно смотреть свойства файла(:

OCR

интресный факт — системы распознования текста (FineReader Engine 8.0 например) часто продают лицензии из рассчета количества распознаных символов или страниц и никаких блекджеков )

OCR

О, на глаза попалась ещё одна распознавалка code.google.com Лежит так же у бубунты в репозиториях.
В третьей версии умеет несколько языков, в том числе и русский. Распознаёт вполне годно.
Для меня самое важное, что она не смущаясь распознала на фотке текст с экрана мобильного телефона.

Приходил сегодня свояк, притащил с собой нужду. Есть короче одна организация в которой в день сканируют примерно 300-400 штук однотипных бумажек. Необходимо эти бумажки в как можно более автоматизированном режиме сканировать и сохранять ВНИМАНИЕ с именем, состоящим из номерочка этой бумажки, который прописан примерно в одном месте на всех сканах (плюс-минус 5 миллиметров вверх-вниз, влево-вправо) и в формате JPEG. Дополнительная проблема в том, что бумажки поступают не по порядку номеров. Есть идеи у жуйкоюзеров как порешать?

Ну неужели под Linux так плохо с распознавателями текста? Он-лайн FineReader за бесплатно распознает только 10 страниц. Нашел распознаватель текстов по лицензии GPL, так этот проект под маздай. Кто может посоветовать хороший распознаватель текстов?