» Scan Tailor: Часть 2

Исправил код и залил в git...

Цитата:

Обновил Ubuntu до 11.4 - и Qt 4.7.2

Кстати, такой вопрос: у вас после обновления qt программа не стала сегфолтиться при закрытии окна? Т.е., я к примеру открыл st, создал проект или внес изменения в существующий, но не сохранил. При закрытии окна программа падает и не показывает диалог с предложением сохраниться:


Код: (<unknown>:7990): Gtk-WARNING **: Error loading theme icon 'dialog-question' for stock: Error opening file: No such file or directory

(<unknown>:7990): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed

** (<unknown>:7990): CRITICAL **: murrine_style_draw_render_icon: assertion `base_pixbuf != NULL' failed

(<unknown>:7990): Gtk-CRITICAL **: IA__gtk_style_render_icon: assertion `pixbuf != NULL' failed

(<unknown>:7990): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_pixels: assertion `GDK_IS_PIXBUF (pixbuf)' failed

(<unknown>:7990): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_width: assertion `GDK_IS_PIXBUF (pixbuf)' failed

(<unknown>:7990): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_height: assertion `GDK_IS_PIXBUF (pixbuf)' failed
Segmentation fault

Такой ситуации с закрытием не сохраненного проекта у меня не было. Дома вечером проверю - напишу результат.

В общем поковырялся немного. Проблема возникает только если для qt4 используется тема gtk+ С другими темами все нормально. Оно делает вид, что не может найти иконку со знаком вопроса и\или иконок для кнопок, хотя сама иконка есть и другие темы ее прекрасно подхватывают. Также сегфолтится при попытке удаления страницы из проекта. Есть предположение, что это как-то связано с тем, что в настройках gtk прописано "Не показывать иконки на кнопках". ST хочет эти иконки обязательно отрисовать, но тема не позволяет.

Я проверил - все работает. Даже на теме gtk+. У меня ST никак не хочет сегфолтить Может у вас что-то с системой?

Тааак. Методом тыка таки нашел виновника: им оказалась тема значков elementary-monochrome. Жесть в общем Единственно, что я так и не понял, так это почему те же самые значки в сочитании с оксидженом или клирлуксом не приводили к крэшу.

Сия тайна покрыта мраком веков

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

VidelSamogO
А пример выложить не судьба? И написать что делали.

Вот сколько не пытаюсь возвратиться на кромсатор, а снова и снова прихожу к одному выводу. Scan Tailor на порядок удобнее, логичнее и юзабельнее! Просто лучший! К разработчику - просьба поработать над более широкими возможностями выравнивания яркости и адаптивности в бинаризации. Необходимы ползунки ручных подстроек и усилителей действия параметров практически во всех функциях. (Поясню. Зачастую после первой разрезки в цветном режиме вывода приходится использовать illum_corr, после чего Scan Tailor даже при +99 яркости НЕ ВЫТЯГИВАЕТ детали при бинаризации! Отсюда просьба - расширить рамки возможного до +-300) Это ук уже неплохо реализованному. А к плохо - нужны параметры подстройки - задаваемые пределы - рамки для деворпинга например.
slava_kry
В режиме цветного вывода, если раньше цвет окаймления можно было задавать - (Цветной/Серый, Белые поля... ) То теперь - когда не выбираем режим белых полей - получаем вместо них - ярко голубое окаймление. Хотя я его конечно потом могу замаскировать, но это снова костыли.

После удаления страницы из проекта ST перескакивает на первую страницу. Было бы имхо логичней, если бы переходил на следующую.

Изменил логику заливки фона в ST Separator 3.1.
на приведенном ранее примере
теперь получается такой результат

Никак не придумаю надежную логику для заливки внутренней области символов, чтобы она охватывала сложный случай из 0002_.tif. Т.е. если есть одна сплошная черная область, одновременно служащая и фоном для одних букв и основным цветом для других букв. Пока что для заливки содержимого таких черных областей используется цвет фоновой области максимальной площади среди областей, касающихся данной черной области снаружи. Что и привело к белой заливке внутренней части символов ф,о,р.

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

StanFreeWare
У меня вообще не работала никогда ни одна из версий outliner'а. Может подскажете алгоритм, чтобы я на регулярных выражениях обработчик построил?

VidelSamogO
Исходники вроде как открыты. Но, боюсь, regexp'ами тут не обойтись. Много математики.
И я бы предпочел сделать рабочую и для вас версию аутлайнера. Может, все-таки закинете через личку нерабочий проект и мы вместе как-нибудь победим проблему? На rutracker'е и djvu-scan-forum'е тоже жаловались, но пока молчат, хотя и обещали проект. Может быть, хоть Вы поможете?

Кстати, ни у кого на W7x64 c Сепаратором проблем не было (версия 3.0 не в счет - там была ошибка в коде)?

StanFreeWare
# - под катом - Информация об ошибке, Проект
#


Добавлено:
StanFreeWare
Сепаратором не пользуюсь. Есть же рабочий ST Split. Если нетрудно, создайте скрин-видео, как полностью работать с тем сепаратором Только на полной книге со смешанным контентом на 500 страниц. меня были всегда с ним проблемы. Пришлось отказаться.

VidelSamogO
Кажется, понял - похоже, Вы решили, что аутлайнер превращает непрямоугольные ПОЛЬЗОВАТЕЛЬСКИЕ зоны в прямоугольные. А на самом деле он обводит АВТО-зоны прямоугольниками.

Если Сплит устраивает, то смысла переходить на Сепаратор нет. Максимум получите экономию места на винте за счет возможности предварительного ужимания картинок (не в Djvu Imager).
Тем не менее, не могу понять какие проблемы на книге со смешанным контентом могут быть. Натравляешь прогу на папку Out и идешь куришь. А дальше все по стандартной схеме, как и со Сплитом...

StanFreeWare
Нет. Это я для примера сделал. На автоопределённых как серые, точках - зонах-картинках, происходит та же самая ошибка. Просто картинку неудачную на этот раз взял, вот и пришлось самому зон наляпать. Я всё правильно понимаю.

Добавлено:
Ну могу сделать то же самое со страничкой, на которой автоопределится зона серого изображения.

Ну сделайте

Добавлено:
Но предпочтительней через личку.

В личке.

Кто ссылку на git из шапки убрал ?
Верните на место !

Продуктивное общение с VidelSamogO вылилось в новые версии ST Outliner 0.4 и ST Separator 3.1.4.

Программа не может ресайзить сканы?
Например, одна страничка отсканена с разрешением 3000х2000, вторая - 1500х750.
Есть опция Match Size to other Page, но после ее применения получается голая страничка с маленьким сканом посередине. Выглядит, конечно, некрасиво. Логичней если бы картинка просто ресайзилась до ширины или высоты максимальной картинки или до заданного пользователем значения.

LonerDergunov
Задайте DPI и все станет логично и красиво.
Странно, что сканер не сохранил эту информацию.

LonerDergunov
Либо перед обработкой сделайте ресайз в какой нибудь сторонней программе, либо задайте dpi для первой странички 300 для второй 150. На выходе получите одинаковый размер картинок.

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

Как известно, в Book Restorer имеется выравнивание освещённости - которое превосходит по качеству таковое в СТ.

А зачем нам вообще нужно выравнивание освещённости?

Оно нужно потому, что, считается, что оно улучшает последующую бинаризацию - только для этого оно нужно.

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

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

Отсюда получается такой вывод: наличие в СТ только одного вида бинаризации - Otsu - является недостаточным. Для Otsu cколь ни расширяй диапазон бинаризации - 30 - 50 - 100 - ... - всё это будет недостаточной мерой для бинаризации неравномерно-освещённых сканов. Такие сканы ИМХО пока что лучше в Book Restorer бинаризировать - получается гораздо лучше. В Book Restorer имеются тонкие настройки - там можно вручную подобрать оптимальный порог бинаризации.

Я делаю так (только для неравномерно-освещённых сканов): ставлю в Book Restorer максимально возможный порог бинаризации, выше которого буквы начинают обрастать грязью. Запускаю бинаризацию. В итоге получаются хорошие достаточно жирные буквы - но сам скан при этом получается довольно замусорен мелкой грязью, которую приходится вручную чистить. И тут деваться некуда - без этой паразитной грязи не обойтись, а вот в СТ она никогда не появляется, и мне кажется, Tulon специально на это пошёл. Tulon'у явно не хотелось появления такой паразитной грязи - тогда нужно было бы предусматривать чистку сканов в СТ. Однако без этих мер страдает качество (но только для случая неравномерно-освещённых сканов).

Однако, и в Book Restorer бинаризация далеко не идеальна - для неравномерно-освещённых сканов. Всё равно качество бинаризации для таких сканов получается не очень - хотя и заметно лучше, чем в СТ.

Общий вывод таков:

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

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

Пока что создавать СТ - передние субсканы в режиме серого умеет единственная программа - ST Split. Но такой функционал надо бы внедрить напрямую в СТ. Без этого никак не обойтись - это жизненная необходимость.

Цитата:

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

В планах есть... Нужно только время на все запланированное

Я попробовал опытным путём выяснить, как выравнивание освещённости в Book Restorer (LCBR) влияет на последующую бинаризацию.

Сделал несколько образцов одного и того же серого скана до и после LCBR, бинаризовал всё это в СТ Plus на 50.

Результат оказался поразительным: оказалось, что LCBR крайне пагубно влияет на последующую бинаризацию! Буквы получаются тонкими и с разрывами.

Возникает вопрос: а зачем же тогда вообще нужно LCBR?

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

Платой же за выравнивание освещённости является сильное снижение контрастности - что крайне пагубно сказывается на последующей бинаризации.

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

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

И ручная коррекция высветление тёмных пятен и затемнение засвеченных участков наведением линзы, не помешала бы.

А может делать пошагово?
И не делать из него Фотошоп.