» DjvuOCR

myual
Вроде, автор не гарантировал беспроблемной работы с FR 9: DjvuOCR 2.4 beta - это именно бета, и этим все сказано.
Поэтому gencho рекомендовал пользоваться FR версии не старше 8.

ghosty
Да все это понятно...
Просто хотелось локализовать проблему и узнать о принципиальной возможности ее самостоятельно исправить.

myual

Цитата:

Просто хотелось локализовать проблему и узнать о принципиальной возможности ее самостоятельно исправить.

Просто автора довольно долго не было. А теперь, судя по офсайту, он вернулся.
gencho, с возвращением! Крепкого Вам здоровья!

Да, делал несколько попыток воспользоваться связкой FR 9 + DjvuOCR 2.4 beta - всегда разочаровывался.
Откатывался на стабильную пару предыдущих релизов обеих программ.
Рад новости, что автор вернулся. Если будет допилена вышеупомянутая связка - будет очень хорошая новость для многих!

Скоро будет доступен 10 ФайнРидер.

С 9-кой бы разобраться. Хотя всё будет зависеть от автора. Прочитал его сообщение на сайте. Вроде настрой положительный

Кстати, если ну очень хочется сделать djvu с текстовым слоем и в качестве движка OCR использовать версии FR (или другой OCR), которые еще не поддерживает DjvuOCR, то можно это сделать по такой схеме: разбить djvu на tiff, загрузить tiff'ы загрузить djvu в FR, распознать в pdf. Затем преобразовать pdf в xml, и сохранить его как текстовой слой в djvu.

Цитата:

Затем преобразовать pdf в xml

Чем?

Цитата:

сохранить его как текстовой слой в djvu

т.е. это будет просто текстовый слой? Который в том же DjvuOCR внедрю в djvu?

В свое время я использовал свободные утилиты pdftohtml и pdf2xml.
Для внедрения текстового слоя - утилиты из djvulibre.
Преобразовывал pdfxml в djvuxml - скриптом Autoit.
Хотя правильнее для преобразования использовать xslt.

есть самопальные скрипты на пайтоне для перевода ОРС слоя из пдф в джвю, а также (через xml) гиперлинков.
однако обратный перевод - из джвю в пдф - неизвестно чем делать.
кстати хотел бы спросить: не знает ли кто , каким образом можно вставить в отсканированный пдф файл заранее заданный ОРС слой, оглавление и гиперлинки? (это может быть актуально, например, для перевода готового джвю файла в пдф с сохранением всех свойств джвю)

are
Как вариант, можно попробовать как-то так:
1. Извлекаем текстовой слой из djvu в xml.
2. Скриптами или xslt преобразуем его в формат Scribus (на основе xml) + добавляем картинки-сканы поверх текста.
3. Из Scribus сохраняем в pdf.

Испытательная версия ABBYY FineReader 10 Professional Edition

http://abbyy.ru/download/finereader_pro

are

Цитата:

однако обратный перевод - из джвю в пдф - неизвестно чем делать.

ИМХО важная и популярная проблема (в смысле OCR). Народ меня по мылу нередко терзает. Давайте будем искать решение.

ФайнРидер 9 нумерует файлы проекта не по порядку. Из-за этого куча проблем при внедрении текста в DJVUOCR 2.4. Это можно решить? Вручную очень долго выбирать нужные страницы, кроме того ФайнРидер в папке своего проекта хранит картинки в каком-то странном формате, к-рый не читается никакими смотрелками. Или можно как-то подправить DJVUOCR, чтобы она брала файлы из проекта ФайнРидер не просто так, а согласно страницам?

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

Цитата:

Это можно решить?

Да, можно. Проблема состоит как раз в новой фиче FR9 - использованию дополнительных ядер процессора - из-за их гонок путается порядок файлов на выходе.
Варианты решений:
1. Отключить все ядра процессора, кроме одного, но будет соответствующее замедление распознавания.
2. Переименовать frf-файлы так, чтобы вернуть соответствие между ними и tif-ками. Путь к tif-файлу, которому соответствует frf, находится в начальных байтах файла frf в формате Unicode. Задача решается простейшей программкой. http://www.onlinedisk.ru/file/274018/
Просто выбираем в программе папку с файнридеровскими frf-ками и ждем до готовности.
Внимание - программа не тестировалась на tif-ках с русскими именами.

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

Цитата:

гораздо проще доставить еще и ее,

Извините, я не совсем корректно выразился.

1 и 2 - это разные решения.

Решение 2 - самодостаточно. И отключать ядра не нужно.

StanFreeWare

Цитата:

2. Переименовать frf-файлы так, чтобы вернуть соответствие между ними и tif-ками.

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

Цитата:

похоже проект потихоньку умирае

Мне тоже жаль, хотя надежда еще теплится. Похоже, в ФР10 вообще отошли от frf файлов. Вместо них теперь папки с *.dat и *.frdat...
Так что для уважаемого gencho поле задач еще более увеличилось... В крайнем случае изобретем конвертор *.frdat->*.frf ))

Добавлено:

Цитата:

за программку спасибо

Тогда благодарите и omgFiRE c infanata.org )
За умение формулировать вопросы, содержащие 99% ответа.

Версия с поддержкой кириллицы. Вроде бы окончательная.
http://www.onlinedisk.ru/file/274206/

Внимание - патч тестировался для версии 9.0.0.622. На версиях, начиная с 9.0.0.724 потребуется коррекция патча - пропуск информации о пользователе в файле frf.

Друзья мои, а в чем собственно проблема-то? 8,9,10 версии FR абсолютно ничем не отличаются по качеству распознавания от 7-й. В чем-то даже хуже. Более того, для текстового слоя особо не актуально это самое качество - всегда вполне хватает кач-ва 7-8-х версий.
Так зачем извращаться и что-то там улучшать?

ghosty
Так зачем извращаться и что-то там улучшать?

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

omgFiRE
а зато можно пользоваться 8-й версией и одновременно распознавать несколько книг

omgFiRE

Цитата:

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

Насколько я помню, там по-другому: один поток - на загрузку страниц, другой - на распознавание (т.е. разные потоки под разные задачи). Поэтому если и будет увеличение производительности, то не в два раза.
Во всяком случае на HT я резкого увеличения производительности не заметил. Вы на двухядернике действительно замеряли разницу во времени между 8-й и 9-й или говорите на глазок?


Добавлено:
are

Цитата:

а зато можно пользоваться 8-й версией и одновременно распознавать несколько книг

Вот, да, кстати

are
а зато можно пользоваться 8-й версией и одновременно распознавать несколько книг

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

ghosty
один поток - на загрузку страниц, другой - на распознавание
Нет, я сначала загружаю страницы без распознавания, потом распознаю. Счётчик распознанных страниц увеличивается парами.

Вы на двухядернике действительно замеряли разницу во времени между 8-й и 9-й
Я замерял разницу между 9-й и 9-й запущенной на одном ядре и на обоих.

Но только сегодня и только для вас сделаю тесты 9 vs 8 и засеку время работы.

omgFiRE

Цитата:

Но только сегодня и только для вас сделаю тесты 9 vs 8 и засеку время работы.

Спасибо! Ждем

По-моему, коректнее говорить не о потоках, а о процессах. Потоков в FR, я так думаю поболее 2х будет..
И, не выдержал, еще шлифанул патч. Теперь, по-идее, должен наводить порядок для всех подверсий FR9.
http://www.onlinedisk.ru/file/274628/
Если нет, скиньте непонятые frf-ки сюда. Ну или сами поправьте исходнике, если шар(п)ите ))

Цитата:

Но только сегодня и только для вас

Я думаю, интересно будет не только ghosty )

Итак тестирование.
Процессор: старенький двухъядерник Intel Core 2 Duo T7500, памяти 4GB, vista x64. Книга: Кнут - Искусство программирования, том 4, выпуск 3. Генерация всех сочетаний и разбиений 208 страниц.

8.0.0.1126 справился за 25 минут, загрузка процессора 50% т.е. потраченное процессорное время (ориентировочно) 25 минут.

9.0.0.662 справился за 16 минут, загрузка процессора 100% т.е. потраченное процессорное время (ориентировочно) 16x2 = 32 минуты.

Девятка сильно притормозила во время загрузки тифок (я тестировал её первой). Т.е. первые несколько минут девятка не загружала процессор, а скрипела жестким диском. Когда тестировал 8-ку обращений к диску почти не было (кэш файлов операционной системы). Но перезагружаться уже не буду.

omgFiRE
Я так и думал - максимум в полтора раза. И то удивительно.
Но все-таки люди при переходе с 8-й на 9-ю словили кучу неприятных косяков - по-моему, Astra55 об этом писал. Особенно что-то стремное было со спецсимволами. Поэтому я остался на 8-й. gencho, вроде, тоже рекомендовал с 8-й не спешить слезать...

8-я версия позволяла запускать полностью пакетное распознавание (т.е. можно взять 1000 джвю книг и все подряд распознать за неделю работы, без вмешательства пользователя и без GUI вообще). А работает ли эта процедура с 9-й и 10-й версиями, неизвестно.