» Scan Tailor

Вопрос почему бы не сделать ST c "shared dll" ?

http://www.smlabs.net/tsmuxer.html
3mb static dll
300k shared dll

Цитата:

Уважаемые, быть может добавить в шапку
RSS ленты:

Для конечных пользователей может быть интересна разве что последняя лента - информация о релизах. Кстати SourceForge может и по мылу оповещать о них. Если зайти на сайт, оттуда на SourceForge Project Page -> Download -> Browse All Packages, то там иконки с конвертом - это как раз подписка на оповещение о релизах.


Цитата:

Вопрос почему бы не сделать ST c "shared dll" ?

То есть разделить пакет на две части - сама программа и библиотеки. Экономия будет только при обновлениях, а гемороя значительно прибавится - и пользователям, и мне. Например когда я захочу обновить какую-либо из этих библиотек, то придется писать на странице закачки: "если вы скачивали пакет с dll'ками до такого-то числа", значит вам нужно их обновить". Кстати в первый раз качать придется больше, чем сейчас - поскольку исполнительный файл + dll'ки будут всяко больше, чем статически скомпилированный исполнительный файл. В общем овчинка выделки не стоит. Что такое два-три лишних мега по сравнению с потерей удобства?

Tulon
При всём моём уважении-напишите линию партии, дабы не было таких вопросов.
Может как помочь ?

Цитата:

При всём моём уважении-напишите линию партии, дабы не было таких вопросов.
Может как помочь ?

Задавание вопросов - это как раз способ узнать линию партии.

А помочь всегда можно найти чем. Можно улучшить или нарисовать новую иконку к программе - кстати в ближайших сборках она уже будет нормально прицепляться к экзешнику. Можно улучшить документацию (на wiki можно вносить изменения без регистрации), можно сделать перевод на другой язык (пока есть английский и русский, скоро возможно будет немецкий). В конце концов можно пропиарить программу на своем блоге или где-нибудь еще. Больше известность -> больше пользователей -> больше вероятность найти еще программистов для участия в проекте.

Цитата:

так может быть, тогда сохранять все же файлы без подстроки "pic"

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

Цитата:

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

Тут поможет ручное выделение картинок, которое я еще не начал делать, хотя задача приоритетная. Уже почти сделал удаление / добавление файлов в проект, а потом как раз займусь ручным выделением картинок.
Кстати вместо фотошопа можно наверное приспособить СК. В СТ вывести в режиме Цветной / Серый и скормить это Кромсатору. Правда сглаживания букв не будет, то есть будет, но СК'шное.


Цитата:

Еще наблюлось, что при "удалять пятна" куски текста пропадают даже при адекватной установке разрешения. Пришлось эту галку отключить, а пятна удалять вручную.

Давайте пример. Это надо сказать довольно странно. Куски текста должны были сохраниться и на основании размера, и на основании близости к другим буквам. Кстати какая у вас версия?

Цитата:

Тут поможет ручное выделение картинок, которое я еще не начал делать, хотя задача приоритетная. Уже почти сделал удаление / добавление файлов в проект, а потом как раз займусь ручным выделением картинок.

ЗдОрово! Спасибо!

Цитата:

Давайте пример. Это надо сказать довольно странно. Куски текста должны были сохраниться и на основании размера, и на основании близости к другим буквам. Кстати какая у вас версия?

Версия Rev.326. Что касается примеров, то я уже сделал книгу (хорошо, кстати, получилась!), а исходные сканы, к сожалению, стер. Я с этим эффектом почему-то часто сталкиваюсь (некачественные сканы?), так что, как обнаружу в следующий раз, сохраню файлы.
Еще интересная штука: в некоторых файлах было (ошибочно) указано разрешение 300. У другой части файлов разрешение указано не было. В момент импорта ST попросил разрешение, я указал 150 для _всех_ файлов, однако у тех, у кого было 300, оно так и попало в проект. Когда это обнаружил (на этапе макета страницы, как водится), пришлось руками редактировать файл проекта. Хорошо, что он текстовый!

Цитата:

В момент импорта ST попросил разрешение, я указал 150 для _всех_ файлов, однако у тех, у кого было 300, оно так и попало в проект. Когда это обнаружил (на этапе макета страницы, как водится), пришлось руками редактировать файл проекта. Хорошо, что он текстовый!

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

iit512
http://apps.sourceforge.net/phpbb/scantailor/viewtopic.php?f=4&t=1&sid=decdefa21d408f7ad7b64d3136066a3a

Спасибо!

а можно реализовать представление страницы в виде слоев (типа Djvu) c возможностью независимого редактирования ?
плюс добавить возможность скриптования для автоматизации обработки.
чтобы можно было открыть Djvu файл, отредактировать фон (убрать пятна), передний план (сделать despeckle), и отредактировать текст, запаковать обратно с минимальными потерями.

ukpyr

Цитата:

а можно реализовать представление страницы в виде слоев (типа Djvu) c возможностью независимого редактирования ?
плюс добавить возможность скриптования для автоматизации обработки.

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

По второму пункту все еще туманнее. Какие именно задачи вы хотите решать с помощью скриптов?

ладно, попробую набросать на PyQt4 как я вижу это...

Цитата:

Очень абстрактные у вас запросы. Вы бы поконкретнее излагали свои пожелания.

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

Далее - система плагинов (на Питоне реализуется очень просто). Представляется в виде дерева :

Код:
Plugins
Scan
.............
OCR
Engine1
Engine2
...............
Filters
.............
Import
.............
Export
.............

ukpyr
Вы описали ни что иное, как графический редактор. Единственное, чего нет в существующих редакторах - это сегментации на текст и графику. Гораздо проще и правильнее будет написать плагин сегментации к какому-нибудь графическому редактору, чем преваращать СТ в графический редактор. У СТ совсем другая концепция: набор шагов -> результат. Вы предлагаете концепцию "Вот вам набор операций - делайте что хотите". В общем ваши предложения не вписываются в концепцию СТ.

Цитата:

Вы предлагаете концепцию "Вот вам набор операций - делайте что хотите". В общем ваши предложения не вписываются в концепцию СТ.

концепция та же ( http://pic.ipicture.ru/uploads/090126/5kOaoD2OOq.jpg ), я описал только только то чего мне не хватает - расширить количество операций над изображениями, возможность правильного импорта и редактирования Djvu, встроенный OCR (можно прикрутить cuneiform,tesseract,ocropus), запоминание и применение последовательности действий к страницам и т.д. Свободного граф.редактора с удобной работой с последовательностью изображений и фильтрами специально для обработки сканов я не нашел. Гимп - монстрообразен и неудобен. Наиболее близок к идеалу - XnView, но все убивает его лицензия и непонятки с системой плагинов (нет документации, писал автору - он прислал невнятный ответ и некомментированный исходник на С).

ukpyr

Цитата:

я описал только только то чего мне не хватает - расширить количество операций над изображениями, возможность правильного импорта и редактирования Djvu, встроенный OCR (можно прикрутить cuneiform,tesseract,ocropus), запоминание и применение последовательности действий к страницам и т.д.

Звучит примерно как: "Я прошу только самое необходимое: виллу на Мальдивах, личный самолет, яхту ...".
Вы где-нибудь видели OCR и графический редактор в одной программе? А все потому, что эти задачи предполагают разные пользовательские интерфейсы. Если отбросить OCR, то вы хотите графического редактора с пакетной обработкой и импортом DJVU. Работа со слоями - явный признак графического редактора. Встраивать такое в СТ - скрещивать ежа с ужом. СТ вообще не задумывался как инструмент для правки готовых DJVU файлов. СТ задумывался как автоматическая система преобразования сырых сканов в состояние, пригодное для сборки DJVU файов. Ручные операции, согласно задумке, были нужны для исправления ошибок автоматики и не более того. Согласно концепции СТ, ручные операции - это иногда необходимое зло, которого надо стараться избегать. То, что вы предлагаете - это как раз набор ручных операций, пусть и с возможностью их запуска в пакетном режиме.
Кстати каких имеено операций над изображениями вам нехватает?

Tulon
У меня возникла такая идея:

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

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

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

Например, именно так была создана библиотека FreeImage - один человек стал писать программку для работы с графикой - а потом выделил часть её функциональности в отдельную dll-библиотеку, задокументировал - и народ стал активно это дело развивать, и за 6 лет получился весьма приличный и удобный продукт (FreeImage).

Путь, конечно, непростой - но ИМХО наиболее верный - это если ставить цель привлечь разработчиков к созданию сканобрабатывающих программ.

Я не призываю Вас начать это делать немедленно. Просто задумайтесь о таком варианте и имейте его в виду.

Например, можно вычленить в такой модуль все алгоритмы. Ещё один модуль - работа с TIF под Qt.

Думаю автор FreeImage не просто так решил выделить функции работы с графикой в отдельную библиотеку, а по какому-то поводу. Может быть начал еще один проект, где нужна была работа с графикой, может захотелось на работе заюзать свой старый код. Затевать такое дело без повода - работа в холостую. Пользы ноль - только трудозатраты. Надежда на то, что библиотеку будут улучшать другие люди - весьма призрачна. Кому такая библиотека может понадобиться? Это не библиотека обработки изображений общего назначения - там есть только то, что мне было нужно. Видел я пару подобных библиотек - вот например. Тоже отпочковалась от кагого-то проекта. Никто кроме авторов ей похоже не занимается, и никому она больше не нужна. Впрочем один алгоритм я взял как раз оттуда. Такая же судьба скорее всего ожидала бы и СТшную библиотеку. Как я уже говорил, даже имея реализации всех нужных алгоритмов - сделать программу сканобработки - все равно очень сложная и объемная задача. Плюс ко всему 95% программистов просто не обладают для этого достаточной квалификацией, хотя отчета себе в этом не отдают. Тут нужны и знания и опыт. Кстати реакция типа "а что тут сложного" как раз является хорошим показателем отсутствия опыта.

а не встречали алгоритмов коррекции геометрии и освещенности как в Book Restorer ?
http://www.i2s-bookscanner.com/produits.asp?gamme=1011&sX_Menu_selectedID=leftV_1011_EDI_1003

Tulon

Цитата:

все равно очень сложная и объемная задача.

В чём именно сложность (в 2 словах)?

Цитата:

Надежда на то, что библиотеку будут улучшать другие люди - весьма призрачна. Кому такая библиотека может понадобиться?

У меня есть своя версия на эту тему. Я думаю, что народ делал бы альтернативы СК и аналогичное - если бы это не было столь неимоверно сложно. Не знаю, что там в Qt (расскажите), а вот в СК самое сложное (ИМХО) - это графический движок. Этот движок bolega либо взял уже готовый - из коммерческой библиотеки ImageLib (не знаю, есть он там (движок), или нет), либо ещё до начала работ над СК имел по нему изрядные наработки. Чудес-то не бывает - такие вещи, как графический движок, без подготовки за 1 месяц не пишутся (как bolega написал, что сделал это за месяц во время болезни).

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

Я видел несколько солидных программ (коммерческих и бесплатных) - где подобный графмческий движок имеет постыдные ляпы в реализации. Пример - Recogniform Image Processor (мерцание при скроллинге), СхImage Demo (тормоза при скролле на больших зумах). Всё указывает на то, что сделать такой (путёвый) движок - весьма непросто.

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

Кстати, иные попытки сделать программу сканобработки были - BFRS от Заскока и ещё (не помню как назывался) нечто - но всё это скончалось до меня.

Цитата:

Не знаю, что там в Qt (расскажите), а вот в СК самое сложное (ИМХО) - это графический движок.

что за граф.движок ? отображение страниц или их обработка ?
в Qt первое делается просто - читается картинка, масштабируется на виджет, отображается.
выделение зон и работа с граф.объектами - чуть сложнее.
главное - грамотная организация интерфейса и модульность программы.
базовая обработка есть - практически все базовые операции с изображениями есть в ImageMagick и других свободных библиотеках.
проблема пока с качественной обработкой сканов - чистка, коррекция геометрии, выделение зон, распознавание.
если это решится - можно легко переплюнуть Файнридер.

Цитата:

не встречали алгоритмов коррекции геометрии и освещенности как в Book Restorer ?
http://www.i2s-bookscanner.com/produits.asp?gamme=1011&sX_Menu_selectedID=leftV_1011_EDI_1003

Готовых не встречал. Ислледования на эту тему читал. Задача в принципе выполнима, но довольно трудозатратна, и к тому же низкоприоритетна, потому как редко бывает нужна. Это я про коррецкцию геометрии. Коррекция освещенности уже есть в СТ. Других готовых реализаций кстати я тоже не встречал.


Цитата:

В чём именно сложность (в 2 словах)?

Как описать вкус креветок тому, кто их не пробовал? Как описать сложность разработки большого проекта тому, кто таких проектов не разрабатыал?
Я все же попробую.
Сразу в отдельный пункт вынесу алгоритмы обработки изображений. По трудозатратам - примерно половина от всего объема работ. Я никаких сторонних библиотек для этой цели не использую, потому как ни одна из них меня не устроила. Например leptonica использует потоко-небезопасный подсчет ссылок, что сразу ее исключает. В итоге пришлось все писать самому (с оглядкой на другие реализации, если таковые удавалось найти), попутно изучая такие вещи как морфология, Эвклидова карта расстояний, и тому подобные вещи.
Идем дальше. Все остальные пункты применимы к любому большому проекту.
Итак: самое главное в большом проекте - это архитектура. Хорошая архитектура позволяет справится с присущей сложностью задачи. Не устранить сложность, а всего лишь справиться с ней. Также она позволяет добавить сложности, и все равно справится с ней. Пример такой добавочной сложности - неблокирующийся интерфейс в СТ. Страница обрабатывается, а интерфейс не заморожен. Чтобы сделать хорошую архитектуру - нужен опыт, причем опыт именно в области архитектуры - то есть создания больших приложений с нуля. Знания тоже не помешают - шаблоны проектирования весьма полезно знать например.
Ну и последний пункт - миллион мелких проблем. Сложность с ними в том, что их много. Для примера возьмем тот же движок отображения. Казалось бы - в чем сложность? Перевел QImage в QPixmap, переопределил paintEvent() - и рисуй его там с произвольной трансформацией. Первая реализация жутко тормозила. Выяснилось что Qt не использует аппаратного ускорения при рисовании картинок с преобразованием. К тому же качество сглаживания оставляло желать лучшего. И Qt тут можно сказать не виноват. Аппаратное ускорение не использует - родной API не предоставляет необходимых возможностей (что GDI в Windows, что XRender в Linux). Антиалиазинг слабый - это только при большом уменьшении - такое редко кому надо. Хотел OpenGL использовать - там свои проблемы: антиалиазинг не отключается и время загрузки картинок возрастает. В итоге все проблемы решились, но ценой сложности - то что должно было уложиться в две-три сотни строк, выросло до двух тысяч. Там у меня и фонововая обработка в отдельном потоке используется, и прямые обращения к XRender, и хаки вроде рисования неотсеченной картинки с последующей заливкой определенных областей цветом фона. И таких сложностей - миллион. Что вы хотите - проект не маленький.

ukpyr

Цитата:

что за граф.движок ? отображение страниц или их обработка ?

Отображение. Конкретно я имею в виду следующее:

Цитата:

Отображение в клиентской области программы изображения загруженного растрового графического файла. При вращении колёсика мыши - зум меняется с шагами 10%. Само зуммирование - в отдельном треде - крутанул колёсико мыши - а картинка "по инерции" шагами домасштабируется. Обязательно наличие скроллбаров и сглаживания. Никакого моргания-мерцания-тормозов (особенно при скроллинге на больших зумах). Масштабирование - в курсор мыши. Наличие режима Fit Width.

В общем, именно это имеется в СК - можно там рассмотреть, как это выглядит.
Да, вспомнил: ещё в CuneiForm плохой графический движок - нет сглаживания.

Цитата:

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

Есть не только базовые, но даже и более специализированные алгоритмы - deskew и т.п. Либо их достаточно реально отыскать-сделать. Движка графического нет - вот в чём беда. Без него всё бессмысленно.

Добавлено:
Tulon

Цитата:

Например leptonica использует потоко-небезопасный подсчет ссылок, что сразу ее исключает.

А что это такое - "подсчет ссылок"?

Цитата:

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

Боже мой, да зачем же ТАКАЯ сложность!? Да хай с ним пусть блокируется - вон в СК блокируется, и ничего.

Цитата:

Для примера возьмем тот же движок отображения. Казалось бы - в чем сложность?

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

У меня возникло такое впечатление, что Вы всё излишне усложняете. На мой взгляд, вполне достаточно сделать некую "спартанского" вида программу.

Добавлено:
Как это - "исключить Лептонику" - ничего себе - да там пол-Лептоники превосходно подходит для скан-обработки - причём многие из её алгоритмов ещё, что назывется, "попробуй найди" где-либо ещё в Интернете.

Огромное спасибо за программу.
Увы,с меня для проекта толку нету- Shell, C++ на начальном уровне. Правда,способен тестировать и пакеты собирать для Linux,хотя бы для Debian.
Очень многое я уже сделал с помощью CT версии 0.9.3.
Обнаружил только несколько странностей.
Получается некоторое количество абсолютно белых страниц,сейчас работаю над книгой ,98 разворотов.
Разрезало и всё остальное без ошибок.Но на выходе 100% белизна.Пробовал отключать "удаление пятен", но такое ощущение что "применить ко всем" не сработало.Всего сделал 4 книги, из нескольких сотен страниц каждая,на каждую сотню страниц бывает по 1-2 абсолютно белых или наоборот абсолютно чёрных страниц на выходе.От каких факторов это может зависеть?
Возможно,я не совсем понял как работать с программой.

Меня не волнует формат файла вывода,может png было бы и лучше.Можно сделать выбор из каких-нибудь 2-3 вариантов.
Насчёт меню-всё в порядке теперь,как в KRename
Есть такая штука- gScan2pdf.С версии 0.9.27 куда-то исчезло устранение перекосов а появилось несколько фильтров...странно всё это.Но она позволяет удалять,добавлять и менять местами страницы,собирать в один файл.
На данный момент аналогов СТ нет.Раньше использовал такое: Обработка сырых сканов (Gimp, Image Magik) правка перекосов (unpaper) сборка в один файл (всё что угодно).
Если бы SK был бы нормально переведён,документирован и работал бы стабильно и приемлемо по скорости в WINE,было бы хорошо... Мечтать не вредно)
Вопрос следующий,нельзя ли заполучить СТ посвежее?

Цитата:

А что это такое - "подсчет ссылок"?

Ну вот например. Про потоко-безопасность там правда не написано - это отдельная тема.


Цитата:

Цитата:
Пример такой добавочной сложности - неблокирующийся интерфейс в СТ. Страница обрабатывается, а интерфейс не заморожен.

Боже мой, да зачем же ТАКАЯ сложность!? Да хай с ним пусть блокируется - вон в СК блокируется, и ничего.

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


Цитата:

Цитата:
Для примера возьмем тот же движок отображения. Казалось бы - в чем сложность?

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

Вы мне напоминаете человека, который считает, что для того, чтобы хорошо играть в баскетбол нужно всего-лишь иметь хорошие кроссовки. Ну возьмите в конце концов движок от СТ и попробуйте сделать что-нибудь на его основе. Что, не хотите использовать Qt? Хотите MFC? Ну извините, с таким же успехрм вы могли бы и для DOSа что-нибудь попросить. MFC - умирающая платформа. Ничего нового на ней уже давно не пишут.


Цитата:

У меня возникло такое впечатление, что Вы всё излишне усложняете. На мой взгляд, вполне достаточно сделать некую "спартанского" вида программу.

Вы бы первым меня в этом и упрекнули. Помните недовольство низким качеством антиалиазинга?


Цитата:

Как это - "исключить Лептонику" - ничего себе - да там пол-Лептоники превосходно подходит для скан-обработки - причём многие из её алгоритмов ещё, что назывется, "попробуй найди" где-либо ещё в Интернете.

Я же говорю - не годится для многопоточной обработки. К тому же она оказалась плохо переносимой - слишком привязана к Unix.


Цитата:

Получается некоторое количество абсолютно белых страниц,сейчас работаю над книгой ,98 разворотов.
Разрезало и всё остальное без ошибок.Но на выходе 100% белизна.

Это исправлено в SVN версии. Кстати об этом упомянается в ChangeLog - там и про SVN версию есть инфа.


Цитата:

Меня не волнует формат файла вывода,может png было бы и лучше.Можно сделать выбор из каких-нибудь 2-3 вариантов.

TIFF по моему всех устраивает, поэтому смысла нет делать выбор. К тому же конверсия TIFF <-> PNG делается без потерь, так что кому надо, сами могут конвертировать.


Цитата:

Вопрос следующий,нельзя ли заполучить СТ посвежее?

Можно собрать из SVN. На Wiki есть кое какая инфа на эту тему. В принципе в эти выходные можно было бы выпустить новую версию, но сначала хочу разобраться с вылетами, которые у некоторых случаются. В принципе тот баг, из-за которого на выходе были белые страницы, мог и к вылетам приводить, но тогда они были бы воспроизводимы, а судя по сообщением вылеты не воспроизводятся. Раз уж вы в Linux'е, то может вы смогли бы помочь с поиском проблемы. Сделайте такой скрипт для запуска СТ:

Код:
#!/bin/sh
ulimit -c unlimited
scantailor

Цитата:

а судя по сообщением вылеты не воспроизводятся.

Cезонное затишье ?
Или пишут что всё OK ?

Цитата:

Cезонное затишье ?
Или пишут что всё OK ?

Сезонное. Такое впечатление, что большинство пишет сюда исключительно с работы - отсюда и тишина в выходные.

Жаль, что у U235 перестали собираться сборки. За последнее время было сделано много изменений.

Собрал отладочную сборку из SVN,ну и в deb-пакет завернул.
Пробую. Спасибо за всякие красивости,только если они не будут сильно влиять на скорость.
Но думаю что с вылетом ничего не получится-Ваша программа отработала 3 суток непрерывно и не вылетела,боюсь у меня не хватит времени чтобы добиться этого.
Что нужно бы -это возможность указания зоны поиска ,то есть при разрезке страниц иногда (зависит от материала) определяет неверно ,по левому краю,по левой границе текста левой половины.Вот здесь и начинаются проблемы,например таких страниц пара десятков и каждую поправить,при том что правка доступна секунд через 5 после выбора страницы в ленте просмотра.
Работает нормально,белых страниц больше не наблюдается.Ещё тысячи полторы сканов обработать осталось...

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

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

Цитата:

Жаль, что у U235 перестали собираться сборки.

Прошу прощенья.
Сейчас вроде бы я разобрался (а ST, наоборот, собрался). Обновил сборку до версии 346.