» Scan Tailor: Часть 2

Tulon

Своп выключен, зачем он при 8 гигах памяти? У меня сложилось впечатление, что проблема именно где-то глубоко в самом Qt запрятана. Мне не удалось вопсроизвести что-то подобное, просто загрузив проц на 100% - при этом скорость реакции приложений вообще не падает. В Qt весьма подозрительные вещи наблаются. Например, приложение создает 7 потоков, хотя в самом приложении явно используются только 2. Что делают остальные, как они докумнтированы? Далее, Qt использует сигналы. По сути это функции, которые вызываются "паровозиком", они могут работать только синхронно. Если в приложении 5 службных потоков будут обмениваться ненужными сообщениями и по каждому из них синхронизироваться, то ожидаемый эффект будет получен.

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

bookreader_new
На самом деле ST создает 4 потока:
1. Поток пользовательского интерфейса.
2. Поток фоновой обработки изображений.
3. Поток подгрузки миниатюр.
4. Вспомогательный фоновый поток. Тут выполняются всякие мелочи, типа отложенного антиалиазинга.
Еще один поток создает обработчик падений. Он собственно ничего не делает, а просто ждет падения.
Еще один или два потока Windows создает для каких-то своих целей.

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

Tulon
На книгах с большим количеством фотоиллюстраций (например, трехтомник Броделя) приходится вручную обводить ручной зоной почти каждую фотографию...

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

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

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

StanFreeWare

Цитата:

Нет ли в планах прямоугольных зон изображений?

Было уже

Настоятельно рекомендую
или версию для печати.

ndch
В очередной раз огромное спасибо за советы.
Я просто пытаюсь понять для себя, почему перемещение прямоугольной зоны за грани, которое уже реализовано как на стадии Полезная область, так и на стадии Макет страницы, приведет к увеличенным трудозатратам на стадии Вывод.

StanFreeWare

Цитата:

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

У вас что, все фотографии сливаются с фоном в той или иной части?


Цитата:

Нет ли в планах прямоугольных зон изображений?

Не планируется. Я больше скажу - на ближайшие этак пол-года планируются всего две вещи: довести до ума despeckle и выравнивание кривизны строк. Пока это не сделано, я бы вообще воздержался от ответов на вопросы "а планируется ли это?". Отрицательный ответ потребует доводов с моей стороны, а с другой стороны возможно вызовет недовольство - кому это надо? Каждый положительный ответ - это еще один кирпич мне в рюкзак. Хрен редьки не слаще в общем.


Цитата:

И все-таки, прошу обратить внимание на следующий вариант построения стадии вывод:

Фич реквесты продолжают игнорироваться.

Tulon
Характерные примеры некорректных автозон.
Кстати, что бы такого сделать с колонтитулом (он напечатан более светлым шрифтом, чем остальной текст), чтобы улучшить его бинаризацию?

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

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

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

Потеря информации - это очень серьезно. Это дискредитирует.

Цитата:

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

Вполне рабочий вариант. И понедельник на это намекал, в своей манере.

StanFreeWare

Цитата:

Характерные примеры некорректных автозон.

Так все правильно, ничего в этом нет неожиданного. Дело в том, что ST выделяет автозоны, в том случае, если они состоят из типографского растра. Такой алгоритм. Если пожать картинки jpeg, или вейвлетом, или размазать Гауссом, то ST автозоны не найдет, что и произошло. Tulon всегда говорил, что ST предназначен для обработки исходных tiff, а не для переделки готовых книг.

Цитата:

ST предназначен для обработки исходных tiff, а не для переделки готовых книг

Спасибо за пояснение. Теперь не буду удивляться такому поведению программы.
Как пользователь расстроен, т.к. сейчас только и делаю, что улучшаю чужие готовые книги со всеми вытекающими. Но! Смирюсь

StanFreeWare


Цитата:

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

Ну скажем Rob первую версию своего алгоритма написал за пару недель. Вторую - трудно сказать, но скажем за месяц. Понятно, что там есть, над чем работать, но также видно, что за пол-года можно сделать очень многое.


Цитата:

Потеря информации - это очень серьезно. Это дискредитирует.

Despeckle я доведу до ума всяко раньше, чем выравнивание строк.

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

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

Tulon
Я берусь за переделку только 200-300dpi книг, сжатых в photo-режиме. Такой первоисточник мало отличается от jpeg-сканов. Для них мне функционала СТ вполне достаточно (за исключением моментов, отмеченных в моих предыдущих сообщениях)
Исправлять книги, сделанные иным способом - согласен, дело гиблое.

Tulon

Цитата:

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

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

Tulon

Цитата:

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

Так же как и сканирование новых

StanFreeWare

Цитата:

Исправлять книги, сделанные иным способом - согласен, дело гиблое.

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

Цитата:

дело гиблое

Любая книга - это информация. Полностью согласен, что ее нужно уважать.
Неоднократно говорил о необходимости зацепиться за базис - информационную площадь скана.
наложить прямоугольную маску, зафиксировать ее к углу и технологической метке (номер страницы), привязать маску к формату вывода на печать (А4 и др.), привязывать маску к скану страниц, корректируя при выходе на коэффициент соответствия (соотношение диагонали маски книги к диагонали маски страницы)
Все! Забудем про целый ряд проблем и не нужных операций.
Все корректировки (текста и строк), разделения (текст, картинка, пустая область) реализуются внутри ИП.
Одновременно увеличим удобство пользователя и качества книги на выходе!
С удивлением и надеждой увидел, что мои логические предположения уже фактически реализованы в интерфейсе программы "Фото на документы"

сама программа (portable)
http://slil.ru/28702838 (2,84 Мб)
как видно, они пошли по другому пути - не изысканные алгоритмы, а просто человеко-машинная среда - зацепился за метки и вперед...
Я бы сказал, что вполне возможно, что либо в той, либо в другой программе эта ниша будет в скором времени занята

Dashout

Цитата:

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

Это утверждение верно при идеальной верстке.

Добавлено:
Зы. здесь не варёз.

Добавлено:

Цитата:

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

Баян - для этого есть, например, фотошоп с направляющими. В новых версиях фотошопа - smart rulers. + автоматизация (actions).

Это как бы оффтопик.

И это идёт явно вразрез с концепциями обработки ст, ск и прочая.

Думаю Tulon в какой-то мере согласен с данным графиком

Зачетная картинка. Захотелось в подпись воткнуть ссылку на нее, что и было сделано.
P.S: но по какой-то причине не сработало.

Tulon
[off] На ру-борде подпись включить - это дело слегка запутанное.

Несмотря на график, и, надеюсь, не баян:
1) есть разворот, слева пустой, справа информация, нахожусь на 4 стадии, удаляю пустую половину, СТ опять проходит стадии до 4, делит страницу по переплету в режиме "+огрызок", и в 3 из 4 случаев оставляет пустую половину разворота...
2) 5 стадия. Нужно вытянуть поле с одной стороны. Разрываю цепь, вытягиваю. Ухожу на другую страницу, возвращаюсь. Цепь замкнута (хотя значения разные). Как следствие начинаю еще подтягивать ранее вытянутое поле, сцепленное поле становится такой же величины. По-моему, если значения разные, цепь замыкать уже не нужно.
3) Неплохо было бы дополнительно выделить на 5 стадии "застраничную" область хотя бы в полосе предпросмотра.
По этой области очень здорово ориентироваться, когда полезная область определяется, например, в нижней половине страницы.

StanFreeWare


Цитата:

1) есть разворот, слева пустой, справа информация, нахожусь на 4 стадии, удаляю пустую половину, ...

Я правильно понял, что "нахожусь на 4 стадии, удаляю пустую половину" означает "правый клик -> удалить рамку"? В таком случае надо полагать режим разреза на тот момент был "две половинки", поскольку "слева пустой, справа информация".


Цитата:

СТ опять проходит стадии до 4, делит страницу по переплету в режиме "+огрызок", и в 3 из 4 случаев оставляет пустую половину разворота

Так так, а что же заставило ST пересмотреть тип разреза? Изначально разрез был ручной или автоматический? Меняли ли вы что-то на стадиях 1-3 после удаления рамки на стадии 4?


Цитата:

2) 5 стадия. Нужно вытянуть поле с одной стороны. Разрываю цепь, вытягиваю. Ухожу на другую страницу, возвращаюсь. Цепь замкнута (хотя значения разные). Как следствие начинаю еще подтягивать ранее вытянутое поле, сцепленное поле становится такой же величины. По-моему, если значения разные, цепь замыкать уже не нужно.

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


Цитата:

3) Неплохо было бы дополнительно выделить на 5 стадии "застраничную" область хотя бы в полосе предпросмотра.
По этой области очень здорово ориентироваться, когда полезная область определяется, например, в нижней половине страницы.

Фич реквесты по прежнему игнорируются.

Tulon
1) С точки зрения пользователя - удаляю пустую страницу с ленты предпросмотра на 3-4 этапе. Вместо нее удаляется следующая за ней страница, а пустая остается.

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

3) Достаточно было бы даже более яркого цвета для застраничной области на 5-м этапе. Что-то типа этого

StanFreeWare

Цитата:

1) С точки зрения пользователя - удаляю пустую страницу с ленты предпросмотра на 3-4 этапе. Вместо нее удаляется следующая за ней страница, а пустая остается.

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


Цитата:

3) Достаточно было бы даже более яркого цвета для застраничной области на 5-м этапе. Что-то типа этого

Все равно не сейчас, и когда - не знаю.

Tulon
Действительно, в последней сборке от U235 удаление половинок отрабатывает корректно.

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

Подразню вас скриншотом пока что:

А есть уже в СТ возможность пропускать стандартные стадии обработки, чтобы пользователь сам решал, какие этапы СТ будет отрабатывать, а какие нет? Чтобы при хорошем скане СТ не пытался ничего "улучшать" или менять.

Цитата:

А есть уже в СТ возможность пропускать стандартные стадии обработки, чтобы пользователь сам решал, какие этапы СТ будет отрабатывать, а какие нет? Чтобы при хорошем скане СТ не пытался ничего "улучшать" или менять.

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

Tulon

Цитата:

На самом деле на всех стадиях это можно эмулировать, кроме как на стадии Deskew

.. и на стадии Полезная область. Или вы уже что-нибудь придумали в плане обхода этой стадии?
Кстати, возможно уже предлагалось - но для улучшения определения полезной области для сканов журналов без полей можно попробовать предварительно сэмулировать эти поля, через групповой инструмент "Добавить рамку" в каком-нибудь просмотрщике (в FS ImageViewer такой инструмент, по крайней мере, есть).

Цитата:

.. и на стадии Полезная область. Или вы уже что-нибудь придумали в плане обхода этой стадии?

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

Цитата:

деспеклинг значительно продвинулся. Еще через пару недель надеюсь закончить его.

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