Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Темы - monday2000

Страницы: 1 [2] 3 4 5
16
DjVu / Перенесено: Однопроходный DjVu кодер
« : 11 ПЭТРам 2011, 16:48:48 »

17
DjVu / Перенесено: Утилита djvupages
« : 11 ПЭТРам 2011, 16:48:29 »

18
Тема перенесена в новый раздел Linux, созданный по просьбе MetaSpirit.

http://www.djvu-scan.ru/forum/index.php?topic=130.0

19
Идея о некоем сканере для полностью автоматического сканирования книг (без участия человека) существует давно.

Несколько раз предпринимались попытки её обсуждения - на разных форумах:

http://natahaus.info/forums/showthread.php?t=5951
http://www.roboforum.ru/viewtopic.php?f=35&t=1699

У меня на сайте есть страничка на эту тему:

http://www.djvu-soft.narod.ru/scan/roboscanner.htm

Ещё эта тема активно обсуждалась на http://diybookscanner.org/forum/ . Там даже приводились ссылки на Ютюб-видеоролики по этой теме.

Ещё я сегодня нашёл новую ссылку по теме: http://www.kti.ru/forum/viewsubject.asp?id=1477 . Значит, интерес есть к проблеме.

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

Тем не менее, надо что-то делать с этой проблемой.

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

Звучит фантастично, понимаю.

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

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

Вот пример человека, который мог бы купить такое устройство:
http://obyvatel.livejournal.com/295468.html

Что мы можем сделать сейчас:

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

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

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

Вообще, ИМХО основной смысл сканирования книг - это оцифровка книг из библиотек, а вовсе не оцифровка книг, купленных в магазине. Автоматический робосканер сделает это возможным.

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

20
Почему во всех рекомендациях указывается формат TIF как промежуточный формат сканобработки?

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

Я предлагаю рассмотреть простой BMP (несжатый). Достоинства:

1. Наиболее легко работать программно.

2. Нет никаких проблем с тегами.

3. Нет "скрытой" многостраничности.

Недостатки:

1. Плохое сжатие - нет аналога LZW и CCIT Fax G4 - как у TIF. Но, с другой стороны - а так ли уж это нужно? Разве что для архивного хранения сканов - но не для процесса сканобработки.

2. BMP не поддерживается Скантейлором. Но это, скорее, недостаток Скантейлора.

22
Pdf / Программная работа с PDF на С++
« : 21 ґХЪРСам 2010, 17:58:08 »
Завёл топик, чтобы собирать ссылки по программной работе с PDF.

Критерий отбора - достаточно интересные, и без опоры на .NET, Java и т.п. - а чисто на С/С++.

PdfView - Peeking into the Internals of PDFs

http://www.codeproject.com/KB/applications/pdfview.aspx

Counting PDF Pages using Regular Expressions

http://www.codeproject.com/KB/cs/pdfpagecountregex.aspx

23
Общий / Поиск дублей DjVu и PDF книг
« : 21 ґХЪРСам 2010, 16:44:48 »
Для больших онлайн-библиотек актуальна проблема поиска дублей PDF и DjVu книг.

То есть, это когда один и тот же DjVu-файл (к примеру) имеется под разными именами в собственной коллекции книг.

Наиболее часто такое бывает, когда набираешь из разных источников электронные книги.

Возникает вопрос: как отыскать дубли (чтобы убрать дублирующие файлы)? Можно попробовать поискать по контрольной сумме (MD5). Или по содержимому OCR-слоя. Но, вообще-то, OCR-слоя может и не быть в общем случае.

Самый тяжелый случай - отыскать не абсолютные дубли - а похожие. Например, случай, когда в одной DjVu-книге нет OCR-слоя - а в другой есть. У таких двух DjVu-книг уже будет разный MD5. Или когда есть 2 книги: одна (исходная) в плохом качестве - и она же, но переделанная с улучшением.

Я сегодня случайно наткнулся на программу по поиску дублей картинок. Причём она ищет не просто полные дубли - а умеет искать ПОХОЖИЕ картинки (!) - используя для сравнения некий математический алгоритм.

Вот статья по этой программе:

http://www.codeproject.com/KB/graphics/cbir.aspx

Я скомпилировал эту программу (в MS VC++ 6.0):

http://www.djvu-soft.narod.ru/soft/cbir.rar  (499 КБ)

Она работает с JPEG-файлами и на базе библиотеки CxImage. Но это не проблема - можно прикрутить туда взамен FreeImage и поддержку любых форматов.

Программа на пробу сработала верно - и нашла полный дубль картинки.

Причём, как сказано в статье, это ещё самая простейшая программа из этой области (поиск дублей картинок). Но даже и такой простейшей программой уже можно реально пользоваться.

Я мог бы добавить в эту программу поддержку DjVu. И тогда ею можно было бы искать дубли DjVu. Аналогично - и с PDF (но потрудней, конечно).

24
anagnost96 с Руборда создал свою Linux-программу для создания электронных версий бумажных книг - только не в формате DjVu, а в формате PDF.

Ссылка - http://forum.ru-board.com/topic.cgi?forum=5&topic=32945&start=600#4 :
Цитировать
Под влиянием iit512  решился опубликовать собственное решение "всё в одном", на сей раз -- для создания PDF. Утилита называется pdfbeads и написана на Ruby с использованием расширения RMagick. При наличии собственно интерпретатора Ruby и пакетного менеджера RubyGems пакет можно скачать и установить командой
 
$ gem install pdfbeads
 
Идея заключалась в том, чтобы по возможности организовать создание PDF-файлов по модели, привычной по формату DJVU: те же двух- и трехслойные страницы, те же методы "подклейки фона" и "раскраски маски". Кроме того, pdfbeads может играть роль оболочки к jbig2enc -- свободному кодировщику формата JBIG2. Среди возможностей скрипта:
 
-- сжатие маски по технологии JBIG2 (с использованием jbig2enc) или Fax G4;
 
-- различные форматы сжатия для фоновых изображений (jpeg2000, jpeg, deflate);
 
-- корректная обработка малоцветных индексированных изображений (создается маска из нескольких слоев, каждый -- со своим цветом);
 
-- автоматическая сегментация "смешанных" файлов, полученных с помощью ScanTailor, причем для картинок можно задать разрешение, формат сжатия и (при желании) принудительную конвертацию в оттенки серого;
 
-- разбиение полноцветного изображения на фон и передний план по заданной маске (подобно тому, как это делает djvumake при указании опции PPM);
 
-- добавление текстового слоя из hOCR;
 
-- добавление оглавления, метаданных и меток страниц.
 
Имеется также русская страница руководства http://rubyforge.org/docman/view.php/9752/10692/pdfbeads.ru.html .

Вот и более свежее сообщение http://forum.ru-board.com/topic.cgi?forum=93&topic=3172&start=1420#2 :
Цитировать
Итак, я залил на rubygems.org обновленную версию, в которой исправлена ошибка с чтением TIFF-файлов, содержащих блок EXIF. Кроме того, при попытке обработать многостраничный TIFF теперь выдается предупреждение об отсутствии поддержки таких файлов.

25
Тема перенесена в Общий.

http://www.djvu-scan.ru/forum/index.php?topic=118.0

P.S. Просто тема по смыслу довольно общая, так что ИМХО ей уместнее быть в разделе "Общий".

26
Программирование / CuneiForm для DjVu
« : 03 ЅЮпСам 2010, 09:27:47 »
Я сумел скомпилировать под Windows CuneiForm-Linux v1.0.0 http://launchpad.net/cuneiform-linux

Посредством компилятора MS VC++ 6.0. Всё делал по инструкции: скачал и установил инсталлятор СMake, сгенерировал им dsp-файлы для MS VC++ 6.0, потом скомпилировал.

Скомпилировался консольный файл плюс dll-файлы для него. Добавил туда также готовые dat-словари из линуксового дистрибутива. Кстати, эти словари - как раз та вещь, которая не даёт CuneiForm'у считаться по-настоящему программой с открытыми исходниками - никто пока не знает ни внутреннюю структуру этих словарей, ни как сделать новый словарь (скажем, для какого-нибудь нового языка). Жаль.  >:( То есть, новый язык распознавания в CuneiForm не добавишь.  :(

Вот что получилось:

http://djvu-soft0001.nxt.ru/cuneiform_hocr_v1_0_0.rar (23,3 МБ)

Зеркало:
http://ifolder.ru/20085782

Я продублировал это сообщение на форуме OpenOCR: http://openocr.org/forum/viewtopic.php?f=2&t=3175 .

Программа поддерживает только BMP на входе. Это потому, что я пока не стал компилировать исходники вместе с ImageMagick++ (тогда была бы поддержка всех форматов). Просто ImageMagick++ может не скомпилироваться в MS VC++ 6.0 (почти наверняка).

Всё остальное в полученной программе - как у Линукс-версии. Попутно я нашёл 3 бага и одну проблему - но смог из них выкрутиться:

Bug #669844 in Cuneiform for Linux: “Start folder cuneiform.dll not found - VC6 build”

Bug #669908 in Cuneiform for Linux: “Bug found (Bool vs Bool 32)”

Bug #669880 in Cuneiform for Linux: “_stdMallocCounter == _stdFreeCounter”

Качайте, пробуйте. Не исключено даже, что всё это будет работать даже под Windows 98 (!) :o

В пакете есть готовый пример - BMP-файл. Запускаете прилагаемый bat-файл - и через секунду генерируется файл-результат распознавания - в формате hOCR.

Всё это я затеял ради генерации hOCR-файла. Дело в том, что официальные Windows-версии CuneiForm не поддерживают вывод hOCR-файлов - ни одна! >:( Поддержку hOCR создали и прикрутили уже в Linux-версии.

hOCR - это формат распознанного OCR-слоя от OCRopus: http://code.google.com/p/hocr-tools/
Цитировать
hOCR is a format for representing OCR output, including layout information, character confidences, bounding boxes, and style information. It embeds this information invisibly in standard HTML. By building on standard HTML, it automatically inherits well-defined support for most scripts, languages, and common layout options. Furthermore, unlike previous OCR formats, the recognized text and OCR-related information co-exist in the same file and survives editing and manipulation. hOCR markup is independent of the presentation.

Вот спецификация hOCR: http://docs.google.com/View?docid=dfxcv4vc_67g844kf

Вообще, сейчас, как я понял, развивается бурными темпами Linux-порт CuneiForm'а. Официальные релизы заглохли намертво, никакой активности там не наблюдается. Жаль. :-\ Спасибо хоть линуксоидам, что хоть как-то развивают программу.

Вот интересные ссылки по теме CuneiForm:

LXF118:Компьютер слушает http://tinyurl.com/37dspzr
Статья проводит сравнение открытых OCR-продуктов Tesseract и CuneiForm.

Новости CuneiForm-Linux
http://www.linux.org.ru/view-news.jsp?tag=cuneiform

Распознавание текста в Linux при помощи CuneiForm
http://www.kv.by/index2009091108.htm

27
Pdf / PDF-технология ClearScan
« : 01 ЅЮпСам 2010, 16:24:17 »
В программе Adobe Acrobat Professional 9 имеется интересная функция, она называется "ClearScan". Вот её описание на английском языке:

http://acrobatusers.com/print/2215

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

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

Вот сообщение romanef с Руборда:
Цитировать
выловил глюк Clearscan, почище чем "инь-янь", пропали целые слова (ПОСЛЕДОВАТЕЛЬНОСТИ, ПРЕ)!!



так что пользоваться им для физмата нельзя...

28
Я написал статью:

Сравнение форматов DjVu и PDF

http://www.djvu-soft.narod.ru/scan/djvu_vs_pdf.htm

Топик создан для её возможности её обсуждения.

Страницы: 1 [2] 3 4 5