» Scan Tailor: Часть 2

kvesda

Цитата:

2). Вычесть зоной этот фрагмент...

Правый клик по зоне -> Свойства -> Вычесть из автослоя.

Добавлено:
iit512
Зачем придумывать проблемы, там где их нет? Откуда у вас появятся такие-же файлы, отличающиеся только регистром? Cам по себе регистр меняться не будет.

Tulon
Можно ли заодно все-таки отказаться от tiff в пользу tif? Типичный пример - когда чб вывод конвертим irfan'ом или faststone'ом в G4FAX для FR8 в ту же папку и получаем два набора файлов с одинаковым именем и разным разрешением tif и tiff...

StanFreeWare

Я бы радовался Можно проверить, что всё преобразовалось правильно, и только потом удалить один из двух наборов.

anagnost96
Не вижу особого повода для радости. Вместо того, чтобы вообще не конвертировать, приходится конвертировать в два этапа. Нет, ну если где-нибудь в настройках СТ можно будет переключаться между типом кодирования LZW и G4FAX для 1-битных тифов, это тоже решит вопрос...

StanFreeWare

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

Цитата:

Правый клик по зоне -> Свойства -> Вычесть из автослоя.

Tulon, спасибо, не знал...

StanFreeWare

Цитата:

Можно ли заодно все-таки отказаться от tiff в пользу tif? Типичный пример - когда чб вывод конвертим irfan'ом или faststone'ом в G4FAX для FR8 в ту же папку и получаем два набора файлов с одинаковым именем и разным разрешением tif и tiff...

Ну раз уж все равно меняем систему именования, то можно и расширение поменять.

Tulon
Внесите, пожалуйста, поправку в страницу документации про наличие Scan Tailor в дистрибутивах Linux.
Пакет имеется и для openSUSE. Находится поиском в http://software.opensuse.org/search?q=scantailor

LazyKent
Wiki обновил.

Закончил со сменой схемы именования выходных файлов.
Новая сборка: http://www.onlinedisk.ru/file/428161/

Кроме схемы именования, изменился механизм удаления из проекта половинки скана. Старый механизм приводил к утере всех настроек для второй половины.

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

Как всегда, просба потестировать, особенно то, что касается вышеописанных изменений.


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

За сборку спасибо!
Tulon

Цитата:

Собираюсь реализовать это через спектральный анализ областей с краю от этих линий. Где больше высокочастотных компонент - там и огрызок.

Не совсем понятно, но ИМХО, делать пребразование Фурье краевых областей будет слишком накладно в вычислительном плане, даже используя оптимизированную библиотеку FFTW. Тем более нужно лишь определить где больше ВЧ компонент, а не точное их значение. Может быть вместо этого подойдет свертка с ядром типа лапласиана или простейшие градиентные фильтры? Это практически тоже самое, что и гауссово размытие, которое есть в СТ, только коэффициенты фильтра другие.
Кстати пробовал использовать спектральный анализ Фурье для выделения растровых рисунков (регулярный растр). Результат был не очень хороший, т.к. высокое разрешение в пространстве (маленькое окно) дает низкое разрешение по частоте и наоборот. Возможно, для решения этой задачи придется использовать вейвлет преобразование.

U235
Я уже проделал некоторые эксперименты. С производительностью проблем нет, если учесть что я делаю FFT на уменьшенном изображении, да к тому же одномерный (только в вертикальном направлении). Первые результаты так себе. Если огрызок содержит достаточно много текста, и известен диапазон частот, в котором его надо искать, то по наличию пиков в этой области действительно можно отличить огрызок от не огрызка. Правда далеко не всегда такие условия выполняются. Скажем вместо текста на огрызке может быть часть картинки.
Кстати вопрос по математической части:
Что лучше, поставить столбцы пикселей один за другим в ряд и сделать FFT на всех их вместе, или же сделать FFT на каждом столбце по отдельности, и потом перемножить спектры, или может сложить?
А насчет варианта со сверткой - без примера, пускай и на матлабе, боюсь что я в этом не разберусь.

Tulon
Смотря что нужно сделать, если надо сделать 2D FFT, то это делается через два одномерных FFT: сначала по строкам, потом по столбцам (или наоборот, не важно) от того что получилось.
Для вертикального направления:
Нужный диапазон частот, как я понимаю, лежит где-то в пределах 30-70 (число строк на странице)?
Тогда можно попробовать сделать так:
1. Ресемплинг до размеров ~ 140 px по вертикали - этим мы избавляется от частот больше 70 (НЧ фильтрация).
2. Свертка с ВЧ фильтром (фильтрация), в данном случае одномерным, вертикальным: h=[0.5, -1, 0.5], т.е. новое значение y(i)=0.5*x(i-1)-1*x(i)+0.5*x(i+1); i - 0..высота страницы
3. Подсчет энергии в заданном диапазоне частот: Сумма квадратов значений Sum(y^2(i)), i=1..n (как вариант - сумма абсолютных значений). Вот немного картинок для пояснения.
Если эта энергия большая, то скорее всего на данном фрагменте присутствуют строки.
Вобще-то я думаю, что идея находить огрызок спектральными методами (как через Фурье, так и через пространственную фильтрацию) не совсем отличная, но каких-то других идей пока нет.

U235
Спасибо, более или менее все понял. На работе мне еще пару подходов предложили - теперь пара недель уйдет на то, чтобы их все попробовать.

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

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

Комментарии?

Tulon
Метод,как мне кажется, должен быть быстрее и универсальнее спектральных методов, т.к. становится не сильно важна переодичность строк.
Еще как вариант можно не округлять до нуля слабые значения и считать не число пересечений с нулем, а вычислять дисперсию или СКО. В этом случае снимается вопрос какие значения считать слабыми, а какие нет. И работать лучше с уменьшенными изображениями, иначе ВЧ шумы могут создавать проблемы.
P.s. Большого опыта работы со сканами с огрызками у меня нет (чаще или двойные или одинарные страницы), поэтому плохо представляю как могут выглядеть самые "тяжелые случаи" таких сканов.

Недостатки Scan Tailor

Обсуждение на моём форуме тут:

http://www.djvu-scan.ru/forum/index.php?topic=48.0

Цитата:

Обсуждение на моём форуме тут:

Обсуждений там не много, в основом там monday2000 занимется поливанием грязью ST и Tulon'а.
Вобщем гадко и мерзко.

U235

Цитата:

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

Вот вам пример сложного случая: http://www.onlinedisk.ru/image/429407/1273603563/
Это не скан, с снимок вот таким самодельным девайсом: http://www.diybookscanner.org/
Из-за конструктивных особенностей, изображение огрызка получается специфическим, и для него не выполняются предположения, на которые ST полагается в настоящее время для данной задачи. Хочется наконец уйти от всех этих эвристик и сделать алгоритм для всех случаев.

Цитата:

Вобщем гадко  и мерзко.

Не согласен! Пзнавательное чтение:
1) Аффтар признал, что СТ - состоявшаяся программа. Иначе о какой "альтернативе" можно говорить?
2) Аффтар возомнил себя Вышинским

Tulon

Цитата:

Вот вам пример сложного случая:

Хм.. может быть попробовать использовать то обстоятельство, что настоящая линия разреза и справа, и слева (если она не совсем с краю) должна быть окружена белыми (более-менее симметричными) полями?
P.s. Есть идея как уменьшить ошибки того алгоритма определения разворота, который есть сейчас в ST:
Вместо 3-х кнопок: без разреза, с огрызком, разворот, сделать 4: без разреза, с левым огрызком, с правым огрызком, разворот. Добавить "применить к каждой второй странице..".
Страницы с огрызками скорее всего будут чередоваться: огрызок справа, слева..
И линию в пространстве Хафа искать с учетом типа разреза. Для данного скана выбрали бы тип разреза : огрызок слева, в этом случае преобразование Хафа можно проводить только для левой половины страницы (или не учитывать линии с правой стороны, что привело бы для данного скана к правильному "угадыванию" разделительной линии). Если выбран тип разреза - разворот , то можно не учитывать кандидаты на линии близкие к краям.

Цитата:

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

Это не выполняется вначале и в конце толстых книг - тень там получается сильно несимметричная. Ну и конечно сильно не хотелось бы добавлять еще эвристик.


Цитата:

Вместо 3-х кнопок: без разреза, с огрызком, разворот, сделать 4: без разреза, с левым огрызком, с правым огрызком, разворот. Добавить "применить к каждой второй странице..".

Я на определенном этапе как раз это и пытался сделать, но потом передумал, и сделал как сейчас. Теперь уже и не вспомню, почему. К тому же есть у меня мнение, что делать это на автомате с высокой точностью вполне возможно, а раз так, то работать нужно как раз в этом направлении.


Цитата:

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

Оно так и работает. С разворотными сканами никаких проблем нет.

Полученный "скан" можно отнести к фотографии страниц книги, сделанной профессиональным фотиком. Поэтому это не задача ST, который предназначен пока только для для сканирования. Для обработки таких сканов применяются совсем другие методы обработки, который отличаются не только сутью, но и порядком их использования. ИМХО, пока рано. Как по мне мы почти уже на пике кривой диаграммы, который показывал один из пользователей (соотношения числа фич и довольных пользователей), если пойти путем полного комбайна, который обрабатывает любые входные картинки, то так можно и не достичь пика , а пойти по наклонной. Хотя учитываю, что Tulon-у виднее. Так и относительно хорошего dewarp-a в программе пока и нет. Думаю, что надо двигаться в этом направлении. И еще один вопросик: заметил, что исправление искажения строк обычно применяют впри корешке книги. Присмотрел достаточно быстрый способ и в то же время дающий хорошие результаты. Но он защищен патентом. Можно ли его использовать?

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


Цитата:

И еще один вопросик: заметил, что исправление искажения строк обычно применяют впри корешке книги. Присмотрел достаточно быстрый способ и в то же время дающий хорошие результаты. Но он защищен патентом. Можно ли его использовать?

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

Последние версии ST Separator'а вылетают при начале разделения...

Цитата:

В общем показывайте свой метод.

Ссылки на оригинальную статью на англ. языке
_http://rapidshare.com/files/386517174/10.1.1.110.6214.pdf.html
_http://ifolder.ru/17680981
Суть метода состоит в том, чтобы отдельно обработать затененную и незатенную области. Концы строк в затененной области аппроксимируются полиномами второй стемени и выпрямляются с учетом этого полиномаю После выпрямления концов строк они объединяются с прямыми фрагментами строк с незатенной области.
Если заинтересовало, то скажите - займусь переводом и мат. частью.

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

Цитата:

Планирую все-таки развивать именно его. Так или иначе, пока не до этого, но за предложение о сотрудничестве - спасибо.

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

woodyfon
OK. В исходниках у меня только старый вариант, где код рос как на дрожжах, и конца и края этому не было видно. Потом сослуживец предложил мне другой алгоритм трассировки строк. Он его использовал для трассировки слоев в древесине, но если хорошенько заблюрить текст, чтобы слова превратились в этакие сосиски, то должен без проблем справиться и с текстом. Он мне его на словах объяснил, поэтому и я буду на словах объяснять.
Так вот, один проход алгоритма делает вот что:
Даны два столбца пикселей. В первом столбце задано любое количество точек в виде y-координат. Точность сабпиксельная, то есть y-координаты могут быть нецелыми. Алгоритм для каждой такой точки найдет соответствующую ей точку во втором столбце. Точность будет также сабпиксельной. При этом учитываются два критерия:
1. Чем ближе цвета (уровни серого) в соответствующих точках, тем лучше.
2. Чем более параллельны соседние вектора от одного столбца к ко второму, тем лучше.
Реализовано это через динамическую оптимизацию. У меня есть proof of concept код.
Если тупо обрабатывать пары соседних столбцов, то будет накапливаться ошибка. Это вполне преодолимо - можно например раз в 50 пикселей делать большой шаг и интерполировать результаты между ними.

Ну как заинтересовало? Если да, я подчишу упомянутый proof of concept код, и выложу его.

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