Решился я переписать DjVu Imager 2.9 от monday2000 с MFC на Qt 5.x.
Результат доступен тут: https://github.com/trufanov-nok/DjVu_Imager-Qt/releases под той же лицензией.

Идея была в том, чтобы получить нативное приложение для Linux, но сборку для Win32 я также сделал. Приложение укомплектовано актуальными утилитами из пакета DjVuLibre, актуальной FreeImage.dll и пересобранным кодировщиком fi_c44.
Теперь, если заменить DjVu Small на minidjvu_mod, можно получить нормальный кросплатформенный инструмент для кодирования multipage bundled DjVu документов по методу раздельных сканов.

Поведение DjVu Imager Qt не должно отличаться от оригинала, за исключением того, что я заменил все настройки префиксов/суффиксов на настройку RegExp выражения, которое я использую для получения номера страницы из имени файла изображения. А "под капотом" я заменил некоторые операции (получение кол-ва страниц, изменение DPI, функционал djvudumpm) на использование djvused.
Тем не менее, косяки возможны, особенно в Win версии, потому что разрабатываю и работаю я преимущественно на Linux машине. Если что - пишите в эту ветку или в Issues на github'е.

m7876 писал(а) 26.03.2020 :: 18:43:26:

На линуксе? Кроме GUI у Imager'а более узкая специализация - менять слой background'а в уже готовом multipage документе. Это позволяет натравить его на файл, собранный проприетарным djvu кодером. Например, ворованным documenttodjvum, распространяемым вместе с DjVu Small. Который приходится запускать под Wine.

У вас, насколько я понимаю, скрипт использует либо кодеры из DjVuLibre, либо minidjvu.  Кодеры из DjVuLibre не лучший выбор для создания multipage документов, т.к. не умеют делать общие для нескольких страниц словари Djbz. Они просто собирают независимо кодируемые страницы. На выходе файл получается слишком большой. А minidjvu - такие словари делать умеет, но авторы поставили в него оптимизацию для скорости - искать вхождения символа только на соседних (емнип) страницах, что дает в среднем на 23% более толстый документ, чем documenttodjvum. Более подробно я все это описывал тут: http://publ.lib.ru/cgi/forum/YaBB.pl?num=1560707465 И там же предложил minidjvu_mod - экспериментальную модифицированную версию minidjvu без этой оптимизации. Кстати, ваш скрипт может легко использовать и её.

Ну и в главных, я в Imager полез разбираться, естественно, с прицелом на то, чтобы когда-нибудь затолкать сборку DjVu документов по методу раздельных сканов непосредственно в ScanTailor с кодером minidjvu_mod, поэтому и портировал на Qt

>  Очень многие пользователи, конечно, пугаются терминала...

Не просто пугаются, так этот bash еще найти и установить нужно. Если бы из cmd работало или bash в комплекте шел, то было бы проще. Пользователь Винды хочет один инсталлятор, который поставит ему и требуемые библиотеки, и утилиты, и ярлычок на рабочем столе создаст. Хотя сейчас MS пытается запихнуть в Windows 10 линуксовое ядро: https://www.opennet.ru/opennews/art.shtml?num=52552
Может это перестанет быть проблемой.

>Вообще, здесь на форуме многие предпочитают (по крайней мере в последнее время) качество размеру.

Ну, тут акценты несколько другие. Использование или не использование Djbz словаря вряд ли может повредить качеству, т.к. Sjbz страницы кодируются также с применением локального для страницы словаря. Если только кодеру не передан параметр типа lossless, но тогда все символы без разбора пойдут в словарь как уникальные и документ по размеру будет подобен подборке чернобелых jpeg изображений. Т.о. беспокоиться о словарях вам все таки нужно т.к. даже single page кодирование без составления словаря не происходит.

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

А размер - важен. На мой взгляд, это вообще единственное преимущество DjVu перед PDF. DjVu хорош именно для долгосрочного хранения документов, которые редко читают, т.е. старой советской литературы. И +/- 20% от размера файла, даже если это килобайты, в масштабах добровольно сидируемых на рутрекере книг - это серьезно. Меньше файл - больше сидов - дольше он проживет во всяких архивах, в случае чего.

> Заталкивать все в одно приложение, на мой взгляд, не самое правильное решение.

Я хочу добиться этим 3-х вещей.
1. Чтобы любой пользователь мог сделать книжку по методу раздельных сканов установив одну программу и в три клика, даже не зная о существовании метода раздельных сканов. В этом, по моему мнению, суть ST - он не сложный и дает хороший результат даже с дефолтными настройками. А про метод раздельных сканов я и сам сильно не стразу узнал.
2. Хочу дать возможность выставлять настройки кодирования для конкретной страницы. Без GUI тут никак.
3. И хочу видеть в real time как эти настройки влияют на результат, чтобы их оптимально подбирать. Т.е. на лету перекодировать и отображать страницу.

1-е требует, чтобы в дистрибутиве были все требуемые потроха. Я могу в пакет ST докладывать утилиты DjVuLibre или еще что, но не могу класть скрипты - они платформозависимы или им интерпретатор требуется. Проще вызов всех утилит делать прямо из Qt - он это умеет, и stdin/stdout писать/читать. В крайнем случае у Qt есть свои script engine и QML, но это уже перебор.

> Но у меня было ощущение, что с большими словарями растет вероятность проблем класса "инь".

Если проблемой считать ошибку с инь в конкретном слове, то теоретически да, растет. Но если считать проблемой то, что кодер в данном конкретном шрифте и тексте вообще способен такую ошибку совершить, то не растет, а наоборот - выявить проблему помогает. Например, слишком высокий параметр агрессивности. А если решать проблему инь просто уменьшая кол-во текста по которому составляется словарь и не меняя параметры кодирования - то это игра в удачу. Может повезет, может нет.
На практике я бы ожидал, что разница при кодировке с одними и теми же параметрами, но разным кол-вом страниц в Djbz словарях будет минимальной. Потому что непропечатанная И в ИНЬ чаще всего путается с Н, а Н там прям следующей буквой. Т.о. у кодировщика все равно будет что с чем перепутать, даже в масштабе одной страницы.

> Но может быть, тогда принять подход img2djvu и разделять сканы на лету? Будет и быстрее, и еще проще для конечного пользователя. А если Freeimage не умеет этого, то может быть, взять Magick++?

Да, что-то такое нужно будет сделать. STU умеет разделять сканы и имеет функцию экспорта. А FreeImage я тащить в проект точно не хочу - средствами Qt и так можно любые картинки читать. В принципе можно было вместо fi_c44.exe сделать qt_c44.exe и отказаться от FreeImage и в Imager'e, но я об этом не подумал. Библиотеки Qt конечно жирнее FreeImage, но я их так и так тащу с собой.. Посмотрим.

>  в Xenial не компилируется Ваш DjVu Imager, может быть, сбавите требуемую версию Qt?

Там вроде доступен из репозиториев Qt 5.5.1 - его должно быть достаточно. Попробуйте поставить qtbase5-dev перед компиляцией или deb пакет с бинарником, и посмотреть, найдет ли он зависимости.

truf писал(а) 26.03.2020 :: 17:01:11:

А для WIN64 не планировали?

truf писал(а) 26.03.2020 :: 21:36:47:

Угу. И может, хоть когда-нибудь люди перестанут вот это публиковать. Ну сколько же лет эта фигня с автосегментированием ещё будет длиться...

Свеженький Дмитриев от manjak61, внешний вид


Содержимое слоев




крупно




Очень хочется хотя бы из ST нормального кодирования. Юные балбесы, работающие в Solo по рекомендациям из гугла, когда-нибудь вымрут же. Но семейство ST активно юзают.

+
В pdf артефакты есть, но не такие страшные

Владислав_72 писал(а) 30.03.2020 :: 19:30:25:


Я не смогу - там используется MFC под Windows, я его просто не знаю.

m7876 писал(а) 31.03.2020 :: 14:17:53:

Не, DjVu Small куда лучше подходит на роль единой утилиты-упаковщика готовых обработанных сканов в дежавю. Это мое мнение, не на слуху знакомого и разработкой софта под конкретного пользователя и его последующей техподдержкой. Принцип должен быть один - "раз настроил и забыл", а не использовать кучу утилит с кучей промежуточных результатов. Подавляющее большинство разработчиков опенсорса об этом не думают.

truf писал(а) 27.03.2020 :: 21:26:46:


Проект fi_c44-multipage переименован в c44-freeimage, а экзешник в c44-fi.
Добавлены deb пакеты для x86/x64.
https://github.com/trufanov-nok/c44-freeimage/releases/tag/3.5.28

В STU пока решил использовать -fi версию - qt из коробки не умеет скейлирование изображений бикубиком.