» ABBYY FineReader

Larry

Цитата:

Имеется ли возможность сделать то, что мне нужно, с помощью FineReader без ручной пометки области картинки у каждого изображения?

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

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

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

Larry
А можно и совсем просто - открыть пакет со сканами, скомандовать "Сохранить изображения" и в открывшемся окошке форматом выбрать PDF.
Только не забудьте поставить галочку "Сохранить страницы в один файл".

unreal666,

Цитата:

можно было просто создать временное изображение ...

Ага, тоже догадался.

Shangry, точно! Буду знать, спасибо!

Почему-то FineReader ставит гиганские поля страниц

Это в FR Это в Word

при передаче материала в Word. В установках создал пользовательский формат страниц со своими полями

но в результирующем документе вся страница тесница в центр и большие поля во краям, при этом поля страницы в ворде вовсе нулевые, формат А4. Видно, что все содержимое страницы помещено в области (ну это понятно, при выборе результата "точный") но и есть область на весь лист, зачем не понятно.
Как это побороть?
ЗЫ. WinXPSP3, FR11Pro (121), Word2003SP3

BarHan
в некоторых случаях спасает выставление параметра Размер бумаги по умолчанию - A4
в остальных случаях у меня в Worde размер листа получается больше. приходится вручную менять. и я не передаю в режиме Точная копия. У меня FR10

Имеется: Windows 7 Макс SP1 x64, FineReader CE 11.0.110.122
Чем можно объяснить следующее:
На входе - 640 страниц tiff-ов (600 dpi, b/w, сжатие: Group 4 Fax Encoding в терминах IrfanView), весьма качественных сканов, общим размером 64,8 Мб.
1) в FR11 сохраняю изображения в pdf - получаю файл1 размером в 1315 Мб;
2) распознаю, сохраняю документ как pdf (опции: Размер бумаги по умолчанию - Использовать размер оригинала; Режим сохранения - Текст под изображением страницы; Разрешить теги PDF; Качество изображения - Сбалансированное; Шрифты - Использовать предопределенные шрифты), правлю OCR минимально (лишь первые 18 стр) - получаю файл2 размером в 16,13 Мб.
Откуда такая разница в размере файлов?
Отмечу, те же манипуляции в FR8 (FineReader Pro 8.0.0.1126) дают файл1 в 68,8 Мб и файл2 в 22,4 Мб.

Ребят, подскажите обывателю решение )
Есть задача пробежаться по архивам документов (форматы pdf, djvu, jpg и пр.), разной степени качества (большая часть получена и Интернет-помоек) и распознать, насколько можно, текстовый слой, там, где его нет, выдав результат в виде каких то оптимальных п/фабрикатов, с целью последующего поедания программами индексации типа Архивариус 3000. Отсюда вопросы:
1. Какую версию FR для этого использовать, является ли он вообще лучшим решением из возможных на рынке OCR для этих целей, можно ли это выполнять на автомате (подсунул папку и ушел курить)?
2. Какой оптимальный выходной формат должен быть для распознанных документов (djvu ?), какие настройки следует произвести для более качественного распознавания (если скорость не критична), допускается ли унификация всего процесса (может ли программа пробежаться по входному каталогу с данными и выдать на экспорт аналогичный каталог с уже распознанными документами, может ли она различать и не заниматься распознаванием тех документов, где это не требуется и пр.)?
3. И наконец, можно ли по результату выдать отчет - что получилось, а что нет, и насколько?
Биг тхенкс.)

corrector

Цитата:

На входе - 640 страниц tiff-ов (600 dpi, b/w, сжатие: Group 4 Fax Encoding в терминах IrfanView), весьма качественных сканов, общим размером 64,8 Мб.
1) в FR11 сохраняю изображения в pdf - получаю файл1 размером в 1315 Мб;

Скорее всего дело в том, что FineReader сохраняет ч/б сканы в PDF вообще без сжатия (только не спрашивайте меня зачем здесь нужен такой идиотизм ). Тогда как раз примерно столько и должно набежать.

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

Frantishek

Цитата:

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

Для произвольной смеси из файловых форматов на непредсказуемо каких языках пока что наиболее оптимален FineReader. Старый русский (до 1920-го) знает только он, за толковую работу с DjVu других универсальных распознавашек ( в смысле, ориентированных на любые форматы) пока что слышать не приходилось.
Из версий, в смысле качества разметки на блоки и качества распознавания, предпочтительнее 11-я.


Цитата:

можно ли это выполнять на автомате (подсунул папку и ушел курить)?

С тех пор, как с 10-й версии в FineReader ввели пакетную обработку (тамошний HotFolder), засовывать целой папкой стало вполне решаемой задачей.
Но если нужен легальный софт, то 10-ю версию уже нигде не купишь (разве что по случаю), а в 11-й на пакетную обработку навешали кучу ограничений. Теперь там осталась не более чем демонстрашка пакетника.


Цитата:

Какой оптимальный выходной формат должен быть для распознанных документов (djvu ?),

А это в зависимости от:
а)для чего они дальше нужны (в смысле на какое дело пойдут);
б)из чего состоит исходная куча - сплошные сканы в ч/б или же смесь ч/б и цветных;
в)надо ли делать выходной объем как можно меньше или же это не очень критично.


Цитата:

какие настройки следует произвести для более качественного распознавания

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


Цитата:

допускается ли унификация всего процесса

Обработка всех файлов из входной папки происходит по одному и тому же комплекту настроек.


Цитата:

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

Поставить галочку на "Обрабатывать подпапки".
Тогда можете давать на вход не одну единственную папку, а хоть целое дерево, а на выходе получать копию этого дерева


Цитата:

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

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


Цитата:

И наконец, можно ли по результату выдать отчет - что получилось, а что нет, и насколько?

Вроде бы нет, но твердо не уверен (пока ни разу не возникало такой потребности).

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

VitRom

Цитата:

то наилучшие результаты (полноценно использующие все преимущества формата, а не ламерские поделки) будут при использовании ФР как только "распознавалки"

Было верно для 9-й и 10-й версий, когда для работы с DjVu разработчики использовали самостийный софт.
Но начиная с 11-й версии, для создания DjVu'шек начали использовать родной софт (лицензия от Caminova), так что результаты должны получаться плюс-минус сходные (в пределах умения пользоваться купленными API).

Shangry
Спасибо за понятные ориентиры. А то я уже грешным делом чуть расстроился, что мои задачки можно будет разрешить при помощи лишь ABBYY Recognition Server 3.5, а он ценой порядка 600 000р. если на процессор ставить без ограничения на вход. Остается лишь дилемма как срастить возможности FR11 и Hot Folder.. видимо зарезали функционал чтобы почетче позиционировать под сервер автоматизацию (сценарии и пр.).

Shangry,
Это радует. Хотя ЕМНИП в тех решениях, что видел я, юзались вообще какие-то "3-пати" тулзы, вроде даже что-то открытое. Впрочем, эти упомянутые решения были нацелены на "вытягивание" максимальных результатов с помощью различных хитростей. Тогда получается, что для 9/10 задач хватит "чистого" ФР-11...
Что ж, это действительно очень радует.

ЗЫ. Хотя не факт, что это именно случай Frantishek, у которого кучи сырья самого разного качества. Или в обрезке/кадрировании/чистке ФР-11 тоже переплюнул уже спецтулзы вроде БукРесторер-а или СканКромсатор-а?

Frantishek

Цитата:

... мои задачки можно будет разрешить при помощи лишь ABBYY Recognition Server 3.5

Как-то полистал немного его Help и вспомнилась фраза из русской классики "Чудовище обло, огромно, озорно и лаяй".
Других слов, чтобы описать это чудо программистики просто в голову не приходит.

Но до 10-й версии ничего другого для пакетизации заданий, увы, не водилось


Цитата:

Остается лишь дилемма как срастить возможности FR11 и Hot Folder.. видимо зарезали функционал чтобы почетче позиционировать под сервер автоматизацию (сценарии и пр.)

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

Что же до HotFolder в 11-версии, то мои знакомые нашли вполне работающий способ обходить процессорный ограничитель (с остальными в варезной ветке уже справились).
Берется какой-нибудь "антиквариат" времен Pentium 4, на него ставится Corporate-вариант 11-й версии и запускается в режиме 24*7. Техники этих времен по чуланам все еще немало валяется, а производительность получается примерно 1 к 5-6 (за один час работы сегодняшнего четырехпроцессорника надо отдать 5-6 часов работы на Р4). Если найдется несколько штук таких "старичков", то в сумме можно получить вполне приемлемые темпы.

VitRom

Цитата:

Хотя ЕМНИП в тех решениях, что видел я, юзались вообще какие-то "3-пати" тулзы, вроде даже что-то открытое.

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


Цитата:

Тогда получается, что для 9/10 задач хватит "чистого" ФР-11...

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


Цитата:

Или в обрезке/кадрировании/чистке ФР-11 тоже переплюнул уже спецтулзы вроде БукРесторер-а или СканКромсатор-а?

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

Так что на ближайшие годы BookRestorer скорее всего так и останется инструментом №1. ScanKromsator тоже хорош, спору нет, но отсутствие документации, но необходимость за ним постоянно присматривать и подкручивать...

Цитата:

Что же до HotFolder в 11-версии, то мои знакомые нашли вполне работающий способ обходить процессорный ограничитель

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

Frantishek

Цитата:

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

Еще смешнее. На какой бы машине не запускался HotFolder (в 11-й версии), он будет работать ровно в мощность одного ядра стоящего там процессора.

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

Shangry

Цитата:

Но начиная с 11-й версии, для создания DjVu'шек начали использовать родной софт (лицензия от Caminova)

в Caminova только одна полезная штука - сегментер. Для всего остального ничего особенного в Caminova нет.

И в FR разбивка на слова/строки при экспорте в DJVU хуже, чем в DjvuOCR:
- в FR:

Цитата:

(page
(word "1-ое слово 1-ой строки")
(char " ")
(word "2-ое слово 1-ой строки\n")
(word "1-ое слово 2-ой строки")
(char " ")
(word "2-ое слово 2-ой строки")
)

- в DjvuOCR:

Цитата:

(page
(line
(word "1-ое слово 1-ой строки")
(word "2-ое слово 1-ой строки")
)
(line
(word "1-ое слово 2-ой строки")
(word "2-ое слово 2-ой строки")
)
)

2-ой вариант лучше, т.к. нет лишних данных о пробелах + из-за разбивки на строки (тег (line ...) ) позволяет делать полуавтоматическое исправление ошибок после экспорта данных в DJVU.

unreal666

Цитата:

в Caminova только одна полезная штука - сегментер.

С этой точки зрения можно сказать, что во всем DjVu только одна по настоящему полезная вещь - толково работающий сегментатор.
Все прочие его компоненты ведь вполне ординарны - wavelet-сжатие (IW44), ч/б сжатие через словарь шаблонов (JBIG2, усовершенствованный до JB2), арифметический компрессор, снижение пиксельности.


Цитата:

И в FR разбивка на слова/строки при экспорте в DJVU хуже, чем в DjvuOCR

В принципе это можно отнести на глюки освоительного периода. Вот если и через релиз-другой не уберут...

Shangry

Цитата:

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

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

unreal666

Цитата:

сегментатор - это фактически прога.

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


Цитата:

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

Ну так почти 15 лет доводки и совершенствования алгоритмов - это вам не хухры-мухры . Здесь как у коллекционных вин - чем старше, тем лучше.

А все, что идет по линии DjVuLibre уже с самого начала имело ограничитель по качеству сегментирования (чтобы не перебегать дорогу коммерческим версиям). Да и после отделения похоже в этом смысле не особо совершенствовалось.

Shangry
Adobe сейчас пытается сделать некую альтернативу сегментатору Каминовы. Они его пока реализовали в своем ClearScan. В чем-то он даже лучше.
Все-таки эта связка лизардтековская уже устарела морально.

ghosty
Adobe под названием ClearScan сделал вполне приличный MRC-компрессор. Но на полноценное и универсальное решение а-ля DjVu он пока еще не тянет.

Во-первых, там заряжено не столько сжатие изображений, как таковых, сколько сжатие текстовой части этих изображений. Сначала OCR-движок отлавливает все текстовые включения, которые есть в картинке, а затем подставляет вместо них обычный шрифтовой вывод. Шрифт то ли берется откуда-то, то ли генерится на ходу - пока не очень понятно.
Вся остальная часть картинки, судя по виду получаемых PDF, обычно сжимается как единое целое, а-ля JPEG и его коллеги, на слои не делится. Результат вполне предсказуемый - там, где текста много, сжимается хорошо, там, где не очень - сжимается так себе.
Во-вторых, в Adobe похоже наступили на грабли, которые в DjVu сумели обойти. Для сжатия графики используется не wavelet-алгоритм, а какая-то разновидность JPEG. А значит и кратность сжатия поменьше и качество получаемых изображений похуже.
Ну, и в третьих, практически полное отсутствие регулировок. Что Акробат захочет, то и выдаст, повлиять никак нельзя.

А вот в LuraTech похоже сумели сделать что-то поинтереснее. Их PDF Compressor я бы назвал самым на данный момент удачным решением в области MRC-технологий.
Качество сегментирования - выше всяких похвал, получаемое сжатие - тоже вполне приличное (хотя и несколько пониже, чем у DjVu), внешний вид получаемых изображений мало чем отличается от оригиналов. Плюс простая удобная система настроек, плюс очень приличный бинаризатор.
Опять же PDF формат куда более распостраненный, чем DjVu, софта больше, работать проще.

Shangry
Все не совсем так.
В 2010 г. я делал краткий обзор ( часть I, часть II) нового сегментера Adobe для CS (у них есть еще старый хреновый - для связки jbig2+jpeg2000) в сравнении с лизардовским.
Вообще, MRC-технологии традиционно обсуждаем здесь. Добро пожаловать

Добавлено:

Цитата:

Шрифт то ли берется откуда-то, то ли генерится на ходу - пока не очень понятно.

Да, генерится свой собственный на ходу.


Цитата:

Для сжатия графики используется не wavelet-алгоритм, а какая-то разновидность JPEG.

JPEG2000 - это именно wavelet-алгоритм, в отличие от JPEG.

В остальном можно продолжить в указанной ветке.

ghosty

Цитата:

Вообще, MRC-технологии традиционно обсуждаем здесь. Добро пожаловать

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


Цитата:

JPEG2000 - это именно wavelet-алгоритм, в отличие от JPEG.

Сначала я и сам думал на JPEG2000 - на сжатых картинках ловятся артефакты, характерные именно для него. Но потом посмотрел какие кодеки прописаны в теле PDF - а там сплошь от JPEG.
Надо думать, в Adobe доработали стандартный JPEG и засунули его в свой компрессор.

unreal666

Цитата:

2-ой вариант лучше,

Shangry

Цитата:

Вот если и через релиз-другой не уберут...

а пока не убрали, на этот случай я сделал костыль - FR11 DjVu Text Layer Crutch
требует наличия 2го фреймворка..

Здравствуйте!!! Подскажите что надо сделать в настройках у меня не передаёт в Word корректно в смысле ни сохраняет, ни для редактирования
как pdf сохраняет нормально! Версия ABBYY FineReader 10
Спасибо

Сегодня 23 февраля FineReader Touch, FineScanner и ABBYY CardHolder для iOS бесплатны.

Программа некоторые названия глав оформляет как колонтитулы и в основной сохраняемый текст такие строки не попадают. Возможно ли отключить проверку верхних колонтитулов?

33oleg

Цитата:

Подскажите что надо сделать...

Как минимум, подробно описать, что именно у вас не в порядке.
Пока что информации здесь на уровне: "У меня болит голова, что мне делать?".