Ru-Board.club
← Вернуться в раздел «Программы»

» Scan Tailor: Часть 2

Автор: monday2000
Дата сообщения: 07.04.2013 21:04
Scan Tailor Featured 2013.04.07

http://rghost.ru/45124123

Добавлено:
Благодаря поддержке Tulon я продвигаюсь вперед с Test-зонами. Эта сборка также является демонстрационной - как и предыдущая. Но в этой сборке я уже значительно продвинулся вперёд - по сравнению с предыдущей.

Теперь векторные Test-зоны уже работают, как надо - но пока что с двумя ограничениями:

1. Нельзя ставить свои векторные зоны картинок.
2. Нельзя двигать вершины автоматически созданных зон картинок.

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

Добавлено:
То есть, в этой сборке можно просто попереключаться между различными значениями "Форма картинок" и посмотреть на результат. Я уже сделал, чтобы при переключении с Test-зон на любые другие векторные авто-зоны сами стирались.
Автор: monday2000
Дата сообщения: 09.04.2013 23:06
Scan Tailor Featured 2013.04.09

http://rghost.ru/45174286

Добавлено:
Кажется, мне удалось. Удалось снять последние 2 ограничения. Но, тестировать ещё, конечно, не помешает...

Добавлено:
Если всё правильно, то эта сборка - уже не демонстрационная, а полноценная.
Автор: LazyKent
Дата сообщения: 10.04.2013 00:24
monday2000, просьба добавить Changelog с вносимыми изменениями.
Автор: monday2000
Дата сообщения: 10.04.2013 18:51
LazyKent

Цитата:
просьба добавить Changelog с вносимыми изменениями.

У меня нет на это времени. Да и никакого смысла не вижу. Я же не храню на оффсайте предыдущие версии. Все изменения я описываю либо тут в топике, либо в http://www.djvu-scan.ru/forum/index.php?topic=1137.0 . Делать же diff от сборки к сборке - увольте.

Теперь я планирую заняться dewarping'ом, а когда с ним закончу (успехом или провалом) - то, скорее всего, приостановлюсь с Featured на неопределённое время.
Автор: monday2000
Дата сообщения: 10.04.2013 22:26
Я обновил версию на оффсайте:

https://sourceforge.net/projects/scantailor/files/scantailor-devel/featured/

Test-зоны я переименовал в "Квадро"-зоны. (Quadro в англ. варианте) "Квадро" - это не строгий алгоритмический термин, а просто условное название, подобно тому, как термин "Despeckle" не является названием математического алгоритма, а является просто как бы "торговой маркой" одной из разновидностей алгоритма шумоподавления.

Бывшие Test-зоны я обозначил в README как:

Quadro_Zoner

Итак, при переключении формы картинок в режим "Квадро" происходит перерисовка зон картинок по ранее описанному алгоритму (который с порогом 25%), и найденные алгоритмом (прямоугольные) растровые зоны автоматически программно подменяются на эквивалентные векторные прямоугольные зоны.

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

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

Квадро-зоны, разумеется, способны сохраняться в XML-файл задания.

Добавлено:
Думаю, что "Обведённые" зоны теперь можно было бы вообще убрать - но я решил их оставить - для сравнения с Квадро-зонами.
Автор: KVOT777
Дата сообщения: 11.04.2013 14:12
Добрый день! А можно доработать программу,чтобы она сохраняла в jpeg качество 80%
Очень нужно! Спасибо!
Автор: tlotr
Дата сообщения: 11.04.2013 14:14
Хм. А в чём проблема переконвертировать любым вьювером типа XnView?
Автор: KVOT777
Дата сообщения: 11.04.2013 14:23
Работы ведутся достаточно большим коллективом и постоянно конвертить в jpeg 80% очень неудобно (сейчас так и делается). Было бы проще, если у программы был бы выбор сохранения формата изображений.
Автор: tlotr
Дата сообщения: 11.04.2013 14:31
Что значит "постоянно"? Перекодировать в вашем случае нужно лишь один раз - когда вся работа завершена и в папке out (ну, или в папках 1, 2 в случае экспорта) появились тиффы.
Если кодировать в джипег постоянно, на каждой итерации работы, это чревато накоплением дефектов изображения и превращением картинки в чёрный/цветной шум, а это обязательно будет, поскольку в процессе работы программы сдвиги на пиксель вправо-влево - это нормальная ситуация. А вот при кодировании с потерями это чревато потерей мелких деталей.
Подобная конвертация (раз уж вам она нужна) должна выполняться единожды.
Однако, обычно предполагается, что выходные файлы пойдут на обработку алгоритмам сжатия в djvu, поэтому нелогично терять информацию на перекодировании в jpg, а потом ещё раз, при создании djvu.
Автор: KVOT777
Дата сообщения: 11.04.2013 14:50
Постоянно - имелось ввиду приходит массив, обрабатывается - конвертится (1 раз).
Ну вот очень нужно, чтобы на выходе имелся выбор сохранения или по умолчанию jpeg... Поможите люди добрые?)
Автор: monday2000
Дата сообщения: 11.04.2013 18:10
KVOT777

Цитата:
Поможите люди добрые?

Если действительно ОЧЕНЬ надо - тогда доработайте её сами - это самый реалистичный вариант.
Автор: femalehandro
Дата сообщения: 30.04.2013 05:56
[more] monday2000, здравствуйте.

При сборке в Wheezy, cmake выдает

Код:
In file included from /home/user/scantailor-featured-2013.04.10/MainWindow.cpp:19:0:
/home/user/scantailor-featured-2013.04.10/MainWindow.h: In constructor ‘MainWindow::MainWindow()’:
/home/user/scantailor-featured-2013.04.10/MainWindow.h:337:19: warning: ‘MainWindow::m_outpaths_vector’ will be initialized after [-Wreorder]
/home/user/scantailor-featured-2013.04.10/MainWindow.h:332:7: warning: ‘bool MainWindow::m_closing’ [-Wreorder]
/home/user/scantailor-featured-2013.04.10/MainWindow.cpp:156:1: warning: when initialized here [-Wreorder]
Автор: monday2000
Дата сообщения: 30.04.2013 19:22
femalehandro
Попробуйте это:

http://rghost.ru/45667082

Отпишитесь о результате.
Автор: femalehandro
Дата сообщения: 01.05.2013 17:54
monday2000, при сборке не "ругается". при работе пока еще не "вылетал".
Спасибо.
Автор: Arrested
Дата сообщения: 02.05.2013 08:15
Вот интересно, а есть ли в какой-либо сборке возможность двигать полезную область ЦЕЛИКОМ, а не отдельными сторонами. Это существенно облегчило бы обработку сканов страниц разных размеров и с "засветками" по краям.
Автор: monday2000
Дата сообщения: 03.05.2013 22:48
Залил исправленную версию (исправление ошибки от femalehandro) на оффсайт:

https://sourceforge.net/projects/scantailor/files/scantailor-devel/featured/
Автор: monday2000
Дата сообщения: 15.05.2013 16:43
Сборка 2013.05.15

http://rghost.ru/46016797

Добавлено:
Новая опция:

Marginal_Dewarping

Я сделал новый вид Dewarping'а. Я назвал его "краевой деворпинг" (marginal dewarping). Его идея очень проста: используется синяя сетка искривления, точнее, её самая верхняя и самая нижняя горизонтальные синие линии.

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

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

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

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

Ещё одно ограничение: для очень крутых искривлений деворпинг пока не совсем точен - видимо, 6 красных точек оказалось маловато. Но никто не мешает доставить вручную ещё 1-2 красные точки и сделать такой деворпинг точнее.

Для малоискривленных сканов выпрямление работает очень хорошо.

В этой сборке есть одно маленькое чисто техническое ограничение: исходный скан должен быть повёрнут на 90 градусов в человеко-читаемую ориентацию (после отсканирования). Это я исправлю в ближайших сборках.

Я оформил новый вид деворпинга просто как ещё один пункт в окошке, где выбирается вид деворпинга.

Скорее всего, я потом более подробно расскажу о новом виде деворпинга.
Автор: monday2000
Дата сообщения: 15.05.2013 22:03
Экспериментирую с новым деворпингом. Выяснилось, что для очень крутых искривлений он работает плоховато - и это явно его принципиальное ограничение. Зато для относительно небольших искривлений он работает очень неплохо.

Добавил в свой деворпинг ещё одну красную точку - это немного улучшило результат.

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

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

В автоматическом деворпинге от Tulon делается анализ кривизны строк и нахождение 2 вертикальных границ контента (по словам Tulon'а, последнее - самое трудное, и поэтому происходят лажания). По верхней и нижней границам кривизны строятся т.н. полилинии - ломаные прямые линии, проходящие через опорные точки кривизны. Затем по этим полилиниям строятся 2 т.н. х-сплайна - исключительно ради того, чтобы дать пользователю возможность подредактировать авто-деворпинг. Затем х-сплайны сэмплируются обратно в полилинии, и по ним уже и делается выпрямление скана. У х-сплайнов - всегда по 5 красных точек (у Tulon'а), а полилинии состоят каждая из десятков опорных точек, поэтому (как я это понимаю сейчас) мой краевой деворпинг даже теоретически всегда будет хуже Tulon'ского авто-деворпинга - если бы последний никогда не лажал. Получается, что именно из-за лажания Tulon'ского авто-деворпинга мой краевой деворпинг приобретает смысл.

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

Пока я не придумал ничего лучшего (чем сделать краевой деворпинг), но теоретически получается, что более выгодно было бы найти способ улучшить авто-деворпинг Tulon'а - чтобы он перестал лажать. Для этого нужно будет ещё долго разбираться в том, как он работает - а получить хотя бы какой-то более-менее приемлемый результат хочется прямо сейчас, да и будет ли у меня когда-нибудь время всерьёз разбираться с Tulon'ским авто-деворпингом?
Автор: monday2000
Дата сообщения: 17.05.2013 15:26
Я убрал зависимость краевого деворпинга от исходной ориентации страницы. Теперь новый деворпинг полностью работоспособен. Залил новую исправленную версию на оффсайт:

https://sourceforge.net/projects/scantailor/files/scantailor-devel/featured/
Автор: monday2000
Дата сообщения: 17.05.2013 18:32
Продолжаю эксперименты с новым деворпингом. Опыты показали, что краевой деворпинг хорош только для малых искривлений. На больших же искривлениях оказалось, что изогнутый край страницы недостаточно точно отображает искривление страницы. Автоматический деворпинг Tulon'а, если он не ошибается, строит модель искривления как по краю страницы (аналогично краевому), так и по изогнутости строки - что гораздо более точно.

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

Зато на малых искривлениях, изогнутость строки и изогнутость кромки книги - практически тождественны, поэтому для малых искривлений (которые, однако, всё равно выглядят крайне раздражающе, если их оставлять) краевой деворпинг довольно хорош, и при условии наличия четких верхней и нижней кромок скана, никогда не ошибётся (в отличие от автоматического деворпинга от Tulon).
Автор: monday2000
Дата сообщения: 17.05.2013 21:55
Я сумел выпросить у разработчиков ещё одну реализацию деворпинга - где модель искривления строится по скелетам линий текста. Я назвал его условно "скелетный dewarping":

http://www.djvu-scan.ru/forum/index.php?topic=1149.0
Автор: VidelSamogO
Дата сообщения: 21.05.2013 08:03
А почему в смешанном выводе нельзя выставить порог бинаризации для чёрно-белых сегментов?
Автор: monday2000
Дата сообщения: 22.05.2013 22:44
Продолжаю эксперименты с краевым деворпингом. Выяснились закономерности:

1. Этот деворпинг хорошо справляется с малыми концевыми изгибами строк. Допустим, вся строка - прямая, и лишь только кончик её - гнутый. Автоматический деворпинг такое искривление просто не замечает (и не выпрямляет, соответственно).

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

3. После проработки краевого деворпинга очень часто сканы нужно опять пропустить через Deskew. Неприятная особенность, конечно, но, видимо, такова уж особенность алгоритма краевого деворпинга - алгоритм выставляет красные точки по линии изгиба кромки, но нам-то нужны не они, а управляемые ими синие узлы сетки - так вот узлы эти немного смещаются вбок (при выставлении красных точек) - поскольку красные точки и (управляемые ими) синие узлы не тождественны по координатам. При автоматическом деворпинге потребности в последующем Deskew я не заметил. Что с этим делать - пока не знаю. Боюсь, что большинство поленятся делать ещё раз Deskew.
Автор: amaid
Дата сообщения: 22.05.2013 23:32
monday2000, как наиграетесь с деворпингом, сделайте видеоурок для чайников.
Несколько раз пробовал, ковырялся, эффект смехотворный в сравнении с затраченным временем.
Автор: monday2000
Дата сообщения: 23.05.2013 12:16
amaid

Цитата:
Несколько раз пробовал

Что пробовали?

Добавлено:
Вот образец сырого скана, специально подобранного, чтобы на нём можно было увидеть, что такое "Краевой деворпинг":

http://yadi.sk/d/aWon_K-p55gMs (6,5 МБ)

Обработайте его в Scan Tailor Featured, выставив при этом "Распрямление строк" в положение "Краевое". После проработки деворпинга не лишним будет заглянуть на вкладку "Распрямление строк", чтобы увидеть расстановку красных точек синей сетки, сделанную этим деворпингом.

Обратите внимание - на скане присутствуют верхняя и нижняя изогнутые кромки страницы - на тёмном фоне. Их наличие на скане, как я уже писал ранее, обязательно - для работы краевого деворпинга.
Автор: amaid
Дата сообщения: 23.05.2013 16:17
на пробной картинке результат впечатляет
в fr 11 лучшего трудно добиться даже вручную
при случае попробую (подобные сканы у меня редко)
Автор: monday2000
Дата сообщения: 23.05.2013 18:04

Цитата:
на пробной картинке результат впечатляет

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

Цитата:
подобные сканы у меня редко

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

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

Любой деворпинг в СТ начинается с того, что за основу берётся область полезного контента, найденная на предыдущих этапах. Если бы не это, то, по словам Tulon'а, деворпинг был бы перенесён на стадию Deskew.

В автоматическом деворпинге Tulon'а внутри области полезного контента вверх-вниз делается сканирование строк текста (и кромок страницы - если они есть - как в моем краевом деворпинге). По самой верхней и самой нижней строке текста (кромке страницы) строятся 2 полилинии (просто набор точек) - по опорным точкам этих строк. Всё это можно увидеть в "режиме отладки" в СТ. В идеале, построенные 2 полилинии должны точно повторять изгибы самой верхней и самой нижней строки (кромки страницы). Однако, как уже было сказано ранее, малые концевые изгибы авто-деворпинг Tulon'а не замечает - не хватает точности (а краевой - замечает).

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

Отсюда вывод: можно самому каким угодно способом сформировать эти 2 полилинии, и подсунуть программе. Я для начала попробовал использовать кромки страниц, а теперь уже, я думаю, надо бы попробовать по строкам текста строить полилинии, можно перепробовать теперь разные способы построения кривизны строк текста. Вдруг получится точнее, чем у Tulon'а.

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

Добавлено:
Новая сборка:

Scan Tailor Featured 2013.05.23. Залил сразу на оффсайт:

https://sourceforge.net/projects/scantailor/files/scantailor-devel/featured/

Вводит новую фичу:

Auto_Dewarping_Vert_Half_Correction

Объясню суть по картинке:



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

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

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

Автор: Myxb
Дата сообщения: 24.05.2013 06:46
monday2000
Пробовал собрать версию 2013.05.23 под Debian Wheezy. Выдает:

Код: [ 72%] Building CXX object filters/output/CMakeFiles/output.dir/Task.cpp.o
In file included from /home/user/scantailor-featured-2013.05.23/filters/output/Task.cpp:55:0:
/home/user/scantailor-featured-2013.05.23/filters/output/OutputGenerator.h:48:25: fatal error: QMessageBox.h: No such file or directory
compilation terminated.
make[2]: *** [filters/output/CMakeFiles/output.dir/Task.cpp.o] Error 1
make[1]: *** [filters/output/CMakeFiles/output.dir/all] Error 2
make: *** [all] Error 2

**** Installation failed. Aborting package creation.

Cleaning up...OK

Bye.
Автор: LazyKent
Дата сообщения: 24.05.2013 07:34
Я изменил на QMessageBox.


Код:
Index: scantailor-featured-2013.05.23/filters/output/OutputGenerator.h
===================================================================
--- scantailor-featured-2013.05.23.orig/filters/output/OutputGenerator.h
+++ scantailor-featured-2013.05.23/filters/output/OutputGenerator.h
@@ -45,7 +45,7 @@
#include "IntrusivePtr.h"
#include "Settings.h"
//Marginal_Dewarping
-#include "QMessageBox.h"
+#include <QMessageBox>
#include "TiffWriter.h"
#include <QtCore/qmath.h>
#include <QFile>
Автор: monday2000
Дата сообщения: 24.05.2013 08:55
Myxb
LazyKent
Точно, не заметил. Да в принципе эту строку вообще можно убрать - я QMessageBox использую там только в отладочных целях.

Цитата:
Я изменил на QMessageBox.

Да, так ИМХО лучше всего.

Страницы: 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061

Предыдущая тема: CmCkA v4


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.