История изменений
Исправление Truf, (текущая версия) :
вся «соль» minidjvu была в том, что попарный матчинг букв, с целью найти одинаковые выполнялся не с масками букв, а с скелетами букв.
На сколько я понимаю - это не так. Емнип там 4 метода сравнения, один из которых (последний?) действительно ищет скелеты букв, но для того, чтобы все кроме скелета залить градиентом серого. Т.е. он из ч.б. буквы делает её grayscale с увеличением интенсивности цвета к скелету. И при сравнении учитывает этот grayscale тем самым более толерантно относясь к несовпадению пикселей по краям буквы, по сравнению с тем что ближе к скелету.
В результате бездумного применения этой идеи djvu-шки созданные энтузиастами максимального сжатия не только изобилуют проблемами «инь» но и зачастую буковки вдоль базовой линии сильно скачут, тоесть сканы оказались испорченными в погоне за «сжатием», и в этих ваших интернетах бывает так, что остались только такие вот результаты работы minidjvu.
Вот если бы вы меня попросили показать djvu книгу, созданную minidjvu - я бы не смог ее показать. Я не знаю ни одной! Где вы нашли сделанные minidjvu книги?
созданные энтузиастами максимального сжатия
Открою вам секрет, энтузиасты максимального сжатия до сего момента minidjvu не использовали вообще, т.к. они использовали ПРОПРИЕТАРНЫЙ ВИНДОВЫЙ documenttodjvum.exe от LizardTech. Даже через Wine. И я тоже ))
зачастую буковки вдоль базовой линии сильно скачут
Если вы мне пришлете пример такого скана (в issue на github), чтобы я мог воспроизвести проблему - я вам буду благодарен. Но возможно вы путаете эту проблему с другой.. попробуйте опцию -a.
Есть достойный инструмент, в опенсорсе - jbig2enc
Я ковырял jbig2enc - мне было интересно, какие методы они используют для классификации и составления словарей. Я сильно сомневаюсь, что он может дать сравнимый с djvu результат. На вскидку я уже не помню, но если бы это имело место - я бы запомнил.
Исходная версия Truf, :
вся «соль» minidjvu была в том, что попарный матчинг букв, с целью найти одинаковые выполнялся не с масками букв, а с скелетами букв.
На сколько я понимаю - это не так. Емнип там 4 метода сравнения, один из которых (последний?) действительно ищет скелеты букв, но для того, чтобы все кроме скелета залить градиентом серого. Т.е. он из ч.б. буквы делает её grayscale с увеличением интенсивности цвета к скелету. И при сравнении учитывает этот grayscale тем самым более толерантно относясь к несовпадению пикселей по краям буквы, по сравнению с тем что ближе к скелету.
В результате бездумного применения этой идеи djvu-шки созданные энтузиастами максимального сжатия не только изобилуют проблемами «инь» но и зачастую буковки вдоль базовой линии сильно скачут, тоесть сканы оказались испорченными в погоне за «сжатием», и в этих ваших интернетах бывает так, что остались только такие вот результаты работы minidjvu.
Вот если бы вы меня попросили показать djvu книгу, созданную minidjvu - я бы не смог ее показать. Я не знаю ни одной! Где вы нашли сделанные minidjvu книги?
созданные энтузиастами максимального сжатия
Открою вам секрет, энтузиасты максимального сжатия до сего момента minidjvu не использовали вообще, т.к. они использовали ПРОПРИЕТАРНЫЙ ВИНДОВЫЙ documenttodjvum.exe от LizardTech. Даже через Wine. И я тоже ))
зачастую буковки вдоль базовой линии сильно скачут
Если вы мне пришлете пример такого скана (в issue на github), чтобы я мог воспроизвести проблему - я вам буду благодарен. Но возможно вы путаете эту проблему с другой.. попробуйте опцию -a.
Есть достойный инструмент, в опенсорсе - jbig2enc
Я ковырял jbig2enc, мне было интересно, какие методы они используют для классификации и составления словарей. Я сильно сомневаюсь, что он может дать сравнимый с djvu результат. На вскидку я уже не помню, но если бы это имело место - я бы запомнил.