понедельник, 14 июня 2010 г.

Создание Djvu документов в Linux от А до Я

Если с PDF всё ясно и понятно, то сборка djvu–документов часто является неким сокровенным знанием. Наиболее полный мануал почему–то обходит стороной такие (довольно важные) моменты, как кодирование цветных изображений и распознавание текста, так что я решил восполнить сей пробел и написать этот пост (позже было добавлено ещё несколько разделов — смотрите раздел UPD). Большая его часть будет пересказом упомянутого руководства; дополнениями станут рассказ о кодировании полноцветных изображений и пояснения к созданию текстового слоя. Для удобства я разбил пост на отдельные части:
  1. Вводные замечания
  2. Кодирование чёрно–белых изображений
  3. Кодирование оттенков серого
  4. Кодирование цветных изображений
  5. Распознавание текста (OCR) и создание текстового слоя
  6. Ссылки в оглавлении
  7. Метаинформация
  8. Работа с не–ASCII символами
  9. Сборка итогового djvu–документа

Вводные замечания

Итак, последовательность создания djvu–документа примерно такова:
  1. Сканирование книги и чистка сканов (по возможности, фон должен быть белым, а текст — чёрным) (этот пункт в данной статье не рассматривается — предполагается, что сканы у вас уже есть; если это не так, сканируйте, обрабатывайте результат — кстати, комментаторы настоятельно рекомендуют использовать Scan Tailor — и возвращайтесь к этой статье);
  2. сжатие каждой страницы отдельно в зависимости от её содержания (не бойтесь слова «отдельно» — операции легко автоматизируются и, скорее всего, вам подойдёт сжатие всех страниц в оттенках серого);
  3. опционально — добавление текстового слоя;
  4. сборка из полученных отельных djvu–файлов одного, финального.
Теперь касательно используемых программ: фактически нам нужны только утилиты, входящие в пакеты djvulibre-bin, netpbm и imagemagick. Всё это добро легко ставится из репозиториев:
$ sudo aptitude install djvulibre-bin netpbm imagemagick
Ну что же, план действий у нас есть, снаряжение подготовлено — в путь, друзья!

Кодирование чёрно–белых изображений

Сжимать сканы в чёрно–белом режиме имеет смысл только в том случае, когда полиграфия действительно качественная, а сканы практически идеальны — в противном случае вы рискуете получить некачественное изображение и/или много шума. Итак, для сжатия изображения в чёрно–белом режиме исходник надо перевести в формат pbm. Сделать это можно, используя утилиты из пакета netpbm:
$ anytopnm ИМЯ_ИСХОДНОГО_ФАЙЛА | ppmtopgm | pgmtopbm -value 0.499 > ВЫХОДНОЙ_ФАЙЛ.pbm
Если вы именовали сканы последовательными номерами, можно использовать цикл. Так, следующая конструкция сконвертирует все tiff–файлы в pbm, меняя расширение:
for file in *.tiff; do anytopnm $file | ppmtopgm | pgmtopbm -value 0.499 > ${file%tiff}pbm; done
Коэффициент 0.499 взят из уже упоминавшегося англоязычного руководства, в котором данная настройка называется оптимальной для большинства случаев. Правда, экспериментировать вам никто не запрещает :)
Наконец, преобразование pbm в djvu–файл выполняется командой:
$ cjb2 -dpi DPI ВХОДНОЙ_ФАЙЛ.pbm ИТОГОВЫЙ_ДОКУМЕНТ.djvu
Обратите внимание на опцию -dpi — вы должны самостоятельно задать «плотность» получающегося документа.
После конвертирования в djvu pbm–файлы могут быть удалены.
Помимо cjb2, существуют и другие инструменты для компрессии чёрно–белых изображений. В частности, monday2000 в комментариях советует использовать minidjvu (в Debian есть существующий пакет), а лучше — DjVu Solo 3.1, запущенный под Wine.

Кодирование оттенков серого

Скорее всего, сканы окажутся не идеальными, а типография оставит желать лучшего, так что кодирование изображений в оттенках серого — это то, чем вы будете заниматься основную часть времени.
Для сжатия сканы придётся сконвертировать либо в JPEG (чего я НЕ рекомендую), либо в PPM/PGM. Поступим разумно и пойдём по второму пути:
$ anytopnm ИМЯ_ИСХОДНОГО_ФАЙЛА | ppmtopgm > ВЫХОДНОЙ_ФАЙЛ.pgm
(думаю, для вас не составит труда самостоятельно написать цикл, автоматизирующий конвертирование всего набора сканов). Дальше в ход пойдёт утилита cpaldjvu:
$ cpaldjvu -dpi DPI -colors КОЛИЧЕСТВО_ОТТЕНКОВ_СЕРОГО ВХОДНОЙ_ФАЙЛ.pgm ВЫХОДНОЙ_ФАЙЛ.djvu
Как видите, добавляется новая интересная деталь — количество используемых оттенков серого. Чем больше это значение, тем больший объём имеет сжатая страница. Для не очень качественных сканов подойдёт значение 3 или 4 — этого вполне достаточно, чтобы получить пусть и бледноватую, но читабельную картинку.

Кодирование цветных изображений

Теперь самое интересное — кодирование цветных страниц. Как правило, в цвете кодируются только обложки, но вы вольны поступать так, как сочтёте нужным.
Сначала конвертируем обложку в PPM:
$ convert ИСХОДНЫЙ_СКАН РЕЗУЛЬТИРУЮЩИЙ_ФАЙЛ.ppm
Теперь сожмём её в Djvu:
$ c44 -dpi DPI ИСХОДНИК.ppm РЕЗУЛЬТАТ.djvu
Не забудьте заменить DPI на подходящее значение — всё остальное программа сделает сама.

Распознавание текста (OCR) и создание текстового слоя

Это опциональный пункт, можете пропустить его, если вам не нужен текстовый слой или вы попросту не хотите тратить время — операция распознавания довольно длительна, а вычитка получившегося текста — это вообще чуть ли не каторжный труд. «Думайте сами, решайте сами, иметь или не иметь…»
В принципе, распознавать имеет смысл только техническую литературу — к примеру, программисты гораздо больше обрадуются книге, из которой можно скопировать листинги. Художественную же литературу распознавать, как мне кажется, особого смысла нет — вспомните, когда у вас последний раз появлялось желание что–то скопировать из художественной книги? То–то же.
От слов перейдём к делу — поставим OCR–движок:
$ sudo aptitude install ocrodjvu
ocrodjvu занимается распознанием текста непосредственно из djvu–файла. Он может как дописывать текстовый слой в обрабатываемый документ, так и создавать новый. Работает это чудо вот так:
$ ocrodjvu -o ВЫХОДНОЙ_ФАЙЛ.djvu ВХОДНОЙ_ФАЙЛ.djvu
или, если вы уверены, что хотите переписать оригинальный документ:
$ ocrodjvu --in-place ВХОДНОЙ_ФАЙЛ.djvu
Замечу, что ocrodjvu является фронт–ендом для различных OCR–движков (по умолчанию используется оболочка для Tesseract под названием OCRopus). Движки эти, к сожалению, поддерживают не так уж много языков. Русский распознаётся только с помощью Cuneiform (который сейчас в non–free ветке sid'а) и уже упоминавшимся tesseract. C’est la vie…
Ещё одним важным замечанием о распознавании является время его выполнения — вы можете распознавать документы и до, и после сборки их в единый файл. Правда, во втором случае вы наверняка потратите лишнее время на то, чтобы в цикле извлечь текст каждой страницы в отдельный файл, а потом так же запихнуть всё обратно. Тут уж поступайте, как знаете.
И последняя, но, вероятно, самая важная заметка — на счёт редактирования текстового слоя. Тут у вас два варианта: либо воспользоваться довольно удобной программкой под названием djvusmooth (спасибо за наводку, Lazy_Kent!), либо с помощью djvused извлекать текстовый слой и править его. Т.к. использование GUI не должно составить особого труда, на djvusmooth я останавливаться не буду — гораздо интереснее поковыряться во внутренностях Djvu и выяснить, как «руками» сделать всё то, что помогает делать графический интерфейс.
Начнём с базовых операций; вынуть текстовый слой всего документа можно так:
$ djvused ВХОДНОЙ_ФАЙЛ.djvu -e "print-txt" > ВЫХОДНОЙ_ФАЙЛ.txt
После этого txt'шник можно открыть любимым vim'ом и править, править, править… О формате поговорим чуть позже. Когда закончите редактирование, вернуть текстовый слой на место помогут такие команды:
$ djvused ВХОДНОЙ_ФАЙЛ.djvu -s -e "remove-txt"
$ djvused ВХОДНОЙ_ФАЙЛ.djvu -s -e "set-txt ТЕКСТОВЫЙ_СЛОЙ.txt"
Первая команда удаляет уже существующий текстовый слой, вторая добавляет тот, что сохранён у нас в текстовом документе и который мы исправили.
Теперь касательно синтаксиса, используемого для описания текстового слоя. Тут всё базируется на списках, которые заключаются в круглые скобки и могут быть вложены друг в друга. Каждый список имеет следующую структуру:
(type xmin ymin xmax ymax ... )
На месте type должен быть один из следующих идентификаторов: page (страница), column (колонка), region (область), para (параграф), line (строка), word (слово) или char (символ). Дальше задаются координаты углов (левого верхнего и правого нижнего) прямоугольника, в котором лежит данный структурный элемент (страница, параграф, строка и т.д.).
Как уже было сказано, каждый список может содержать в себе другие списки. Поэтому логично организовать структуру текстового слоя примерно так:
(page x1 y1 x2 y2
(column x1 y1 x2 y2
(region x1 y1 x2 y2
(para x1 y1 x2 y2
(line x1 y1 x2 y2
(word x1 y1 x2 y2 "This")
(word x1 y1 x2 y2 "is")
(word x1 y1 x2 y2 "an")
(word x1 y1 x2 y2 "example")
(word x1 y1 x2 y2 "of")
(word x1 y1 x2 y2 "possible")
(word x1 y1 x2 y2 "hidden")
(word x1 y1 x2 y2 "text")
(word x1 y1 x2 y2 "description")
(char x1 y1 x2 y2 ".")
)
(line x1 y1 x2 y2
(word x1 y1 x2 y2 "Here")
(word x1 y1 x2 y2 "goes")
(word x1 y1 x2 y2 "second")
(word x1 y1 x2 y2 "line")
(char x1 y1 x2 y2 ".")
(word x1 y1 x2 y2 "You")
(word x1 y1 x2 y2 "have")
(word x1 y1 x2 y2 "got")
(word x1 y1 x2 y2 "that")
(word x1 y1 x2 y2 "already")
(char x1 y1 x2 y2 ",")
(word x1 y1 x2 y2 "right")
(char x1 y1 x2 y2 "?")
)
)
)
)
)
Как видим, тут описан один параграф, состоящий из двух строк. Править это счастье не так уж сложно, если только распознавалка не склеила несколько слов вместе или не проигнорировала какую–то строку или символ. Для упрощения работы очень советую экспортировать обрабатываемую страницу в RAW PPM (вы можете использовать утилиту ddjvu или воспользоваться соответствующей возможностью стандартного просмотрщика djview), открыть её, скажем, в Gimp'е и там с помощью любого инструмента определять границы слова — текущее положение курсора отображается в левом нижнем углу окна с изображением (по крайней мере, так себя ведёт Gimp 2.6.8). Отсчёт почему–то начинается с левого нижнего угла, так что будьте внимательны.
Отдельно следует поговорить о не–ASCII символах — все они должны быть представлены в виде «UTF–8 encoded sequence», т.е. чего–то вроде такого: «\320\222\320\262\320\265\320\264\320\265\320\275\320\270\320\265». Т.к. об этом не расскажешь в паре абзацев, я написал об этом отдельный раздельчик — если будете править текстовый слой или метаинформацию (см. ниже), обязательно прочтите его.
Впрочем, можно обойтись и без этих премудростей с кодированием — у djvused есть опция -u, заставляющая его не перекодировать не–ASCII символы, а выводить их как есть, в UTF–8.
На этом, я думаю, повесть о текстовом слое можно завершить — вы уже знаете достаточно, чтобы создать, вычитать и встроить в документ качественную текстовую «подкладку».

Ссылки в оглавлении

Согласитесь, пользоваться djvu–книгой станет гораздо удобнее, если пункты оглавления будут не просто текстом, а ссылками на соответствующие страницы. Djvu позволяет реализовать это счастье, используя механизм так называемых аннотаций (annotations). Как и текстовый слой, аннотации описываются с помощью списков, заключённых в круглые скобки.
Ссылки создаются с помощью структуры maparea, имеющей следующий формат:
(maparea url comment area ...)
Рассмотрим аргументы этой структуры по порядку.
Итак, url. Вообще–то тут можно указать ссылку на любой документ, а не только на страницу текущего файла — если вам это интересно, читайте man 1 djvused. Я же в дальнейшем буду говорить только о ссылках на страницы текущего документа. Они имеют очень простой формат: #номер_страницы, например, #9. Также допускаются относительные ссылки, имеющие знак — так, #+1 отправит читателя на следующую страницу, а #-1 — на предыдущую.
Теперь comment. Это — тот текст, который будет показан пользователю в виде всплывающей подсказки при наведении курсора мыши на ссылку. Его можно оставить пустым.
area — описание области, которая служит ссылкой. Тут разработчики дали нам довольно большую свободу — выделять можно не только прямоугольники, но также овалы и строки (строки, в принципе, можно было бы выделять прямоугольниками). Синтаксис всего этого добра вы можете найти в man 1 djvused. Я думаю, что читатель сам справится с выбором крайних координат для rect, text или line (в зависимости от того, чем вы решите выделять пункты оглавления).
Три точки в описании maparea означают, что вы можете задать дополнительные параметры, описывающие рамку вокруг ссылки. Тут у нас тоже довольно много вариантов — можно сделать инверсионную рамку (она будет чёрной, если фон белый, и наоборот; идеальна для цветного фона, когда цветная рамка может слиться с фоном), задать ей определённый цвет и толщину, а для некоторых типов выделения можно также задать тень.
Отдельно упомяну опцию (border_avis) — по умолчанию рамка показывается только при наведении на ссылку курсора мыши; данная же опция заставляет рамку отображаться всегда.
Теперь вы знаете всё необходимое. В качестве примера покажу секцию, которую я написал для оглавления одной из книг:
(maparea "#12" "Chapter 1"
(rect 220 759 93 23)
(xor)
)
Таким образом, имеем рамку с подсказкой «Chapter 1» и инверсионной рамкой, отображающейся только при наведении курсора мыши.
Наконец, встроим наши ссылки в файл:
$ djvused ВХОДНОЙ_ФАЙЛ.djvu -s -e "select 6; set-ant ФАЙЛ_СО_ССЫЛКАМИ"
Подразумевается, что оглавление находится на странице 6. Если это не так, поменяйте число после select на правильное.
Ещё раз обращаю ваше внимание на не–ASCII символы — они в обязательном порядке должны быть перекодированы в UTF–8 и представлены в восьмеричном виде! Почитайте соответствующий раздел этого поста, чтобы узнать больше.
Напоследок замечу, что ссылки — не единственное применение аннотаций. Вы также можете задавать дефолтный фоновой цвет страницы, степень её увеличения, режим дисплея (цветной, оттенки серого…), положение в окне ридера (по умолчанию — по центру, но можно сместить, скажем, в левый верхний угол), а также хранить информацию об авторе, названии, даже издания книги — о последнем и пойдёт речь в следующем разделе.

Метаинформация

Djvu позволяет вам добавить в файл особый блок, содержащий данные об авторе, названии книги, годе издания и прочем. Это — метаинформация. В последующем она может быть извлечена и использована: например, если все ваши книги содержат такой блок, вы можете в автоматическом порядке переименовать все книги по единому шаблону, разложить их по директориям по издательствами или годам — да что угодно! При этом для того, чтобы добавить в свой djvu файл такие данные, вам нужно приложить совсем немного усилий.
Итак, хранение метаинформации в Djvu организовано с помощью того же механизма, что и ссылки, то есть с помощью аннотаций. Вот пример файла с метаинформацией:
(metadata
Author "Douglas Adams"
Title "The Hitchhiker's Guide to the Galaxy"
Year "1979"
)
Обратите внимание на то, что внутри списка metadata нет вложенных списков — только пары ключ–значение. В мане сказано использовать списки, но мои эксперименты показали, что так делать нельзя — вложенные списки «удваиваются», т.е. конструкция вида (key value) превращается в ((key value)), в результате чего информация не распознаётся ни читалками, ни djvused. Встроить метаинформацию в файл вам поможет следующая команда:
$ djvused ВЫХОДНОЙ_ФАЙЛ.djvu -s -e "set-mete ФАЙЛ_С_МЕТАИНФОРМАЦИЕЙ"
а извлечь — такая:
$ djvused ВХОДНОЙ_ФАЙЛ.djvu -e "select-shared-ant; print-meta"
Не забудьте, что не–ASCII символы должны быть представлены в виде UTF–8 строк, записанных в восьмеричном виде. Почитайте соответствующий раздел этого поста — там об этом рассказано подробнее.
Учтите, что порядок полей не соблюдается, т.е. в выводе второй команды поля могут идти не в том порядке, в каком вы внесли их в файл с метаинформацией.

Работа с не–ASCII символами

Согласно стандарту Djvu, все текстовые файлы, получающиеся при использовании djvused с командами print-txt, print-meta и прочими, должны быть представлены в кодировке ASCII. Для представления не–ASCII символов символ кодируется в UTF–8, а потом преобразуется в следующий вид: «\321\200\321\217\320\264\321\213,». Эта строка представляет собой набор восьмеричных значений, каждое из которых представляет один байт строки, закодированной в UTF–8.
Для того, чтобы вы понимали суть сказанного, приведу пример. Пусть имеем слово «привет». В этом слове шесть символов. В UTF–8 русские символы представляются двумя байтами, т.е. букве «п» соответствуют два байта — в восьмеричной форме они выглядят как 320 и 277. Добавляем бэкслеши в начале — voilà, мы получили именно то представление, которое используется в текстовых составляющих Djvu файлов.
Это было теория, теперь же перейдём к практике. А задача у нас такая — получив txt–файл с символами, закодированными вышеописанным способом, надо его преобразовать в человеческий UTF–8, который в дальнейшем можно без проблем править любимым редактором. И вторая часть задачи — по завершении правки выполнить обратное преобразование. Поможет нам в этом нелёгком деле утилита uni2ascii (спасибо, Camaleón!), которую мы с лёгкостью ставим из репозитория:
$ sudo aptitude install uni2ascii
Преобразовать файл из восьмеричного представления в Юникод позволяет такой однострочник:
$ ascii2uni -q -a K < ВХОДНОЙ_ФАЙЛ.txt > ВЫХОДНОЙ_ФАЙЛ.txt
а обратно — такой:
$ uni2ascii -q -a K < ВХОДНОЙ_ФАЙЛ.txt > ВЫХОДНОЙ_ФАЙЛ.txtВпрочем, как я уже упоминал, этой рутины можно избежать, если при вызове djvused использовать опцию -u.

Сборка итогового djvu–документа

Завершающим этапом ваших трудов должен стать многостраничный djvu–документ, который легко, просто и быстро собирается из уже сжатых одностраничных djvu'шек такой командой:
$ djvm -c ВЫХОДНОЙ_ФАЙЛ.djvu *.djvu
Всё! Теперь можете наслаждаться свежесозданным документом.

До новых встреч!

UPD 21.06.2010:
  • добавлены разделы о текстовом слое, ссылках и метаинформации (keks.sw, это благодаря твоему комментарию!)
  • расширен раздел об OCR, добавлено упоминание об опции ocrodjvu --in-place, а также программ djvusmooth и Cuneiform (спасибо, Lazy_Kent!)
  • исправлено неверное утверждение касательно способности PPM хранить цвет; соответствующий раздел обновлён (спасибо ещё раз, Lazy_Kent)
  • другие мелкие правки
UPD 16.11.2010 (спасибо monday2000):
  • добавлено упоминание о Scan Tailor
  • в качестве альтернативы cjb2 упомянуты minidjvu и DjVu Solo 3.1, запускаемый под Wine
  • с недавних пор Tesseract начал понимать русский; упоминание об этом добавлено в статью
  • в djvused теперь можно отключать представление не–ASCII символов в виде их кодов — используя опцию -u, можно заставить djvused выводить символы в UTF–8

Копируете статью — поставьте ссылку!

32 комментария:

Юрий комментирует...

i̶m̶a̶g̶e̶m̶a̶g̶i̶c̶ imagemagick

Никита Мельниченко комментирует...

А какой тип привязки (char, word, line, etc.) обычно вставляют автоматические распознавалки в текстовый слой? Насколько это удобно править?

drakulavich комментирует...

Спасибо за ликбез.
Мне нравится, как ты оформляешь посты. Сейчас вот глянул, как в html сделать "отдельные части" со ссылками на фрагменты поста.
Сделал для одной из заметок аналогичным образом, только не включал название частей в тег ссылки, чтобы исключить моргание.

Minoru комментирует...

Yurij, спасибо за исправление — вечно забываю про «k» в конце, и команду, признаюсь, написал по памяти, а не скопировал из терминала.

2 Никита Мельниченко:
> А какой тип привязки (char, word, line, etc.) обычно вставляют автоматические распознавалки в текстовый слой?
За все сразу не скажу, но могу рассказать про ocrodjvu (который, напоминаю, всего лишь фронтенд для tesseract). Он использует все доступные привязки в порядке спадания: сначала страница, в ней колонка, в ней регион, в ней абзацы, в них строки, в них слова или символы.

> Насколько это удобно править?
Править, как мне кажется, неудобно. Я пробовал вычитать один абзац книги — задолбался переключаться между vim'ом и djview (экран у нетбука маленький, два окна рядом не поставишь). Но это меньшая из бед — вот если распознавалка случайно слепила два слова в одно или вовсе проигнорировала целую строку, дело худо, потому что вам придётся самостоятельно выяснять координаты прямоугольника, в котором лежит строка/слово, и вбивать это дело в текстовик. Надеюсь, для этого есть какой-то GUI…

2 Dr.AKULAvich:
> только не включал название частей в тег ссылки
Гм, кстати да, надо починить — некрасиво же.

Спасибо за комментарии!

keks.sw комментирует...

Подозреваю, что имелось в виду "C'est la vie"
Спасибо за рецепт.

Minoru комментирует...

2 keks.sw:
до твоего замечания искренне полагал, что «se la vi» по-французски так и пишется. Погуглил, прозрел. Спасибо!

Анонимный комментирует...

Есть ли способ под линаксом добавить в djvu ссылки в оглавление (чтоб можно было нажимать на них и сразу переходить на нужную страницу) и метаданные об авторе, название, годе издания?

Minoru комментирует...

2 idima89:
да, всё это можно сделать с помощью djvused и его команд print-ant, set-ant и print-meta, set-meta. С ними я, правда, ещё не разбирался, так что более подробно рассказать не могу. Увы, быстрая пробежка по инету не дала никаких результатов, так что придётся либо изучать самому, либо искать дольше и глубже.

Удачи!

Lazy_Kent комментирует...

1. c44 принимает PPM.
2. ocrodjvu поддерживает Cuneiform, у которого с русским всё в порядке.
3. У ocrodjvu есть опция --in-place.
4. Для редактирования текста и создания оглавления есть графическая программа djvusmooth (от автора ocrodjvu).

Minoru комментирует...

1. > c44 принимает PPM.
Мне казалось, что PPM не умеет хранить цвет (по карйней мере, я с помощью утилит из netpbm не смог получить цветной ppm — надо будет разобраться, почему). Сейчас почитал немного интернет, прозрел, поправил соответствующий раздел.

2. > ocrodjvu поддерживает Cuneiform, у которого с русским всё в порядке.
Не знал. Правда, Cuneiform — это non-free, к тому же есть только в сиде…
Тем не менее, упоминание добавил.

3. > У ocrodjvu есть опция --in-place.
В статье упоминалось, что ocrodjvu может переписывать документ. На всякий случай добавил готовую команду-пример с использованием --in-place

4. > Для редактирования текста и создания оглавления есть графическая программа djvusmooth (от автора ocrodjvu).
О, тот самый GUI, на существование которого я так надеялся (см. мой первый комментарий)! Спасибо огромное, с удовольствием добавил в пост и поюзал сам.

Спасибо ещё раз за ценные замечания, Lazy_Kent!

morbo комментирует...

Такие вот команды

cat ВХОДНОЙ_ФАЙЛ.txt | uni2ascii -q -a K > ВЫХОДНОЙ_ФАЙЛ.txt

можно записать проще:

uni2ascii -q -a K < ВХОДНОЙ_ФАЙЛ.txt > ВЫХОДНОЙ_ФАЙЛ.txt

morbo комментирует...

Глядя на скобки в текстовых файлах, вкрадывается смутное подозрение: авторы утилит - лисперы? (Кстати, вот вам и пример встроенного проблемно-ориентированного языка, о котором часто говорил Луговский.)

Анонимный комментирует...

Для обработки сканов перед кодированием есть прекрасная кроссплатформенная программы Scan Tailor - http://scantailor.sf.net/
Русскоязычный форум для её - http://forum.ru-board.com/topic.cgi?forum=5&topic=32945&start=0

Minoru комментирует...

2 morbo:
> можно записать проще
Да, не подумал об этом. Спасибо!

> авторы утилит - лисперы?
Может быть, может быть…


2 Анонимный
> Для обработки сканов перед кодированием есть прекрасная кроссплатформенная программы Scan Tailor
Я же в самом начале статьи сказал, что вопрос сканирования и обработки сканов рассматриваться не будет — я описываю конкретно процесс создания djvu.

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

Lazy_Kent комментирует...

Джентльмены, я сейчас делаю перевод djvusmooth на русский язык. Почти всё готово. Испытываю трудности со словами "Flatten" и "Pushpin".
Кто попользовался программой, подскажите, как лучше перевести.
И ещё: раздел "Outline" назвать "оглавление"?

deepweb комментирует...

при подготовке сканов хорошо себя зарекомендовал Scan Tailor, правда я делаю книги в оттенках серого или черно белыми, как он с цветом обращается не знаю

deepweb комментирует...

Улучшение качества DJVU книг
http://surrender-zen-way.blogspot.com/2010/02/djvu.html - pвконце есть скрипт сборки DJVU


Обработка сфотографированых/отсканированных страниц документов с помощью imagemagick
http://surrender-zen-way.blogspot.com/2009/07/imagemagic.html

Анонимный комментирует...

Не подскажут ли благородные Доны, почему созданные при помощи djvulibre мною djvu отлично смотрятся на линаксе и в (простите) уиндусе под WinDjview, но не в популярном DjVuReader'е. В нём наблюдается проблемка --- страницы перевёрнуты и отражены. В принципе, хрен бы с ним --- DjVuReader безнадёжно устарел, давно не поддерживается, а автор потерял исходники. Но интересует, почему только эти djvu? С остальными всё в порядке. Версия djvulibre --- 3.5.22-2.

Arkady комментирует...

Если надо быстро, много и грубо - вот этот скрипт. (У меня было порядка 300 статей, которые надо было превратить в djvu)

#Автоматизация создания djvu-файлов.
#Предполагается следующая структура каталогов
#Scans - корневой каталог. Scans/issuenumber - папка, в которой лежит скан статьи с номером issuenumber(можно любое название, но без пробелов)
#Scans/issuenumber/out - каталог, в котором лежат обработанные ScanTailor или ScanKromsator сканы в формате .tif с названиями *.tif
#Файлы сохраняются под именами issuenumber.djvu в Scans

!#/bin/sh
for dir in /home/arkady/Scans/* ; do
cd $dir/out ;
for file in *.tif ; do anytopnm $file | ppmtopgm > ${file%tif}pgm; done ;
for file in *.pgm ; do cpaldjvu -dpi 300 -colors 5 $file ${file%pgm}djvu; done ;
d=${PWD%/out} ;
d=${d#/home/arkady/Scans/} ;
djvm -c /home/arkady/Scans/$d.djvu *.djvu ;
echo created $d.djvu ;
rm *.pgm ;
rm *.djvu ;
done

monday2000 комментирует...

Спасибо за интересную статью!

Некоторые замечания:

- Процесс подготовки сканов под кодирование в DjVu слишком тесно связан с непосредственно созданием DjVu - так что его тоже имеет смысл освещать (Scan Tailor).

- Вместо cjb2 для кодирования в DjVu чёрно-белых сканов следует использовать хотя бы minidjvu. Но лучше всего DjVu Solo 3.1 в Wine запустить. Это уже проверялось на работоспособность под Linux.

- В статье не освещён Метод разделённых сканов при создании DjVu. Под Linux для этого существует готовый инструмент: http://www.djvu-scan.ru/forum/index.php?topic=96.0 .

- tesseract уже распознаёт русский язык.

- djvused уже умеет выдавать полностью человеко-читаемые файлы. Для этого там на днях введена опция -u. То есть вместо строки «\320\222\320\262\320\265\320\264\320\265\320\275\320\270\320\265» будут человеко-читаемые буквы.

- кому не нравится djvused, могут юзать бесплатные DjVu XML утилиты - эффект то же самый, но только через XML-файлы (ИМХО так удобней).

- Существует т.н. "конвейер" под Linux - см. http://www.djvu-soft.narod.ru/soft/all2djvu.htm .

- Есть ещё и ABBYY FineReader под Linux. См. http://ocr4linux.com/ . Можно им создавать OCR-слой в DjVu - находясь под Линуксом.

- Теоретически в природе существует коммерческий DjVu SDK в Линукс-версии - на Caminova.net . Но никто ещё никогда его не видел. Пока что в ходу лишь виндовые DjVu SDK.

- Главный вывод в том, что свободно-бесплатными инструментами хороший DjVu под Линукс можно сделать только посредством DjVu Solo 3.1 под Wine. cjb2 - это полный отстой. minidjvu - тоже не фонтан (хотя и много лучше).

- Если будет желание, заходите на мой форум http://www.djvu-scan.ru/forum/index.php - пообщаемся поконкретнее. Тема DjVu под Linux - это интересно.

Minoru комментирует...

monday2000, благодарю за содержательный комментарий! Сейчас поправлю соответствующие части статьи.

Про Scan Tailor я рассказывать не хотел потому, что в моём случае нужно было из уже готовых постраничных сканов (обработанных) сделать книжку, и пост как раз на этом и сосредоточен. Тем не менее, учитывая количество комментариев с упоминаниями Scan Tailor, я добавлю отсылку к нему в начало статьи.

Анонимный комментирует...

monday2000 уже упомянул о моем img2djvu ( https://github.com/ashipunov/img2djvu ), хотелось бы добавить, что главное, на мой взгляд, его достоинство -- это возможность комбинировать разные методы кодирования (два вида цветного, малоцветный и два вида черно-белого) в зависимости от типа изображения и указанных опций.
===
С уважением,
А. Шипунов

monday2000 комментирует...

Является ли требование использования свободно-бесплатных DjVu-программ под Linux обязательным?

Дело в том, что, как ни крути, а самое лучшее - это частично использовать пиратские версии коммерческих DjVu-программ. Хотя бы для создания чёрно-белого DjVu.

Но ещё в большей мере это относится к OCR-нию. К сожалению, никакой CuneiForm или Tesseract не сравнится с ABBYY FineReader (который сейчас есть уже прямо под Линукс).

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

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

DjVu Solo 3.1 - это, пожалуй, единственное исключение. Будучи легально свободно-бесплатной программой, она, тем не менее, даёт качество почти такое же, как и у коммерческих платных DjVu-кодировщиков.

Использовать cjb2 категорически несерьёзно. Да и minidjvu то же самое - если честно признаться. Самое правильное - отговаривать всех в статье от использования cjb2. А в качестве основного средства преподносить DjVu Solo 3.1 под Wine.

Анонимный комментирует...

Мне кажется, что не стОит рубить сплеча. Вот Вам пример: три файла из одних и тех же исходников -- http://rghost.ru/3292522 . Один сделан cjb2, другой сделан minidjvu, третий сделан documenttodjvu. В двух текстовый слой сделан cuneiform, в одном -- FR8. Угадайте, где какой ;-)

monday2000 комментирует...

> Мне кажется, что не стОит рубить сплеча.
Я думаю, Вы и сами понимаете, что один специально подобранный пример - это не показатель.

cjb2 ИМХО вообще нецелесообразно сравнивать с аналогами - поскольку он в принципе не использует словари разделённых символов при созданиии DjVu - а значит, заведомо хуже всех.

CuneiForm с Файнридером даже как-то грустно сравнивать. Слишком уж велика разница в мощности. Хотя, ИМХО у CuneiForm есть перспективы улучшения - я лишь на это рассчитываю (говоря о CuneiForm).

Анонимный комментирует...

Я не подбирал этот пример.

Анонимный комментирует...

если этот форум ещё жив - подскажите, пожалуйста, - как можно автоматизировать работу утилиты cpaldjvu. Мне необходимо следующее: у меня есть уже готовые к форматированию файлы PGM-формата. Мне нужно их "пакетом" перегнать в DJVU-формат. Команда #cpaldjvu -dpi 600 -colors 16 001_1L.pgm 001_1L.djvu работает для ОДНОГО файла. Пробовал написать следующее: #for file in *pgm; do cpaldjvu -dpi 600 -colors 16 $file > ${file%pgm}djvu; done - не работает. Прошу скрипты ПОЛНОЙ обработки не предлагать - мне нужно автоматизировать только один этап - перегонку из PGM в DJVU.

Minoru комментирует...

Это не форум, это блог :)

Вывод cpaldjvu никуда не нужно перенаправлять — программа принимает имя выходного файла последним параметром. То есть твой цикл должен выглядеть так:

for file in *.pgm; do cpaldjvu -dpi 600 -colors 16 $file ${file%pgm}djvu ; done

Unknown комментирует...

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

Minoru комментирует...

Blogger на меня обиделся и не пущал комментировать из-под родного гугловского аккаунта и Chromium. А сейчас, из Firefox, пустило. Страннота!

В общем, Никит, на выбор утилит для конвертирования повлиял мануал, на который я сослался в начале поста. Можно использовать и convert, конечно, но я не пробовал.

Murfen комментирует...

Спасибо большое за описание!
1. Для ч/б страниц, состоящих только из текста, у меня гораздо лучше результат получился командой:
convert -threshold 70% ИСХОДНЫЙ_ФАЙЛ ВЫХОДНОЙ_ФАЙЛ.pbm

2. Есть ряд страниц с текстом и иллюстрациями. Пытаюсь их кодировать программой cpaldjvu с 5 цветами - получается очень бледно, с 8 цветами - размер файла в 1,5 раза больше, чем исходный jpeg. Пытаюсь их же кодировать как цветные - комадной c44 - размер получается в самый раз. В чем магия?

Minoru комментирует...

Murfen, спасибо за комментарий! И прости, что задержал с ответом.

Что касается convert -threshold, тот значение тут зависит от сканов. Как уже сказано в статье, экспериментировать с величиной никто не запрещает.

По второму пункту — две цитаты из оглавления документации DjVuLibre:

> cpaldjvu — A DjVuDocument command line encoder for images with few colors. This encoder is well suited to compressing images with a small number of distinct colors (e.g. screen-shots). The dominant color is encoded by the background layer. The other colors are encoded by the foreground layer.

> c44 — A DjVuPhoto command line encoder. This state-of-the-art wavelet compressor produces DjVuPhoto images from PPM or JPEG images.

Если совсем вкратце, то ответом на твой вопрос будет «просто алгоритмы сильно разные». Если подробней, то cpaldjvu семь из восьми цветов загонит в передний слой, который в высоком разрешении — отсюда и резкий рост размера файла. О вейвлетах я подробностей не знаю, но, предположительно, они правильно раскладывают цвета по слоям и, как следствие, дают подходящий результат.

Из твоего опыта можно сделать вывод, что если нет времени возиться с подбором количества цветов, можно просто скормить все сканы c44.

Отправить комментарий

Примечание. Отправлять комментарии могут только участники этого блога.

 
Blogger logo Debian logo Creative Commons License FeedBurner Subscribers Counter