» Scan Tailor

ndch

Цитата:

Может быть поможет на стадии "макет" убрать галку "выравнивать с другими страницами" ?

Может и поможет, спасибо за предложение, но мне нужны не догадки и вопросы, а ответы. Нужно чтобы автор или кто-то из специалистов ответили, например, если я загружу файлы в проект, указав при этом править dpi на 300х300, затем перейду на пункт меню "Полезная область" и определю ее, затем перейду на "Макет страницы" и поставлю все поля в "0" а также сниму галочку с "Выровнять с другими страницами", затем перейду на "Вывод" и сниму галочку с "Удалять пятна", DPI вывода поставлю в 300, а ползунок "Тоньше-Жирнее" поставлю в "0", то щелкнув на иконке любой другой страницы я получу в каталоге "out" правленый файл ТОЧНО ТАКИМ ЖЕ по полезной зоне, как исходный, и только с обрезанными полями или все-таки какое-то изменение полезной зоны будет?

PS. А поля тогда я добавлю и выровняю уже в XnView раз ST не может этого.

Баг в Qt до сих пор не исправлен. Вот версия с патченым Qt: http://www.onlinedisk.ru/file/254637/
Эта падать не должна, а в остальном полностью идентична предыдущей.

Добавлено:
ndch

Цитата:

Я чего путаю или без поворота и с одинаковым входным и выходным разрешением ресемплинг не делается ?

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

woodyfon

Цитата:

Tulon, а какой алгоритм вы используете для определения угла поворота при наклоне отсканированной страницы? Хотелось бы алго почитать не в кодовом виде, а в текстовом.

http://leptonica.com/skew-measurement.html - на английском. Там еще есть ссылка на PDF в конце. Вот только мне кажется, что исходник понятней будет.


Цитата:

какие параметры имеет точка изображения для ввода в алго поворота изображения на определенный угол? (Я так понимаю цвет, координаты точки относительно относительного начала координат, всего пять параметров * разрешение изображения (размер0 = комп просто-напросто зависнет. Получается матрица размером [высота]*[ширина] в пикселях.

Алгоритм работает на черно-белых изображениях (хотя в принципе может работать и на серых), соответственно имеем матрицу битов [ширина] x [высота], где биты упакованы в байты. То есть имеем массив байтов размером примерно [ширина] x [высота] / 8



Добавлено:
domo22

Цитата:

Может и поможет, спасибо за предложение, но мне нужны не догадки и вопросы, а ответы. Нужно чтобы автор или кто-то из специалистов ответили, например, если я загружу файлы в проект, указав при этом править dpi на 300х300, затем перейду на пункт меню "Полезная область" и определю ее, затем перейду на "Макет страницы" и поставлю все поля в "0" а также сниму галочку с "Выровнять с другими страницами", затем перейду на "Вывод" и сниму галочку с "Удалять пятна", DPI вывода поставлю в 300, а ползунок "Тоньше-Жирнее" поставлю в "0", то щелкнув на иконке любой другой страницы я получу в каталоге "out" правленый файл ТОЧНО ТАКИМ ЖЕ по полезной зоне, как исходный, и только с обрезанными полями или все-таки какое-то изменение полезной зоны будет?

Изменение наверняка будет.

Tulon

Цитата:

Изменение наверняка будет

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

Цитата:

А вообще - чем лента предпросмотра не индикатор прогресса (с зажатой верхней кнопкой)?

Ситуация - поставил я проект ST на длительную операцию и занимаюсь другими делами на компьютере. Чтобы оценить, на какой стадии сейчас эта операция я должен переключиться на окно ST, и по полосе прокрутки оценить эту стадию.
В то же время беглого взгляда на панель задач с процентами было бы достаточно.
Про многопроходную обработку - не понял. Я имел в виду только те операции, которые запускаются кнопкой play. А там, вроде бы, все просто - отношение количества уже обработанных с момента запуска операции страниц к оставшемуся количеству страниц.
Еще из хотелок придумал возможность полуавтоматического определения полезного размера изображения. Что-то типа кнопок на ребрах прямоугольника, ограничивающего полезную площадь, при нажатии которого ищется следующий экстремум. Ибо для того, чтобы результат не скакал от листа к листу делать это нужно с точностью до пиксела, что вручную трудно.
Кстати, не лучше ли вместо ЛК использовать нажатие колесика для перемещения страницы. Сделал несколько книг в ST, но так и не догадался попробовать переместиться с помощью ЛК (потому что ЛК четко сасоциировалась с перемещением границ самой области). Честно полагал, что это такой авторский юзабилити-ход - и масштабирование, и перемещение видимой области страницы - только вращением колесика...
По поводу wiki - на sourceforge я arichikato. Запрос там на присоединение отправил. Там явно не хватает в FAQ про кнопку слежения за обрабатываемой страницей. Или явную подпись к кнопке (если всплывающих подсказок в линуксе нет?). Подсказки в статусной строке - хорошо, но большинство пользователей, на которых программа расчитана, по-моему их просто не замечает.

domo22

Цитата:

Все понятно. А можно в будущей версии предусмотреть режим, когда будут только обрезаться страницы, а полезная область не меняться? Часто надо только размер страниц подправить, но при этом быть уверенным, что больше нигде ничего не произойдет.

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


Цитата:

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

Ну не получится такого и все тут. Либо одно либо другое - либо свобода действий, либо процесс, не вызывающий вопросов. Нужна свобода действий - берите Book Restorer.

StanFreeWare

Цитата:

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

OK, полезность вижу. Может когда-нибудь реализую.


Цитата:

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

Слишком низкое отношение необходимости к сложности реализации.


Цитата:

Кстати, не лучше ли вместо ЛК использовать нажатие колесика для перемещения страницы. Сделал несколько книг в ST, но так и не догадался попробовать переместиться с помощью ЛК (потому что ЛК четко сасоциировалась с перемещением границ самой области). Честно полагал, что это такой авторский юзабилити-ход - и масштабирование, и перемещение видимой области страницы - только вращением колесика...

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

Цитата:

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

Вы это серьезно? Или просто меня не поняли?
Не знаю, как сложилось в специализированных обработчиках сканов.
Но усредненное поведение браузеров, просмотрщиков книг (windjview и adobe reader), векторных и растровых графических редакторов (gimp и inksсape), cad-программ таково:
Ctrl+Колесико = Масштаб
Колесико - скролл видимой области страницы по вертикали.
Перемещение мышки при нажатом колесике - перетаскивание видимой области страницы.
Ну и еще в "самых правильных" редакторах изображений и просмотрщиках - Shift+Колесико - скролл по горизонтали.
То есть лично я вижу сформировавшиеся де-факто соглашения в пользовании колесиком. И ST им не соответствует. Что может навредить его конечной цели - простое автоматизированное создание книг любым пользователем.
Так настойчиво поднимаю этот вопрос потому, что, сделав в ST 10 книг, честно жал все вышеописанные комбинации, но так и не нашел ЛК+перемещение мыши для перемещения по видимой области страницы. Видимо потому, что стоял четкий блок после пользования графическими редакторами, что ЛК+перемещение мыши отвечает за действие над содержимым страницы (например, рисование линии, выделение текста), но не за перемещение по странице. Так (только не смейтесь) масштабируя колесом туда-сюда и пытался попасть в нужный мне фрагмент страницы все эти 10 книг.
А перемещение мышки при нажатой ЛК тогда остается, например, для перемещения выделенной области, т.е. для чего-то, связанного уже не с масштабированием и навигацией по листу, а с конкретными действиями пользователя на данном шаге.
Imho, так намного логичнее с точки зрения usability...
Но, само собой, все это возможно только после введения полос прокрутки, иначе без мышки с колесом (например, с тачпэдом ноутбука) к ST вообще не будет смысла подходить...

Цитата:

Слишком низкое отношение необходимости к сложности реализации.

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

Страница-убийца Scan Tailor (по крайней мере, на системе с 1 Гб оперативки) - http://www.onlinedisk.ru/file/256437/
Что можно сделать, кроме как подсунуть файлу проекта, как будто он уже нашел ее рабочую область?

Цитата:

Страница-убийца Scan Tailor (по крайней мере, на системе с 1 Гб оперативки) - http://www.onlinedisk.ru/file/256437/
Что можно сделать, кроме как подсунуть файлу проекта, как будто он уже нашел ее рабочую область?

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

Режим 4. При большом масштабе увеличения сбивается попадание курсором по границе полезной области. Ощущение что курсор считает границу выровненной по пикселам.

Добавлено:
Режим 5. Возможность изменения полей перемещением рамки полезной области только сбивает с толку и очень раздражает. Вполне достаточно оставить только перемещения рамки результирующего размера страницы. Предлагаю либо убрать возможность перемещения рамки полезной области в режиме 5, либо при попытке перемещения рамки полезной области переходить в режим 4 и редактировать непосредственно полезную область.
И еще - не совсем понятно размещение кнопок самая высокая и самая широкая страница в режиме 5. Обычно после нажатия на эту кнопку приходится переходить в режим 4 и править полезную область (потому что автоматика, например, приняла мусор на странице за полезную информацию и включила его в полезную область).

Цитата:

Режим 4. При большом масштабе увеличения сбивается попадание курсором по границе полезной области. Ощущение что курсор считает границу выровненной по пикселам.

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


Цитата:

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

Не так все просто. Как вы собираетесь тянуть внешнюю линию для расширения полей, если она и так у края экрана?
Переходить в режим четыре - тоже не вариант. Если реально переходить на другой этап - вот это как раз будет реально раздражать. А если делать чтобы этап 5 тоже мог изменять рамку контента - такого без ломания существующей архитектуры не получится.

А продублировать ссылки на широкую и высокую страницы в 4 этапе архитектура даст?
Реально последовательность действий такова:
1. Этап 5. Жму "самая широкая"
2. Приближаю колесиком - вижу что соринка в глаз попала - нужно тянуть границу полезной области
3. Либо перехожу на этап 4 и опять увеличиваю, чтобы убрать соринку, либо зашпариваюсь и тяну границу еще на этапе 5. Жду 10 секунд, ибо подтормаживает, пока нарисуются новые поля, правлю поля назад, жду еще 10 секунд и, матерясь, иду на этап 4.
4. В этапе 4 вытаскиваю соринку из глаза и на шаг 1. Повторяю, пока соринки не кончатся. А их может быть и 10, и 20, и 30... Уж смотря какая книга.
Короче говоря, процедура не из приятных получается...

Цитата:

Как вы собираетесь тянуть внешнюю линию для расширения полей, если она и так у края экрана?

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

Цитата:

А продублировать ссылки на широкую и высокую страницы в 4 этапе архитектура даст?

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


Цитата:

2. Приближаю колесиком - вижу что соринка в глаз попала - нужно тянуть границу полезной области
3. Либо перехожу на этап 4 и опять увеличиваю, чтобы убрать соринку, либо зашпариваюсь и тяну границу еще на этапе 5. Жду 10 секунд, ибо подтормаживает, пока нарисуются новые поля, правлю поля назад, жду еще 10 секунд и, матерясь, иду на этап 4.
4. В этапе 4 вытаскиваю соринку из глаза и на шаг 1. Повторяю, пока соринки не кончатся. А их может быть и 10, и 20, и 30... Уж смотря какая книга.
Короче говоря, процедура не из приятных получается...

Согласен, не дело это. Впрочем тормоза при тягянии рамок должны изчезнуть с включенным 3D ускорением, которое появится в следующем релизе.

Драг средней клавишей я ксати тоже следал. Убирать ли драг левой клавишей - еще подумаю, но скорее всего пусть будет и так и так.

Релиз кандидат все еще надеюсь выпустить сегодня. Осталось только обновить перевод и собрать под Windows, что делается небыстро - у меня сейчас Windows только под виртуальной машиной.

Добавлено:

Цитата:

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

Ослабить ограничение - не проблема, но по моему такое решение проигрывает в юзабельности.

Tulon


Цитата:

Драг средней клавишей я ксати тоже следал.

Едва ли это оправдано. Вы ведь в одном из предыдущих постингов совершенно правильно заметили, что перетаскивание средней кнопкой есть вещь совершенно неслыханная. А то, о чем пишет StanFreeWare -- это вовсе не драг, а прокрутка, которая визуально должна выглядеть совершенно по-другому (особая форма курсора, ускорение/замедление в зависимости от характера движения мыши...). И даже такая прокрутка является стандартом только для Windows, но не для Unix-подобных систем, где средняя кнопка традиционно используется для вставки буфера обмена.


Цитата:

Убирать ли драг левой клавишей - еще подумаю, но скорее всего пусть будет и так и так

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

anagnost96

Цитата:

Едва ли это оправдано. Вы ведь в одном из предыдущих постингов совершенно правильно заметили, что перетаскивание средней кнопкой есть вещь совершенно неслыханная. А то, о чем пишет StanFreeWare -- это вовсе не драг, а прокрутка, которая визуально должна выглядеть совершенно по-другому (особая форма курсора, ускорение/замедление в зависимости от характера движения мыши...). И даже такая прокрутка является стандартом только для Windows, но не для Unix-подобных систем, где средняя кнопка традиционно используется для вставки буфера обмена.

Да нет, я проверил в Gimp'е - там действительно средняя кнопка - полноценный драг. Надо полагать и в фотошопе то же самое. Видимо для людей, занимающихся графикой - это привычное дело.


Цитата:

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

Не убирать - так не убирать.

Релиз кандидат готов: http://www.onlinedisk.ru/file/256811/

Изменения по сравнению с предыдущей сборкой:
* Используется 3D ускорение для пользовательского интерфейса. Можно отключить в настройках.
* Линия разреза теперь не ищется в зонах, вплотную прилегающих к краям.
* Появились скроллбары в центральной области. Мне правда кажется, что они больше мешаются под ногами чем помогают, но все таки контролировать невыход контента за пределы рамки или картинки за пределы зоны с ними удобнее.
* Драг теперь работает и по левой и по средней клавише мыши.
* Вроде как должна быть решена проблема с неполным переводом.

У меня, на dell inspiron 1501 3d отрабатывает так:
http://www.onlinedisk.ru/image/256898/SCREEN.png
Хотя в момент масштабирования пытается перерисовывать нормально.

Да, пылесос иногда грубовато работает. Видимо, на шрифт Courier не рассчитан. Регулятор чувствительности нужен, наверное. Ну, да вы и сами знаете.
http://www.onlinedisk.ru/file/256925/

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

Добавлено:
Кстати, возвращаясь к теме "Страница-убийца http://www.onlinedisk.ru/file/256437/" - есть ли способ (алгоритм) превратить "серый точками" в "серый заливкой" без особого вреда для расположенного в серой области текста? А то у меня из-за нее и ей подобных результирующий размер djvu на порядок больше возможного.

2StanFreeWare
Кстати, возвращаясь к теме "Страница-убийца http://www.onlinedisk.ru/file/256437/" - есть ли способ (алгоритм) превратить "серый точками" в "серый заливкой" без особого вреда для расположенного в серой области текста? А то у меня из-за нее и ей подобных результирующий размер djvu на порядок больше возможного.
Есть способ.
1) для эффективной фильрации необходимо, чтобы растр был четкий, не размазанный. Поэтому сканировать такие страницы чаще всего приходится с разрешением 600 dpi, без всяких хитростей, вроде сканировать в 300, потом увеличить в два раза.
2) Удаление растра должно быть первой операцией, до всяких других фильтров. Поворачивать (устранять перекос) тоже нужно потом. До удаления растра обрезать и делать флипы (повороты на ±90°, 180°). Также можно делать коррекцию уровней/цветов, но аккуратно, следя за четкостью растра.
Сначала обрабатываем страницу полосовым или низкочастотным фурье-фильтром, настроенным на пространственную частоту и направление сетки точек (растра).
Возможно, потом понадобится пройтись билатеральным фильтром и unsharp.
Вот пример
до обработки:


спектр изображения с наложенным в центре фильтром низких частот, для пояснения


после фурье-фильтра


после билатерального фильтра + unsharp


Пример сделан за 5 минут, поэтому подгонка параметров не делалась. В частности фильтр брался просто низкочастотный, направление растра не учитывалось. Также параметры билатерального фильтра не подгонялись. Можно сделать и лучше.

Если нужно, могу описать подробнее

StanFreeWare

Цитата:

У меня, на dell inspiron 1501 3d отрабатывает так:
http://www.onlinedisk.ru/image/256898/SCREEN.png
Хотя в момент масштабирования пытается перерисовывать нормально.

Видюха не интеловская случайно?

Напишите, у кого работает, у кого нет, и в каких конфигурациях (видеокарта + операционная система).

Добавлено:
IvanStorogev
Да, интересно. Правда пока неприоритетно.

2Tulon
Если станет приоритетным имейте ввиду, для всего этого есть мощные опенсорсные библиотеки, поэтому обработку писать будет не надо. Только GUI.
Кстати, угол перекоса тоже можно определять с помощью фурье-анализа.

IvanStorogev

Цитата:

Если нужно, могу описать подробнее

Был бы очень благодарен, если бы вы попробовали на цветном изображении убрать растр.
Потому что люди очень давно ищут бесплатную замену фильтру Sattva Descreen.
Уничтожение полиграфического растра самая проблемная часть обработки цветных сканов на стадии подготовки.

2slava_kry
Был бы очень благодарен, если бы вы попробовали на цветном изображении убрать растр.
Да точно также, только каждый канал раздельно.
Вот пример
До фурье-фильтрации

После. Кроме фурье-фильтрации обработка не делалась

Только вот для обработки реальных сканов, например обложек журналов, нужен мощный компьютер. Память 4Gb — самый минимум, лучше 8Гб; 64-разрядная ОС; процессор 2-4-ядерник от 3 ГГц.

slava_kry
Цитата:

Потому что люди очень давно ищут бесплатную замену фильтру Sattva Descreen.
Уничтожение полиграфического растра самая проблемная часть обработки цветных сканов на стадии подготовки.

А чем Вам не нравятся обычные фильтры: Медиана, Сглаживание, Размытие по Гауссу, Адаптивное размытие (и их комбинации). На мой вкус нормально работают на цветных сканах, как и на серых.
Этот пример
Цитата:

Вот пример
До фурье-фильтрации

Медиана не хуже обработала чем
Цитата:

После. Кроме фурье-фильтрации обработка не делалась

2Arcand
Медиана не хуже обработала
А Вы практически попробуйте и сравните. Особенно на мелких деталях.

IvanStorogev
Цитата:

А Вы практически попробуйте и сравните. Особенно на мелких деталях.

Без проблем. Вот результат применения Медеаны+Адаптивное размытие.

2Arcand
Ну так откройте две картинки рядом и сравните. Вам пришлось практически полностью "замазать" поверхности и убить переходы. А от растра всё равно полностью избавиться не удалось, что хорошо заметно на однотонных поверхностях.
Кроме того, для изначально хреновой картинки какого-то прибора Ваш подход ещё прокатит.
А представьте, что нужно обработать скан лица из художественного альбома или хорошего журнала? Вы же его превратите в псевдорисунок масляной краской.
В общем против математики не попрешь — фильтры на основе преобразования Фурье гораздо эффективнее сверточных, если нужно удалять регулярную помеху, такую, например, как растр. Это давно разобрано в соответствующих книгах.

IvanStorogev

Цитата:

Вам пришлось практически полностью "замазать" поверхности и убить переходы.

Я специально "размазал" адаптивной размытостью - на свой вкус. А вот какие переходы я убил... не увидел.

Цитата:

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

Так и Вам не удалось избавится от растра, даже в большей степени.

И вообще, лучше-хуже, какая разница! При кодирование скана в дежавю, его кодер так пожует рисунок, что никакая математика не поможет

Цитата:

Изменения по сравнению с предыдущей сборкой:
* Используется 3D ускорение для пользовательского интерфейса. Можно отключить в настройках.

На вид и по ощущениям это 3D-торможение. Курсор мыши много раз замирает на доли секунды. Крайне неприятно. Хорошо что можно отключить. Сразу же выключил.


Цитата:

Напишите, у кого работает, у кого нет, и в каких конфигурациях (видеокарта + операционная система).

Нормально работает xp sp3 rus, geforce 8600 gt. Довольно распространена (или была часто встречаемой год-два назад).

Tulon
WinXP SP3, ATI Radeon® Xpress 1150 256M
IvanStorogev
Спасибо за развернутый ответ, но зачем же было картинками-то форум забивать. Надо было ссылками на файлообменник (или фотообменник).
slava_kry
Спасибо за ссылку на Sattva Descreen. Почитал документацию к нему ( http://www.sattva.ru/help/descreen/rus/professional/descreen_manual.htm ), чего и всем тем, кому кажется, что все так просто, желаю. Безумно интересно...

Я же имел в виду несколько другое... Здесь все-таки речь о djvu-книгах, а значит, в основном, о gray scale. Книга далеко не всегда сканируется в тех условиях, о которых говорится у Sattva Descreen.
Понятно, что в общем случае основа алгоритма - это фильтрация + последующая обработка порогом. Но, возможно, для моего случая можно придумать что-то относительно простое алгоритмически, оставляющее только одноцветный серый фон и текст на нем.
Например так:
1. Определяем среднюю яркость серого участка.
2. Порог, чтобы остался только текст и самые черные точки в серой части.
3. Пылесосим точки и шлифуем буквы.
5. Накладываем фон цветом, определенным на шаге 1.
А алгоритмы опробывать не на абстрактном куске электронных часов, а на странице-убийце. Если результат в серой части после djvu будет не хуже заголовка той же страницы (он на белом фоне), тогда и можно будет говорить об алгоритме в контексте Scan Tailor. Иначе тема забьется флудом (хотя местами и очень познавательным).

Tulon:
Конфигурация: WinXP 32bit, rus, sp2 AMD Athlon 64, 2200 MHz, 1Гб ОЗУ, Nvidia Ge Force 8600 GT 512 Mb.
Разницы, с OpenGL и без, пока не заметил. Отрисовка, по-моему, и так хорошо работала.

IvanStorogev

Цитата:

Сначала обрабатываем страницу полосовым или низкочастотным фурье-фильтром, настроенным на пространственную частоту и направление сетки точек (растра).

Но в качестве примера Вы почему-то приводите "ненастроенный" на "звездочки" спектра фильтр. Вообще Фурье-фильтрация (фильтр в частотой области) в том виде, который Вы приводите, действует глобально на все изображение. Т.е. не только на растр, но и на текст, Line-art, что не очень хорошо. Один из выходов - предварительное деление на растр и нерастровые элементы (что и делается в ST на стадии вывод в смешаном режиме). Кстати, глаз человека борется с растром простым усреднением (в первом приближении ФРТ - круг).
С цветным растром сложнее - нужно дополнительно делать преобразование RGB->CMYK (вообщем случае на цвета используемых красок, а их количества и значения еще надо как-то найти).
Предлагаю перенести обсуждение методов удаления растра сюда:
http://forum.ru-board.com/topic.cgi?forum=93&bm=1&topic=3172&start=200#lt

Иллюстрация:
Оригинал
Descreen
Немного шумодава
Такого, методом, который предлагает Arcand не добится.

Хотелось бы увидеть "результат применения Медеаны+Адаптивное размытие" и сравнить.