» Scan Tailor

monday2000

Цитата:

Является ли интерфейс СК блокирующим? (Насколько я понимаю, да).

В СК - блокирующийся.


Цитата:

А как же гимповские плагины? Каждый же может написать свой плагин - неужели все делают неблокирующиеся?

В Gimp - неблокирующийся. Насчет всех плагинов сказать не могу, но первое что попробовал - нерезкая маска - неблокирующийся. Думаю в Gimp блокирующийся плагин либо совсем нельзя написать, либо нисколько не проще, чем неблокирующийся. Это кстати показатель хорошей архитектуры.

Rsbr

Цитата:

Спасибо за всякие красивости,только если они не будут сильно влиять на скорость.

На глаз замедления точно не заметите. По замерам получалось примерно 2% замедления из-за анимации на 1Ghz машине под Linux. На более современной машине, и под XP думаю пол процента будет, не больше.


Цитата:

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

А на огрызке другой страницы контент какой-нибудь был? Если нет - то это не проблема - можно хоть по линии разворота разрезать, хоть по внешней границе, хоть совсем ничего не отрезать. Ну а если контент был - давайте пример.


Цитата:

Вот здесь и начинаются проблемы,например таких страниц пара десятков и каждую поправить,при том что правка доступна секунд через 5 после выбора страницы в ленте просмотра.

Линию тягать действительно вам дадут не раньше, чем автомат определит ее положение. А вот переключит режим разреза (может этого будет достаточно в вашем случае) - можно сразу.

Tulon
Возможна ли переделка Лептоники (и иных блокирующихся) в неблокирующийся вид, и за счёт каких усилий? Ведь чисто в математическом смысле те алгоритмы ИМХО весьма любопытны - жаль их так просто отмести.

Добавлено:
Tulon
ИМХО неблокирующийся алгоритм наиболее хорош при визуальном подборе параметров какого-либо преобразования - как, например, в БукРесторере при подборе параметров бинаризации - двигаешь ползунки, и картинка сама тут же меняется соответственно (аналогичное есть в Корел Фото-Пайнте).

Просто я хотел сказать - это, конечно же, дополнительная и весьма существенная сложность - и, если бы Вы не стали с этим заморачиваться - то никто бы Вам ничего плохого не сказал. А так Вы добровольно взвалили на себя дополнительное бремя и лишние неудобства (вот теперь уж и Лептонику, оказывается, "нельзя использовать" ).

СК, к примеру, я всегда критиковал, конечно же, вовсе не за это - а за те откровенные и очевидные нелепости, которые там есть. ИМХО наличие там блокирующегося (а не неблокирующегося) интерфейса вполне удовлетворительно.

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

Цитата:

А на огрызке другой страницы контент какой-нибудь был? Если нет - то это не проблема - можно хоть по линии разворота разрезать, хоть по внешней границе, хоть совсем ничего не отрезать. Ну а если контент был - давайте пример.

Я наверное не смогу объяснить,что там есть,лучше один раз увидеть...
Вот несколько сканов которые СТ обрезает с левого края:
http://globz.ifolder.ru/11731073

monday2000

Цитата:

Возможна ли переделка Лептоники (и иных блокирующихся) в неблокирующийся вид, и за счёт каких усилий? Ведь чисто в математическом смысле те алгоритмы ИМХО весьма любопытны - жаль их так просто отмести.

От низкоуровневых алгоритмов неблокируемость как правило не требуется. У меня например все алгоритмы в imageproc блокирующиеся. Более высокоуровневые алгоритмы, которые строятся из низкоуровневых, могут просто после каждого этапа проверять атомарную переменную на предмет того, не отменено ли это задание. Если отменено - выкидывается исключение, которое потом ловится в диспетчере задач. Соответственно сами эти алгоритмы более высокого уровня, а также весь код, который их вызывает, должен быть exception-safe. Атомарную переменную выставляет главный поток (на котором работает GUI), а самой обработкой занимается фоновый поток. Короче перенести код из той же Leptonica - не проблема. Неблокируемость там не нужна (низкий уровень), exception-safety тоже не нужна (этот код не выкидывает исключения), но и просто так использовать leptonica тоже нельзя, точнее можно, при условии что ее объекты не будут перемещаться между потоками. Ну и с переносимостью там тоже плохо. В общем с лептоникой классическая проблема - авторы хорошо разбираются в проблемной области, но плохо в программировании.


Цитата:

Вы рискуете "утонуть" в сложностях.

Уже бы утонул, если бы не хорошая архитектура.

Rsbr

Цитата:

Я наверное не смогу объяснить,что там есть,лучше один раз увидеть...
Вот несколько сканов которые СТ обрезает с левого края:
http://globz.ifolder.ru/11731073

Клинический случай однако. По линии не получается разрезать, потому что от линии там только рваные остатки. По белому просвету тоже не получается - потому что внизу сильный мусор, да еще и черно-белый. Если сами сканировали - то зря конечно в черно-белом. Этим вы убили много полезной информации, и добавили трудноудалимый черно-белый мусор.

Цитата:

Клинический случай однако. По линии не получается разрезать, потому что от линии там только рваные остатки. По белому просвету тоже не получается - потому что внизу сильный мусор, да еще и черно-белый. Если сами сканировали - то зря конечно в черно-белом. Этим вы убили много полезной информации, и добавили трудноудалимый черно-белый мусор.

Нет,это обработка чужих сканов... Вообще такие гораздо проще обработать в ImageMagik или Gimp ,разрезать примерно а потом уже в CT ,почистит,наклон исправит...Эта книжка из 92 таких сканов и вот эти 15 определяются вот так...

Tulon
Значит, можно разделить задачу - одни могли бы заниматься алгоритмами, а другие - облекать их в нужную программную форму (это я не об СТ, а вообще).

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

А вот, если бы, все они, скажем, писали свои алгоритмы на базе, например, FreeImage - то у них было бы гораздо больше шансов на повторное использование.

так-с, система плагинов уже готова (на PyQt).
каждый модуль-плагин экпортирует объект-плагин cо своим описанием и и описанием всех параметров (для визуального отображения и справки юзверю).
сейчас дописываю GUI и систему работы с документами,страницами, слоями и выделенными зонами.

любое действие можно сделать мышкой в GUI или командой в скрипте.
любые сложные операции в свою очередь можно оформить в виде плагина.
например, добавить/удалить страницы, изменить размер/обрезать/скорректировать яркость/контраст всех страниц или только отдельных выделенных зон можно скриптом из нескольких строк текста.

Цитата:

Значит, можно разделить задачу - одни могли бы заниматься алгоритмами, а другие - облекать их в нужную программную форму (это я не об СТ, а вообще).

Можно конечно. Желающих только нет.


Цитата:

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

Это конечно затрудняет совмещение разных библиотек в одном проекте. Проблема там не в том, что каждая библиотека сама грузит картинки, а в том, что каждая библиотека имеет свою структуру данных для их хранения. И не все структуры одинакого полезны. Где-то формат хранения не подходящий - например черно-белые пиксели могут храниться как байты, или как биты, причем если биты - то еще вопрос, в каком порядке и какими кусками (байт?, 4 байта?). Для обработки изображений идеален вариант "биты, старшие слева". Размер куска при таком порядке битов значения не имеет, разве что с точки зрения выравнивания. Где-то другие недостатки - неатомарный подсчет ссылок, нет copy-on-write, неподходящее выравнивание. Я например не смотрел FreeImage, а если посмотрел бы, наверняка нашел бы недостатки. Я например написал свой класс для черно белых изображений, а для остальных использую QImage.

ukpyr

Цитата:

так-с, система плагинов уже готова (на PyQt).
каждый модуль-плагин экпортирует объект-плагин cо своим описанием и и описанием всех параметров (для визуального отображения и справки юзверю).
сейчас дописываю GUI и систему работы с документами,страницами, слоями и выделенными зонами.

Быстро вы однако. Посмотрю как выложите.

Tulon

Цитата:

Можно конечно. Желающих только нет.

Рискну предположить, что если будет графический движок (в виде хорошо документированного класса под VC++ или т.п.), то и желающие появятся.

Цитата:

Проблема там не в том, что каждая библиотека сама грузит картинки, а в том, что каждая библиотека имеет свою структуру данных для их хранения.

Ну да, я именно это и хотел сказать. Что так просто код из одной либы в другую не перекинешь (как правило), надо сидеть и думать.

Цитата:

Я например не смотрел FreeImage

черно-белые пиксели там хранятся битами - доступ через "ассемблерный" макрос.

Цитата:

"биты, старшие слева".

Там для этого макрос, который абстрагирует для юзера этот порядок. FreeImage ведь и под Линукс предназначена, и под Винду.
Выравнивание памяти - есть (для загруженных в память битмапов) - на границу двойного слова.

Tulon
Буржуины плачутся, что, мол, "в СТ в данный момент нет деспекла":
http://www.djvu.org/forum/phpbb/viewtopic.php?p=1534#1534

Цитата:

Рискну предположить, что если будет графический движок (в виде хорошо документированного класса под VC++ или т.п.), то и желающие появятся.

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


Цитата:

Цитата:
"биты, старшие слева".

Там для этого макрос, который абстрагирует для юзера этот порядок. FreeImage ведь и под Линукс предназначена, и под Винду.
Выравнивание памяти - есть (для загруженных в память битмапов) - на границу двойного слова.

Вот вам и причина, по которой объекты FreeImage, по крайней мере для черно-белых картинок, для наших целей не подходят. Вся черно-белая морфология реализуется как работа со словами, а не с битами. Благодаря этому скорость повышается в разы. Порядок битов должен быть известен заранее, причем "старшие слева" явно предпочтителен. С таким порядком размер слова не имеет значения, и одно и то же изображение можно обрабатывать хоть 32-битными кусками, хоть 64-битными.

Добавлено:

Цитата:

Буржуины плачутся, что, мол, "в СТ в данный момент нет деспекла":
http://www.djvu.org/forum/phpbb/viewtopic.php?p=1534#1534

Открыл им глаза.

После долгого перерыва испробовал последнюю версию.
Спасибо за сетку в Компенсации наклона. Уже пригодилась.
Правильно ли я понял, что теперь пакетная обработка начинается только с того скана, который активен в данный момент? Если я ошибаюсь, то как правильно звучит новшество в соответствующей ревизии программы?

выкладываю куски, может кому-нибудь будет интересно : http://ifolder.ru/11791295
Объекты-модули наследуются от класса Plugin, который наследуется от класса Introspectable object IObj (модуль ul_iobj.py), который может иметь произвольное количество объектов-атрибутов (свойств) IAttr. IAttr имеет такие свойства : tag - краткое англ.название, по которому производится чтение/запись этого атрибута, type - тип атрибута (str, int, float, bool, color и т.д.), name - полное название (с переводом через GetText), которое отображается пользователю в списке параметров, descr - полное описание (также с переводом), отображается как всплывающая подсказка или help, val - текущее значение, vals - список или диапазон возможных значений, val_def - значение по умолчанию, history - список-история введенных значений, и boolean свойства fixed - атрибут фиксирован (невозможно удалить), ro - значение не редактируется, hidden - атрибут скрыт от пользователя.
Класс Plugin определяет такие атрибуты-свойства плагинов : tag - краткое англ.название, name - полное назание (с переводом), descr - полное описание, params - список параметров, редактируемых пользователем, call - функция, вызываемая при запуске плагина.
Каждый модуль в папке плагинов при своем подключении создает объекты-плагины с заданными параметрами и списком параметров и включает их в общее дерево плагинов.
После загрузки всех плагинов они отображаются в виде дерева на панели плагинов. При выборе плагина параметры params отображаются на панели параметров. Для численных значений с заданным диапазоном отображаются слайдеры, для атрибутов 'color' - кнопки выбора цвета и т.д. Если для плагина задана функция call, ее можно вызвать с заданными параметрами, применив их к текущей странице, выбранной зоне и т.д.
Эту же операцию можно вызвать из скрипта, например так выглядит обработка всех страниц документа :

Код:
for page in app.documents.current:
for layer in page:
plugins.filters.contrast(app, documents, layer, {'level':75.0})

Цитата:

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

Да. Это полезно, когда вы запускаете пакетную обработку, следите за лентой предпросмотра, как видите проблемную страницу - останавливаете пакетную обработку, исправляете вручную, возобновляете пакетную обработку.

ukpyr
Пока что у вас получился сферический конь в ваакуме. До реальной программы еще очень и очень далеко.

Цитата:

Пока что у вас получился сферический конь в ваакуме. До реальной программы еще очень и очень далеко.

понятно, значит сказать Вам нечего. ухожу.

Цитата:

понятно, значит сказать Вам нечего. ухожу.

Ну ладно, вы сами напросились. Скачал и посмотрел ваш код. Что я там увидел? Практически ничего. Ничего связанного с обработкой графики или с интерфейсом пользователя - это точно. Есть абстрактый интерфейс плагинов - настолько абстрактный, что совершенно бесполезый. От плагина можно получить кое-какую мета-информацию, типа названия, автора, и вызвать некую операцию. Какие аргументы будут передаваться операции - неопределено. Как она будет взаимодействовать с интерфейсом пользователя - тоже непонятно.

Давайте проведу аналогию чтобы не-программисты поняли:
Вы говорите мне - а нельзя ли к вашему пароходу приделать колеса чтобы он смог по дорогам ездить, и крылья, чтобы смог летать. Я вам отвечаю - нельзя, плохо совместимые это вещи. Вы мне говорите - ничего сложного тут нет, сейчас быстренько следаю демонстрационный макет. В итоге вместо макета я получаю рисунок колеса. Что я должен на это ответить: "Да действительно все просто оказалось - сейчас наделаю таких колес и приделаю к пароходу"? Неужели вы думаете, что я не знаю, как выглядит колесо, или как делаются плагины? Сложность совсем не в этом.

Tulon

Цитата:

Те, кому в принципе под силу написать полноценное приложение - для них написать движок отображения не проблема

Значит, Вам добавить скроллбары в СТ не проблема? Это было бы весьма желательно.

Цитата:

Значит, Вам добавить скроллбары в СТ не проблема? Это было бы весьма желательно.

Скажем так, захотел бы - сделал бы. Не то, чтобы это совсем просто, но вполне реально. Скроллбаров на данный момент нет потому что:
1. В них нет особой необходимости.
2. Они мне не нравятся с эстетической точки зрения.

Tulon
Попалась мне одна книжка, где были полутоновые фотографии, и ещё явно нужно было сделать выравнивание освещённости. Получается, что Book Restorer не приспособлен именно для такого случая. Попробовал выровнять освещённость там - полутоновые фотографии безнадёжно запортились. Пришлось их потом вставлять вручную - т.е. исходные, незапорченные.

То выравнивание освещённости, которое есть в СК, ИМХО недостаточно - т.е. чисто визуально заметно, что освещённость после СК всё же не до конца выровнена (а вот после BR - полностью выровнена).

Значит, из числа особенных умений Book Restorer именно выравнивание освещённости наиболее желательно как можно более полноценно воспроизвести, скажем, в СТ.

Кстати, выпрямление искривленных строк ИМХО лучше всего делать уже над ЧБ-сканами - а не над "ещё серыми" сканами - потому что на "выпрямленных" серых сканах плохо видно, не покорёжил ли их Book Restorer при выпрямлении строк.

Что касается случая присутствия полутоновых фотографий, то мне представляется наиболее идеологически верным следующее:

1. Первое, что следует делать с сырыми сканами - это разрезать сдвоенные развороты.

2. Второе - это deskew (результат проверить и подкорректировать, если надо).

3. Затем - "вырезать" (т.е. не вырезать буквально, а копировать) из них полутоновые фотографии (в отдельные файлы).

4. Далее обрабатывать эти сырые сканы как обычно - как будто на них нет никаких полутоновых фотографий. Последовательность такая: выравнивание освещённости (если надо), апсемплинг 300->600, бинаризация, выпрямление искривленных строк (выпрямление уже над BW), кромсание (в единый размер).

Полутоновые фотографии же обрабатывать совершенно отдельно. Как правило, их обязательно требуется сильно осветлять - иначе они потом слишком "чёрные" получаются. Плюс, возможно, размытие растра.

И только на самом последнем этапе следует вставлять назад серые полутоновые фотографии в полностью готовые покромсанные ЧБ-сканы.

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

Вставлять полутоновые фотографии можно либо без слияния (с прицелом на последующий метод разделённых сканов (МРС), либо со слиянием (для тех, кто не любит МРС, предпочитая ему игру с настройками documenttodjvu).

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

Уж лучше с самого начала просто "отсечь в сторону" полутоновые фотографии - и спокойно работать над сырыми сканами как обычно - а в конце вернуть полутоновые фотографии на место. (Кстати, это также даст возможность применить Book Restorer для выравнивания освещённости - ведь картинок-то уже не будет. СК же, кстати, не допускает и мысли, что отдельные этапы обработки можно захотеть делать в сторонних программах.)

Но КАК их туда вернуть - вот это самое тут главное. Вручную ли, автоматом ли, или ещё как-то - вот в чём вопрос. Может, как-то автоматически "распознавать" исходные позиции полутоновых фотографий - и автоматически туда их вставлять. Или корректировать их координаты - через все обработки сырых сканов (что делается в СК).

Добавлено:
Забыл сказать - я для себя давно уже разделяю все сканы на 2 большие категории:

1. Сканы, не содержащие цветных объектов.

2. Сканы, содержащие цветные объекты.

Что делать с п.1 - принципиально более-менее ясно. Да и таких книг - подавляющее большинство. А со 2-м пунктом надо ещё будет разбираться отдельно.

monday2000
Для начала попробуйте сделать выравнивание освещения в СТ. Оно там как ни странно есть, причем в последних версиях его можно делать даже в режиме Цветной / Серый. Есть вероятность, что вы им останетесь довольны, и тогда мне не придется тратить время на разбор каждого пункта ваших предложений.

Выпустил версию 0.9.4.

Tulon

Цитата:

Выпустил версию 0.9.4.

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

Небольшие замечания:

1. Стоит ли вообще отображать в окне "файлы не в проекте" файлы, имеющие не-графические расширения?

2. Выходная папка имеет имя "out" - это создаст путаницу с СК-шными выходными папками (те тоже "out"). Скорее всего, на тех компах, где будет ставиться СТ, стоит также и СК.

3. Косячок русика: в пункте 6 "вывод" есть кнопка "применить к...". При её нажатии появляется окошко, где есть слово "Примененить".

Цитата:

Для начала попробуйте сделать выравнивание освещения в СТ.

Заметил, попробую. Но, вообще-то, дело не только в СК или СТ (или БР), любопытно ещё и саму идеологию методики сканобработки подетальнее продумать. ScanAndShare ИМХО ещё недостаточно детален.

Кстати, вот Вам важная ИМХО идея: подумайте над тем, сможет ли юзер делать отдельные этапы СТ-сканобработки в сторонних программах - СК, БР и т.д. Ну согласитесь, ни Вы, ни кто-либо ещё, не может быть семи пядей во лбу, чтобы наиидеальнейшим образом воплотить в своей программе все нужные алгоритмы. Какая-либо сторонняя программа может всё-таки делать некий данный алгоритм лучше. В СК эта идея ИМХО напрочь не учитывается.

Может быть, юзер захочет в процессе сканобработки перекидывать сканы из СТ -> СК -> БР -> СТ или как-то аналогично. Всё-таки имейте эту идею в виду, не отметайте её заранее (как это сделал bolega, БР и все остальные).

Добавлено:
Tulon
Сделайте, пожалуйста, где-то в программе упоминание о её лицензии. Например, добавьте пункт меню "About".

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

Tulon
Я скопировал Вашу документацию по Scan Tailor к себе на сайт сюда:

http://www.djvu-soft.narod.ru/st_index.htm

Просто мне читать её с SF неудобно - сайт у них довольно тормозной, загружается всё крякозяблами и надо вручную броузеру указать кодировку UTF-8, а если сохранить её на диск - то сбивается форматирование, и ширина становится больше, чем ширина экрана - так не почитаешь.

Заодно это сработает как ещё одно привлечение внимания общественности к Вашей программе (я поставлю ссылку на эту доку на главной странице моего сайта).

Цитата:

1. Стоит ли вообще отображать в окне "файлы не в проекте" файлы, имеющие не-графические расширения?

Я решил все-же отображать. Так по крайней мере понятно, что тот или иной файл просто не поддерживается. Если бы я их совсем не показывал, можно было бы заподозрить баг в программе. Главное что такие файлы не выбираются и не переносятся в проект.


Цитата:

2. Выходная папка имеет имя "out" - это создаст путаницу с СК-шными выходными папками (те тоже "out"). Скорее всего, на тех компах, где будет ставиться СТ, стоит также и СК.

Такая ли это большая проблема? Никто ведь не мешает изменить имя выходной директории. Впрочем если достаточное число людей попросит - изменю на output.


Цитата:

3. Косячок русика: в пункте 6 "вывод" есть кнопка "применить к...". При её нажатии появляется окошко, где есть слово "Примененить".

Я бы не сказал, что это косяк. Сам по себе диалог, в отрыве от кнопки, которая его открывает, выглядит вполне логично. А открыв диалог, вы быстро забудете, как называлась эта кнопка.


Цитата:

Заметил, попробую. Но, вообще-то, дело не только в СК или СТ (или БР), любопытно ещё и саму идеологию методики сканобработки подетальнее продумать. ScanAndShare ИМХО ещё недостаточно детален.

У меня компенсация освещения делается без особого обращения с картинками. С картинками происходит то же, что и с остальными частями страницы, а именно:
1. Они осветляются (настолько, чтобы окружающая их бумага стала белой).
2. Выравнивается контраст (где был низкий - повышается).


Цитата:

Кстати, вот Вам важная ИМХО идея: подумайте над тем, сможет ли юзер делать отдельные этапы СТ-сканобработки в сторонних программах - СК, БР и т.д. Ну согласитесь, ни Вы, ни кто-либо ещё, не может быть семи пядей во лбу, чтобы наиидеальнейшим образом воплотить в своей программе все нужные алгоритмы. Какая-либо сторонняя программа может всё-таки делать некий данный алгоритм лучше. В СК эта идея ИМХО напрочь не учитывается.

Это плохо вписывается в концепцию СТ. В СТ все стадии кроме последней производят не новое изображение, а новую информацию об исходном изображении. Если бы такая интеграция была бы сильно нужна, я бы все-же нашел способ ее реализовать. Но оно того не стоит.


Цитата:

Сделайте, пожалуйста, где-то в программе упоминание о её лицензии. Например, добавьте пункт меню "About".

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

Сделаю как руки дойдут, а пока держите под рукой инсталлятор - там полный текст лицензии приводится.


Цитата:

Я скопировал Вашу документацию по Scan Tailor к себе на сайт сюда:

http://www.djvu-soft.narod.ru/st_index.htm

Просто мне читать её с SF неудобно - сайт у них довольно тормозной, загружается всё крякозяблами и надо вручную броузеру указать кодировку UTF-8, а если сохранить её на диск - то сбивается форматирование, и ширина становится больше, чем ширина экрана - так не почитаешь.

Заодно это сработает как ещё одно привлечение внимания общественности к Вашей программе (я поставлю ссылку на эту доку на главной странице моего сайта).

ОК, я не против.

Добрый день!
Постепенно набираю опыт с СТ. Очень бы хотелось:
1) Автосохранения проекта после любого изменения настроек, по крайней мере после "применить ко всем" -- потому что СТ падает, а потом лихорадочно вспоминаешь, на какой странице остановился и что менял
2) Применения выбранной полезной области ко всем страницам -- очень надо, когда сканы уже обработаны
3) Автоматического выравнивания полезной области на странице (скажем, если полезная зона занимает меньше половины по высоте; а то я теперь стал просто выделять полезную область с дополнительным белым участком сверху или снизу -- потому что очень много ошибок на этапе ручного выравнивания)
4) Применения настроек не ко всем страницам, и не к текущей, а к нескольким, например, отмеченным некоторым образом (скажем, выделенным справа)
5) Отложенной обработки на этапе вывода (то есть когда опции меняются, а вывод происходит потом, когда пользователь нажимает на кнопку, а то очень долго ждать, особенно когда выводишь цветные вперемежку с черно-белыми в 600)
6) Одноэтапного вывода ("нажал кнопку и ложись спать", сейчас можно все сделать в два этапа, но потом же все равно приходится проходить и просматривать)
7) Регулировки "силы" смешанного вывода
8) Регулировки чувствительности автоматического выделения полезной области
9) Возможности править разрешение на начальном этапе, даже если разрешение уже указано в метаданных файлов
Мелочи:
-- После массового вывода страниц с середины до последней почему-то опять обрабатывается самая первая
-- Во время вывода выделена не текущая страница, а предыдущая
-- Во время выделения полезной области рамка области залезает на края букв, так что очень хочется ее раздвинуть, хотя это не нужно, поскольку область, если я правильно понимаю, маркируется _внешней_ границей рамки
И, конечно очень нужно удаление/добавление файлов, рисуночные зоны и возможность простейшего редактирования результата (хотя бы ластик). Но об этом уже много говорилось выше.
Все это -- результат работы с последней сборкой scantailor-2009-04-26-U235-Rev.355
Прошу прощения, что много. Накопилось.

Цитата:

Очень бы хотелось:
1) Автосохранения проекта после любого изменения настроек, по крайней мере после "применить ко всем" -- потому что СТ падает, а потом лихорадочно вспоминаешь, на какой странице остановился и что менял

Нужно решать саму проблему падений, а не изобретать костыли.
С оффициальным релизом 0.9.4 падает?
Где падает? На выводе? При взаимодействии с интерфейсом?
На пакетной обработке когда-либо вылетало?

Остальным: не надейтесь, что падения будут исправлены без вашего участия. У меня программа категорически отказывается падать. Если бы хоть раз упала - знал бы где искать проблему и уже давно бы нашел и исправил ее. Так что сообщайте о падениях, и давайте побольше деталей.


Цитата:

2) Применения выбранной полезной области ко всем страницам -- очень надо, когда сканы уже обработаны

Если у вас сканы так хорошо обработаны, что поля совершенно одинаковые, то зачем вам вообще понадобился СТ?


Цитата:

3) Автоматического выравнивания полезной области на странице (скажем, если полезная зона занимает меньше половины по высоте; а то я теперь стал просто выделять полезную область с дополнительным белым участком сверху или снизу -- потому что очень много ошибок на этапе ручного выравнивания)

Откуда программе знать, как именно выравнивать? В версии 0.9.4 я поменял выравнивание по умолчанию - теперь это "верх-центр", а не "центр-центр". Все-таки таких страниц гораздо больше.


Цитата:

4) Применения настроек не ко всем страницам, и не к текущей, а к нескольким, например, отмеченным некоторым образом (скажем, выделенным справа)

Это конечно полезная вещь, но сделать ее непросто, да и нужна она редко. Приведите что-ли примеры, где вам было нужно такое.


Цитата:

5) Отложенной обработки на этапе вывода (то есть когда опции меняются, а вывод происходит потом, когда пользователь нажимает на кнопку, а то очень долго ждать, особенно когда выводишь цветные вперемежку с черно-белыми в 600)

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


Цитата:

6) Одноэтапного вывода ("нажал кнопку и ложись спать", сейчас можно все сделать в два этапа, но потом же все равно приходится проходить и просматривать)

Надо думать, как это с точки зрения графического интерфейса реализовать.


Цитата:

7) Регулировки "силы" смешанного вывода

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


Цитата:

8) Регулировки чувствительности автоматического выделения полезной области

Там не один, а целый набор алгоритмов, и неочевидно, где именно нужно менять чувствительность. Давайте примеры в общем.


Цитата:

9) Возможности править разрешение на начальном этапе, даже если разрешение уже указано в метаданных файлов

Это пожалуй можно. Добавить просто чекбокс типа "Править DPI" в диалог "Файлы проекта".


Цитата:

-- После массового вывода страниц с середины до последней почему-то опять обрабатывается самая первая

Ну это меня попросили по окончании пакетной обработки переходить на первую страницу. Сейчас мне это уже не кажется такой уж хорошей идеей - такое поведение действительно сбивает с толку.


Цитата:

-- Во время вывода выделена не текущая страница, а предыдущая

Это специально сделано. Иначе текущая страница всегда была бы со знаком вопроса. Это не удобно для контроля ошибок в реальном времени по ленте предпросмотра.


Цитата:

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

Нет, внутренней. Идеальной визуальной точности достичь не получается - что при определении рамки, что при визуализации - выполняется преобразование изображения - разные преобразования, да еще и по разным алгоритмам - в одном случае моя реализация - в другом Qt'шная. В общем если видите, что автомат определил границу почти точно - в пределах толщины линии - считайте что она определена совсем точно.


Цитата:

И, конечно очень нужно удаление/добавление файлов, рисуночные зоны и возможность простейшего редактирования результата (хотя бы ластик). Но об этом уже много говорилось выше.

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

Большое спасибо за ответ.

Цитата:

Нужно решать саму проблему падений, а не изобретать костыли.

Полностью согласен. Однако мне кажется, что это очень бы помогло -- впереди не один релиз программы, она становится все сложнее, системы, где она используется, очень разные -- короче, за всем не уследишь. Падают любые программы, в том числе и великолепно отлаженные, и именно для таких случаев и введено автосохранение. Разумеется, я нажимаю Ctrl-S всегда, когда об этом вспоминаю, но я бы чувствовал себя гораздо комфортнее, если бы система делала это (хотя бы иногда) за меня.

Цитата:

С оффициальным релизом 0.9.4 падает?

Официальный релиз не пробовал. Чем он отличается от сборки 355? Если ли где-нибудь в доступности change log?

Цитата:

Где падает? На выводе? При взаимодействии с интерфейсом?

На выводе, при взаимодействии с интерфейсом -- если быстро листать в процессе. У меня была такая задача -- я взял PDF книги, разобрал на страницы и выводил его в смешанном режиме. Страницы, распознанные неверно -- перевыводил в черно-белом. Для этого я быстро листал превьюшки справа. Вот СТ и падал, примерно через каждые 50 страниц. Невоспроизводимо падал.

Цитата:

На пакетной обработке когда-либо вылетало?

Нет.

Цитата:

Если у вас сканы так хорошо обработаны, что поля совершенно одинаковые, то зачем вам вообще понадобился СТ?

Для того, чтобы вывести grayscale в черно-белый с улучшением качества. Поля не одинаковые, но меня устраивали. Пример я уже приводил -- книга, скачанная из Google Books. Другой пример -- PDF (кем-то аккуратно сделанный, скажем, через фотошоп) в DjVu. Или DjVu Photo -- в "нормальный" DjVu. Вообще, в случаях, когда требуется переделка уже "сделанной" книги.

Цитата:

Откуда программе знать, как именно выравнивать? В версии 0.9.4 я поменял выравнивание по умолчанию - теперь это "верх-центр", а не "центр-центр". Все-таки таких страниц гораздо больше.

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

Цитата:

Это конечно полезная вещь, но сделать ее непросто, да и нужна она редко. Приведите что-ли примеры, где вам было нужно такое.

Вывод книги с черно-белыми и цветными страницами. Я только этим практически и занимаюсь в СТ. Было бы замечательно пробежаться по проекту и пометить все черно-белые и цветные отдельно.
Другой пример -- обложка требует особых установок и по полезной области, и по полям/выравниванию, и по режиму. Однако обложка -- это, как правило, первый и последний файл проекта. Цветные вклейки. Вообще, любые вклейки.

Цитата:

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

Да, это я давно понял. Но я хотел бы вообще не заставлять СТ каждый раз что-то начинать обрабатывать, а просто изменять опции обработки в проекте. Так будет гораздо эффективнее работать, и ресурсов меньше расходуется.

Цитата:

6) Одноэтапного вывода ("нажал кнопку и ложись спать", сейчас можно все сделать в два этапа, но потом же все равно приходится проходить и просматривать)
Надо думать, как это с точки зрения графического интерфейса реализовать.

Просто разрешить пользователю сразу использовать кнопку пакетного режима в пункте "Вывод". Сейчас выскакивает сообщение, что сначала надо сделать полезную область/макет.

Цитата:

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

Ура! Спасибо!

Цитата:

Там не один, а целый набор алгоритмов, и неочевидно, где именно нужно менять чувствительность. Давайте примеры в общем.

OK, пример: в 30% случаев рамка не попадает на номер страницы. Разрешение установлено правильно. Что делать?

Цитата:

Это пожалуй можно. Добавить просто чекбокс типа "Править DPI" в диалог "Файлы проекта".

Спасибо!

Цитата:

Ну это меня попросили по окончании пакетной обработки переходить на первую страницу. Сейчас мне это уже не кажется такой уж хорошей идеей - такое поведение действительно сбивает с толку.

Я уже приспособился, но проблема такова: я устанавливаю для обложки цветной вывод без полей и выравнивания света (то есть я хочу только upsampling). Дальше по ходу просмотра я что-то применяю "ко всем страницам", запускаю, и получаю черно-белую обложку.
Кстати говоря, "что-то" -- это, как правило, отключение "удаления пятен". К сожалению, на моих книгах оно работает ужасно -- то стирает куски текста, то стирает текстовые точки или точки-лидеры в оглавлении.

Цитата:

Это специально сделано. Иначе текущая страница всегда была бы со знаком вопроса. Это не удобно для контроля ошибок в реальном времени по ленте предпросмотра.

OK, к этому можно приспособиться.

Цитата:

Нет, внутренней. Идеальной визуальной точности достичь не получается - что при определении рамки, что при визуализации - выполняется преобразование изображения - разные преобразования, да еще и по разным алгоритмам - в одном случае моя реализация - в другом Qt'шная. В общем если видите, что автомат определил границу почти точно - в пределах толщины линии - считайте что она определена совсем точно.

Понятно, спасибо.

Цитата:

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

Не знал, здОрово! Спасибо еще раз!

У меня программа пару раз падала при скролле окна с превьюшками после разрезания страниц и выделения полезной области. WinXP + SP2.

У меня тоже падала одной раз (0.9.4) при скролле окна с превьюшками после разрезания страниц и выделения полезной области. WinXP + SP3

Цитата:

Полностью согласен. Однако мне кажется, что это очень бы помогло -- впереди не один релиз программы, она становится все сложнее, системы, где она используется, очень разные -- короче, за всем не уследишь. Падают любые программы, в том числе и великолепно отлаженные, и именно для таких случаев и введено автосохранение. Разумеется, я нажимаю Ctrl-S всегда, когда об этом вспоминаю, но я бы чувствовал себя гораздо комфортнее, если бы система делала это (хотя бы иногда) за меня.

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


Цитата:

Официальный релиз не пробовал. Чем он отличается от сборки 355? Если ли где-нибудь в доступности change log?

По моему изменений со времени релиза не было. ChangeLog коммитов в SVN в принципе ведется, но хорошего сервиса для его просмотра нет. Тут давали ссылку на RSS feed этого ChangeLog'а, но там очень не удобно смотреть - в каждый пункт кликать надо. Вот здесь есть нормальный ChangeLog, но он всегда идет с опозданием.


Цитата:

Цитата:

Если у вас сканы так хорошо обработаны, что поля совершенно одинаковые, то зачем вам вообще понадобился СТ?

Для того, чтобы вывести grayscale в черно-белый с улучшением качества. Поля не одинаковые, но меня устраивали. Пример я уже приводил -- книга, скачанная из Google Books. Другой пример -- PDF (кем-то аккуратно сделанный, скажем, через фотошоп) в DjVu. Или DjVu Photo -- в "нормальный" DjVu. Вообще, в случаях, когда требуется переделка уже "сделанной" книги.

Если поля не идеально равны, то применения рамки контента ко всем страницам ни к чему хорошему не приведет.
Пожалуй это можно было бы вот так реализовать:
На первой стадии сделать галку "Только вывод". При этом все стадии кроме первой и последней становятся как бы read-only - зайти туда можно, менять ничего нельзя. Тип разреза будет "ничего не отрезать", компенсация наклона - 0, рамка контента - вся страница, поля - нулевые. Впрочем уже вижу проблему - выравнивание освещения будет плохо работать без правильно определенной рамки контента, особенно если линия разворота или темные края попали в скан.


Цитата:

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

Можно будет попробовать как-нибудь. Свободного времени очень мало - в рабочие дни практически совсем нет.


Цитата:

Было бы замечательно пробежаться по проекту и пометить все черно-белые и цветные отдельно.

Понятно. Фича действительно полезная, но все-же не на первом месте по приоритету.


Цитата:

OK, пример: в 30% случаев рамка не попадает на номер страницы. Разрешение установлено правильно. Что делать?

30% - очень много. У меня такое тоже бывает, но только на сильно неполных страницах, где этот номер очень далеко от остального текста. Если это решать изменением чувствительности, вместе с номером в рамку залезет и нижняя граница контента. Тут нужна особая обработка именно номеров страниц. Возможно оптическое распознавание символов - думаю цифры не так сложно будет распознать. Либо просто набор эвристик - внизу, короткая строка, выглядит как текст - значит номер страницы. Кстати оценка текст / не текст уже имеется, и она увеличивает шансы того, что считает текстом остаться в рамке, но при очень больших расстояниях он все равно убирается. Посмотреть, правильно ли определился текст, можно через режим отладки - Инструменты -> режим отладки, потом переключится в ручной режим и обратно (все это на стадии определения рамки). Потом ищите вкладку text_mask.


Цитата:

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

Вообще-то не хорошо так делать - применять ко всем страницам то, что им всем не подходит. Впрочем это навело меня на мысль добавить опцию "применить ко всем последующим".


Цитата:

Кстати говоря, "что-то" -- это, как правило, отключение "удаления пятен". К сожалению, на моих книгах оно работает ужасно -- то стирает куски текста, то стирает текстовые точки или точки-лидеры в оглавлении.

Ну в оглавлении это можно понять, а вот текстовые точки не должны удалятся - они ведь рядом с буквыми. Выложите пример файла, где такое происходит.


Цитата:

Просто разрешить пользователю сразу использовать кнопку пакетного режима в пункте "Вывод". Сейчас выскакивает сообщение, что сначала надо сделать полезную область/макет.

Сделать такое пожалуй можно, но с большой вероятностью все равно вывод придется переделывать - достаточно одной страницы с мусором, попавшем в рамку контента, чтобы распухли все файлы на выводе.