Вернуться к разделу "Материалы по сканированию и оцифровке бумажных книг".
Автор: Rainhaart.
Для обзора взята версия программы 7.1.0.20397, полученная на сайте www.caminova.net. Там ее можно скачать, как trial-вариант.
Как можно увидеть из названия, разработчик седьмой версии линейки DjVu Document Express — это уже не Lizardtech, а Celartem (Celartem Technology, Inc). Именно к ней недавно перешли права на формат DjVu и все, относящееся к нему.
Это японская компания, со штаб-квартирой в Токио, занимающаяся технологиями, связанными с хранением и распостранением медиаконтента, в частности ведущая работы в области сжатия изображений и их масштабируемого просмотра.
Объем дистрибутива — примерно 190 Мб. В него входят файлы:
Аппаратные потребности (заявленные разработчиком):
В связи с рекомендациями по аппаратной части сразу небольшой комментарий:
| Затрудняюсь сказать
какими соображениями руководствовались те, кто
писал аналогичные рекомендации для предыдущих
версий DjVu-компрессоров, однако все, что мне
встречалось на эту тему, было именно минимальными
комплектациями компьютеров. Если исходить из
обычных рабочих потребностей DjVu-компрессоров, то
предлагаемых конфигураций, должно было хватить
ровно-ровно на то, чтобы запустить очередную
программу и полюбоваться видом ее рабочего окна.
На какую-либо работу можно было и не
рассчитывать. Если в седьмой версии подобная “традиция” по-прежнему продолжается (а судя по предлагаемому комплекту железа, на это очень похоже), то для сколь-либо нормальной работы рекомендованные цифры надо, как минимум, удвоить-утроить. |
Document Express 7 Enterprise устанавливается на Windows XP и более старшие версии. Для работы требует .NET Framework версии 3.5. В состав рассматриваемого дистрибутива файлы .NET Framework не входят, так что, при необходимости, их надо скачать с сайта Микрософт и установить.
Как уже было сказано, для работы (а значит и для инсталляции) в системе должна быть установлена .NET Framework 3.5. Какой именно вариант версии 3.5 — без Service Pack или с ним — для установки Document Express 7 Enterprise похоже безразлично, ставится и так, и так.
(Сам инсталлятор .NET Framework 3.5 в процессе работы непременно лезет в Сеть, чтобы оттуда что-то скачать. Если на машине нет выхода в Сеть, то делает пять попыток “дозвона”, на этом успокаивается и продолжает установку в обычном порядке.)
В процессе установки инсталлятор требует ввода серийного номера. Но при этом сам же генерирует номер для trial-периода.
Ещё он требует, чтобы ему непременно указали логин и пароль для любой учетки с правами администратора. Если их не ввести, то отказывается продолжать установку дальше. По всей видимости это необходимо для каких-то чисто технических надобностей, поскольку никаких видимых последствий от этой операции в дальнейшем не наблюдается.
Приятным отличием DEE 7, от многих других программ можно считать то, что trial-период здесь определен в два месяца. Во всяком случае, программа, установленная 6 ноября, при каждом очередном запуске уведомляет, что будет работать до 5 января.
Во время установки создает следующие папки:
В состав программы входят следующие модули:
1. Document Express 7 Enterprise Configuration.
Создает графический интерфейс для работы command-line утилит, составляющих рабочую основу Document Express 7 Enterprise. Обеспечивается исполняемым файлом djvuwatch.exe
2. Command-line утилиты.
Они служат для преобразования графики различных форматов в DjVu и других операций с DjVu-файлами. Сюда входят:
3. DjVu Profile Editor.
Создает графический интерфейс для редактирования и сохранения всего комплекта настроек программы. Обеспечивается исполняемым файлом profedit.exe.
4. DjVu Virtual Printer.
Виртуальный принтер для преобразования в DjVu файлов основных документальных форматов — .DOC/.DOCX, .XLS/.XLSX, .PPT/.PPTX и .PDF.
Устанавливается в системе, как еще один принтер. Работа управляется через command-line утилиту VPDAdmin.exe и модуль графического интерфейса DjVuPrintConverterUI.exe.
5. PDF to DjVu.
Преобразование в DjVu PDF-файлов. Обеспечивается исполняемым файлом pdftodjvu.exe
6. OCR.
Распознавание изображений, содержащих текст. Обеспечивается исполняемым файлом ocr32host.exe.
Что нового в программе
Если смотреть с точки зрения разработчика,
Celartem, то имеем:
1. Новый, заметно переписанный, движок DjVu-компрессора.
2. Поддержка системы Windows-служб. Один из модулей Document Express 7 Enterprise (djvuwatchsvc.exe) теперь запускается как служба.
3. Введение т.н. Secure DjVu Support, то есть возможности закрывать работу с DjVu-файлами на пароль, с различными уровнями прав и доступа.
4. Полная поддержка Microsoft Office 2003/2007.
5. Поддержка системы Windows Event Log.
6. Поддержка 64-битных ОС.
7. Дополнение модуля редактирования настроек возможностью сразу проверить работу новых настроек на тестовом изображении, выводимом в окне редактора настроек. (Если быть точным, то что-то аналогичное существовало и в предыдущей версии, DEE 5.1. Почему Celartem заявляет этот момент, как новинку — не очень понятно.)
Если же смотреть с точки зрения пользователя, то:
1. Вместо прежнего режима “указываем пакет изображений и сжимаем их” программа теперь работает как “сторож” (watch). Есть целевая папка (watch folder), все, что в ней оказывается, отслеживается и немедленно преобразуется в DjVu-файл, в соответствии с заданными настройками.
2. Практически полностью переписаны названия профилей сжатия (presets), используемых в программе. От той системы именования, что использовалась в предыдущих версиях DjVu-компрессоров, оставлены только два-три пункта. Да и то совершенно не факт, что в них используются те же самые настройки сжатия, что и раньше.
Так что в логике работы имеющегося в DEE 7 комплекта профилей похоже придется разбираться практически с нуля.
3. Система настроек, сравнительно с предыдущей версией (DEE 5.1), заметно упрощена м сведена в одно общее окно.
4. Настройки, связанные с преобразованием PDF—>DjVu, теперь можно не только просматривать, но и редактировать. В DEE 5.1 не было предусмотрено ни того, ни другого - лишь выбор одного из нескольких профилей.
5. Встроенный в программу OCR-движок, судя по имеющимся в его окне настройкам, теперь можно применять не только к DjVu-файлам, но и к PDF. А также к продукту работы DjVu Virtual Printer.
6. В настройках программы появилась закладка, позволяющая создавать в качестве выходного файла не только DjVu, но и PDF (причем для PDF обещается уровень сжатия, сравнимый с DjVu).
Для графических форматов: JPEG (.jpg), TIFF 6.0 (.tif), GIF, PNG, Bitmap (.bmp) HD Photo (.hdp, .wpd), Icon (.ico).
Для документальных форматов: PDF, Microsoft
Word 2003/2007 (.doc, .docx), Microsoft Excel 2003/2007 (.xls, .xlsx), Microsoft Power
Point 2003/2007 (.ppt, .pptx).
В том, что касается документов Microsoft Office сделана
оговорка: в данной версии поддерживаются только
английская и японская локализации.
Что будет происходить при попытке преобразовать в DjVu документ из других “локалей” — пока не очень понятно. Есть ли версии с полной поддержкой всех “локалей” — тоже неясно.
Максимальный размер входного изображения оставлен тем же, что и в предыдущих версиях — 32 767 х 32 767 пиксела.
При этом делается оговорка, что данный размер надо воспринимать скорее как “теоретический” предел для возможностей формата DjVu. На практике же, из-за потребностей в больших объемах виртуальной памяти при сжатии цветных изображений, рабочим пределом можно считать 18000x18000 пикселов.
Для распознавания текста используется движок от IRIS (Image Recognition Integrated Systems S.A.). Версия движка относительно новая, библиотеки датированы 2008 годом.
В отношении технической поддержки в Help обнаружена интересная фраза: “Your Celartem product comes with complimentary technical support for 30 days from the date of purchase”.
Если принять вариант перевода “complimentary technical support” = “бесплатная техническая поддержка”, то получается что-то совсем любопытное. :-)
Для тех, кто уже работал с различными версиями DjVu-компрессоров, основное рабочее окно DEE 7 (сокращенно DEE 7) будет иметь непривычно аскетический вид. По сути это просто текущий список задач или точнее список папок, которые надо контролировать на предмет появления в них чего-либо подлежащего сжатию. Подобное обычно называется watch folder.
В default-режиме редактирование рабочих настроек невозможно — программа висит в памяти и ждет “добычи” в контролируемых папках. Чтобы получить возможность что-то менять, надо предварительно нажать кнопку “Stop”.
После ее нажатия становятся активными кнопки “Add...”, “Edit...”, “Delete”, “Clean”.
“Add...” позволяет добавить новый watch folder и выставить необходимые настройки для сжатия материалов, которые будут в него попадать. “Edit...” позволяет изменить настройки для одного из уже имеющихся watch folder. Обе кнопки вызывают одно и то же окно.
“Delete” удаляет выбранный watch folder, а “Clean” делает очистку всей структуры используемых папок от служебных файлов (когда и если эти файлы не удалены в ходе процесса самой программой).
Рис. 1. Основное окно для работы с заданиями
Структура окна “Add/Edit Watch Folder” достаточно проста для интуитивного понимания.
Здесь задаются пути ко всем рабочим папкам (“Base Folder”, “Watch Folder”, “Output Folder”, “Error Folder”, “Move Folder”) и устанавливаются настройки конвертирования. Настройки можно задать сокращенным образом, просто выставив один из уже имеющихся профилей и разрешение сжатия, а можно в полном объеме, через кнопку “Configure”.
Структура папок легко понимаема из их обозначений:
“Base Folder” — основная папка для работы с Document Express 7 Enterprise. В ней расположены все остальные рабочие папки.
“Watch Folder” — место куда должны складываться изображения для обработки. Все, что сюда попадает незамедлительно (причем без каких-либо окошек с запросами) обрабатывается, в соответствии с имеющимися настройками.
“Output Folder” — здесь создаются выходные DjVu-файлы.
“Error Folder” — сюда перемещаются изображения, которые программа по каким-то причинам не в состоянии обработать и сжать в DjVu-файл.
“Move Folder” — сюда перемещаются уже обработанные изображения.
Для каждой из перечисленных папок можно принять тот путь, который DEE 7 генерирует сам, когда указывается изначальная папка “Base Folder”, а можно задать любое другое место.
Еще в структуре рабочих папок существует не отмеченные в настройках:
- <Base Folder>\log — создается достаточно
подробный журнал процесса сжатия;
- <Base Folder>\temp — для временных файлов,
создаваемых в процессе обработки.
Рис. 2. Окно настроек для текущего watch folder
Кнопка “Configure” в “Add/Edit Watch Folder” открывает окно “Detail Setting” с восемью закладками для регулирования всего, что в программе вообще можно настраивать. В нем имеются следующие блоки настроек:
- закладка “Multipage” — позволяет указывать как будут упаковываться исходные изображения после сжатия — все исходные изображения в один конечный DjVu-файл или же каждое изображение в самостоятельный файл. Также здесь можно задавать имена генерируемым DjVu-файлам, причем как напрямую, так и через маску;
Рис. 3. Окно 'Detail setting', закладка 'Multipage'
- закладка “Parameters” — здесь должны регулироваться все моменты, связанные с процессом обработки изображений и получения из них DjVu-файлов. Однако же возможностей что-то настроить в этом окне не так чтобы много. Фактически можно всего лишь выбрать один из заранее заданных профилей, после чего в окошках “Subsample” и “Quality” появляются соответствующие данному профилю значения для слоев Background и Foreground.
Каков точный рабочий смысл настроек “Subsample” и “Quality”, не очень ясно. В Help сколь-либо вразумительных комментариев тоже не имеется.
Основной объем настроек становится доступными только, когда нажмешь на кнопку “Configure”;
Рис. 4. Окно 'Detail setting', закладка 'Parameters'
- закладка “OCR” — здесь можно задать настройки, регулирующие процесс распознавания обрабатываемых изображений (когда и если там имеется что-то пригодное для распознавания);
Рис. 5. Окно 'Detail setting', закладка 'OCR'
- закладка “VPD” — здесь можно установить будет или не будет создаваться текстовый слой (searchable text) в выходных продуктах DjVu Virtual Printer;
Рис. 6. Окно 'Detail setting', закладка 'VPD'
- закладка “PDF” — в ней задаются настройки по преобразованию PDF в DjVu;
Рис. 7. Окно 'Detail setting', закладка 'PDF'
- закладка “Security” — в ней, при необходимости, можно выставить установки, тем или иным способом ограничивающие доступ к созданным DjVu-файлам. Предусмотрено паролирование операций по копированию, сохранению частей DjVu-файла и его распечатке, а также ограничение срока общего доступа (expiration time) к файлам;
Рис. 8. Окно 'Detail setting', закладка 'Security' - 1
Рис. 9. Окно 'Detail setting', закладка 'Security' - 2
- закладка “Print Header/Footer” — здесь можно задать формирование колонтитулов, текст которых в создаваемом DjVu-файле будет накладываться на исходные изображения;
Рис. 10. Окно 'Detail setting', закладка 'Print Header/Footer' - 1
Рис. 11. Окно 'Detail setting', закладка 'Print Header/Footer' - 2
- закладка “Output” — позволяет сжимать изображения не только в DjVu, но и в PDF. Правда, в отличие от DjVu, сжимать получается только в режиме “одно изображение на входе — один PDF-файл на выходе”. Есть ли где-нибудь в программе переключение на создание многостраничных PDF-файлов — пока неясно.
Сжатие в PDF, судя по настройкам, можно выполнять двумя способами — или в соответствии с настройками создания самих DjVu-файлов и по аналогичной логике (Надо думать здесь подразумевается одна из разновидностей технологии MRC (Mixed Raster Content, растровое содержимое смешанного типа)), или по отдельно задаваемым настройкам в виде командных ключей.
Рис. 12. Окно 'Detail setting', закладка 'Output'
Кроме этого, как уже упоминалоось, на закладке “Parameters” можно нажать кнопку “Configure” и получить доступ к рабочему окну DjVu Profile Editor. В нем собраны все настройки, связанные с процессом преобразования исходных изображений в DjVu-файл (анализ, разделение на слои и сжатие).
Рис. 13. Окно 'Profile Editor'
Document Express 7 Enterprise по своей внутренней организации и логике работы является логическим преемником другого DjVu-компрессора — Document Express Enterprise 5.1 (сокращенно DEE 5.1). Поэтому будет вполне логичным анализировать его работу в сравнении именно с DEE 5.1.
Прежде всего бросается в глаза разница в подходе к организации процесса обработки изображений.
Версия DEE 5.1 фактически была наиболее вдумчиво оптимизированным вариантом классического DjVu-компрессора, этакой квинтэссенцией подхода “быстро и эффективно сжать множество изображений”. Соответственно было построено и “рабочее место” — указать папку, из которой надо брать изображение, указать папку, куда класть готовый DjVu-файл, указать настройки обработки, разместить сформированное рабочее задание в общем потоке обрабатываемых изображений, запустить его в работу.
Версия DEE 7 сохранила все заложенные в DEE 5.1 возможности, однако теперь она ориентирована на несколько иной круг дел — отслеживание некоей целевой папки (по-английски — watch folder) и автоматическое сжатие всего, что там появляется. Или же отслеживание не одной такой папки, а набора из нескольких.
Обычно подобное делается, как один из типовых этапов поточной оцифровки больших объемов печатных материалов — со сканера/сканеров поступают изображения, они автоматом складываются в папку/папки, оговоренные технологической схемой, оттуда автоматом же преобразуются программой-“сторожем” (в данном случае — Document Express 7 Enterprise) в некий “конечный продукт” или же в полуфабрикат для следующей технологической операции.
Чтобы быть совсем уж точным, надо сказать, что режим отслеживания заданной watch folder существовал и в версии DEE 5.1. Но там это было просто одной из возможных разновидностей режимов работы, а в DEE 7 стало основной целевой функцией.
Различие в целевых функциях обеих программ определило и различия в организации основного рабочего окна каждой из них.
В DEE 5.1 интерфейс выполнен по принципу “просто, удобно и с минимальными затратами времени сформировать рабочее задание на сжатие изображений”.
Рабочее окно состоит из трех основных закладок (Есть еще и четвертая, но она не столько для настроек, сколько для отслеживания процесса работы) — “Workflow”, “Input”, “Output”. На каждой из них пункты настроек, связанные с данной областью работы, регулируемые независимо друг от друга (что особенно существенно для “Input” и “Output”), с возможностью запомнить последнее состояние и другими удобными мелочами, облегчающими поточную работу.
В DEE 7, судя по компоновке интерфейса, подход был несколько другой — большую часть времени работа должна происходить без вмешательства оператора, по имеющимся настройкам, но если требуется что-то изменить, то это надо сделать быстро и с минимумом “телодвижений”.
Соответственно, основное рабочее окно выполнено в минималистской манере — список отслеживаемых папок, включение и отключение режима “сторожа”, кнопки “Добавить”, “Редактировать”. Вся остальная работа вынесена в дополнительно вызываемые окна, тоже организованные в иерархической манере “более частые операции — на верхних этажах вызовов, более редкие — на нижних, по нисходящей”.
Какие получаются из подобного подхода удобства, вполне понятно — сидим в трее, никого не беспокоим, сторожим и перевариваем “добычу” в контролируемой папке.
Какие получаются неудобства — понятно не сразу, а только после некоторого объема работы. Но тоже таки возникают.
Во-первых, здесь нельзя, как раньше, сформировать большой блок заданий с различными настройками сжатия в каждом задании и запустить его разом в обработку (В DEE 5.1 такая возможность была очень неплохим подспорьем, когда требовалось перевести в DjVu большой объем литературы. Формируешь сколь угодно длинный список заданий, определяешь каждому свои настройки, затем разом отправляешь его в обработку и спокойно занимаешься своими делами. Программа, закончив с одним заданием, сама переходит к следующему и так до полного исчерпания списка.).
Содержимое каждого watch folder будет обрабатываться только с данными конкретными настройками, пока их не перепишешь. Можно конечно создать на N запланированных заданий столько же разных watch folder, в каждый класть соответствующие изображения, устанавливать настройки и т.д., но в целом получается более громоздко и неудобно, чем в DEE 5.1.
Во-вторых, интерфейс основного окна организован так, что во время работы нельзя посмотреть текущие настройки сжатия (когда и если в том возникает необходимость). Чтобы получить доступ к настроечной части обязательно надо нажать “Stop”. В DEE 5.1 для этого всего лишь требовалось перещелкнуть рабочее окно программы в соседнюю закладку, что разрешалось даже во время запущенного процесса сжатия (просто все кнопки становились неактивными).
Из необходимости иногда нажимать кнопку “Stop” возникает еще одно неудобство —остановить работу этой кнопкой можно лишь тогда, когда программа закончила обрабатывать текущее содержимое watch folder. Если пытаться до того, то сколько ни нажимай, будет висеть в памяти и досчитывать остаток изображений. В этом случае можно вмешаться только через Диспетчер задач (удалить процесс djvuwatchsvc.exe).
Из неудобств общих и для DEE 5.1, и для DEE 7 можно отметить то, что в интерфейсе обоих не предусмотрено никакого подобия прогресс-индикатора. В результате можно только догадываться о том, в какой стадии находится сжатие изображений и сколько еще времени осталось до его завершения.
В DEE 5.1 с отмеченных для сжатия заданий хотя бы исчезали галочки (когда их содержимое оказывалось полностью обработано), а здесь и того нет — галочка на watch folder будет стоять пока ее сам не снимешь. Разве что открыть Проводник и смотреть на убывание файлов в папке.
1. Большой расход виртуальной памяти при обработке цветных и “серых” (Grayscale) изображений.
К сожалению, в седьмой версии положение дел не изменилось. Как раньше процесс обработки изображений этих типов мог потребовать объема виртуалки 5-6-7 крат, сравнительно со сжимаемым изображением, так и здесь требует.
По-видимому переделка движка, производимая разработчиками Celartem, до этого момента еще не добралась.
2. Если в DjVu-компрессоры, начиная от Solo и кончая DEE 5.1, попытаться за один раз загрузить файлы, количеством больше 550-570-600 штук, то они подобные объемы совершенно не переваривали. Загрузка изображений или просто не происходила, или компрессор в ответ на попытку выдавал какое-нибудь аварийное окошко.
Рис. 14. DEE 5.1. Error-окошко в связи с превышением критического количества загружаемых файлов.
В седьмой версии проблема похоже снялась сама собой, поскольку за один раз обрабатывается один файл. Во всяком случае те книги, которые из-за их объема раньше можно было конвертировать в DjVu только по частям, здесь можно обрабатывать целиком и за одну загрузку.
3. Если в сжимаемом ч/б (Bitonal) изображении были большие области, залитые черным цветом (бинаризированные фотографии, штриховые рисунки и т.д.), то многие DjVu-компрессоры отказывались сжимать подобную графику и выдавали разнообразные ошибки.
Не буду утверждать, что эта проблема полностью ликвидирована (для этого требуется проверка на достаточно большом объеме изображений), но все имеющиеся у меня ч/б файлы, на которые раньше выдавались отказы, теперь переводятся в DjVu без проблем.
Честно говоря, для оценки сравнительного качества сжатия изображений этих типов требуется более обстоятельная работа, чем вот такой беглый обзор. При сравнительном анализе необходимо учитывать и получаемые объемы DjVu-файлов, и качество сжатого изображения, соотносительно с оригиналом, и качество разделения исходного изображения на отдельные слои и еще некоторое количество привходящих обстоятельств.
Но если ограничиться только общей оценкой, то можно сказать, что в седьмой версии пока не заметно каких-либо особо радикальных изменений, по сравнению с предыдущими DjVu-программами.
Если мы будем брать исходные изображения различных типов и сжимать их в DEE 5.1 и в DEE 7 так, чтобы на выходе получались DjVu-файлы примерно одинакового размера, то можно увидеть что для каких-то разновидностей изображений качество получаемого DjVu будет немного лучше в DEE 5.1, для каких-то немного лучше в DEE 7.
На каких-то разновидностях графики DEE 7, при примерно одинаковом качестве сжатого изображения, дает несколько меньшие объемы, а на каких-то идет вровень со своими предшественниками.
Где-то качество разделения на слои лучше у DEE 7, а
где-то у предыдущих DjVu-компрессоров. И так далее и
тому подобное.
Единственное что пока можно более или менее
точно сказать о седьмой версии — это заметно
улучшившееся качество бинаризации (выделения из
исходного изображения структур, относящихся к
слою Mask).
Существуют разновидности изображений, которые традиционно доставляют DjVu-компрессорам заметно больше проблем с точки зрения качественного сжатия. А если точнее, с точки зрения аккуратного разделения на отдельные слои. Как правило, это гравюрные и штриховые рисунки с большим объемом мелкой деталировки, сложные и насыщенные деталями карты и цветные чертежи, а также страницы книг старых изданий, со шрифтами и полиграфией не очень высокого качества.
Так вот, к несомненному достоинству DEE 7 можно отнести то, что изрядная часть изображений, которые предыдущими версиями сжимались с огрехами и искажениями, заметными даже при беглом просмотре, здесь обрабатываются куда более качественно. А полученные из них DjVu-файлы при просмотре выглядят более естественно.
С этим типом графики пока что наблюдается не очень понятная странность. Во всех изображениях, протестированных на седьмой версии, DjVu-файлы из них стабильно получаются заметно более “рыхлыми”, чем в том же DEE 5.1. Причем “заметно более” может выливаться в разницу объемов DjVu-файлов до двух раз.
Для сравнения выбирались DjVu-файлы самого маленького размера, который только можно было получить в данном компрессоре из исходного изображения, при переборе всех имеющихся preset’ов.
Сначала возникло естественное предположение, что причина в неудачном выборе сканов для тестирования. Для более тщательной проверки было взято шесть книг с заметно различным качеством сканирования (от сделанных более или менее прилично, до откровенно некачественных) и с достаточно большим разнообразием содержимого (обычный текст, рисунки, фотографии, формулы, чертежи и диаграммы, сложная верстка и т.д.). Плюс к тому, одна из книг была проверена во всех основных профилях сжатия, которые имеются в DEE 7.
Но и при такой расширенной проверке сохранилась та же самая закономерность - версия DEE 5.1 стабильно давала большую (а иногда заметно большую) степень сжатия, чем DEE 7. При том, что в обоих случаях качество изображения в получаемом DjVu-файле было практически одинаковым. Мелкие отличия, незаметные при обычном просмотре страниц, можно было обнаружить только при увеличении до масштаба 1:1.
Предположение, что разработчики из Celartem пошли на сознательное ухудшение DjVu-сжатия, выглядит, мягко говоря, странноватым :-). Поэтому причиной полученных результатов я пока что склонен считать какие-то собственные ошибки, связанные с непониманием деталей работы программы.
Но в чем они могут быть - не очень понятно,
поскольку выполнялись достаточно рутинные
операции уровня “зайти в настройки, выбрать
профиль сжатия такой-то, загрузить в watch folder
изображения, запустить сжатие”.
Какие еще обнаружены детали, существенные для
работы?
При сжатии пакета изображений (например
отсканированной книги) в многостраничный
DjVu-файл, страницы книги, по не очень понятным
причинам, меняются местами.
Выглядит это так. Исходные изображения в папке сложены как обычно, в порядке нумерации страниц — 1,2,3,4,5,6, ... N. Это легко проверяется просмотром через любую программу-viewer. Но вот в DjVu-файле, полученном на выходе из DEE 7, эти же страницы будут в хаотично перетасованном состоянии. Например 1,2,6,4,3,5, ... N.
Причина такого пока непонятна. Общая ли это закономерность или мне просто не повезло с использованными для тестов сканами — тоже неясно. Но во всех шести книгах, использованных для тестирования, дело обстоит именно так.
Если смотреть структуру DjVu-файла, сгенерированного седьмой версией, в окошке “Document Properties”, то видно, что вместо прежнего набора суб-файлов (cуб-файлом здесь называется отдельный модуль DjVu-файла (в терминологии формата это будет “chunk”), включающий в себя или одну из страниц, или словарь сжатия) *.djvu, пронумерованных по порядку страниц, плюс вклинивающихся между ними суб-файлов *.djbz (словари сжатия), он состоит из файлов *.iff, по числу сжимаемых изображений. При этом, вместо прежней порядковой нумерации, каждый iff-файл обозначается сложной комбинацией букв и цифр.
Например, 1248b5c6-3478-4622-8a64-8945830e5091.iff, d8dc0538-597b-46ac-8067-53833231897c.iff или 34533372-4e2d-4171-8c23-d12dec28106d.iff.
Чтобы что-то говорить точно, надо сравнивать
логи процесса сжатия у каждой версии компрессора
для одних и тех же входных изображений. Но, чисто
на глаз, работать стало несколько быстрее.
В завершении об одной особенности версий 5.1 и 7.0,
которая меня уже давно не перестает забавлять. :-)
Все консольные программы, выполняющие основную работу, и там, и там написаны на С++. Это легко проверить заглянув в текст программ, где можно найти отсылки к файлам *.cpp. Однако же одна-две программы, которые обеспечивают исключительно интерфейс управления (т.е. являются не более чем GUI-оболочкой, front-end), сделаны на .NET, причем обязательно в “самой наипоследнейшей версии” этой самой .NET.
Может с точки зрения программистов такой кунсштюк чем-то и обоснован, но для человека непосвященного, вроде меня, выглядит чем-то вроде “вы не думайте, мы не совсем от парижской моды отстали - вот тоже умеем”. :-)
Оригинал статьи в формате DOC (164 КБ)
Автор: Rainhaart.
Подготовил: monday2000.
17 февраля 2010 г.
Обсудить данную статью можно на форуме здесь (требуется регистрация).
E-Mail (monday2000 [at] yandex.ru)
