Программа DjVu Imager

[monday2000]

57an
Обратите внимание: суффикс "sep" уже нет необходимости добавлять вручную к файлам, получаемым из Scan Tailor. Нужно только в Опциях включить фильтр "Произвольные файлы" и выставить его в значение "Нет" (стоит по умолчанию). После этого можно открывать файлы без суффикса "sep".

[57an]

А без уничтожения этой крайне полезной фичи (я имею в виду вставку иллюстраций с кратным пиксельным размером) проблему совместимости с Djvu Reader 2.0.0.26 разве никак нельзя решить?
Дело в том, что как Вы знаете, разделенные сканы после СТ часто требуется подвергать дополнительной обработке - удалению растра, повышению контрастности. И если эти действия делать над 600dpi иллюстрациями, то вычислительных ресурсов требуется гораздо больше, чем если предварительно привести отделенные иллюстрации в разрешение сканирования (300 или, реже, 200dpi) и обрабатывать уже приведенные.
Тут уже простым ДЗФ никак не обойтись.

[monday2000]

57an
В принципе, можно. Но в том виде, как я это вижу сейчас, мне это крайне неудобно. Поясню: если допустить кратные иллюстрации - то кратность принять одинаковой для всех иллюстраций, или разной? Если разной - то мне это будет крайне муторно реализовывать. Представьте, первая - в 2 раза меньше, 2-я - в 3 раза меньше, в 3-я - в 4 раза меньше, и т.д.

Я ещё могу согласиться на одинаковую кратность. (Тогда я смогу обойтись лишь авто-установкой ДЗФ на эту кратность). Скажем, выяснять на самом первом скане, какая кратность, и, если все последующие сканы имеют точно такую же кратность, продолжать - иначе выход.
Проверка на размеры тогда останется - просто она будет делаться по формуле http://www.djvu-scan.ru/forum/index.php?topic=14.msg300#msg300 .

[57an]

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

[monday2000]

57an
Хорошо, я так сделаю (с единой кратностью).

Не совсем понял, при чем тут ДЗФ.

ДЗФ и кратность - это одно и то же. Смысл ДЗФ - уменьшить входные сканы до нужной кратности. А раз уж входные сканы уже уменьшены до какой-то кратности - тогда надо и в интерфейсе программы установить в регуляторе ДЗФ это значение кратности - иначе будет путаница, и потеряется возможность (при желании) ещё больше уменьшить (через ДЗФ) уже и так кратно-уменьшенные входные сканы.
ДЗФ удобен тем, что он позволяет "по месту" подобрать кратность уменьшения иллюстраций - пробуя при каждом шаге уменьшения, как это будет выглядеть в результате.

[57an]

Я пользовался ДЗФ. Только все равно не пойму - если я вручную уменьшу в 3 раза, то (из опыта) если я поставлю еще и ДЗФ = 3, то в результате получу уменьшение в 9 раз.
Т.е. как раз при вставке предварительно уменьшенных сканов галку ДЗФ нужно сбрасывать (при этом кратность пусть вычисляется программно по вышеприведенной формуле).

[monday2000]

Тут всё просто: кратность должна быть в пределах 1..12. Если входят уже, скажем,  3-кратные файлы, а ДЗФ (сейчас) поставить на 12 - то суммарная кратность будет уже 15 - что вызовет ошибку. При загрузке 3-кратных файлов ДЗФ (только в интерфейсе) будет (в будущей версии) отображаться со значением "3". Что будет означать, что имеем файлы с 3-ей кратностью.

Т.е. смысл ДЗФ немного изменится - он начнёт учитывать уже имеющуюся кратность (а сейчас ДЗФ это не делает). Это будет имитация загрузки полноразмерных сканов, которым пользователь сам выставил ДЗФ=3.

[57an]

Тогда может быть есть смысл при вставке полноразмерной иллюстрации определять ее dpi (и указывать в ДЗФ раз меньший)? Это проще, чем определять DPI для всех поддерживаемых графических форматов..

[monday2000]

57an

Тогда может быть есть смысл при вставке полноразмерной иллюстрации определять ее dpi

Это было бы вообще неверно. Не путайте ресемплинг и ресайзинг. В этой ситуации надо, чтобы именно пиксельные размеры были определёнными. ДЗФ делает именно ресемплинг (т.е. изменяет количество реальных пикселей), а не ресайзинг (изменение значения DPI).
DPI - это просто число в заголовке графического файла, и всё. DPI - это абстракция, нужная для вычисления другой абстракции - линейных размеров скана (в сантиметрах) - т.е. площади отображения на экране/принтере. Реально скан характеризует только реальное количество пикселей в нём.

Это проще, чем определять DPI для всех поддерживаемых графических форматов..

Поскольку я использую в DjVu Imager библиотеку FreeImage, то она абстрагирует все поддерживаемые графические форматы к своему внутрибиблиотечному типу FIBITMAP. Так что получить что DPI, что пиксельные размеры одинаково просто.

[57an]

ДЗФ делает именно ресемплинг (т.е. изменяет количество реальных пикселей), а не ресайзинг (изменение значения DPI).

Вот именно. В результате ресемплинга пиксельные размеры уменьшаются. Если не подправлять DPI, получим соответствующее уменьшение физических размеров, и, как следствие, скачки размеров страниц в просмотрщике http://www.djvu-scan.ru/forum/index.php?topic=14.msg317#msg317.

[monday2000]

Новая подверсия:

DjVu Imager v2.5

http://www.djvu-soft.narod.ru/soft/djvu_imager_v2_5.rar  (1,17 МБ)

Исходники:

http://www.djvu-soft.narod.ru/soft/djvu_imager_v2_5_src.rar  (77 КБ)

Что нового:

Модифицирована проверка равенства пиксельных размеров вклеиваемой иллюстрации и соответствующей ей обклеиваемой DjVu-страницы. Теперь допускаются заведомо субсемплированные входящие иллюстрации (но их размеры тоже проверяются на правильность - по формуле из csepdjvu).

Кстати, вот эта формула: http://djvu.cvs.sourceforge.net/viewvc/djvu/djvulibre-3.5/tools/csepdjvu.cpp?revision=1.29&view=markup линия 1080 и 1081. (И проверку я взял именно оттуда).

Я решил пойти простым путём и не делать задуманное авто-определение общей для всей DjVu-книги кратности (с последующей авто-установкой ДЗФ). Это оказалось довольно сложно реализовать (учитывая тот факт, что пиксельные размеры DjVu-страниц в общем случае вовсе не постоянны от страницы к странице, а также моя функция авто-определения номеров иллюстраций в общем случае не обязана всегда гарантированно давать 100% правильность работы).

Таким образом, теперь, если пользователь подаёт на вход программы заведомо субсемплированные иллюстрации (с некоей кратностью), то, в случае использования ещё и ДЗФ, реальное ДЗФ (или кратность, что то же самое) будет (во время вставки) больше на входящую кратность иллюстраций. И это реальное ДЗФ также должно быть в пределе 1..12 (иначе программа сейчас уже не пропустит иллюстрации на вклейку).

И ответственность за корректный выбор ДЗФ в такой ситуации будет ложиться на пользователя (я хотел это сделать программно - но, как я показал, это оказалось уж слишком трудоёмко реализовать).

[monday2000]

Вот именно. В результате ресемплинга пиксельные размеры уменьшаются. Если не подправлять DPI, получим соответствующее уменьшение физических размеров, и, как следствие, скачки размеров страниц в просмотрщике

Не понял я это. Если будет такой глюк снова - сообщите. Но, думаю, вряд ли такой глюк снова возникнет. Программа вообще игнорирует DPI вклеиваемой иллюстрации - в результирующий DjVu попадает (или можно сказать - остаётся) DPI обклеиваемой DjVu-страницы.

Кстати, выяснилось, что в получаемом DjVu вклеенная субсемплированная иллюстрация так и хранится в субсемплированном (т.е. уменьшенном) виде. А DPI чанков заднего фона, которое отображается в WinDjView по правой кнопке мыши на странице - Информация о странице не хранится в DjVu, а вычисляется "на лету" путём деления DPI INFO-чанка на фактор субсемплирования.

Это стало очевидным из опыта применения djvudpi.

[monday2000]

Леон Боту прислал мне ответ на мой запрос относительно проблемы с файлом bad.djvu http://www.djvu-scan.ru/forum/index.php?topic=14.msg397#msg397 :

You can correct the file by using djvmcvt twice:
once to make it an indirect,
and back to a bundled file.

The problem was caused by two extra bytes after the first page.
Viewers can show the pages because the DIRM offsets were correct.
But the overall IFF structure of the file was wrong at this point.

In addition something else was wrong in the first page length.
Somehow the length record in the DIRM chunk does not match
the one declared in the IFF structure. I cannot see how this can happen.
Maybe there is something wrong with your single page iw44 only djvu.

- L.

То есть, все проблемные DjVu-книги, обработанные старыми версиями DjVu Imager - а именно такие, которые не открываются в DjVu Reader 2.0.0.26 (или отображаются там с перевёрнутыми-отзеркалированными страницами), можно исправить. Для этого нужно сделать 2 вещи:

1. Обработать их (проблемные DjVu-книги) посредством djvufixrotate http://www.djvu-scan.ru/forum/index.php?topic=14.msg393#msg393 (исправление перевёрнутости).

2. Распаковать-собрать их при помощи djvmcvt (по подсказке Леона) (исправление не-открываемости, вызывающей ошибку-исключение при открытии).

Также я на своём сайте постарался разместить в соответствующих местах информацию о том, что DjVu Reader 2.0.0.26 устарел, и вместо него следует использовать WinDjView.

[monday2000]

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

http://djvu.cvs.sourceforge.net/viewvc/djvu/djvulibre-3.5/tools/csepdjvu.cpp?revision=1.29&view=markup линия 1080 и 1081

должна быть встроена в СК и СТ, а также во все иные программы-посредники между СТ (СК) и DjVu Imager. Пока что этого явно не наблюдается.

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

[57an]

и программы-посредники

Обязательно учту, если буду добавлять функцию субсемплирования в Separator. Пока что учитываю при пакетном субсемплировании посредством FS ImageViewer.
Авторам СТ и СК эта формула известна.