» ScanKromsator СканКромсатор (Часть 2)

Arcand
Спасибо огромное... Повторил последовательность действий, все получилось...
Единственное - Корел у меня английский, а я в нем... поэтому хотелось бы уточнить термины:

1.1. Адаптивное (Интеллектуальное, так называется в Кореле) размытие - Smart blur
3.2. Тоновая коррекция (Увеличение контрастности). Contrast Enhancement
3.3. Сглаживание Blur>Smooth

И есть пара вопрсов.


Цитата:

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

Можно про это поподробнее? Я остальные страницы тоже буду делать в Кореле

И еще - какими параметрами можно варьировать, а какие оставить без изменений. Меня немного смущает "3.2. Тоновая коррекция" - подойдет ли для всех сканов примено одного качества (не считая самых бледных)?

Если не трудно, покажите на примере (если размер большой, прежму/обрежу)

http://rapidshare.com/files/55107377/Image_0019.rar.html (1680 KB)

Alexx S

Цитата:

Инетересно, а возможно ли сделать "ужирнение" теста, когда выделяется контур, выделение расширяется на заданное кол-во пикселей и сглаживается. Ну и заливка...

Можно, я в Photoshop так развлекался на одном оччень плохом скане. Там скрипты пишутся тоже элементарно.

Melirius
Я имел в виду именно Кромсатор, в Фотошопе и я такое делал

(...)

Alexx S
Цитата:

хотелось бы уточнить термины:

Все так, проверил на английской версии.
Цитата:

покажите на примере

Это обычный по качеству скан. Немного смущает тень от сгиба у левого края. Если освещенность сканов раномерная, то я не использую Correct illumination в СканКромсаторе. В противном случае без нее не обойтись. Ваш пример обработал обычным образом как для случая равномерной освещенности сканов.

1. Кромсание в СканКромсаторе. Enhance image=off. На выходе gray.

2. Обработка.
Скрипт:
1.1. Адаптивное размытие. Количество=25.
Обычно в диапазоне 20-40. Смотреть в первую очередь тонкие и поэтому бледные линии и перемычки в буквах. Если они есть и надо их сохранить - меньшие значения. Надо сильнее размыть фон - большие значения. Назначение - позволяет уменьшить количество мусора от фона.
1.2. Ресемплинг. Увеличение разрешения 300 дпи -> 600 дпи. Сглаживание и сохранение пропорций включено. Неансов нет.
1.3. Тоновая коррекция. Обрезка входных значений=95; 220.
Обычно гистограмма выглядит как небольшой подъемчик, широкое плато, подъем на максимум, небольшое плато и спад. Точка черного устанавливается немного правее подъемчика, точка белого на большом подъеме. Текст должен быть не очень жирным или тощим; не слишком темным или бледным (знание придет с опытом). Смотреть бледные фрагменты, чтобы не потерять или сделать слишком бледными и не пережирнить текст. Назначение - по возможности убрать фон (сделать его белым) а текст достаточно черным.
1.4. Сглаживание. Процент=100 (всегда). Мягкое сглаживание, особенностей не замечал. Назначение - сгладить контуры букв перед Контурной резкостью.
1.5. Контурная резкость. Радиус=3 (всегда, соответствует эмпирическому правилу радиус=дпи/200). Порог=0 (всегда). Процент=300.
Обработка делает контуры резкими с перехлестом, т.е. прилигающие к контуру светлые участки становятся светлее, темные - темнее. При этом подчеркиваются неровности. Обычно процент в диапазоне 150-350. Большие значения, чтобы вытянуть бледные перемычки (плюс сохранить промежутки между засечками), меньшие - когда последних нет и можно избежать появления неровностей. Побочный эффект - вытягивается мусор.
1.6. Сглаживание. Процент=100 (всегда), выполнить два раза. Нюансов нет (но надо следить, чтобы узкие перемычки не затянулись). Обычно обработка выполняется один или два раза подряд. Назначение - сгладить буквы перед бинаризацией.
1.7. Бинаризация. Метод преобразования=штриховой рисунок, порог=170 (можно было бы сделать и побольше, но появляются следы от тени, возможно потребуется чистить фон). Порог подбирается визуально по вкусу.

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

3. Чистка мусора в СканКромсаторе.

ЗЫ: Запас прочности у обработок имеется. Поэтому, если сканы (и страницы в оригинале) визуально в отношении тона различаются не сильно, то все будет нормально.
Если имеется заметное различие между сканами по тону, то я делаю предварительную обработку: адаптивное размытие и автокоррекцию. Из основной обработки адаптивное размытие естественно убирается.
Предварительная обработка может понадобится и в случае других проблем со сканами (наличие просвета).

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

Здравствуйте, спасибо bolega за программу! Как начинающий хотел бы спросить по поводу резаков, доки и материалы monday2000 прочитал. Как я из них понял, синие резаки отделяют полезную от всякого мусора, красный резак показывает точную границу текста. Видимо я неправильно понимаю, что если стоят все синие резаки, то вся область внутри них должна быть включена в результирующий файл. Например, если есть страница с текстом только в начале (окончание главы) Если только ее выделить только синими резаками (то есть нижний резак выше половины страницы) или если нижний резак поставить вниз (то есть растянуть область внутри синих резаков, на примерный размер страницы без полей) то в результирующем файле область с текстом оказывается в конце страницы. Я бы понял, если такое происходило только в первом случае (кромсатор по своему алгоритму располагает эту область). А почему так получается во втором случае? С этим можно бороться только выставлением красного верхнего резака? Или я чего-то в них недопонял? Спасибо.

vladal
Синие резаки действительно только обрезают мусор (как расположен текст между резаками, роли уже не играет). Затем кромсатор определяет контур текста и располагает его в соответствии с заданным выравниванием (!). Если для страницы задано выравнивать по нижнему краю, то невысокий абзац окажется внизу, т.е. в конце страницы. Видимо, так у Вас и происходит. Задайте выравнивание по верху v.align = T (top).
Бывает, что на странице имеется строка текста (или номер страницы из одной цифры), которую кромсатор не включает в контур текста, т.к. не может однозначно решить, текст это или мусор (тень к примеру). Точнее, он решает, но нередко не в пользу текста В результате после кромсания такой выступающий текст оказывается срезанным. Чтобы этого избежать, нужно отключить для данного резака под-опцию automargin, резак примет малиновый цвет и Вы должны выставить его максимально близко к краю этого выступающего обрезающегося текста. В этом случае малиновый резак трактуется кромсатором как заданный вручную контур текста (левый, правый, и т.п. в зависимости от резака) и обрезать текст в этом месте уже не будет.

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

как расположен текст между резаками, роли уже не играет

Что вне резаков (сейчас и далее я имею ввиду только синие), то точно отрезается, а что внутри все равно может быть отрезано? Так как в указанной Вами ситуации с одной цифрой можно было бы просто передвинуть синий резак, чтобы цифра попала внутрь области. Вы же пишете, что

Цитата:

нужно отключить для данного резака под-опцию automargin

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

Цитата:

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

Об этом я и написал. Может. Если это одинокий символ или единичная строка. Вы спросите: если резаками мы отрезали весь мусор, то пусть кромсатор учитывает все, что внутри, за текст и тогда срезания одиноких символов можно избежать. К сожалению, скан есть скан. Часто отрезать мусор полностью не удастся, т.е. белых промежутков на скане не бывает никогда, поэтому sk все-равно проверяет его даже после отрезания реаками и контур текста (и иллюстраций) ищется всегда с учетом того, что мусор может быть (fuzzy-поиск). Однако если вы уверены, что мусора нет, то можете увеличить чувствительность определения контура изменением опций на закладке options2, в этом случае малиновые резаки можно и не использовать.


Цитата:

как кромсатор определяет контур текста в случае синих резаков

Подробностей алгоритмов я никогда не разглашаю


Цитата:

Не совсем понятна фраза

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

bolega
Спасибо за подробные объяснения Последние уточнения. Алгоритм получается следующий: Запускаю draft kromsate. Проверяю резаки на каждой странице, если часть текста не попала в выделенную область, то сам указываю правильную границу малиновым резаком. Если же весь текст попал в выделенную область и там нет паразитного мусора у границ, оставляю как есть, если есть мусор, обрубаю его синим резаком. Такой вопрос: если кромсатор сам поставил малиновый резак, то его нужно вплотную подвести к границе текста, менять на синий (ставить соответствующий automargin) не надо. Еще вопрос: Резаки на исправление перекоса текста никак не влияют, их можно повернуть только для того, чтобы максимально избавиться от грязи. Я все правильно понял?

vladal

Цитата:

оставляю как есть, если есть мусор, обрубаю его синим резаком

Все правильно. Но за мелким мусором особо охотиться не стоит, т.к. он будет убираться despeckl-ом при обработке.

Цитата:

Такой вопрос: если кромсатор сам поставил малиновый резак, то его нужно вплотную подвести к границе текста, менять на синий (ставить соответствующий automargin) не надо

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


Цитата:

Я все правильно понял?

Да

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

bolega
Обрабатываю журнал, на каждой странице которого много серых и цветных picture-зон.
В окне Result view очень не хватает возможности сделать merge сразу для всех picture-зон этой страницы, приходится на каждой странице выходить в основное окно, затем возвращаться назад.
И еще. Здесь основную подчистку делаю в режиме Auto-magic clear, иногда переходя в режим Auto-clear и обратно.
Хорошо бы здесь этот переход делать по двойному щелчку мыши, как в случае черно-белых сканов переход между режимами Auto-clear и Auto-despecle.

Забавно западники на гигапедии интерпретируют

Цитата:

    
Hi
Does anyone know what is the password in english for the rar file for the new scankromsator version 5.81 NY. In russian it is something like "xpioxpio" but when I try to extract from the rar file, it does not work.

Цитата:

    
Pw: "hryuhryu" in the English layout

Вот такую свинью уважемемый bolega подложил нашим зарубежным коллегам

Кстати, смех смехом, а мне вчера предложили пост модератора на закрытом международном форуме, родственном этой гигапедии и посвященном книгам и всему, что с ними связано. Попросили курировать ветку по ripping/processing Об СК они еще не знают. Вопрос: можно ли им рассказывать об СК, если да, то какую версию рекомендовать? Просто, помню, было уже здесь, по-моему, обсуждение по этому поводу. Кто-то был против распространения СК за пределы русскоязычного сообщества
Топик там можно сделать закрытым...

VadimirTT


Добавлено:
ghosty
Не думаю, что не знают. Если у них собирется сильное сообщество, то они сами распространят и освоют СК. Интерфейс же на английском. Вопрос только в том, кто начнет об этом рассказыть и в благословлении bolega этого дела.

На сайте http://bolega.hotmail.ru/
лежит версия 5.81 NY но в виде rar архива с паролем
Никто не подскажет какой пароль
А то хотелось попробовать новую версию

vladimirzaytsev
См. 4 поста выше.

bolega

Если мне не изменяет память, то в предыдущих версиях был инструмент "magic wand". Сейчас, работая с зонами, я его не нашел, а ведь было бы очень удобно - если контур изображения без разрывов и достаточно темный, то фон можно было бы почистить одним кликом...

shch_vg

Цитата:

В окне Result view очень не хватает возможности сделать merge сразу для всех picture-зон этой страницы, приходится на каждой странице выходить в основное окно, затем возвращаться назад

А почему Вы не используете команду в осн. окне, которая объединит зоны сразу для всех файлов?


Цитата:

Сейчас, работая с зонами, я его не нашел

Клик мышки при нажатых Ctrl+Shift

bolega

Цитата:

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

Мне гораздо удобнее обрабатывать последовательно каждую страницу, причем на любой из них может быть как удаление отдельных зон, так и добавление/изменение.
Если бы предложенный Вами способ был удобен, то можно было бы после обработки книги сделать автоматически (по параметру) объединение всех зон.
Еще одно, что на мой взгляд помогло бы более удобно обрабатывать такие сканы:
Страница обработана Кромсатором, но нужно на ней переобработать пару-тройку зон. Приходится выходить в основное окно, вносить изменения в зоны и обрабатывать заново всю страницу. Нельзя ли сделать, чтобы Кромсатор сам определял, в какие зоны внесены изменения и обрабатывал только их (при удалении зоны делать обработку области под бывшей зоной по основному алгоритму). А верхом мечты было бы делать все это не выходя из окна Result view.
Я понимаю, что все предложенное мной потребует большой дополнительной работы, но я делал несколько журналов, содержащих много как цветных, так и черно-белых фото и фрагментов, поэтому написанное мною выше действительно облегчило бы такую обработку. В этих случаях ручной работы (кроме вышеперечисленного еще и расстановка многочисленных зон с разными параметрами) очень много.

Если кто-то знает простую технологию обработки таких сканов, просьба поделиться ею.

bolega

Цитата:

Клик мышки при нажатых Ctrl+Shift

Что-то работает не так, как должна - при одинаковой чувствительности я magic clear либо ничего не выделяет, либо выделяте только по клику на определенное место (цвет задан правильно). При если цифры чувствительности увеличивать, то выделяте только наружный контур, объекты внутри выделения игнорируются

bolega
Есть ли сейчас возможность определить, к какой обработанной странице относится тот или иной файл из директории OUT с префиксом PIC?

shch_vg

Цитата:

Если бы предложенный Вами способ был удобен, то можно было бы после обработки книги сделать автоматически (по параметру) объединение всех зон

Я уже год так и делаю. Считаю это вполне удобным и логичным. Сначала все обработал, почистил, и в заключение слил зоны.
Слияние всех зон страницы из окна VR сделаю


Цитата:

но нужно на ней переобработать пару-тройку зон

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


Цитата:

А верхом мечты было бы делать все это не выходя из окна Result view.

Думаю, это возможно.


Цитата:

Есть ли сейчас возможность определить, к какой обработанной странице относится тот или иной файл из директории OUT с префиксом PIC?

Нет, но сделаю.
Сейчас определить можно так: в окне свойств зоны в заголовке пишется ее идентификатор. Этот идентификатор совпадает с тем номером, который содержится в имени выходного файла.

bolega

Цитата:

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

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

Цитата:

Цитата:Есть ли сейчас возможность определить, к какой обработанной странице относится тот или иной файл из директории OUT с префиксом PIC?

Нет, но сделаю.
Сейчас определить можно так: в окне свойств зоны в заголовке пишется ее идентификатор. Этот идентификатор совпадает с тем номером, который содержится в имени выходного файла.

В приведенной цитате я имел в виду другое. Обрабатываю постранично сканы и в окне RV каждой зоне делаю Merge с последующей подчисткой вокруг нее. После завершения всей работы в директории Out обнаруживаю файлы с префиксом PIC, т.е. где-то я пропустил зону и не сделал ей Merge. Конечно, я могу сделать общий Merge, который сольет все пропущенные зоны, но они останутся неподчищенными. Хотелось бы по имени PIC иметь возможность выйти на нужную страницу и обработать пропущенную зону.
Как я понимаю, это не сделать программно, можно лишь как-то заложить в нумерацию PIC, например, PICХХХ-YYY, где ХХХ - номер обрабатываемой страницы, а YYY - номер зоны на странице.

shch_vg

Цитата:

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

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


Цитата:

Обрабатываю постранично сканы и в окне RV каждой зоне делаю Merge с последующей подчисткой вокруг нее

Теперь я понял, почему Вы просите слияние. Я предпочитаю чистить зону, а потом сливать, а не наоборот. Ведь так намного быстрее. После слияния скан станет например 24-битным, а чистка 600-dpi 24-битного скана выполняется намногоо дольше и медленне, чем чистка маленькой зоны.


Цитата:

Как я понимаю, это не сделать программно

Как это не сделать??? Элементарно. В меню Find добавлю еще один ключ поиска - номер зоны (его возьмете из имени файла). И кромсатор сам найдет страницу, откуда зона вырезана. А именовать pic-файлы по-другому я не буду, думаете, теперешнее именование - это первое, что пришло мне в голову? Ошибаетесь. Здесь я все продумал. Имя страницы намеренно не присутствует в имени файла, иначе при изменении порядка исх. файлов (снятие или взвод галки, удаление, добавление, перемещение файла в списке) пришлось бы переименовывать огромное количество файлов зон. Например, я как-то делал 500 страничную книгу с 4000 зонами. Потом на первое место место добавил обложку, значит, по-вашему, мне нужно все эти 4000 файлов зон переименовывать? Зачем, если и без этого все можно сделать.

bolega

Цитата:

Цитата:Обрабатываю постранично сканы и в окне RV каждой зоне делаю Merge с последующей подчисткой вокруг нее

Теперь я понял, почему Вы просите слияние. Я предпочитаю чистить зону, а потом сливать, а не наоборот. Ведь так намного быстрее. После слияния скан станет например 24-битным, а чистка 600-dpi 24-битного скана выполняется намногоо дольше и медленне, чем чистка маленькой зоны.

У каждого варианта есть свои достоинства и недостатки. Я сравнительно редко захожу в режим Zones (в основном для поворота фото, реже для убирания пятен), большинство зон у меня не на фото, а на тексте и линиях ( для смягчения черного цвета, т.к. основная обработка задается в Ч/Б, либо для цветных заголовков). Кстати, я уже писал, что после захода в режим Zones из режима Fit width довольно затруднительно вернуться в него снова.
Для меня оптимален такой вариант работы: переход на очередной лист в окне RV, возможный заход в режим Zones с возвратом, слияние всех зон на листе и подчистка в режиме Auto-magic clear.

====
Закончил модернизацию импорта pdf. Понимаются все версии pdf до Adobe 7 включительно, за исключением пока картинок, сжатых вейвлет-методом (jpg2000 из adobe 7). JBIG2-сжатие понимается. Прозрачные картинки, вставленные в pdf-страницы (например кромсатором), импортируются как зоны с поддержкой прозрачности, т.е. трактуются как непрямоугольные зоны. Т.е. получился теперь полный замкнутый цикл - кромсатор делает pdf-файл с зонами - импортирует его с полным восстановлением по сути исходного задания, которое его произвело (скан+зоны).

P.S. Возможно, некоторых нервирует моя озабоченность pdf-форматом. Просто не читайте тогда. Но pdf пока что еще никто не отменил, как раз наоборот. Часто слышу, что pdf, мол, отмирает. Чушь. Стандарт, который существует десять или более лет, никогда просто так не отомрет. По крайней мере, Adobe довольно богата и могущественна, чтобы этого никогда не допустить.

bolega

Цитата:

P.S. Возможно, некоторых нервирует моя озабоченность pdf-форматом. Просто не читайте тогда. Но pdf пока что еще никто не отменил, как раз наоборот. Часто слышу, что pdf, мол, отмирает. Чушь. Стандарт, который существует десять или более лет, никогда просто так не отомрет. По крайней мере, Adobe довольно богата и могущественна, чтобы этого никогда не допустить.

Целиком и полностью согласен. Есть вероятность, что JB2 рано или поздно все-таки уступит JBIG2. Во всяком случае Cvision активно над этим работает. А тогда DJVU действительно может настать конец.

Только я все равно не понял, зачем нужен импорт из PDF?

ghosty

Цитата:

Только я все равно не понял, зачем нужен импорт из PDF?

Для перевода в "умирающий" DJVU.


Добавлено:
bolega

Цитата:

Закончил модернизацию импорта pdf.

А пустые страницы будут создаваться?