Tulon
Остались ли резервы по увеличению быстродействия стадии вывод (кроме подключения GPU)?
Остались ли резервы по увеличению быстродействия стадии вывод (кроме подключения GPU)?
» Scan Tailor: Часть 2
StanFreeWare
Ну можно SSE тут там заюзать, можно обрабатывать несколько страниц одновременно на разных ядрах. И то и другое тупиковый путь IMHO.
Подождать пару лет, и вычисления на GPU станут поддерживать даже встроенные видюхи. Как раз к тому времени у меня возможно дойдут до этого руки.
Ну можно SSE тут там заюзать, можно обрабатывать несколько страниц одновременно на разных ядрах. И то и другое тупиковый путь IMHO.
Подождать пару лет, и вычисления на GPU станут поддерживать даже встроенные видюхи. Как раз к тому времени у меня возможно дойдут до этого руки.
Проверил rc1. Маленький веник работает.
Tulon
А как Вам задача раскраски маски для последующего малоцветного кодирования - чем больше вникаю в нее, (см сканы от VladimirTT в топике сканирования и обработки) тем больше понимаю, что решаться она должна как раз в районе стадии Вывод.
Т.е. как это вижу я -
от пользователя требуется задать набор используемых в маске цветов (пусть даже поначалу это будет лишь один цвет) и, (возможно, необязательно) порог поиска цвета при раскраске. Можно, конечно, пойти еще дальше и определять такие цвета на автомате, но для начала хотя бы так.
При бинаризации, для областей с близким данному цветом порог бинаризации либо автоматически, либо вручную подправляется (особенно, если цвет достаточно тусклый).
Далее, несоприкасающиеся области, в частности, буквы закрашиваются либо требуемым цветом, либо черным, согласно условию - чьих пикселей больше - такого цвета и буква. Это позволит более грубо задавать порог поиска и избежать цветных вкраплений или ореола у черных букв.
Есть еще контрпример - книга по каллиграфии, для подобных ей возможность неоднотонной заливки букв придется ставить под галочку.
Я к тому, что рубеж метода разделенных сканов за мелкими нюансами Скан Тэйлором взят, а метод раскраски маски - нет (хотя, понимаю, что необходимость в нем случается на порядок реже, чем в МРС).
Кроме того, по скорости вывода СТ сейчас сильно проигрывает Кромсатору. Для людей, которые делают много книг, это критично.
Просто я не сказал бы, что задача кодирования "гуманитариями" в djvu сейчас как-то особо остро стоит.
Есть очень шустрый комплект от monday2000 (я надеюсь, что он все-таки победит свою фобию перед "вредным универсализмом" и как-нибудь грамотно их объединит).
Есть очень мощный, и, что немаловажно, одноэтапный и не менее шустрый FSD.
Есть некоммерческий Djvu Solo, который можно использовать, как минимум, как кодер битональных сканов.
И есть крайне медленный minidjvu, хотя, возможно, по сравнению с многочасовым выводом в СТ полчасика на кодирование в djvu это ерунда (правда, при достаточно большом объеме словаря там уже далеко не полчасика).
А как Вам задача раскраски маски для последующего малоцветного кодирования - чем больше вникаю в нее, (см сканы от VladimirTT в топике сканирования и обработки) тем больше понимаю, что решаться она должна как раз в районе стадии Вывод.
Т.е. как это вижу я -
от пользователя требуется задать набор используемых в маске цветов (пусть даже поначалу это будет лишь один цвет) и, (возможно, необязательно) порог поиска цвета при раскраске. Можно, конечно, пойти еще дальше и определять такие цвета на автомате, но для начала хотя бы так.
При бинаризации, для областей с близким данному цветом порог бинаризации либо автоматически, либо вручную подправляется (особенно, если цвет достаточно тусклый).
Далее, несоприкасающиеся области, в частности, буквы закрашиваются либо требуемым цветом, либо черным, согласно условию - чьих пикселей больше - такого цвета и буква. Это позволит более грубо задавать порог поиска и избежать цветных вкраплений или ореола у черных букв.
Есть еще контрпример - книга по каллиграфии, для подобных ей возможность неоднотонной заливки букв придется ставить под галочку.
Я к тому, что рубеж метода разделенных сканов за мелкими нюансами Скан Тэйлором взят, а метод раскраски маски - нет (хотя, понимаю, что необходимость в нем случается на порядок реже, чем в МРС).
Кроме того, по скорости вывода СТ сейчас сильно проигрывает Кромсатору. Для людей, которые делают много книг, это критично.
Просто я не сказал бы, что задача кодирования "гуманитариями" в djvu сейчас как-то особо остро стоит.
Есть очень шустрый комплект от monday2000 (я надеюсь, что он все-таки победит свою фобию перед "вредным универсализмом" и как-нибудь грамотно их объединит).
Есть очень мощный, и, что немаловажно, одноэтапный и не менее шустрый FSD.
Есть некоммерческий Djvu Solo, который можно использовать, как минимум, как кодер битональных сканов.
И есть крайне медленный minidjvu, хотя, возможно, по сравнению с многочасовым выводом в СТ полчасика на кодирование в djvu это ерунда (правда, при достаточно большом объеме словаря там уже далеко не полчасика).
iit512
Цитата:
Меня больше интересует то, нужно ли подкручивать параметры веников и стоит ли вернуть средний веник как веник по умолчанию. Эти вопросы вызваны тем, что после исправления бага c гуляющей аггрессивностью, средняя аггрессивность всех веников понизилась.
Цитата:
Проверил rc1. Маленький веник работает.
Меня больше интересует то, нужно ли подкручивать параметры веников и стоит ли вернуть средний веник как веник по умолчанию. Эти вопросы вызваны тем, что после исправления бага c гуляющей аггрессивностью, средняя аггрессивность всех веников понизилась.
Цитата:
стоит ли вернуть средний веник как веник по умолчанию
Думаю, не стоит, та страница, из-за которой я просил по-умолчанию сделать маленький веник и на последней сборке средним веником слишком грубо подметается. Даже на 30й жирности.
Кстати, на -30 жирности малый веник удаляет целую строчку отточий в середине оглавления. Но почему-то не трогает отточия в первой и последней строчках.
Цитата:
стоит ли вернуть средний веник как веник по умолчанию
Не стОит, малый веник для моих многочисленных отточий -- то, что нужно.
StanFreeWare
Цитата:
Ответ - в подписи.
Цитата:
А как Вам задача раскраски маски для последующего малоцветного кодирования
Ответ - в подписи.
Попалась еще одна книга, требующая для стадии макета возможности применения настроек выравнивания "К каждой второй выбранной странице".
Вообще, выравнивание разных половинок страниц разворота по разному краю - это достаточно общее место в оформлении, например, рекламных буклетов.
В MS Word такие поля называются зеркальными.
Вообще, выравнивание разных половинок страниц разворота по разному краю - это достаточно общее место в оформлении, например, рекламных буклетов.
В MS Word такие поля называются зеркальными.
StanFreeWare
Знаете, я конкретно устал от фич-реквестов.
Знаете, я конкретно устал от фич-реквестов.
Tulon
Отсутствие зеркальных полей это баг
Отсутствие зеркальных полей это баг
Tulon
Считаю целесообразным встроить "Сепаратор" от StanFreeWare в СТ. В смысле, делать прямо в СТ разбиение "Смешанного" выходного скана на 2 субскана - чёрно-белый (передний субскан - текст) и серый (задний субскан - иллюстрация). И выводить получаемые субсканы в отдельные папки - типа подпапки out.
Иначе СТ выглядит очевидной недоделкой.
Считаю целесообразным встроить "Сепаратор" от StanFreeWare в СТ. В смысле, делать прямо в СТ разбиение "Смешанного" выходного скана на 2 субскана - чёрно-белый (передний субскан - текст) и серый (задний субскан - иллюстрация). И выводить получаемые субсканы в отдельные папки - типа подпапки out.
Иначе СТ выглядит очевидной недоделкой.
monday2000
Считаю абсолютно некорректным по отношению к U235 ссылаться здесь именно на Сепаратор, а не на LayerTailor.
Также считаю целесообразным включить аналогичную логику все-таки в Djvu Small, а кодирование МРС через Djvu Imager - сделать одним из его профилей.
Короче, даешь однокнопочный Djvu-кодер!
Кстати, логику LayerTailor неплохо было бы прикрутить также и к FSD - опять же получим однокнопочный кодер, достаточный для большинства применений, не требующих scanned-style профилей коммерческих кодеров.
Считаю абсолютно некорректным по отношению к U235 ссылаться здесь именно на Сепаратор, а не на LayerTailor.
Также считаю целесообразным включить аналогичную логику все-таки в Djvu Small, а кодирование МРС через Djvu Imager - сделать одним из его профилей.
Короче, даешь однокнопочный Djvu-кодер!
Кстати, логику LayerTailor неплохо было бы прикрутить также и к FSD - опять же получим однокнопочный кодер, достаточный для большинства применений, не требующих scanned-style профилей коммерческих кодеров.
monday2000
Цитата:
Ну так и займитесь этим. Сделайте свою сборку ST. Никто же не против, исходники открыты.
Зачем же указывать автору ST что и как ему делать в свободное от работы время?
StanFreeWare
Цитата:
Четные и нечетные страницы после вывода из ST легко можно разделить по разным папкам в total commander'e или используя стандартный поиск. Затем можно добавить поля с помощью пакетных программ типа xnview, irfan, imagemagick и т.д. И вообще, это можно сделать bat-ником из ~10 строк.
StanFreeWare
Цитата:
В чем некорректность? LayerTailor - это больше демонстрационная утилита, а Сепаратор - вполне себе рабочий инструмент.
Цитата:
Считаю целесообразным встроить "Сепаратор" от StanFreeWare в СТ.
Ну так и займитесь этим. Сделайте свою сборку ST. Никто же не против, исходники открыты.
Зачем же указывать автору ST что и как ему делать в свободное от работы время?
StanFreeWare
Цитата:
Попалась еще одна книга, требующая для стадии макета возможности применения настроек выравнивания "К каждой второй выбранной странице".
Четные и нечетные страницы после вывода из ST легко можно разделить по разным папкам в total commander'e или используя стандартный поиск. Затем можно добавить поля с помощью пакетных программ типа xnview, irfan, imagemagick и т.д. И вообще, это можно сделать bat-ником из ~10 строк.
StanFreeWare
Цитата:
Считаю абсолютно некорректным по отношению к U235 ссылаться здесь именно на Сепаратор, а не на LayerTailor.
В чем некорректность? LayerTailor - это больше демонстрационная утилита, а Сепаратор - вполне себе рабочий инструмент.
Tulon
Вот ответ Ильи Межирова по поводу того, кому какой код принадлежит в исходниках minidjvu:
Цитата:
От себя добавлю, что в первую очередь смотрел бы файлы с расширением cpp (minidjvu написан на C, и вставки на C++ -- именно по причине заимствования из djvulibre). Но код в любом случае подвергся довольно сильной адаптации, так что его ревизия на предмет соответствия именно последней версии едва ли имеет смысл.
Что касается моего вклада, то здесь, наверное, проще всего скачать версии 0.7 и 0.8 и обработать diff'ом. Логи SVN не помогут, т. к. заливка в репозитарий была проведена уже после выхода версии 0.8.
Вот ответ Ильи Межирова по поводу того, кому какой код принадлежит в исходниках minidjvu:
Цитата:
Большая часть кода (и C, и С++) как-то соотносится с кодом из djvulibre. Наиболее близок zp-кодер и Ваш bzz. Но это не означает, что Bottou/LeCun имеют копирайт на код minidjvu. Например, любой имеет право выпустить копию djvulibre под GPL3 и своим копирайтом, разумеется при условии, что все ссылки проставлены.
От себя добавлю, что в первую очередь смотрел бы файлы с расширением cpp (minidjvu написан на C, и вставки на C++ -- именно по причине заимствования из djvulibre). Но код в любом случае подвергся довольно сильной адаптации, так что его ревизия на предмет соответствия именно последней версии едва ли имеет смысл.
Что касается моего вклада, то здесь, наверное, проще всего скачать версии 0.7 и 0.8 и обработать diff'ом. Логи SVN не помогут, т. к. заливка в репозитарий была проведена уже после выхода версии 0.8.
StanFreeWare
Цитата:
Я не хочу этого делать - по той причине, что не хочу добавлять в дистрибутив DjVu Small файл freeimage.dll (это было бы излишнее утяжеление "веса" DjVu Small). Это пусть Tulon вставляет в СТ такие сомнительной нужности вещи, как CrashReporter, ведущие к утяжелению веса программы - кому надо, могли бы отдельно скачивать CrashReporter.
Цитата:
Ни в коем случае. Это было бы опасным безумием. Уподобиться авторам СК и СТ, делающим "гибрид печки, мясорубки, и стиральной машины в одном флаконе"?
Цитата:
Вот этот лозунг мне нравится. Я "за". Но кто сказал, что ради его реализации нужно слить воедино DjVu Small и DjVu Imager? Есть же и другие варианты: можно просто придумать некую схему, упрощающую связку DjVu Small и DjVu Imager.
И потом: допустим, я объединил в одну программу DjVu Small и DjVu Imager. А что, если кому-то захочется кодировать в DjVu при помощи DjVu Solo 3.1 (minidjvu), а иллюстрировать при помощи DjVu Imager? Как обрабатывать такую ситуацию предлагаемым мне "безумным комбайном"?
А, если кто-то хочет, скачав из Интернета произвольный DjVu-файл, вклеить туда иллюстрации - зачем ему объединённый DjVu Small+DjVu Imager?
Но есть и ещё одна важная причина: глюки. Гораздо проще и удобней отлаживать глюки в 2-х раздельных программах - чем в одной объединённой.
Да и слишком уж велика концептуальная разница между DjVu Small и DjVu Imager, чтобы их объединить воедино. Отличается и частота использования (популярность), и критерий устоявшаяся/экспериментальная (программа).
Нет, объединять DjVu Small и DjVu Imager в единую программу было бы в корне неверно. Это пусть Tulon полностью отнимает у пользователя свободу действий, диктуя "а сейчас ты сделаешь то-то, а затем - то-то, а по-другому - нельзя - потому что я так хочу".
Потому и нет настоящего успеха ни у bolega, ни у Tulon, что они оказались неспособны понять такие простейшие элементарные вещи - а погнались за кажущейся химерой.
U235
Цитата:
Была у меня такая мысль, но я отказался. Риск слишком погрязнуть - СТ уж чересчур концептуально-ошибочен. Целесообразнее начать агитировать-искать желающих сделать альтернативу СТ - чем пытаться его исправлять.
Цитата:
Потому что существует определённая логика здравого смысла, которая хочешь-не хочешь, а диктует именно определённые решения - независимо от того, хотим мы того, или нет.
Разделение "Смешанного" вывода на пары субсканов должно осуществляться именно в СТ - поскольку ВСЕ ныне существующие DjVu-кодёры не в состоянии самостоятельно отделить от "Смешанного" СТ-вывода то, что они смогут закодировать в DjVu. Именно поэтому СТ должен подстроиться под окружающий мир - а не наоборот. Существование LayerTailor и Сепаратора - есть лишь вынужденное извращение, порождённое Tulon.
Конечно, я могу встроить в DjVu Small автоматическое отделение нужного контента (из СТ-вывода) - но это было бы настолько идеологически неверно, что даже и делать этого совсем не хочется (лучше сделаю свой аналог LayerTailor-Сепаратор, и возложу ответственность за появление очередного "костыля" на Tulon).
Цитата:
Также считаю целесообразным включить аналогичную логику все-таки в Djvu Small,
Я не хочу этого делать - по той причине, что не хочу добавлять в дистрибутив DjVu Small файл freeimage.dll (это было бы излишнее утяжеление "веса" DjVu Small). Это пусть Tulon вставляет в СТ такие сомнительной нужности вещи, как CrashReporter, ведущие к утяжелению веса программы - кому надо, могли бы отдельно скачивать CrashReporter.
Цитата:
, а кодирование МРС через Djvu Imager - сделать одним из его профилей.
Ни в коем случае. Это было бы опасным безумием. Уподобиться авторам СК и СТ, делающим "гибрид печки, мясорубки, и стиральной машины в одном флаконе"?
Цитата:
Короче, даешь однокнопочный Djvu-кодер!
Вот этот лозунг мне нравится. Я "за". Но кто сказал, что ради его реализации нужно слить воедино DjVu Small и DjVu Imager? Есть же и другие варианты: можно просто придумать некую схему, упрощающую связку DjVu Small и DjVu Imager.
И потом: допустим, я объединил в одну программу DjVu Small и DjVu Imager. А что, если кому-то захочется кодировать в DjVu при помощи DjVu Solo 3.1 (minidjvu), а иллюстрировать при помощи DjVu Imager? Как обрабатывать такую ситуацию предлагаемым мне "безумным комбайном"?
А, если кто-то хочет, скачав из Интернета произвольный DjVu-файл, вклеить туда иллюстрации - зачем ему объединённый DjVu Small+DjVu Imager?
Но есть и ещё одна важная причина: глюки. Гораздо проще и удобней отлаживать глюки в 2-х раздельных программах - чем в одной объединённой.
Да и слишком уж велика концептуальная разница между DjVu Small и DjVu Imager, чтобы их объединить воедино. Отличается и частота использования (популярность), и критерий устоявшаяся/экспериментальная (программа).
Нет, объединять DjVu Small и DjVu Imager в единую программу было бы в корне неверно. Это пусть Tulon полностью отнимает у пользователя свободу действий, диктуя "а сейчас ты сделаешь то-то, а затем - то-то, а по-другому - нельзя - потому что я так хочу".
Потому и нет настоящего успеха ни у bolega, ни у Tulon, что они оказались неспособны понять такие простейшие элементарные вещи - а погнались за кажущейся химерой.
U235
Цитата:
Ну так и займитесь этим. Сделайте свою сборку ST. Никто же не против, исходники открыты.
Была у меня такая мысль, но я отказался. Риск слишком погрязнуть - СТ уж чересчур концептуально-ошибочен. Целесообразнее начать агитировать-искать желающих сделать альтернативу СТ - чем пытаться его исправлять.
Цитата:
Зачем же указывать автору ST что и как ему делать в свободное от работы время?
Потому что существует определённая логика здравого смысла, которая хочешь-не хочешь, а диктует именно определённые решения - независимо от того, хотим мы того, или нет.
Разделение "Смешанного" вывода на пары субсканов должно осуществляться именно в СТ - поскольку ВСЕ ныне существующие DjVu-кодёры не в состоянии самостоятельно отделить от "Смешанного" СТ-вывода то, что они смогут закодировать в DjVu. Именно поэтому СТ должен подстроиться под окружающий мир - а не наоборот. Существование LayerTailor и Сепаратора - есть лишь вынужденное извращение, порождённое Tulon.
Конечно, я могу встроить в DjVu Small автоматическое отделение нужного контента (из СТ-вывода) - но это было бы настолько идеологически неверно, что даже и делать этого совсем не хочется (лучше сделаю свой аналог LayerTailor-Сепаратор, и возложу ответственность за появление очередного "костыля" на Tulon).
Tulon
Для такого файла порога +30 чуть-чуть не хватает.
Для такого файла порога +30 чуть-чуть не хватает.
StanFreeWare
ST не учитывает при бинаризации цветовую компоненту, т.е. он просто приводит вначале картинку к оттенкам серого, поэтому получается такой результат. И повышение порога в этом случае тупиковый путь. Скорее всего это не поможет.
Как вариант можно разложить картинку на компоненты и обрабатывать их отдельно (или слить в один файл, бинаризовать, а раскрашивать по цветам потом отдельно).
Пример (делалось самописной на FreePascale утилитой + XnView, т.к. для синей компоненты получается низкая контрастность, видимо где-то ошибся с коэффициентами):
http://www.onlinedisk.ru/file/410602/
Кстати, Вы случайно не делали программку для извлечения угла поворота и размеров полезной области из ST-проекта в какой-нибудь текстовой файл? Она бы очень помогла при обработке книги такого типа.
ST не учитывает при бинаризации цветовую компоненту, т.е. он просто приводит вначале картинку к оттенкам серого, поэтому получается такой результат. И повышение порога в этом случае тупиковый путь. Скорее всего это не поможет.
Как вариант можно разложить картинку на компоненты и обрабатывать их отдельно (или слить в один файл, бинаризовать, а раскрашивать по цветам потом отдельно).
Пример (делалось самописной на FreePascale утилитой + XnView, т.к. для синей компоненты получается низкая контрастность, видимо где-то ошибся с коэффициентами):
http://www.onlinedisk.ru/file/410602/
Кстати, Вы случайно не делали программку для извлечения угла поворота и размеров полезной области из ST-проекта в какой-нибудь текстовой файл? Она бы очень помогла при обработке книги такого типа.
U235
Цитата:
Для этого скана поможет. Он на +30 бинаризуется без грязи. Так что запас есть.
Но в целом, конечно, бинаризация без учета цветовой компоненты для книги VladimirTT дает низкое качество результата - например, на одной из страниц повышение порога до хотя бы минимальной разборчивости синего текста привело к появлению в черных формулах лишних знаков - "проявились" просвечивающие символы с обратной стороны страницы.
Я раньше пытался решить подобную задачу через выделение цветовой компоненты и их отдельной бинаризации с последующей склейкой. Но технология Separator 2.0 мне кажется гораздо "технологичнее" (естественно, там есть куда развиваться - в частности, нужен быстрый алгоритм для выделения отдельных символов для их последующей заливки, да и вместо HSV логики сравнения наверное можно придумать что-нибудь более наукоемкое).
Цитата:
Не совсем понял, а какой в этом смысл - все равно парсить придется, так не все ли равно что парсить - xml-проекта или текстовый файл со вновь придуманной структурой?
Цитата:
Поясните, поподробнее, как именно?
Цитата:
Скорее всего это не поможет.
Для этого скана поможет. Он на +30 бинаризуется без грязи. Так что запас есть.
Но в целом, конечно, бинаризация без учета цветовой компоненты для книги VladimirTT дает низкое качество результата - например, на одной из страниц повышение порога до хотя бы минимальной разборчивости синего текста привело к появлению в черных формулах лишних знаков - "проявились" просвечивающие символы с обратной стороны страницы.
Я раньше пытался решить подобную задачу через выделение цветовой компоненты и их отдельной бинаризации с последующей склейкой. Но технология Separator 2.0 мне кажется гораздо "технологичнее" (естественно, там есть куда развиваться - в частности, нужен быстрый алгоритм для выделения отдельных символов для их последующей заливки, да и вместо HSV логики сравнения наверное можно придумать что-нибудь более наукоемкое).
Цитата:
Кстати, Вы случайно не делали программку для извлечения угла поворота и размеров полезной области из ST-проекта в какой-нибудь текстовой файл?
Не совсем понял, а какой в этом смысл - все равно парсить придется, так не все ли равно что парсить - xml-проекта или текстовый файл со вновь придуманной структурой?
Цитата:
Она бы очень помогла при обработке книги такого типа.
Поясните, поподробнее, как именно?
anagnost96
Цитата:
Я с большой степенью уверенности считаю, что Bottou/LeCun имеют таки копирайт на тот код, который перешел из djvulibre в minidjvu, даже если он перешел не в чистом виде. А версию djvulibre под GPL3 выпустить конечно можно, потому что они поменяли лицензию на "GPL2 или выше". Поменяли с разрешения других держателей копирайта надо сказать. Свой копирайт добавить тоже можно, но нельзя убирать копирайт других авторов.
В общем работа по привидению всего этого в порядок мне предстоит не из легких и не из приятных, ну что поделаешь.
Прошу не считать мои возражения придирками. Кто действительно придирается, так это Линукс дистрибутивы. К ST например придрались из-за одной иконки под лицензией Creative Commons. Если бы я иконки держал отдельно от исполнительного файла, тогда проблем бы не было. А у меня они вкомпилированы прямо в экзешник, в результате чего нарушается GPL, с которой не совместима Creative Commons.
Цитата:
Большая часть кода (и C, и С++) как-то соотносится с кодом из djvulibre. Наиболее близок zp-кодер и Ваш bzz. Но это не означает, что Bottou/LeCun имеют копирайт на код minidjvu. Например, любой имеет право выпустить копию djvulibre под GPL3 и своим копирайтом, разумеется при условии, что все ссылки проставлены.
Я с большой степенью уверенности считаю, что Bottou/LeCun имеют таки копирайт на тот код, который перешел из djvulibre в minidjvu, даже если он перешел не в чистом виде. А версию djvulibre под GPL3 выпустить конечно можно, потому что они поменяли лицензию на "GPL2 или выше". Поменяли с разрешения других держателей копирайта надо сказать. Свой копирайт добавить тоже можно, но нельзя убирать копирайт других авторов.
В общем работа по привидению всего этого в порядок мне предстоит не из легких и не из приятных, ну что поделаешь.
Прошу не считать мои возражения придирками. Кто действительно придирается, так это Линукс дистрибутивы. К ST например придрались из-за одной иконки под лицензией Creative Commons. Если бы я иконки держал отдельно от исполнительного файла, тогда проблем бы не было. А у меня они вкомпилированы прямо в экзешник, в результате чего нарушается GPL, с которой не совместима Creative Commons.
StanFreeWare
Цитата:
txt файл можно и batником парсить в цикле FOR, с xml сложнее.
Цитата:
Хотелось бы обработать отдельно синий и ч/б слои, но для того, чтобы собрать слои в конце в один файл надо знать углы поворота и параметры обрезки полей.
В идеале, как я представляю, после обработки должно быть получится 2 файла: ч/б/синий с текстом и lineart для малоцветного кодирования в cpaldjvu и ч/б/синий - с растровыми картинками для кодирования в c44 , затем эти djvu файлы объединяются в один.
Цитата:
а какой в этом смысл - все равно парсить придется
txt файл можно и batником парсить в цикле FOR, с xml сложнее.
Цитата:
Поясните, поподробнее, как именно?
Хотелось бы обработать отдельно синий и ч/б слои, но для того, чтобы собрать слои в конце в один файл надо знать углы поворота и параметры обрезки полей.
В идеале, как я представляю, после обработки должно быть получится 2 файла: ч/б/синий с текстом и lineart для малоцветного кодирования в cpaldjvu и ч/б/синий - с растровыми картинками для кодирования в c44 , затем эти djvu файлы объединяются в один.
Добрых суток всем, я (Илья) наконец подумал над лицензией minidjvu и пришел к такому выводу. Тут надо не GPL 2+, а 3+, и вот почему. Лицензия на DjVu Reference Library, выданная LizardTech'ом, дает право только на некоторые патенты, связанные с DjVu, но не на все.
Конкретно,
[quote="http://djvu.sourceforge.net/licensing.html"]
everyone is allowed to distribute a modified version of the DjVu Reference Library under the GPL, provided that this modified version does not contain additional patent infringements.
[/quote]
minidjvu косвенно (через DjVuLibre) является модифицированной версией DjVu Reference Library, но предоставляет и дополнительную функциональность, а именно многостраничное сжатие. На него есть патенты - например, Леон объяснял мне, что просто сжать каждую страницу отдельно, а потом собрать общий словарь нельзя, потому что этот способ запатентован. На патенты, относящиеся к многостраничному сжатию, лицензия от LizardTech не распространяется. Следовательно, нужна хоть какая-то защита от патентных исков.
GPL 3 содержит весьма занимательное условие, что подающий в суд насчет патентов лишается лицензии сразу же и независимо от исхода дела. Это даст некоторую защиту от исков и позволит спокойнее реализовывать предположительно патентованные алгоритмы.
Есть ли какие-нибудь причины оставить GPL 2?
Конкретно,
[quote="http://djvu.sourceforge.net/licensing.html"]
everyone is allowed to distribute a modified version of the DjVu Reference Library under the GPL, provided that this modified version does not contain additional patent infringements.
[/quote]
minidjvu косвенно (через DjVuLibre) является модифицированной версией DjVu Reference Library, но предоставляет и дополнительную функциональность, а именно многостраничное сжатие. На него есть патенты - например, Леон объяснял мне, что просто сжать каждую страницу отдельно, а потом собрать общий словарь нельзя, потому что этот способ запатентован. На патенты, относящиеся к многостраничному сжатию, лицензия от LizardTech не распространяется. Следовательно, нужна хоть какая-то защита от патентных исков.
GPL 3 содержит весьма занимательное условие, что подающий в суд насчет патентов лишается лицензии сразу же и независимо от исхода дела. Это даст некоторую защиту от исков и позволит спокойнее реализовывать предположительно патентованные алгоритмы.
Есть ли какие-нибудь причины оставить GPL 2?
alihv
Добро пожаловать, Илья.
Цитата:
Для себя таких причин не вижу. ST идет под GPL3+
Чтобы лишний раз вас не напрягать, я собираюсь сам подготовить соответствующий патч, если не возражаете. Только сообщите свою строку копирайта, типа:
Copyright (C) John Smith <john.smith@gmail.com>
От anagnost96 жду того же самого.
Добро пожаловать, Илья.
Цитата:
Есть ли какие-нибудь причины оставить GPL 2?
Для себя таких причин не вижу. ST идет под GPL3+
Чтобы лишний раз вас не напрягать, я собираюсь сам подготовить соответствующий патч, если не возражаете. Только сообщите свою строку копирайта, типа:
Copyright (C) John Smith <john.smith@gmail.com>
От anagnost96 жду того же самого.
alihv
Цитата:
А как тогда будет сочетать 3+ со своими программами в 2+?
Добавлено:
Цитата:
Непонятно. Можно подробнее?
Цитата:
Тут надо не GPL 2+, а 3+, и вот почему.
А как тогда будет сочетать 3+ со своими программами в 2+?
Добавлено:
Цитата:
Леон объяснял мне, что просто сжать каждую страницу отдельно, а потом собрать общий словарь нельзя, потому что этот способ запатентован. На патенты, относящиеся к многостраничному сжатию, лицензия от LizardTech не распространяется.
Непонятно. Можно подробнее?
alihv
Цитата:
Видимо, в случае перехода minidjvu на 3+, прийдётся сделать ответвление на 2+. Т.е. вместо одного нынешнего minidjvu появится два - на 2+ и на 3+.
Цитата:
Тут надо не GPL 2+, а 3+, и вот почему.
Видимо, в случае перехода minidjvu на 3+, прийдётся сделать ответвление на 2+. Т.е. вместо одного нынешнего minidjvu появится два - на 2+ и на 3+.
Опубликовал ST Separator 2.1
Добавил масштабирование субсканов иллюстраций в меньшее разрешение и возможность по ходу разделения субсканов удалять содержимое папки Out.
Добавил масштабирование субсканов иллюстраций в меньшее разрешение и возможность по ходу разделения субсканов удалять содержимое папки Out.
Автору ST:
Прежде всего - огромное спасибо за прогу!
Я очень давно не заглядывал сюда на форум, поэтому, если повторю, что уже было - простите.
Отсканировал несколько десятков толстых (по 1500 стр) книг, пропустил через ST, удалил по-глупости исходники, и только потом обнаружил, что некоторые сканы, полученные сканы после ST УРЕЗАНЫ по ШИРИНЕ, а некоторые - по ВЫСОТЕ!
На форумах, где обсуждается ST уже не раз писали пожелания о том, чтобы программа могла показывать самые МАЛЕНЬКИЕ сканы по ВЫСОТЕ и по ШИРИНЕ (как это есть сейчас для самых больших). Пожалуйста, может вы сделаете это в следующем релизе? Это не каприз юзеров - я реально запортил несколько десятков тысяч страниц - исходники не сохранил, чтобы прислать вам.
Спасибо за понимание...
Прежде всего - огромное спасибо за прогу!
Я очень давно не заглядывал сюда на форум, поэтому, если повторю, что уже было - простите.
Отсканировал несколько десятков толстых (по 1500 стр) книг, пропустил через ST, удалил по-глупости исходники, и только потом обнаружил, что некоторые сканы, полученные сканы после ST УРЕЗАНЫ по ШИРИНЕ, а некоторые - по ВЫСОТЕ!
На форумах, где обсуждается ST уже не раз писали пожелания о том, чтобы программа могла показывать самые МАЛЕНЬКИЕ сканы по ВЫСОТЕ и по ШИРИНЕ (как это есть сейчас для самых больших). Пожалуйста, может вы сделаете это в следующем релизе? Это не каприз юзеров - я реально запортил несколько десятков тысяч страниц - исходники не сохранил, чтобы прислать вам.
Спасибо за понимание...
Цитата:
Чтобы лишний раз вас не напрягать, я собираюсь сам подготовить соответствующий патч, если не возражаете. Только сообщите свою строку копирайта, типа:
Спасибо, я попробую сам. Мне хочется обновить что-нибудь еще, кроме шапки.
Цитата:
А как тогда будет сочетать 3+ со своими программами в 2+?
Кто?
Цитата:
Видимо, в случае перехода minidjvu на 3+, прийдётся сделать ответвление на 2+. Т.е. вместо одного нынешнего minidjvu появится два - на 2+ и на 3+.
Зачем?
Цитата:
Непонятно. Можно подробнее?
Точного текста Леона я не найду, но смысл такой. Самый простой способ разбить на кластеры все буквы в книге - это сначала отождествить буквы на каждой странице, выбрать из каждого кластера по представителю, а потом отождествлять глобально по всей книге эти представители. Но кто-то (то ли Samsung, то ли Motorola, не помню) что-то похожее уже запатентовал.
kvesda
Я изначально планировал сделать переключаемую сортировку на ленте предпросмотра - по ширине рамки контента, по высоте, и обычную. Однако в итоге решил, что отношение сложности реализации к полезности получается черезчур высокое.
Ничего не обещаю, но подумаю над этим вопросом.
alihv
Цитата:
Буду весьма признателен.
Я изначально планировал сделать переключаемую сортировку на ленте предпросмотра - по ширине рамки контента, по высоте, и обычную. Однако в итоге решил, что отношение сложности реализации к полезности получается черезчур высокое.
Ничего не обещаю, но подумаю над этим вопросом.
alihv
Цитата:
Спасибо, я попробую сам. Мне хочется обновить что-нибудь еще, кроме шапки.
Буду весьма признателен.
Узнал, скачал, собрал, установил. Проект крайне нужный и судя по тому, что я успел сделать с 16-страничным сканом, удобный. Тем не менее, на этапе "Полезная область" ST падает на федоре 11 x86_64.
Также 18 апреля было сообщение о падении на "Полезная область" в федоре 12-й.
http://sourceforge.net/tracker/index.php?func=detail&aid=2988928&group_id=227253&atid=1070628.
Я запустил scantailor из-под valgrind
$ valgrind --trace-children=yes --log-file=scantailor.err --error-limit=no --leak-check=full --show-reachable=yes -v --malloc-fill=0x00 --free-fill=0x00 scantailor
Привожу конец отчета (14299 строк):
==18037== LEAK SUMMARY:
==18037== definitely lost: 7,400 bytes in 21 blocks.
==18037== indirectly lost: 21,280 bytes in 662 blocks.
==18037== possibly lost: 160,313 bytes in 615 blocks.
==18037== still reachable: 21,746,177 bytes in 21,422 blocks.
==18037== suppressed: 0 bytes in 0 blocks.
--18037-- memcheck: sanity checks: 16101 cheap, 159 expensive
--18037-- memcheck: auxmaps: 3426 auxmap entries (219264k, 214M) in use
--18037-- memcheck: auxmaps_L1: 5146552 searches, 48075016 cmps, ratio 93:10
--18037-- memcheck: auxmaps_L2: 728606 searches, 3426 nodes
--18037-- memcheck: SMs: n_issued = 16280 (260480k, 254M)
--18037-- memcheck: SMs: n_deissued = 15526 (248416k, 242M)
--18037-- memcheck: SMs: max_noaccess = 524287 (8388592k, 8191M)
--18037-- memcheck: SMs: max_undefined = 433 (6928k, 6M)
--18037-- memcheck: SMs: max_defined = 6471 (103536k, 101M)
--18037-- memcheck: SMs: max_non_DSM = 1389 (22224k, 21M)
--18037-- memcheck: max sec V bit nodes: 133842 (11502k, 11M)
--18037-- memcheck: set_sec_vbits8 calls: 2098820 (new: 157128, updates: 1941692)
--18037-- memcheck: max shadow mem size: 37870k, 36M
--18037-- translate: fast SP updates identified: 129,328 ( 86.5%)
--18037-- translate: generic_known SP updates identified: 19,670 ( 13.1%)
--18037-- translate: generic_unknown SP updates identified: 476 ( 0.3%)
--18037-- tt/tc: 3,268,435 tt lookups requiring 39,778,656 probes
--18037-- tt/tc: 3,268,435 fast-cache updates, 8 flushes
--18037-- transtab: new 126,771 (3,371,448 -> 55,973,921; ratio 166:10) [0 scs]
--18037-- transtab: dumped 0 (0 -> ??)
--18037-- transtab: discarded 178 (3,947 -> ??)
--18037-- scheduler: 1,600,611,603 jumps (bb entries).
--18037-- scheduler: 16,101/4,198,464 major/minor sched events.
--18037-- sanity: 16102 cheap, 159 expensive checks.
--18037-- exectx: 98,317 lists, 76,897 contexts (avg 0 per list)
--18037-- exectx: 1,105,810 searches, 1,109,489 full compares (1,003 per 1000)
--18037-- exectx: 6,172,993 cmp2, 1,867 cmp4, 0 cmpAll
--18037-- errormgr: 1,025 supplist searches, 80,506 comparisons during search
--18037-- errormgr: 1,855 errlist searches, 1,890 comparisons during search
Также 18 апреля было сообщение о падении на "Полезная область" в федоре 12-й.
http://sourceforge.net/tracker/index.php?func=detail&aid=2988928&group_id=227253&atid=1070628.
Я запустил scantailor из-под valgrind
$ valgrind --trace-children=yes --log-file=scantailor.err --error-limit=no --leak-check=full --show-reachable=yes -v --malloc-fill=0x00 --free-fill=0x00 scantailor
Привожу конец отчета (14299 строк):
==18037== LEAK SUMMARY:
==18037== definitely lost: 7,400 bytes in 21 blocks.
==18037== indirectly lost: 21,280 bytes in 662 blocks.
==18037== possibly lost: 160,313 bytes in 615 blocks.
==18037== still reachable: 21,746,177 bytes in 21,422 blocks.
==18037== suppressed: 0 bytes in 0 blocks.
--18037-- memcheck: sanity checks: 16101 cheap, 159 expensive
--18037-- memcheck: auxmaps: 3426 auxmap entries (219264k, 214M) in use
--18037-- memcheck: auxmaps_L1: 5146552 searches, 48075016 cmps, ratio 93:10
--18037-- memcheck: auxmaps_L2: 728606 searches, 3426 nodes
--18037-- memcheck: SMs: n_issued = 16280 (260480k, 254M)
--18037-- memcheck: SMs: n_deissued = 15526 (248416k, 242M)
--18037-- memcheck: SMs: max_noaccess = 524287 (8388592k, 8191M)
--18037-- memcheck: SMs: max_undefined = 433 (6928k, 6M)
--18037-- memcheck: SMs: max_defined = 6471 (103536k, 101M)
--18037-- memcheck: SMs: max_non_DSM = 1389 (22224k, 21M)
--18037-- memcheck: max sec V bit nodes: 133842 (11502k, 11M)
--18037-- memcheck: set_sec_vbits8 calls: 2098820 (new: 157128, updates: 1941692)
--18037-- memcheck: max shadow mem size: 37870k, 36M
--18037-- translate: fast SP updates identified: 129,328 ( 86.5%)
--18037-- translate: generic_known SP updates identified: 19,670 ( 13.1%)
--18037-- translate: generic_unknown SP updates identified: 476 ( 0.3%)
--18037-- tt/tc: 3,268,435 tt lookups requiring 39,778,656 probes
--18037-- tt/tc: 3,268,435 fast-cache updates, 8 flushes
--18037-- transtab: new 126,771 (3,371,448 -> 55,973,921; ratio 166:10) [0 scs]
--18037-- transtab: dumped 0 (0 -> ??)
--18037-- transtab: discarded 178 (3,947 -> ??)
--18037-- scheduler: 1,600,611,603 jumps (bb entries).
--18037-- scheduler: 16,101/4,198,464 major/minor sched events.
--18037-- sanity: 16102 cheap, 159 expensive checks.
--18037-- exectx: 98,317 lists, 76,897 contexts (avg 0 per list)
--18037-- exectx: 1,105,810 searches, 1,109,489 full compares (1,003 per 1000)
--18037-- exectx: 6,172,993 cmp2, 1,867 cmp4, 0 cmpAll
--18037-- errormgr: 1,025 supplist searches, 80,506 comparisons during search
--18037-- errormgr: 1,855 errlist searches, 1,890 comparisons during search
Страницы: 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061
Предыдущая тема: CmCkA v4
Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.