Ластик - отличная идея. Часто использую в СК.
» Scan Tailor: Часть 2
Может тогда лучше, чтобы по клику по изображению просто вызывался внешний графический редактор? Любой, на усмотрение пользователя, какой пропишет в настройках.
Tulon
можно легко исправлять отдельные страницы в djvu-файле. Особенно если он сделан в cjb2, т.к. тогда джвю-файл просто является набором страниц без словарей. На стандартных утилитах djvulibre это выглядит так:
djvm -d file.djvu 142 # стереть страницу 142
djvm -i file.djvu newpage.djvu 142 # добавить новый файл как страницу 142
единственное, что будет нетривиально при выводе напрямую в джвю-файл, это отслеживать страницы, которые ещё не обработаны, а также правильно закодировать страницы, содержащие цвет.
но лучше наверно отделить джвю-вывод от самого СТ.
можно легко исправлять отдельные страницы в djvu-файле. Особенно если он сделан в cjb2, т.к. тогда джвю-файл просто является набором страниц без словарей. На стандартных утилитах djvulibre это выглядит так:
djvm -d file.djvu 142 # стереть страницу 142
djvm -i file.djvu newpage.djvu 142 # добавить новый файл как страницу 142
единственное, что будет нетривиально при выводе напрямую в джвю-файл, это отслеживать страницы, которые ещё не обработаны, а также правильно закодировать страницы, содержащие цвет.
но лучше наверно отделить джвю-вывод от самого СТ.
are
Надо полагать при вставке страницы в DJVU файл у этой страницы будет отдельный словарь. Соответственно нельзя строить концепцию сборки DJVU файла на итеративном добавлении страниц.
Да и других причин хватает для того, чтобы не пихать эту функциональность в ST.
Надо полагать при вставке страницы в DJVU файл у этой страницы будет отдельный словарь. Соответственно нельзя строить концепцию сборки DJVU файла на итеративном добавлении страниц.
Да и других причин хватает для того, чтобы не пихать эту функциональность в ST.
Цитата:
Ластик - отличная идея. Часто использую в СК.
Про ластик тут кричит каждый второй. Именно кричит, потому что Tulon, к сожалению, уверен, что не хочет, а не может, его прикрутить. Программа сейчас лучшая в своем сегменте по пакетной обработки сырых сканов. Если делать все в одном, будет ну очень много кипеша. Понятным развитием программы есть внедрение работающего алгоритма dewarp. И ластика
Растровый ластик я делать не хочу, так как это не вписывается в концепцию ST. Если конкретнее, то это противоречит тезису о том, что все манипуляции с изображениями должны быть отражены в файле проекта.
Ластик, базирующийся на зонах, сделать несложно, учитывая что зоны были спроектированы с прицелом на повторное использование. Почему до сих пор не сделал? Потому что были и остаются задачи важнее.
Кстати мое отношение к фич реквестам не изменилось - снятие игнора было временным в связи с надвигавшимся релизом.
Ластик, базирующийся на зонах, сделать несложно, учитывая что зоны были спроектированы с прицелом на повторное использование. Почему до сих пор не сделал? Потому что были и остаются задачи важнее.
Кстати мое отношение к фич реквестам не изменилось - снятие игнора было временным в связи с надвигавшимся релизом.
Tulon
Считаете ли Вы целесообразным введение дополнительной галки "Не выравнивать освещение в зонах" и для смешанного режима?
Я считаю, что такая галка поможет охватить "сложные для СТ случаи", частично засвечивающие иллюстрацию, например, при касании зоной края изображения.
Или у Вас есть свои идеи по поводу данной проблемы?
Считаете ли Вы целесообразным введение дополнительной галки "Не выравнивать освещение в зонах" и для смешанного режима?
Я считаю, что такая галка поможет охватить "сложные для СТ случаи", частично засвечивающие иллюстрацию, например, при касании зоной края изображения.
Или у Вас есть свои идеи по поводу данной проблемы?
StanFreeWare
Цитата:
В крайнем случае так и сделаю, если ничего лучше не придумаю. Когда - не обещаю.
Цитата:
Считаете ли Вы целесообразным введение дополнительной галки "Не выравнивать освещение в зонах" и для смешанного режима?
В крайнем случае так и сделаю, если ничего лучше не придумаю. Когда - не обещаю.
Цитата:
are
Надо полагать при вставке страницы в DJVU файл у этой страницы будет отдельный словарь. Соответственно нельзя строить концепцию сборки DJVU файла на итеративном добавлении страниц.
Да и других причин хватает для того, чтобы не пихать эту функциональность в ST.
здесь как раз словарь не важен: т.к. вы будете использовать djvulibre, другого варианта нет для работы с джвю, то там нельзя создавать многостраничные словари и всё равно каждая страница будет с отдельным словарём.
преимущество такое: на выходе программы будет не директория с большим количеством тиффов, а один готовый к просмотру джвю файл. Размеры этого файла будут примерно вдвое меньше, чем суммарный размер тиффов (если они чёрно-белые и сжаты с tiff/G4)
далее этот джвю файл конечно придётся пережимать более оптимально, что может сократить его размер ещё примерно втрое.
можно создавать многостраничный тифф на выходе, но такое почти никто не умеет просматривать.
можно создавать многостраничный пдф на выходе, это будет по объёму равно общему объёму тиффов. Но джвю проще.
далее, по поводу ластика. Насколько я понял, ластик совершенно не вписывается в вашу архитектуру.
архитектуру я понимаю так:
- на входе - пачка тиффов
- во время обработки на всех этапах, кроме последнего, с этими тиффами ничего не делается, т.е. не производится никаких промежуточных тиффов, а происходит только предварительная обработка (детектирование зон и т.д.) и запоминание всех операций, которые надо будет потом с этими тиффами проделывать. Генерируются на диске только временные thumbnails для показа в правой полосе. В центральном окне каждый раз генерируется некая временная картинка, которая никуда не идёт и забывается при переходе на следующую страницу. (поэтому и некоторая задержка при листании - каждый раз считывается тифф файл, декодируется и т.д.)
- и только на последнем шаге наконец проделываются с каждым тиффом все запомненные операции (все шаги с первого до последнего) и пишется выходной файл в out/
конечно при такой архитектуре необходимо все операции запомнить в xml-файл проекта. Это хорошая идея - чтобы никаких промежуточных файлов не надо было иметь. Тогда операции с ластиком придётся тоже запоминать там же и выполнять на последнем этапе, а также на каждом этапе просмотра. Логичнее всего было бы разместить ластик на последнем этапе, там же, где и деспекл. Тогда не надо будет отслеживать операции с ластиком на предыдущих этапах. Операция с ластиком - это выбор размера ластика и последовательность отрезков прямых линий, которые пробежал ластик.
да, в принципе в ластике нет особой нужды - если ластик всё равно на последнем этапе, то почему бы просто не открыть гимп и не отредактировать все выходные тиффы в гимпе. Уж в гимпе-то ластиков очень много. Я бы на самом деле редактировал бы исходные сканы, а не выходные. Но если какой-нибудь примитивный ластик несложно добавить, то почему бы и нет.
are
Цитата:
Можно можно взять за bw-основу minidjvu (соответственно доработав его в плане быстродействия). Он нормально работает с многостраничными словарями, да и в плане качества не так уж плох (аккуратнее либровского jb2-кодера). Тогда можно сразу делать конкурентоспособные djvu.
Цитата:
Ластик, сохраняемый в векторном виде - это практически то же самое, что белая зона.
Чистить ластиком до обработки в СТ может быть чревато - получившиеся на месте мусора белые области будут вводить в заблуждение алгоритмы выравнивания освещения вплоть до некачественной бинаризации.
Цитата:
будете использовать djvulibre, другого варианта нет для работы с джвю
Можно можно взять за bw-основу minidjvu (соответственно доработав его в плане быстродействия). Он нормально работает с многостраничными словарями, да и в плане качества не так уж плох (аккуратнее либровского jb2-кодера). Тогда можно сразу делать конкурентоспособные djvu.
Цитата:
Операция с ластиком - это выбор размера ластика и последовательность отрезков прямых линий, которые пробежал ластик.
Ластик, сохраняемый в векторном виде - это практически то же самое, что белая зона.
Чистить ластиком до обработки в СТ может быть чревато - получившиеся на месте мусора белые области будут вводить в заблуждение алгоритмы выравнивания освещения вплоть до некачественной бинаризации.
StanFreeWare
а кто будет дорабатывать minidjvu?
и почему он аккуратнее? (т.е. я видел когда-то явные ошибки в cjb2 -lossy, но minidjvu по-моему мало тестировался вообще)
далее, конечно не надо делать белую зону - надо заливать не белым, а локально доминирующим цветом фона.
а кто будет дорабатывать minidjvu?
и почему он аккуратнее? (т.е. я видел когда-то явные ошибки в cjb2 -lossy, но minidjvu по-моему мало тестировался вообще)
далее, конечно не надо делать белую зону - надо заливать не белым, а локально доминирующим цветом фона.
are
Цитата:
Дело в том, что код, отвечающий за сжатие с потерями в djvulibre/cjb2, был предоставлен Ильей Межировым и взят не из какого иного места, как из старой версии minidjvu Так что minidjvu уже потому аккуратнее, что прошел с тех пор некоторый путь развития. В частности, значительная "работа над ошибками" была проделана мною при подготовке к последнему релизу.
Кроме того, в minidjvu есть алгоритм усреднения образцов, который, по моему опыту, существенно улучшает внешний вид знаков, т. к. позволяет сгладить случайные неровности.
Цитата:
и почему он аккуратнее?
Дело в том, что код, отвечающий за сжатие с потерями в djvulibre/cjb2, был предоставлен Ильей Межировым и взят не из какого иного места, как из старой версии minidjvu
Так что minidjvu уже потому аккуратнее, что прошел с тех пор некоторый путь развития. В частности, значительная "работа над ошибками" была проделана мною при подготовке к последнему релизу. Кроме того, в minidjvu есть алгоритм усреднения образцов, который, по моему опыту, существенно улучшает внешний вид знаков, т. к. позволяет сгладить случайные неровности.
Говоря о недостаточной оптимизации в плане быстродействия minidjvu я имел в виду следующее: кодирование 240 чб страниц в режиме lossless, 20 стр/словарь, 600dpi -
minidjvu 0.8 - 35мин, использование памяти 250 Мб
Djvu Small 0.4.2 (documenttodjvu) - 30сек, использование памяти 11 Мб.
anagnost96
как Вы считаете, есть ли возможность уменьшить этот гиганский разрыв между опенсорс и коммерческим jb2-кодировщиками (ведь в плане кодирования iw44 все более-менее приемлемо)?
minidjvu 0.8 - 35мин, использование памяти 250 Мб
Djvu Small 0.4.2 (documenttodjvu) - 30сек, использование памяти 11 Мб.
anagnost96
как Вы считаете, есть ли возможность уменьшить этот гиганский разрыв между опенсорс и коммерческим jb2-кодировщиками (ведь в плане кодирования iw44 все более-менее приемлемо)?
StanFreeWare
Цитата:
Зачем лишняя галка? Можно попробовать просто учитывать растр на этапе выравнивания освещения. Детектор растра в ST есть, только, как я понимаю, сейчас он используется после выравнивания освещения.
are
Цитата:
Я наоборот считаю, что набор тифов, как есть сейчас лучше, чем один djvu. Tiff - это уже фактически стандарт для изображений. Кодирование djvu это достаточно ресурсоемкая операция. Кроме того, не очень хорошо навязывание какого-то одного формата для выходного файла. Может быть человеку pdf или многостраничный tiff понадобится, а не djvu, или хочется немного дообработать выходные файлы во внешнем редакторе.
Лично меня устроил бы пункт в меню Файл/экспорт/djvu(pdf).
are
Цитата:
Как я понимаю, основная цель у автора minidjvu при написании программы была избежать ошибок замены символов. Поэтому у него и ниже скорость кодирования, из-за большей "аккуратности". Кстати, не советую кодировать в minidjvu с опциями -e и -l - буквы становятся слегка ступенчатыми.
Цитата:
Считаете ли Вы целесообразным введение дополнительной галки "Не выравнивать освещение в зонах" и для смешанного режима?
Зачем лишняя галка? Можно попробовать просто учитывать растр на этапе выравнивания освещения. Детектор растра в ST есть, только, как я понимаю, сейчас он используется после выравнивания освещения.
are
Цитата:
преимущество такое: на выходе программы будет не директория с большим количеством тиффов, а один готовый к просмотру джвю файл.
Я наоборот считаю, что набор тифов, как есть сейчас лучше, чем один djvu. Tiff - это уже фактически стандарт для изображений. Кодирование djvu это достаточно ресурсоемкая операция. Кроме того, не очень хорошо навязывание какого-то одного формата для выходного файла. Может быть человеку pdf или многостраничный tiff понадобится, а не djvu, или хочется немного дообработать выходные файлы во внешнем редакторе.
Лично меня устроил бы пункт в меню Файл/экспорт/djvu(pdf).
are
Цитата:
и почему он аккуратнее? (т.е. я видел когда-то явные ошибки в cjb2 -lossy, но minidjvu по-моему мало тестировался вообще)
Как я понимаю, основная цель у автора minidjvu при написании программы была избежать ошибок замены символов. Поэтому у него и ниже скорость кодирования, из-за большей "аккуратности". Кстати, не советую кодировать в minidjvu с опциями -e и -l - буквы становятся слегка ступенчатыми.
U235
Цитата:
Цель была сделать хоть какой-нибудь алгоритм сжатия с потерями, поскольку свободных аналогов на тот момент не было вообще. Собственно, их нет и сейчас, поскольку, как я уже сказал, соответствующий код в djvulibre заимствован из старой версии minidjvu.
Цитата:
Дело не в аккуратности, а в поддержке разделенных словарей. Если от них отказаться (сжимать файлы по одному), скорость кодирования возрастет на порядок.
StanFreeWare
Разница в скорости по сравнению с коммерческим кодировщиком имеется (хотя я не уверен, что она столь значительна), но как с ней бороться, я по вышеуказанной причине не знаю. Естественно, что при обработке нескольких страниц приходится держать в памяти все символы с каждой из них, да еще и несколько раз пройтись по всему списку в процессе выявления однотипных. Есть какие-то идеи, как можно этот процесс оптимизировать?
Цитата:
Как я понимаю, основная цель у автора minidjvu при написании программы была избежать ошибок замены символов.
Цель была сделать хоть какой-нибудь алгоритм сжатия с потерями, поскольку свободных аналогов на тот момент не было вообще. Собственно, их нет и сейчас, поскольку, как я уже сказал, соответствующий код в djvulibre заимствован из старой версии minidjvu.
Цитата:
Поэтому у него и ниже скорость кодирования, из-за большей "аккуратности".
Дело не в аккуратности, а в поддержке разделенных словарей. Если от них отказаться (сжимать файлы по одному), скорость кодирования возрастет на порядок.
StanFreeWare
Разница в скорости по сравнению с коммерческим кодировщиком имеется (хотя я не уверен, что она столь значительна), но как с ней бороться, я по вышеуказанной причине не знаю. Естественно, что при обработке нескольких страниц приходится держать в памяти все символы с каждой из них, да еще и несколько раз пройтись по всему списку в процессе выявления однотипных. Есть какие-то идеи, как можно этот процесс оптимизировать?
да, думаю что будет тяжело увеличить скорость работы minidjvu в разы. Коммерческие алгоритмы для многостраничных словарей чуть ли не запатентованы. Но во всяком случае, думаю, что надо планировать возможность того, что тифф-файлы после scantailor будут обрабатываться дальше уже без участия человека для перевода в какой-либо другой формат.
Следовательно, необходимо лишь поместить эти тифф файлы в надёжный контейнер, из которого потом легко будет извлечь изображения страниц без каких-либо искажений и полностью автоматически. Вариантов три: lossless djvu, PDF, или просто архив zip.
Очевидно, что кодирование цветных страниц в djvu сопряжено с проблемами (оно не совсем lossless, т.к. происходит сегментация). zip архив нельзя сразу просматривать. Поэтому PDF кажется наиболее оптимальным вариантом как контейнер.
Перевод тиффов в пдф - операция несложная, не требующая кодирования, и сводящаяся лишь к копированию тифф-streams и заворачиванию их в какой-нибудь примитивно организованный пдф. Единственное, что нетривиально - указать правильные размеры страниц в пдф, чтобы получалось правильное разрешение, а то будут проблемы потом. Но это не слишком сложно, т.к. на выходе всегда все тиффы одинакового размера.
Следовательно, необходимо лишь поместить эти тифф файлы в надёжный контейнер, из которого потом легко будет извлечь изображения страниц без каких-либо искажений и полностью автоматически. Вариантов три: lossless djvu, PDF, или просто архив zip.
Очевидно, что кодирование цветных страниц в djvu сопряжено с проблемами (оно не совсем lossless, т.к. происходит сегментация). zip архив нельзя сразу просматривать. Поэтому PDF кажется наиболее оптимальным вариантом как контейнер.
Перевод тиффов в пдф - операция несложная, не требующая кодирования, и сводящаяся лишь к копированию тифф-streams и заворачиванию их в какой-нибудь примитивно организованный пдф. Единственное, что нетривиально - указать правильные размеры страниц в пдф, чтобы получалось правильное разрешение, а то будут проблемы потом. Но это не слишком сложно, т.к. на выходе всегда все тиффы одинакового размера.
anagnost96
Цитата:
Первое что пришло в голову это создать алгоритм вычисления хешей похожести символов и хранить в памяти их, будет требоваться дополнительное процессорное время на их вычисление, но сравниваться они будут быстрее. Кроме того вычисление все один раз производится, а сравнений много как я понял, в этом случае можно вообще пренебречь временем затраченным на вычисления. Плюс меньшие затраты по памяти. Другой вопрос где взять алгоритм, возможно стоит посмотреть в сторону алгоритма поиска дупликатов фото.
Еще вариант более приземленный, хранить уменьшенные копии образцов, строить списки похожих, подгружать по-очереди и сравнивать в полном объеме. Если сравнение меньших изображений будет быстрее протекать, то некоторое увеличение будет и по памяти меньше затраты. Его недостаток в том, что по сути это костыль и выше описанный метод будет работать еще быстрее и меньше затрат по памяти.
Цитата:
Естественно, что при обработке нескольких страниц приходится держать в памяти все символы с каждой из них, да еще и несколько раз пройтись по всему списку в процессе выявления однотипных.
Первое что пришло в голову это создать алгоритм вычисления хешей похожести символов и хранить в памяти их, будет требоваться дополнительное процессорное время на их вычисление, но сравниваться они будут быстрее. Кроме того вычисление все один раз производится, а сравнений много как я понял, в этом случае можно вообще пренебречь временем затраченным на вычисления. Плюс меньшие затраты по памяти. Другой вопрос где взять алгоритм, возможно стоит посмотреть в сторону алгоритма поиска дупликатов фото.
Еще вариант более приземленный, хранить уменьшенные копии образцов, строить списки похожих, подгружать по-очереди и сравнивать в полном объеме. Если сравнение меньших изображений будет быстрее протекать, то некоторое увеличение будет и по памяти меньше затраты. Его недостаток в том, что по сути это костыль и выше описанный метод будет работать еще быстрее и меньше затрат по памяти.
U235
Цитата:
Потому что он наровит тень в области корешка принять за картинку.
Цитата:
Зачем лишняя галка? Можно попробовать просто учитывать растр на этапе выравнивания освещения. Детектор растра в ST есть, только, как я понимаю, сейчас он используется после выравнивания освещения.
Потому что он наровит тень в области корешка принять за картинку.
Tulon
по поводу экспорта в пдф. Нашёл, что экспорт любого количества тиффов в корректный пдф (сжатие lzw) происходит так: (стандартная библиотека libtiff)
tiffcp *.tiff result.tif
tiff2pdf -z result.tif -o result.pdf
и всё.
по поводу экспорта в пдф. Нашёл, что экспорт любого количества тиффов в корректный пдф (сжатие lzw) происходит так: (стандартная библиотека libtiff)
tiffcp *.tiff result.tif
tiff2pdf -z result.tif -o result.pdf
и всё.
По поводу технологии создания малоцветных книг из проекта СТ, пройденного в режимах mixed и color.
Цветной текст бинаризуется, а раскрашивается уже потом, цвет берется из папки вывода color.
Получил первый результат.
Пока что привожу к чистым цветам по [more=простой пороговой формуле]
if (colorRow[xBlue] > 128 || colorRow[xRed] > 128 || colorRow[xGreen] > 128)
{
if ((colorRow[xBlue] > colorRow[xGreen] + 10) && (colorRow[xBlue] > colorRow[xRed]))
{
maskRow[x] = BLUE;
}
else if ((colorRow[xGreen] > colorRow[xBlue] + 10) && (colorRow[xGreen] > colorRow[xRed] + 10))
{
maskRow[x] = GREEN;
}
else if ((colorRow[xRed] > colorRow[xBlue] + 10) && (colorRow[xRed] > colorRow[xGreen] + 10))
{
maskRow[x] = RED;
}
else
maskRow[x] = WHITE;
}
[/more]
Есть намерение вставить эту логику в Separator.
Цветной текст бинаризуется, а раскрашивается уже потом, цвет берется из папки вывода color.
Получил первый результат.
Пока что привожу к чистым цветам по [more=простой пороговой формуле]
if (colorRow[xBlue] > 128 || colorRow[xRed] > 128 || colorRow[xGreen] > 128)
{
if ((colorRow[xBlue] > colorRow[xGreen] + 10) && (colorRow[xBlue] > colorRow[xRed]))
{
maskRow[x] = BLUE;
}
else if ((colorRow[xGreen] > colorRow[xBlue] + 10) && (colorRow[xGreen] > colorRow[xRed] + 10))
{
maskRow[x] = GREEN;
}
else if ((colorRow[xRed] > colorRow[xBlue] + 10) && (colorRow[xRed] > colorRow[xGreen] + 10))
{
maskRow[x] = RED;
}
else
maskRow[x] = WHITE;
}
[/more]
Есть намерение вставить эту логику в Separator.
are
Цитата:
Именно так все и есть.
Добавлено:
StanFreeWare
Цитата:
Выглядит впечатляюще. Правда если сделать зум на обычные черные буквы, то можно заметить у них на границе цветные пиксели. Кстати чем кодировали в DJVU?
Цитата:
архитектуру я понимаю так:
- на входе - пачка тиффов
- во время обработки на всех этапах, кроме последнего, с этими тиффами ничего не делается, т.е. не производится никаких промежуточных тиффов, а происходит только предварительная обработка (детектирование зон и т.д.) и запоминание всех операций, которые надо будет потом с этими тиффами проделывать. Генерируются на диске только временные thumbnails для показа в правой полосе. В центральном окне каждый раз генерируется некая временная картинка, которая никуда не идёт и забывается при переходе на следующую страницу. (поэтому и некоторая задержка при листании - каждый раз считывается тифф файл, декодируется и т.д.)
- и только на последнем шаге наконец проделываются с каждым тиффом все запомненные операции (все шаги с первого до последнего) и пишется выходной файл в out/
Именно так все и есть.
Добавлено:
StanFreeWare
Цитата:
По поводу технологии создания малоцветных книг из проекта СТ, пройденного в режимах mixed и color.
Цветной текст бинаризуется, а раскрашивается уже потом, цвет берется из папки вывода color.
Получил первый результат.
Выглядит впечатляюще. Правда если сделать зум на обычные черные буквы, то можно заметить у них на границе цветные пиксели. Кстати чем кодировали в DJVU?
Цитата:
Правда если сделать зум на обычные черные буквы, то можно заметить у них на границе цветные пиксели. Кстати чем кодировали в DJVU?
Видимо, слабовато условие по 10 градациям яркости. Слишком простая формула. Буду думать дальше.
Кодировал в FSD 1.2 (именно данную книгу, обычно используемая связка Small + Imager для малоцвета не подходит).
Кстати, так и не понял, какова лицензионная чистота его jb2-кодека, в том числе и с позиции упоминания утилиты в wiki к ST.
Убрал из логики определение зеленого и синего цвета. Поднял порог до 30. И, самое главное - убрал ветку, закрашивающую белым цветом - это абсолютно недопустимо.
Второй (и, видимо, окончательный) результат
Мусор не чистил сознательно, чтобы не удалить тонкие штрихи. По той же причине не бинаризовал часть каллиграфического текста.
Второй (и, видимо, окончательный) результат
Мусор не чистил сознательно, чтобы не удалить тонкие штрихи. По той же причине не бинаризовал часть каллиграфического текста.
StanFreeWare
На с. 131 черно-красные буквы почему-то ушли в фон.
На с. 131 черно-красные буквы почему-то ушли в фон.
anagnost96
Это сделано специально, как и на с.130. Там очень тонкие линии, которые при бинаризации исчезают. Поэтому вывел как фотозону.
Это сделано специально, как и на с.130. Там очень тонкие линии, которые при бинаризации исчезают. Поэтому вывел как фотозону.
В версии 0.9.8 обнаружился баг, из-за которого аггрессивность деспеклинга зависит от полуслучайных факторов. Баг исправлен, из-за чего аггрессивность в среднем понизилась. Просьба потестировать новую сборку на тему следующих вопросов:
1. Найдутся ли такие страницы, где средний веник уладяет лишнего?
2. Найдутся ли такие страницы, где малый веник бесполезен - не удаляет почти ничего, в то время как большой веник работает хорошо?
Новая сборка: http://www.onlinedisk.ru/file/404023/
Добавлено:
anagnost96
Я так понимаю вы один из разработчиков minidjvu? Если так, то хотелось бы поднять вопрос о перелицензировании его под GPL2+. Сейчас он под GPL2 only, а ST - под GPL3+, то есть лицензии несовместимы. С djvulibre проблем не будет, если вы с ней линкуетесь или заимствуете код, так как ее какое-то время назад уже перелицензировали под GPL2+.
1. Найдутся ли такие страницы, где средний веник уладяет лишнего?
2. Найдутся ли такие страницы, где малый веник бесполезен - не удаляет почти ничего, в то время как большой веник работает хорошо?
Новая сборка: http://www.onlinedisk.ru/file/404023/
Добавлено:
anagnost96
Я так понимаю вы один из разработчиков minidjvu? Если так, то хотелось бы поднять вопрос о перелицензировании его под GPL2+. Сейчас он под GPL2 only, а ST - под GPL3+, то есть лицензии несовместимы. С djvulibre проблем не будет, если вы с ней линкуетесь или заимствуете код, так как ее какое-то время назад уже перелицензировали под GPL2+.
Tulon
Я не то что бы разработчик: просто приложил определенные усилия к тому, чтобы полнее реализовать потенциал проекта и заодно адаптировать его к моим собственным нуждам В результате этого появилась версия 0.8.
Я так понимаю, проблема с лицензией только в том, что автор изначально поленился загнать уведомление о копирайте в болванку всех исходных файлов. В результате единственным упоминанием о лицензии в дереве проекта оказался файл COPYING, содержащий GPL2. Пееделывать это теперь, пожалуй, будет довольно долго и скучно. Достаточно ли просто положить в корень еще и файл COPYRIGHT, в котором будет написано, что, дескать, this software is subject to, and may be distributed under, the GNU General Public License, either Version 2 of the license, or (at your option) any later version?
Я не то что бы разработчик: просто приложил определенные усилия к тому, чтобы полнее реализовать потенциал проекта и заодно адаптировать его к моим собственным нуждам
В результате этого появилась версия 0.8. Я так понимаю, проблема с лицензией только в том, что автор изначально поленился загнать уведомление о копирайте в болванку всех исходных файлов. В результате единственным упоминанием о лицензии в дереве проекта оказался файл COPYING, содержащий GPL2. Пееделывать это теперь, пожалуй, будет довольно долго и скучно. Достаточно ли просто положить в корень еще и файл COPYRIGHT, в котором будет написано, что, дескать, this software is subject to, and may be distributed under, the GNU General Public License, either Version 2 of the license, or (at your option) any later version?
anagnost96
Цитата:
Основная проблема не в том, что менять каждый файл сложно, а в том, что менять лицензию можно только с разрешения владельца копирайта (всех владельцев - если их несколько). Например в архиве исходников djvulibre лежит PDF email'а от LizardTech, в котором они разрешают поменять лицензию с GPL2 only на GPL2 or above.
И прописать лицензию и авторство в каждом файле - дело тоже весьма желательное.
Цитата:
Я так понимаю, проблема с лицензией только в том, что автор изначально поленился загнать уведомление о копирайте в болванку всех исходных файлов. В результате единственным упоминанием о лицензии в дереве проекта оказался файл COPYING, содержащий GPL2. Пееделывать это теперь, пожалуй, будет довольно долго и скучно. Достаточно ли просто положить в корень еще и файл COPYRIGHT, в котором будет написано, что, дескать, this software is subject to, and may be distributed under, the GNU General Public License, either Version 2 of the license, or (at your option) any later version?
Основная проблема не в том, что менять каждый файл сложно, а в том, что менять лицензию можно только с разрешения владельца копирайта (всех владельцев - если их несколько). Например в архиве исходников djvulibre лежит PDF email'а от LizardTech, в котором они разрешают поменять лицензию с GPL2 only на GPL2 or above.
И прописать лицензию и авторство в каждом файле - дело тоже весьма желательное.
Tulon
Ну так авторов всего двое: Илья Межиров и отчасти я. Кроме того, кое-какой код заимствован из djvulibre, но с ним, как я понял, проблем нет.
Ну так авторов всего двое: Илья Межиров и отчасти я. Кроме того, кое-какой код заимствован из djvulibre, но с ним, как я понял, проблем нет.
anagnost96
Хорошо. Давайте тогда совместными усилиями урегулируем этот вопрос. Чтобы не грузить вас с Ильей, я сам сделаю необходимые изменения в исходниках и потом вышлю вам diff.
От вас мне понадобится следующая информация:
1. Какие из файлов содержат код от djvulibre?
2. Какие из файлов содержат ваш код? В крайнем случае я могу это и сам узнать, просмотрев логи SVN для каждого из файлов.
3. Строчки копирайта вашего и Ильи, что-то типа:
Copyright (C) 2005-2010 John Smith <john.smith@gmail.com>
Даты можно не писать - их обычно пишут если человек на совсем отошел от проекта.
Кроме того надо будет получить согласие от Ильи. Идеальный вариант - ветка на форуме (списка рассылки я так понимаю у вас нет), в которой он и вы отпишитесь о своем согласии поменять лицензию на GPL2+. Потом один из вас закоммитит изменения.
Так все будет по правилам. А иначе получается даже, что вы сами нарушаете лицензию GPL, используя код от djvulibre без упомянания о его происхождении.
Добавлено:
Еще одна (решаемая) проблема будет в случае, если вы взяли код из djvulibre до того, как они сменили лицензию на GPL2+. В этом случае придется этот код обновить. Это я тоже могу взять на себя.
Хорошо. Давайте тогда совместными усилиями урегулируем этот вопрос. Чтобы не грузить вас с Ильей, я сам сделаю необходимые изменения в исходниках и потом вышлю вам diff.
От вас мне понадобится следующая информация:
1. Какие из файлов содержат код от djvulibre?
2. Какие из файлов содержат ваш код? В крайнем случае я могу это и сам узнать, просмотрев логи SVN для каждого из файлов.
3. Строчки копирайта вашего и Ильи, что-то типа:
Copyright (C) 2005-2010 John Smith <john.smith@gmail.com>
Даты можно не писать - их обычно пишут если человек на совсем отошел от проекта.
Кроме того надо будет получить согласие от Ильи. Идеальный вариант - ветка на форуме (списка рассылки я так понимаю у вас нет), в которой он и вы отпишитесь о своем согласии поменять лицензию на GPL2+. Потом один из вас закоммитит изменения.
Так все будет по правилам. А иначе получается даже, что вы сами нарушаете лицензию GPL, используя код от djvulibre без упомянания о его происхождении.
Добавлено:
Еще одна (решаемая) проблема будет в случае, если вы взяли код из djvulibre до того, как они сменили лицензию на GPL2+. В этом случае придется этот код обновить. Это я тоже могу взять на себя.
Страницы: 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061
Предыдущая тема: CmCkA v4
Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.