Программа DjVu Imager

[57an]

По поводу программы Djvu Sep.
Поясните здесь что ли, отличается ли Djvu Imager от Djvu Sep, или второе - просто устаревшая версия первого..
Боюсь, народ начинает путаться.
Из ее хелпа вообще непонятно, чем она занимается:

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

Если программа устарела, то не пора ли вообще исключить ее из списка программ на Вашем сайте, оставив ремарку в комментарии к Djvu Imager, что, мол, программа является развитием утилиты Djvu Sep?

[monday2000]

57an

оставив ремарку в комментарии к Djvu Imager, что, мол, программа является развитием утилиты Djvu Sep?

А я такую ремарку поставил тут (на днях): http://www.djvu-soft.narod.ru/scan/djvu_sep.htm . Просто, т.к. я это сделал на днях, народ ещё не заметил этого.
Хорошо, поставлю такую ремарку ещё и сюда: http://www.djvu-soft.narod.ru/scan/djvu_imager.htm

Из ее хелпа вообще непонятно, чем она занимается:

Да, она действительно гораздо более мудрёная, чем DjVu Imager, и более неудобная во всех смыслах. Сейчас глянул - действительно, на фоне наличия DjVu Imager, дока http://www.djvu-soft.narod.ru/scan/djvu_sep.htm уже кажется непонятной. Я её подправлю - чтобы было точно ясно, чем отличается DjVu Sep от DjVu Imager. Отличие простое:
DjVu Sep берёт пары субсканов, и превращает каждую такую пару в одностраничный DjVu. Затем тупо вставляет такой одностраничный DjVu между страницами другого, многостраничного DjVu-файла (при помощи djvm). Так и достигается иллюстрирование. Теперь это кажется уже ужасной тупостью. Но по-другому тогда ещё никак не умели.

то не пора ли вообще исключить ее из списка программ на Вашем сайте

Да пусть будет - для истории. 

P.S. Я же планирую сделать свой вариант "Сепаратора". Соответственно, и доку к нему напишу, и статью об его использовании. Тогда уж, думается, путаница и исчезнет полностью. Ах, если бы Tulon встроил "Сепаратор" в СТ! Какой бы это был мощный удар по "путанице"...

[monday2000]

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

DjVu Imager v2.6

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

Исходники:

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

Что нового:

- Сделано окно с отображением постраничного прогресса процесса вклейки иллюстраций.

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

- Исправлено несколько мелких багов.

- Улучшена проверка при ручном изменении пользователем номеров страниц (проверка на циферную природу вводимого набора символов, т.е. если во введённом наборе символов окажется хоть одна не-цифра - программа не даст изменить номер файла).

[57an]

для имен файлов в стиле 0014_014.sep.tiff во всех строках в столбце # отображается -1

[monday2000]

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

DjVu Imager v2.7

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

Исходники:

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

Что нового:

- Исправлен глюк с неправильным авто-определением номера иллюстрации:

для имен файлов в стиле 0014_014.sep.tiff во всех строках в столбце # отображается -1

57an
Исправлены все замечания относительно устарелости и ссылок на DjVu Sep.

[monday2000]

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

DjVu Imager v2.8

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

Исходники:

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

Что нового:

- Язык интерфейса теперь автоматически устанавливается при самом первом запуске - в зависимости от языка текущей локали пользователя (сейчас есть только один вариант - "Русский", иначе ставится "English").

При этом можно впоследствии насильственно указать английский интерфейс - для тех, у кого русская Windows, но кому нравится именно английский интерфейс.

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

[57an]

Почему при попытке кодирования этого скана в Djvu Imager выскакивает ошибка? Он ведь, вроде бы 24 битный RGB TIFF LZW..

[57an]

Разобрался сам, это 32RGBA.
Кстати, поддерживаемый и не изменяемый после обработки в ST (в режимах вывода mixed и color) формат файла.

[57an]

Сделал очередную версию 2.1 ST Separator, куда встроил ДЗФ, аналогичный используемому в Djvu Imager.
Этим исключился еще один шаг (и ошибки на этом шаге) перед удалением растра в иллюстрациях.
По-идее теперь полная совместимость между ST и Djvu Small + Djvu Imager, даже если часть страниц выводить в режиме цветной/серый в разрешении сканирования, а не в 600dpi.

[monday2000]

57an

Кстати, поддерживаемый и не изменяемый после обработки в ST (в режимах вывода mixed и color) формат файла.

Плохо, что не изменяемый. А не изменяемый, возможно, потому, что поддержка TIF в СТ - самодельная, и сделана самим Tulon (поскольку TIF не поддерживается почему-то в Qt).

Кстати - FreeImage поддерживает практически любые мыслимые варианты TIF - это мне просто было неохота заморачиваться и делать в DjVu Imager поддержку всякой экзотики. Я подумаю - может, и сделаю как-нибудь.

Между прочим, ещё неизвестно, как файлы такого рода воспринял бы DjVu Small - может, тоже не смог бы "переварить".

А как такой скан вообще изначально появился? Сканировать нужно в Irfan View - чтобы не генерировать экзотику всякую левую.

Этим исключился еще один шаг (и ошибки на этом шаге) перед удалением растра в иллюстрациях.

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

Именно поэтому я ратую за одинаковость размеров пар субсканов на входе в DjVu Imager (у меня лично такая одинаковость достигается автоматически у сканов после СТ) - я и не очень-то понимаю, почему у других СТ-пользователей это не так.

Ведь такой подход является наиболее простым. Его минусы - только завышенный расход дискового пространства, и время на ресемплирование сканов с 300 dpi на 600 dpi в СТ.

Требования к дисковому пространству - ИМХО пустяк - с нынешними-то винтами. Время, потребное для ресемплинга? Тоже не проблема - руками-то ничего делать не надо, лишь "запусти СТ и подожди", и всё.

Подход "неодинаковость размеров пар субсканов на входе в DjVu Imager" я считаю не "промышленным". Этот подход завышает требования к умственным способностям и знаниям DjVu-книгосканировщиков.

[57an]

Плохо, что не изменяемый

Неизменяемый - потому что это нормально - что на входе, то и на выходе..

Требования к дисковому пространству - ИМХО пустяк - с нынешними-то винтами

У кого-то "с нынешними винтами", а у кого - ноутбук с винтом довольно среднего объема, достаточного из-за нынешнего-то Интернета.

Согласен, что вывод в СТ с разными разрешениями - далеко не мейнстрим, вполне возможно, что я один так делаю.
В таком случае - ладно, это  особо не нужно, но зато и это работает.

Насчет ДЗФ - просто у меня рука не поворачивается кодировать отсканированные в 300 dpi иллюстрации с разрешением, меньшим, чем 300 dpi, особенно в 100-120 dpi, необходимом для полного удаления растра.
А вот размывать Гауссом почему-то поворачивается ) И размываются 300 dpi гораздо быстрее, чем 600.
Хотя не исключаю, что после гауссова размытия информации остается не больше, чем после ДЗФ.

[57an]

Неверно работает логика определения номера страниц после ST. Интересующая часть в левой части имени файла в формате <номер страницы>_<имя_файла_скана>.tif. Особенно характерно нестыковка проявляется при разрезке сканов разворотов на страницы - из p001.tif получится 0001_p001.tif и 0002_p001.tif, а Imager для обоих файлов определяет номер страницы, равный 1.

[monday2000]

57an

Неизменяемый - потому что это нормально - что на входе, то и на выходе..

Надо приводить вывод к некоему "стандартному" виду. Например, 32 бита перегонять в 24 - и т.п.

Неверно работает логика определения номера страниц после ST.

Это не баг, это фича.

Интересующая часть в левой части имени файла в формате

Я беру только правую часть - и её конвертирую в номер. Левая часть игнорируется.

Просто я пробовал смотреть разные сканы из СТ - и пришёл к выводу, что значащей частью является именно правая.

при разрезке сканов разворотов на страницы

А, понял. Дело в том, что я никогда не разрезаю развороты сканов в СТ пополам - я это делаю в СК - потому и никогда не сталкивался. Это Tulon "виноват" - ему следовало бы назвать такие сканы так, чтобы правая часть была значащей и в этом случае.

0001_p001.tif и 0002_p001.tif, а Imager для обоих файлов определяет номер страницы, равный 1.

Нет. Как раз именно для данных имён файлов DjVu Imager v2.8 "правильно" определяет номера страниц. Вы хотели сказать "0001_p001.tiff и 0002_p001.tiff" - для таких имён файлов авто-определение номеров страниц действительно срабатывает "неправильно".
Эту проблему можно удобно решать сбросом галки "Узнавать имена файлов Scan Tailor" - если её сбросить, тогда и для имён "0001_p001.tiff и 0002_p001.tiff" авто-определение номеров страниц действительно сработает "правильно".

Программа исходит из предположения, что имена файлов из СТ имеют расширение "tiff" и символ подчёркивания на 4-ой позиции. Для таких имён файлов авто-определение номеров страниц берёт за основу "правую часть" - правее подчёркивания (при условии, что галка "Узнавать имена файлов Scan Tailor" установлена). В противном случае авто-определение номеров страниц осуществляется как обычно: все небуквенные символы в имени файла заменяются на пробелы, полученная строка подаётся на вход функции atoi() - и получаем некое целое число (уж как там его atoi() вычисляет, я особо не разбирался).

Короче, весь этот бред организовал Tulon - а мы теперь вынуждены мучаться. Ему следовало всегда выдавать на выходе из СТ имена вроде 0001.tif, 0002.tif, ..., 0010.tif, ..., 0100.tif - как поступают все порядочные программы по работе с растровой графикой.

В общем, я порой и не знаю, каким ужом мне ещё вывернуться, чтобы подстроиться под СТ.

И размываются 300 dpi гораздо быстрее, чем 600.

Это понятно. Вообще, если хочется и быстрее, и проще одновременно - то надо это реализовывать в СТ. А пока что мой вариант мне представляется наиболее простым (за счёт той издержки, что надо ждать дольше - но "чайнику" ИМХО подождать нетрудно, ему трудно лишний раз шевельнуть извилиной).

[57an]

В общем, я порой и не знаю, каким ужом мне ещё вывернуться, чтобы подстроиться под СТ

Ну тогда и не нужно.
Я в последнем ST Separator (версии 2.3) сделал переименование имен файлов субсканов в стиле FSD (только из цифр) + sep для иллюстраций, исходя из Tulon'овской концепции именования.
Так что и с Djvu Imager 2.8 будет работать.

Для таких имён файлов авто-определение номеров страниц берёт за основу "правую часть"

а нужно было брать левую.
"Весь этот бред" содержит и старое имя файла (чтобы, если что, легче на скан выйти) справа от подчеркушки и сквозную нумерацию в левой части имени - чтобы сортировалось по-правильному. По-моему достаточно толково.
Основное достоинство -  исходные сканы могут и не иметь возрастающие по алфавиту имена файлов.
Есть и серьезный недостаток - после запуска стадии вывода изменять структуру проекта (добавлять/удалять файлы) категорически не рекомендуется - иначе получим кучу одинаковых файлов с разными именами... (кстати, возможно стоит добавить анализ такого случая в следующую версию Сепаратора).

[monday2000]

57an

По-моему достаточно толково.

В принципе, я сам ещё толком не пробовал использовать СТ в сочетании с DjVu Imager. Надеюсь, когда попробую, то опыт покажет, как ещё лучше "подстроить" DjVu Imager под СТ.

Пока что мне представляется, что иногда нужно высчитывать номер иллюстрации в DjVu Imager по "левой" части СТ-имени, а иногда - по "правой". Пример: если обрабатывать всю книгу целиком в СТ - то левые и правые части будут идентичны - и можно будет брать левую. А если обработать только выборочные страницы - с целью отделить иллюстрации в задние субсканы - то тогда придётся брать правые части (0001_0035.tiff, 0002_0036.tiff). Но что будет, если в последнем случае сделать ещё и разрезку разворотов в СТ? У меня получилось следующее:

0001_0035.tiff, 0002_0035.tiff, 0003_0036.tiff, 0004_0036.tiff

Такое не вставишь напрямую в DjVu Imager. В подобном случае нужно после разрезки переименовывать разрезанное в новую сплошную нумерацию (по идее) - и только потом загружать результат в СТ и дообрабатывать до конца.

Кстати, я буду всем советовать разрезать развороты в СК - а уже потом грузить их в СТ, и дообрабатывать до конца. СТ не годится для задачи разрезания разворотов (точнее, в 95-98% случаев им можно пользоваться, а в оставшихся 2-5% случаев он крайне неудобен для разрезки. СК же удобен для 100% случаев разрезки). Да и вообще - на моё субъективное мнение разрезка разворотов в СК гораздо симпатичнее и принципиально проще. Не говоря уже о том, что я вообще сторонник подхода "делать разрезку в независимой стадии обработки (или в отдельной программе)".

При таком подходе (если не разрезать развороты в СТ) каких-либо проблем с СТ-именами порезанных разворотов вроде не должно возникнуть (в DjVu Imager).

Есть и серьезный недостаток - после запуска стадии вывода изменять структуру проекта (добавлять/удалять файлы) категорически не рекомендуется - иначе получим кучу одинаковых файлов с разными именами...

ИМХО Tulon мог бы и заблокировать фичу "добавлять/удалять файлы" - ничего по большому счёту не потерял бы.