Вернуться к разделу "СканКромсатор v5.6A. Пособие по программе".
В этот раздел вошли те самые разнообразные материалы из форумов, которые в основном не нашли отражения в Пособии по Кромсатору ("лишние"), а выбрасывать их жалко.
По сути, эти материалы не столько описывают элементы управления Кромсатора, сколько являются, скорее, полезными советами и рекомендациями по использованию Кромсатора - от автора программы СканКромсатор bolega (поэтому они и не вошли в Пособие).
Думаю, читать всё это имеет смысл только после прочтения Пособия по СканКромсатору 5.6A - иначе многое будет непонятно.
Спасибо Arcand и другим за предоставленные материалы.
Если что непонятно - спрашивайте, или ждите готовящейся доки. Успехов.
bolega
Предисловие от bolega:
По поводу проблемы размер/качество (DjVu-файла):
Если уменьшение размера финального DjVu-файла достигается просто правильным применением настроек Document Express Enterprise 5.1 или сглаживанием букв - это одно, если же таким кардинальным методом (читай - деградацией), как 600->300dpi, это уже другое.
Часто можно прочитать фразу "без потери качества". Вот здесь меня терзают смутные сомнения. Как именно оценивается это качество? Боюсь, что беглый визуальный осмотр результата (думается, что именно так всегда и происходит) в DjVu-просмотрщике или в Кромсаторе, которые показывают страницы в сильно уменьшенном масштабе и с применением облагораживающих внешнее представление фильтров, действительно не покажут ухудшения. Зато когда начинаешь внимательно читать, оказывается, что там индексы стали неразборчивы, там перемычки в буквах исчезли, там тонкие линии на графиках полностью испарились, там плюсики стали минусиками и т.д. Естественно, что при беглом осмотре этого вряд ли заметишь.
Насчет общего размера библиотеки: мне кажется, что иметь её на 1 диске, или на 2-3-х - уже становится не принципиально. При большом количестве книг, лишние несколько болванок уже ничего не решают. Зато как обидно, когда достаешь из этого сборника редкую книгу, шансов найти которую на бумаге абсолютно нет, с целью прочитать какие-то выкладки или справочник, и с ужасом обнаруживаешь, что то, что тебе нужно, там либо изначально при сканировании, либо дальнейшей обработкой, приведено в нечитабельно-неразборчивый вид. Тогда задаешь себе вопрос: а зачем всё это тогда делается??? Для кого и для чего? "Шобы было?" Выдадим в пятилетку столько-то книг и засунем их на столько-то дисков? Это, что ли, цель?
Лично я считаю, что делать похуже качеством только из-за модемщиков (т.е. тех, у кого модемное подключение к Интернету и кто не может скачивать большие файлы) - это какая-то времянка. Если речь идет не об одной книге, а о библиотеке, может проще будет записать её потом на CD или DVD и дать скопировать желающим?
Причём если книги там действительно редкие, то и сделать их лучше в хорошем качестве, чтобы на века (в смысле никогда их не переделывать).
1. Все сканы разные, качество меняется не только от книге к книге, но и от страницы к странице. Это я к тому, что многие полезные вещи можно было бы реализовать в кромсаторе, но тогда из-за упомянутого разнобоя в качестве сканов пришлось бы предоставлять пользователю множество параметров, которые, подобранные и хорошо работающие на одном скане, на другом бы не дали бы ничего.
Это я к тому, что превращать кромсатор в графический редактор с десятками вручную подбираемыми параметрами я не хочу - по большому счету этим подбором никто заниматься не будет. Все хотят, чтобы нажал кнопку - и получил результат. Кромсатор - это в первую очередь для пакетной обработки с минимальными усредненными настройками. А иначе какой смысл в изобретении нового фотошопа.
1. Draft kromsate и Process
2. По поводу разбиения разворотов на две страницы. Здесь результат зависит от качества скана. Если разворот симметричный, без особой грязи по краям, без наползания на текст полосы посередине, то FineReader 7.0, BookRestorer 4.1 и Кромсатор 5.51, наверное, практически одинаковы. В Кромсаторе же автоматический Draft kromsate оптимизирован именно под небрежные сканы: несимметричный, с большими полями, маргинальными полосами по краям и в середине. Ну, а чистые и симметричные сканы - это для него вообще как орешки щёлкать. В Кромсаторе нужно открыть эти файлы и выполнить команду Draft kromsate. В окошке, которое появится после выбора команды, нужно поставить галку на Split page и на Don't use Deshadow option.
3. Большинство проблем с обрезкой можно предотвратить 3-мя способами:
1). Выбрать подходящий gap. Для 600 dpi я использую 150 x 180, для 300 dpi - 80 x 100. Т.е. нормальные поля компенсируют погрешности оконтуривания. А проблемы бывают. Это из-за того, что определитель контура работает с определённой заложенной в него погрешностью, чтобы ложно не спотыкаться на мусоре. Кроме того, контурный анализ проводится не построчно, а по 4-8 строк/столбцов (в зависимости от dpi) за раз (для убыстрения, да и со статистической точки зрения более достоверно). Поэтому например, может не включить в контур номер страницы(особенно в начале книги, когда номер из одной цифры).
2). Вручную задать резак: ставим резак вплотную к настоящему краю (например, снизу) и убираем соответствующую галку в под-галках Automargins. Т.е. как бы вручную задаём положение нижнего контура для данной страницы.
3). Если страница режется слева, просто поставьте для неё выравнивание Right или Center. Помогает хорошо. В новой версии можно указать режим None для отдельной страницы. Это бывает нужно, например, для обложки - она практически всегда больше, чем все остальные страницы. В этом случае её размер будет определяться исключительно резаками, gap-ы игнорируются, и в расчёте окончательных размеров она также не участвует.
4. А могу ли я как-нибудь получить значения усреднённых размеров страницы (для подстановки в Book->Page Width/Hight (Fixed)) после работы Draft kromsate?
Нет, Draft kromsate не занимается расчётом размеров
страниц. !!!
Можно просто обработать какую-нибудь одну
страницу и посмотреть какой у неё размер
получился.
5. !!! Определяет ли Draft kromsate точно контур голого текста, или ему на это плевать, и он только грязь распознаёт? (обозначая её резаками)
Определяет не столько контур, сколько блоки текста. Полагаться просто на определитель грязи нельзя - слишком ненадёжно. А вот делать и то, и другое одновременно - гораздо лучше. Я как-то писал, что draft анализирует текст вплоть до строчек и букв, чтобы потом методом вероятностного анализа "отсеивать" мелкую и среднеразмерную грязь от текста. Вообще, драфту приходится несладко. Скажем, было бы гораздо легче, если бы он одновременно с распознаванием грязи тут же удалял бы её. Но это делать нельзя, и поэтому 2-я его задача - не просто определить полезный контур, но еще и оптимальным образом всунуть между ним и грязью резак. Ведь нередко из-за наклонов скана и наличия маргинальных теней и полос последние не только не оставляют белых просветов в горизонтальных или вертикальных направлениях, но и сливаются с текстом. Вот тут-то вступает в работу 2-я группа алгоритмов по оптимальной установке резаков. Если бы грязь была удалена, то этот процесс был бы тривиальным. Но кромсатор не изменяет исходных сканов.
Но в целом вы правы - задача драфта - расставить резаки так, как это бы сделал человек. Учитывая, что назначение резаков - отсекать грязь, то и драфт соответственно делает именно это. Вся информация, накопленная драфтом относительно страницы, по окончании работы драфта теряется. Процессы драфта и последующего кромсания никак не связаны.
6. !!! Такого, похоже, раньше не было: ставлю резак ниже номера страницы, а Кромсатор не обращает внимание на резак и всё равно отрезает по нижней границе текста. А выключаю Automargin для нижнего резака, работает по резаку - т.е. номер страницы жив остаётся. Так ведь, вроде, если резак установлен, то Automargin работать вообще не должен, или я не прав?
Не правы. Всё наоборот.
Отсутствие любой из подгалок Automargins означает, что
вы сами зададите положение данного края текста
_резаком_. Там, где поставите резак, там и будет
край текста (к нему и будет прибавлять поля
Кромсатор).
Ох, а я-то наивно полагал, что после работы Draft kromsate (и правки результатов вручную) полученные резаки имеют больший приоритет, нежели "автоматические" опции (т.е. в данном случае соответствующие подгалки Automargins). Оказывается, я зря старался... Это ведь в любых системах так - если я задаю какие-то параметры вручную, любая другая автоматика должна уважать мой выбор. Т.е. автоматика должна выключаться автоматически. :) Теперь нужно будет перепроверить все сделанные книжки на предмет "ошибок автоматики". :(
Вы плохо представляете себе назначение
резаков. Основное их назначение - отрезать мусор,
но не определять края страницы (поэтому резаки и
не обязательно ставить вплотную точно к тексту, а
иначе выставлять их было бы мучением, да и
невозможно это бывает при перекосе страницы). И
только когда кромсатор не может самостоятельно
правильно это сделать, только тогда резаку можно
придать дополнительную функцию (что и
сигнализируется теперь изменением цвета резака).
Если бы после каждого нашего движения резаком
кромсатор принимал его за фиксацию, то это был бы
ужас. Т.е. я сдвинул резак, чтобы просто лучше
отсечь какое-нибудь пятнышко и при этом резак ещё
далеко от текста, а кромсатор возьми и зафиксируй
этот порыв как край текста. Так нельзя.
Собственно, об этом все хорошо написано ещё в 1-й
доке. С тех пор в поведении резаков ничего не
поменялось.
Но вы подали мне одну идею: если резак двигать
например с нажатым Shift, то Кромсатор
автоматически бы сбрасывал бы под-опцию automargins,
всё ж меньше щёлкать.
7. Draft Kromsate Кромсатор для всех сканов ставит зеленую галку, с тем чтобы их позже покромсать. Как исключить из кромсания часть сканов - скажем, я просмотрел и поправил резаки на первой сотне и хочу посмотреть, что получится в результате кромсания. Как исключить сканы, начиная со 101?
Галку снимать нельзя, иначе потеряются все
настройки для этих сканов. (!!!)
Но Кромсатор позволяет обработать любую группу
сканов. В меню Process->Group->... и там выберите что
нужно, в том числе если стать на 100-й файл и
выбрать process up to current.
Кромсать можно и произвольные файлы, если их
предварительно пометить как selected (т.е. красным,
через пробел можно) и покромсать уже только их.
8. При Draft Kromsate Кромсатор часть сканов в списке выделяет жирным. Что это значит?
На эти сканы после Draft Kromsate следует обратить особое внимание, для них для одной или нескольких сторон кромсатор убирает под-галку на опциях Pages -> Automargins, что означает, что Кромсатор определил контур текста с помощью вероятностных методов, а потому возможны ошибки.
Нужно ли снова ставить эти убраные галки при просмотре перед кромсанием?
Вероятностные методы кромсатор использует
если несколько строк текста сильно вылазят за
край всего остального текста, либо имеется
колонка из цифр или букв, отстоящая от остального
текста, либо имеется сильно разряженный текст.
Кромсатор в этом случае выполняет более
углубленный и полный анализ содержимого
страницы (высчитывает размеры шрифтов, размеры
заглавных букв, выделяет каждую строку текста),
чтобы далее понять, что это такое вылазит :) и к
какой строке текста это относится. Делается это
для того, чтобы определить, то ли это текст, то ли
мусор на полях. Если он решит, что это текст (без OCR
это не так-то легко сделать, поэтому возможны
промахи), он подводит резак вплотную к его краю и
убирает под-галку для этой стороны.
В общем случае, если это действительно одиночный
текст, галку взводить не надо! Иначе при
кромсании велика вероятность, что этот
выступающий текст будет обрезан (так же, как это
бывает иногда с номерами страниц). Отсутствие
галки для какого-то края является как-бы приказом
для кромсатора - здесь действительно край
полезного текста, отрезать нельзя!
Посмотрел ваши примеры. Не знаю, зачем вы
сканируете такую большую лишнюю площадь, но в
Кромсатор заложено ограничение на положение
резака относительно края скана (ограничение
работает только для грязных краев, если же на
скане будут просто огромные белые поля, то это
уже не будет являться ограничением). В 99% случаев
до предела дело не доходит. Но в ваших сканах -
редкий случай, когда доходит, и ниже этого
предела резак не опустится намеренно. В draft на
этот случай можно применять пред-обрезку таких
областей, но к сожалению, в текущей версии она не
предусмотрена для верха и низа, а только для
боков. Учту.
9. Пытался повторить вот этот прием, но размеров страниц так и не получил в соответствующих полях:
Цитата:
Cначала я кромсаю при Book -> Page width = Auto / Book -> Page
height = Auto, получаю в итоге нужные размеры, потом
переключаюсь на Book -> Page width = Fixed / Book -> Page height =
Fixed и дорабатываю отдельные страницы, не заботясь
уже об их размерах. Причем часто я кромсаю при Auto
страниц 10-20, получаю от Кромсатора Fixed-размеры,
переключаюсь на режим Fixed и кромсаю уже всю книгу.
Т.е. я так понял, что эти размеры должны автоматически подставляться в поля Page width / Page height. Или не так?
И так, и не так. При расчете одной страницы сами действительно не подставляются. Это сделано специально. Вам придется узнать их по команде Image info в окне Result view. В новой версии я сделал более удобную команду в основном окне.
10. Как обрабатывать сканы вида "1 страница в 1 скане" (обычно сбоку от неё видна полоса - часть соседней страницы)?
Очень хороший вопрос. Прежние версии такие ошметки отметали на ура (имеется ввиду draft kromsate). Затем одна из последних версий "поумнела" (в плохом смысле), т.е. запросто может поставить резак и за ошметком, а не как надо, т.е. перед ним.
Это вызвано тем, что кромсатор теперь распознает текст на странице и ставит резаки с учетом этого. Кое-какие меры я предпринял, но срабатывает не всегда.
Выхода два - ввести специальную опцию для таких сканов, либо воспользоваться существующей фичей. При draft kromsate доступна настройка Pre-cut margin. Она задает область страницы, которая будет исключаться из анализа при draft. Там несколько вариантов этих исключений, например, исключать область слева, справа, слева на первой странице и справа на следующей т.е. чередовать и т.д. Область задается приблизительно, в долях ширины страницы. Особая точность не нужна, т.к. эти области все равно варьируются от страницы к странице.
Повторю, что это все имеет значение только для Draft kromsate. При обработке же эти ошметки никак не влияют, если они правильно отсечены резаком.
11. Не получается разделить страницу пополам и удалить чёрные полосы посередине, с правого бока и с верху. Как это сделать?
Загружаете файлы, выбираете вверху угол поворота, так чтобы развороты стали горизонтально. Не ставя никакие галки, нажимаете вверху кнопку Draft kromsate (или через главное меню), в появившемся окошке ставите галки на Split (если у вас развороты), Safe top/bottom и Don't use deshadow option. Нажимате OK и Кромсатор начнет сам расставлять резаки. По окончания процесса проверьте правильность расстановки. Если скан бледный или сама печать плохая, то лучше на закладке Options задать Despeckle method = Safe.
И как все файлы выделить галочками (т.е. как "marked") автоматически, а не самому клацать по отдельности на каждом файле?
Все галки проставляет Draft kromsate. Можете сделать это и сами. Под списком файлов имеется три больших кнопки (Apply ...). Станьте на последний файл в списке и нажмите Apply up to current. Только учтите, что при этом ко всем файлам будут применены одинаковые значения опций, включая и положения резаков (в отличие от Draft kromsate). Поэтому я бы порекомендовал все-таки сделать Draft kromsate для всех файлов, и видя, что верхний резак выставился неправильно, поставить его правильно, т.е. пониже в вашем случае, затем щёлкнуть правой кнопкой мыши на ползунке top-резака и в контекстном меню выбрать команду Copy current position to... В итоге положение резака откорректируется на всех помеченных галкой файлах.
12. Ваш Draft Kromsate тут слишком много отрезает... Не смог настроить - может, посмотрите, это хороший пример "сложной" ситуации...
Ситуация действительно непростая. Я сделал так:
1. Стал на 1-ю страницу.
В draft выставил: Kromsate = From current alternate; Cutting lines = Left, Top,
Bottom (т.е. справа не кромсаю - чтоб не резался
жиденький текст); Pre-cut margin = Left; 1/10 (этот параметр
позволяет избавиться от куска чётной страницы,
1/xx - это примерный размер куска в долях ширины
страницы, значение xx можно узнать с помощью
контекстного меню ползунка резака "metric".
Задавать значение xx точным необходимости нет - лучше недорезать, чем отрезать лишнее. Для данной книги я навскидку оценил среднеё xx=8, для перестраховки задал меньше - 1/10). Запустил.
2. Стал на 2-ю страницу. В draft выставил: Kromsate = From current alternate; Cutting lines = Right, Top, Bottom (т.е. слева не кромсаю, но в начале книги слева имеется полоса - см. далее); Pre-cut marging = Right; 1/10. Тут можно сразу бы выставить левый резак на 120 пикселей и в Draft дополнительно задать Pre-crop using = Left, а где этот Pre-crop? но обнаружился баг - pre-crop не взялся из-за того, что в Cutting lines не был задан Left.
Поэтому уже после окончания draft выставил левый резак на 120 пикселей от левого края, и в контекстном меню ползунка левого резака выбрал команду "Copy current position to -> alternate down". На весь draft у меня ушло в общей сложности 3 минуты.
13. Вот вы утверждаете, что Кромсатор точно определяет контур голого текста, я правильно понял?
Как я говорил, с точностью 4-8 pixels, в зависимости от разрешения. (Могу конечно, заложить и пиксельную точность, но как я уже раньше говорил, по всем законам статистики она будет _недостоверна_, поэтому бессмыслена). Плюс нечувствительность к небольшим выступающим частям букв. Вы можете теперь регулировать чувствительность с помощью бегунка на закладке Options 2.
14. По идее, после обрезки сканов Кромсатором, поля слева и справа должны быть ВИЗУАЛЬНО СОВЕРШЕННО ОДИНАКОВЫ. А вот у меня на контрольной книге так хорошо не получилось. В чём тут дело?
Тут возможны две причины.
Первая - вы задали горизонтальное выравнивание
текста по центру. Так как выравнивание в
Кромсаторе выполняется с точностью 8 бит, то для
b/w-сканов оно не идельно. В принципе, можно и
идеально выравнивать.
Вторая - ширину книги Кромсатор определяет
статистическим методом, при этом вполне
возможно, что получившаяся ширина не будет в
реальности равна ширине текста (а что это вообще
такое, если в книгах всегда имеются страницы с
более узкой и более широкой шириной содержимого)
+ 2*gap. В этом случае, если задано выравнивание по
левому краю, то поле справа будет везде больше
или везде меньше, чем поле слева, именно из-за
того, что выдерживание ширины книги, т.е.
страницы, является более приоритетным, чем
выдерживание правого поля. Почему правого?
Потому что, если вы листаете книгу, то не очень
приятно, когда начало столбика текста страницы
(т.е. левый край страницы) пляшет от страницы к
странице. Поэтому Кромсатор корректирует ширину
только за счёт правого поля, и только если его
приходиться слишком укорачивать (более 50%), то
"займет" кусочек от левого.
Если вам такой подход не нравится, вы можете
сделать так. Замерить типичную ширину текста
страницы, прибавить поля и задать ширину книги
как фиксированное значение. Т.е. не полагаться на
то, как кромсатор статистически вычислит ширину
и высоту.
Замерить можете и на самой книге с помощью
линейки в мм. Только не забудьте на закладке Book
задать единицу измерения в 10*мм.
Кстати, вы свои опыты проводите на всей книге или
только на её маленькой части? Ведь учтите, что
статистический расчет кромсатором ширины книги
будет очень неточным, если вы обрабатываете мало
страниц, да ещё с разной шириной текста на них.
Если это так, то проблема с сильно различными
полями теперь понятна, я описал выше почему.
15. Цитата:Draft Kromsate почти всегда съедает края текста я тоже так считаю - именно ПОЧТИ ВСЕГДА, увы.
Так уж и всегда! Я заметил только на номерах страниц, и то только из первого десятка. Вообще-то точность определения края зависит только от всего нескольких параметров-констант. Причем если их увеличить - начинается спотыкание на мусоре, если их уменьшить - появляются съедания. Я жестко заложил среднеё значение. В принципе можно вывести их в диалог для выбора пользователем.
Цитата: а пустые страницы выбрасываю.
Зачем? Чем они Вам мешают? Они не занимают места. Спросите у другого народа, все оставляют пустые страницы.
Цитата: Боковые поля же я убираю по той же причине, по которой вы их оставляете, т.к. предпочитаю чтобы текст заполнял весь экран (к тому же надо только изменить Zoom для того чтобы появились поля когда читают с экрана).
См. выше. Поля нужны везде и всем. Вот посмотрите на эту страницу, которую вы сейчас читаете. У неё тоже есть поля, и это сделано не зря, это помогает при чтении переводить вгляд на след. строку. Издатели давно этим занимались, и если бы поля были не нужны, они бы с удовольствием экономили бы на них бумагу.
Вспомните ещё тетрадки, на которых вы писали в школе, там была специальная линия для отступа слева. Конечно, поля свыше 100 pts тоже неприятны, особенно при чтении с экрана, но 70 pts, которые стоят в кромсаторе по умолчанию, это самое то.
Кромсатор сам умеет расставлять поля, только за это bolege памятник нужно поставить.
16. user1: А вот эта проблема - нераспознавание мелких деталей (номеров страниц и т.п.), отстоящих на расстоянии от основного текста - это очень серьёзная проблема, она практически сводит на нет смысл существования Кромсатора (в плане кромсания).
user2: И меня тоже напрягает эта проблема. ИМХО после интерфейса эта самая главная проблема кромсатора. Хотя её можно уменьшить с помощью text sensivity, но только при условии что скан чистый.
user3: Подгоняете нужный резак (снаружи внутрь) впритирку к краю текста, снимаете соответствующую галку в Automargins на закладке Pages и кромсаете проблемную страницу.
bolega: И меня, честно говоря, тоже напрягает эта
проблема. Но сами посудите, чтобы понять,
является ли какая-то закорючка, например, цифрой
"1" от номера страницы или это кусок крошки,
попавший на сканер, нужно выполнить очень
сложный анализ (например, ОСR или другой). При этом
время кромсания увеличится как минимум вдвое.
Если учесть, что количество таких страниц
составляет не больше 5%, готовы ли вы тратить кучу
времени на улучшение таких блох? Или лучше
потратить лишние 2 минуты, чтобы снять галки
automargins у таких страниц? Я выбрал в кромсаторе
второе. И не из-за прихоти, а из твердых убеждений
считаю, что так будет правильнее. Если же кто-то
требует от кромсатора 100% точности распознавания,
значит, этот человек ничего не понимает.
(Я вот думаю, а что пишут Яну в Abbyy, если FineReader не
распознает одно-два слова на странице. Неужели,
тоже бросаются отсоветовать всем пользоваться
им? :))
user2: Ну так, может, сделайте это, скажем, в 10
версии. И скорость компов подрастет. Тем более
для некоторых людей скорость работы не так
критична, как её качество. Я лучше комп на ночь
оставлю кромсать сканы, чем потом полчаса
мучаться с расстановкой резаков.
И к тому же кромсатор обычно ошибается на номерах
страниц, а они располагаются примерно на одном и
том же месте, поэтому пользователь может сам
задать область относительно границ текста где
нужно этот номер искать.
bolega: И насчет интерфейса: каков бы он ни был, но я не попугай, чтобы копировать чей-то чужой интерфейс.
2. Резаки
17. Как сделать, чтобы Кромсатор выдавал голый текст без полей на выходе?
Задайте параметры на вкладке Book:
H.Gap Value = 0, V.Gap Value = 0, Page width = Nonе и Page height = Nonе. по-моему, тут ошибка: ставить Page width = Nonе и Page height = Nonе не надо, достаточно выставить H.Gap Value = 0, V.Gap Value = 0.
18. Подскажите, как сделать так, чтобы вообще сканы не обрезались сверху-снизу?
Отключение резаков скопом не предусмотрено (чревато). Но выход есть - нужно вывести резаки за пределы картинки.
Итак, последовательность такая:
1) Ctrl + отщёлкиваем Pages -> Automargins -> T (Top).
2) Ctrl + отщёлкиваем Pages -> Automargins -> B (Bottom).
3) Ставим Book -> V.Gap value = 0.
4) Cтановимся на любой файл и ставим top-резак в координату y = 0 (или даже <0). В контекстном меню top-ползунка выбираем команду Copy current position to all marked.
5) Cтавим bottom-резак в координату y = конец картинки или даже лучше пониже её. В контекстном меню bottom-ползунка выбираем команду Copy current position to all marked.
В итоге на выходе высота всех файлов останется неизменной и равной высоте исходных изображений (разница может все-таки быть из-за компенсации Deskew).
19. У меня к вам парочка вопросов по поводу резаков. Есть ли какая-то комбинация клавиш, по которой можно включить тот или иной резак? Дело в том, что у меня после Draft kromsate Кромсатор довольно часто не ставит нижний резак, хотя он там нужен. Приходится каждый раз путешествовать мышкой через весь экран - сначала наверх, чтобы включить нижний резак, а потом вниз, чтобы его правильно установить. Можно ли первую часть операции повесить на какой-то шорткат?
Щёлкните правой кнопкой мыши на верхней панели на области, где выводятся координаты резаков, и в контекстном меню выберите Copy cutter's state to... Предполагается, что на текущем файле уже взведён bottom-резак. В появившемся окошке поставьте галку на Bottom, и выберите, на какие файлы копировать. В результате у всех выбранных файлах взведётся bottom-резак.
Дело в том, что недостающие резаки я ставлю, когда проверяю правильность Draft kromsate, - обычно двигаюсь снизу вверх и при необходимости включаю резак и устанавливаю его в нужное положение. И если сделать так, как вы советуете, то тоже получится двойная работа (сначала нужно отметить все файлы без нижнего резака, потом скопировать положение этого резака из одного файла на остальные, а потом ещё раз проверить все эти файлы - вдруг на каком-то из них резак залез на текст. Если бы все сканы были ровно отсканированы, то можно было бы не беспокоиться, но к сожалению это далеко не всегда так. Может быть есть какой-то ещё способ быстро включить этот резак?).
Нет. Скопируйте state на все файлы ниже текущего. Копироваться будет только признак вкл/выкл., без выставления позиции. Естественно, на тех файлах, где уже стоит резак, ничего делаться не будет, поэтому выделять ничего не надо.
20. А нельзя ли ввести в Кромсатор функцию "откусывания полей" с разных сторон? Вот жизненная ситуация: кто-то сделал книгу, а поля в ней, на мой вкус, широковаты. Приходится перекрамсывать, но делать это вручную.
Нет, формально это можно сделать и сейчас: поставить automargins. Уберите все галки с файлов и опций, включая automargins. Станьте на последний файл, выставьте нужные резаки, нажмите Apply up to current. Запустите обработку. В итоге все страницы будут обрезаны одинаково. Вот Вам и Crop.
Примечание: этого же можно достичь ещё и в Irfan View - добавить поля.
3. Чётное-нечётное
21. Хочу поделиться, как я теперь обрабатываю книги, где чётные и нечётные страницы сканируются отдельно.
Сканирую сначала чётные, потом нечётные, нумерация сплошная, т.е. если последний номер чётной страницы, к примеру, 200, то первая нечётная будет иметь порядковый номер 201.
Потом загружаю в кромсатор все скопом. Кромсаю как есть.
Т.к. теперь кромсатор автоматом может переименовывать выходные файлы при любых манипуляциях в исходном списке (удаление, добавление, перемещение, изменение признака Split), то теперь осталось только перемешать в правильном порядке чётные и нечётные страницы.
Становлюсь на первую нечётную страницу (пусть #201), выделяю её, становлюсь на последнюю нечётную страницу, т.е. в конец списка, нажимаю Shift + пробел.
В результате выделяется всё, что находится в диапазоне от последнего выделенного (т.е. 201) до текущего.
Теперь делаем Edit/Copy selected (при этом ничего не происходит, просто выделенные файлы запоминаются во внутреннем буфере), затем становимся на файл №1 и затем Edit/Paste interliev.
В итоге файлы перемешиваются как надо (interliev - через один).
Если до этого момента есть уже обработанные выходные файлы (все или частично), то кромсатор предложит переименовать их (что именно и как переименовывать, кромсатор позаботится сам).
Бывает, что из-за пропуска в сканах после перемешивания имеет место нарушение последовательности страниц. Ничего страшного. С помощью команды Edit/Move-shift selected можно корректировать положение файлов в списке как угодно (опять же с автоматич. переименовыванием вых.файлов).
Move перемещает все выделенные файлы (выделение может быть не обязательно сплошным, а, например, через один) в определённую позицию в списке файлов. Например, можно выделить все чётные страницы и переместить их в конец списка, где они расположатся уже последовательно, т.е. выполнить операцию, обратную перемешиванию.
При Shift же все выделенные файлы сдвигаются на заданное количество строк вверх или вниз, сохраняя при этом расстояние между друг другом.
22. Иногда необходимо загрузить в Кромсатор отдельно чётные и нечётные страницы. Если они лежат в одной папке, то выбирать каждый второй файл неудобно, а как это сделать быстро или как разделить на автомате в файловом менеджере чётные-нечётные страницы - не знаю. Можно ли сделать в окне выбора файлов возможность открывать каждый второй файл, начиная с выделеного?
Загрузите все файлы, затем выделите через один (Edit->Select group->Alternate down, при этом, если курсор на первом файле, то выделятся все нечётные, если на 2-м - то все чётные) и удалите их из задания (File->Delete files->All selected).
23. Как поворачивать чётные страницы?
2 способа:
1) Очевидный. Скопировать чётные страницы в отдельную папку, напустить на них Кромсатор и повернуть ВСЕ. Потом собрать все вместе обратно в одну папку и обрабатывать как будто ничего не было.
2) Стоим на крайней чётной странице, поворачиваем её, затем жмем Apply alternate -- он будет поворачивать только чётные. Потом встаем на крайнюю нечётную страницу, отменяем поворот, опять жмем Apply alternate -- опять галки проставляет. Прогоняем -- обрабатываем дальше. Вообще, я придерживаюсь идеологии многопроходного кромсания: сначала делаю простые массовые операции (поворот, сопряженный с перекодированием в CCIT G4 tif), а затем уж поля обрезаю и делаю Split. Так удобнее.
4. Despeckle
24. По поводу Despeckle.
Во-первых, в Кромсаторе заложен алгоритм (fine
despeckle), при котором он в процессе чистки
распознает буквы i и j (часто используемые в
индексах формул) и не позволяет "зачищать"
ихние точки. Для этого используется упрощённый
OCR, при помощи которого эти точечки распознаются
и despeckl-ом не трогаются (иначе нельзя, т.к. размеры
таких точечек чаще всего меньше предельно
допустимых). Главное, что мне удалось
совместить одновременное выполнение этих двух
операций (OCR и despeckle), и с очень высокой скоростью.
На это ушло 2 месяца мучений.
Во-вторых, имеется специальный safe-метод despeckle,
суть которого в следующем: сначала на странице
выделяются все символы, строится спец.хэш из их
контуров, и в процессе despeckle чистятся только те
точки, которые не принадлежат контурам букв.
Метод не идеальный, но буквы страдают гораздо
меньше.
Не идеальный, потому что чересчур сильно
разрозненные части букв могут и не слиться в один
контур. Здесь тоже есть над чем подумать. (Хотя
такие случаи я уже обрабатываю в draft, там ведь
тоже теперь проводится полный layout-анализ
страницы: выделение букв, строк текста,
иллюстраций и т.д., вероятностный анализ
буква-мусор и т.д.).
Главное в нашем деле, чтобы было из чего
выбирать. Имею ввиду ПО. Тогда и книг будет больше
сделано.
Всем удачи.
25. Если скан неважный (буквы с сильными разрывами), и despeckle заметно портит их, на закладке Options выберите режим despeckle = safe. В этом случае в процессе обработки области, занимаемые буквами, чиститься не будут. Как альтернатива, можно на закладке Pages нажать кнопку Special и там "смягчить" степень деспеклирования (fine-2, fine-3 и т.д.)
И ещё: НЕ Применяйте despeckle для сканов плохого качества, когда буквы рваные и бледные. Либо задайте для всех страниц despeckle=[fine-3].
Кстати: despeckle он и есть despeckle. По определению убирает изолированные точки заданного размера. И если линия превратилась в набор точек, то это уже не линия. Это на экране при уменьшенном масштабе и фильтре она глазом воспринимается как линия, а с точки зрения pixels это уже не так.
При despeckle при каком виде despeckle? удаляются ещё и ряд спеклов, больших чем заданный предел. При этом анализируется соотношение площади чёрных точек к площади спекла и его ориентация. Методика чисто эвристическая и подбиралась экспериментально.
Fine despeckle действительно чистит капитально (в пределах заданного допуска). Для бледных сканов лучше, конечно, не использовать.
26. Всё-таки мусор чистится на серых сканах, потом преобразование в B/W?
Нет, кромсатор чистит только b/w, т.е. сначала GREY->B/W, потом уже despeckle.
27. В первой строке листинга на картинке удаляется точка над буквой j. В других местах точки над i и j сохраняются. Это так должно быть? Или надо ещё что-то подкрутить для гарантированного сохранения этих точек?
Есть такая проблема.
Кромсатор плохо распознает шрифт Courier, в нем
буква j больше напоминает скобку ] из-за слишком
широкой верхней полочки. Я пока эту проблему не
решил, возможно, придется явно вводить опцию типа
"scan have courier fonts". Как правило, таким шрифтом
издатели любят набирать в программистских
книгах примеры кода. Автоматическая детекция в
принципе возможна, но здесь главное скорость,
если в процесс Despeckle вводить чересчур
продвинутый OCR, то Despeckle будет выполняться
слишком медленно, а это недопустимо.
Помогает только задание размера спеклов Default-2 в
пост-обработке (или стараться не включать такие
буквы в Clear-выделения) и [Fine-2] в опциях для
обработки (закладка Pages, кнопка Special).
4. Deskew
28. А вот с выравниванием у меня бывают проблемы, может всегда устанавливать Art?
Art влияет только на способ детектирования наклона. А вот как потом поворот осуществляется - зависит от параметра Deskew Method. В зависимости от него ступеньки и искажения могут проявляться или нет.
Вот что могу сказать по поводу deskew, точнее rotate.
1. B/W сканы.
При разрешении 600 и выше каким бы методом не
выполнялся поворот, артефакты практически не
заметны. При 400 и ниже артефакты имеют место,
причем чем меньше dpi, тем сильнее это бросается в
глаза. Уже при 300 dpi это становится неприятным. В
последней версии Кромсатора я ввел новый метод
rotate: shear с автоматической компенсацией
артефактов. Данный метод я и рекомендую
настоятельно. Метод, в отличие от antialias, без
побочных эффектов.
2. Grey/Color-сканы.
Для предотвращения артефактов (например,
"ступеньки" в строках текста) подойдет любой
метод, в котором предусмотрена интерполяция (в
Кромсаторе это interpolate или antialias). Даже
примитивнейшей линейной интерполяции хватает,
чтобы качество букв не страдало.
29. Кто-то говорил, что Кромсатор плохо определял перекос цветных сканов. Скажу честно, на цветных сканах я не сильно тестировал. Скажу только, что перед deskew их выполняется предобработка, т.е. сначала убирается фон, мусор, потом скан переводится в b/w и только потом делается определение угла deskew. Поскольку эта пред-обработка делается автоматически, то она сильно зависит от многих параметров (глубина убирания фона, размера мусора, яркости скана и т.д.). Видимо, после такой предобработки исходный скан сильно искажается (из-за неправильно выбранных Кромсатором параметров),что и приводит к неверному определению угла deskew. В общем есть над чем работать. Либо я советую для цветных сканов использовать Art-метод deskew.
30. Вопрос в следующем, при сканировании картинок (например, я сканировал карту из атласа) кромсатор не может выравнивать страницу? Галочки Art и Ortho выставлял.
И не сможет. И вряд ли какая программа сможет на полном автомате.
Есть быстрый метод - ручное указание на изображении области (например, прямоугольным выделением), где есть только текст, и тогда можно тоже быстро определить его наклон автоматом. а как конкретно это сделать?
Другой способ - в предобработке занести фиксированные углы через Ruler или есть ещё другой способ? в поля Fixed deskew angle (Pages->кнопка Special...).
5. Конвертация grey -> b/w
31. user: Преобразовывать серые сканы в чёрно-белые просто. Надо только подобрать подходящие опции на язычке 'Convert' в Кромсаторе, все остальные не касаются "grey -> b/w".
bolega: Здесь вы не совсем правы. Если grey-скан более-менее чистый и интенсивность фона заметно отличается от текста, то да. А если есть тени, да ещё близкие по цвету к тексту, то обычный Convert ничем не поможет: либо тень станет в итоге чёрной полосой (и текст не будет виден), либо наоборот, убирание тени уничтожит и текст.
Поэтому нужно убирать фон и, если текст плохо различим на нём, то ещё и задействовать спец.фичу по "вытягиванию" текста из фона. Всё это делается в "grey enhance" на закладке Quality.
32. Для серых на глаз довольно трудно определить реальный dpi. Лучше замерить точно. Это важно. Как уже не раз говорилось, простая конвертация в b/w по порогу для dpi<600 дает плохой результат. Другие методы конвертации опять же не подходят, т.к. скан с фоном, а эти самые методы его не чистят, и получается ужасная грязь. Надо обязательно одновременно с конвертацией поднимать в 2 раза dpi. Ну, и если фон неравномерный, то нужно его предварительно убирать.
Напомню, что в кромсаторе убирание фона оптимизировано для неравномерных фонов.
33. Нельзя ли в кромсатор ввести возможность сохранять результат ОДНОВРЕМЕННО в сером и чёрно-белом вариантах?
На закладке Pages есть кнопочка special..., в ней можно для отдельных файлов задать индивидуальный формат цвета (так же как и ряд других опций), отличный от всех остальных. Если же нужно именно из каждого файла получить два, но с разной цветностью, то можно в список исходных файлов внести нужные файлы два раза (дублирование не запрещается), и опять же в special для дублей задать формат grey или color.
6. Улучшение качества grey-сканов (убирание фона + вытягивание текста)
34. Возможность убирать фон с серых сканов:
На закладке Quality кнопка enhance.
Задать там Cleaner passes=1. Лучше убрать галку с Protect black
pixels.
Если на скане есть иллюстрации, залитые серым или
градиентным цветом, то их нужно заключить в
exclude-зону, чтобы не повредить. Если тень наползает
на текст и очень темна (текст на фоне её плохо
различим), то можно включить галку на Correct low contrast
и поиграться значением Sensitivity (5 - 30). Результат
можно наблюдать, если нажимать на закладке Quality
кнопку Preview или Preview with resample (в последнем случае
будет выполнено изменение dpi, если задано. В
первом же случае оно будет игнорироваться). Если
там же взвести Don't change out color, то при Preview не будет
проводиться и изменение цветности (т.е. grey->b/w не
будет). Это влияет только на Preview.
35. Бывают толстые книги, где тени, как ни прижимай книгу, всё равно будут. В этом случае, если сосканировать такие страницы в сером, Кромсатор очень хорошо может удалять их, не портя буквы.
36. Попробовал новую версию 5.6A, кое-что не получилось: выставил Quality -> Gray enhance... -> Background cleaner -> Cleaner passes = 1 для чистки серединки (выравнивания освещенности) и такое впечатление, что опция не включается. Может в новой версии нужно включать теперь что-то еще?
Да, там внизу нужно ставить галку на Enabled. Я это
сделал для унификации всех опций.
Там ещё добавилась одна новая опция Background cleaner ->
Ignore exclude zones. Раньше, если есть Exclude zone (красная), то
фон в ней не убирался. Теперь можно регулировать:
если зона нужна только для того, чтобы защитить
её от Despeckle, но при этом все равно чистить фон, то
нужно включить эту опцию.
37. Я тут вспомнил один случай. Принесли мне ксерокопию одного важного документа. Копия была ужасная, сплошная грязь от тонера, как будто лет 20 пролежала в угольной шахте. Задача была облагородить его, чтобы документом можно было потрясать в верхах. Все попытки вычистить его вручную попахивали месячной чисткой, а надо было за пол-часа. Тогда я отсканировал эту бумагу в сером, убрав в сканере опцию повышения контраста. Пропустил через cleaner passes=1 и, о чудо, вся грязь от тонера исчезла совсем! Буквы абсолютно при этом не пострадали. Поигрался ещё с контрастом и гистограммой, и получился вообще документ как из под принтера.
38. Нельзя ли так исхитриться при преобразовании 300dpi -> 600dpi, чтобы полутоновые изображения в полученном ч/б файле ВЫГЛЯДЕЛИ бы чуть получше?
Выделите нужную зону изображения мышкой (для обработки, в отличие от работы с исходным сканом, поддерживаются только прямоугольные выделения), в контекстном меню команду Exclude and mark as dither. Данная зона при обработке будет переводиться в b/w по специальному алгоритму, предназначенному для правильной передачи полутоновых или цветных изображений.
39. В действительности кромсатор сглаживает форму букв. Но для этого надо включить опцию Enhance.Smooth это где? и задать кол-во проходов (1-3). Кроме этого, всякие лохматости неплохо убираются despeckl-ом, но как я увидел на этих сканах, для этого нужен не один проход despeckle, как сейчас, а несколько. В существующей версии кромсатора этого не предусмотрено. В новой версии это есть, но уже в окне ViewResult. Как Вы правильно заметили, все эти операции носят статистический характер. А иначе как вы определите, не задействуя OCR, какие закорючки - хлам, а какие - часть букв или тем более иллюстраций. Поэтому ожидать даже после smooth идеальной формы букв не приходиться. Тем более, что многие буквы из упомянутых сканов - песочно-образные, состоят из разрозренных точек. Поэтому опция sand despeckle (которая хоть как-то соединит точки букв) здесь не помешает.
40. Как обработать низкокачественные сканы - 4-bit 100 dpi?
Такие сканы - это очень плохо. Хорошо хоть, что текст более-менее прочитывается. Обрабатывать их так:
1) Выходное dpi = x2.
2) Convert value = Average (!) это как сейчас
называется - Smooth?
3) При таком value мусор превращается в точки.
Поэтому его можно отсечь только thresholding-ом (это
где рисуется гистограмма) и despeckl-ом (новым). Нужно
задать только white-thresholding (примерно 210-220). Если же
картинка 4-bit, то это практически не поможет, т.е.
либо мусор всё равно останется, либо побледнеют
буквы.
4) При таком value буквы толстеют. Для 100 dpi это
нормально и ничего делать не надо, т.к. идёт
только на пользу. Для больших dpi это лечится
заданием Sharpen (1 или 2 прохода). Если что-то не
работает, как я описал, возможно это глюки старой
версии кромсатора.
41. Как правильно обрабатывать полутоновые рисунки-фотографии:
Выделить в исходной картинке нужную область, дать команду Convert to b/w (при этом порог конвертации берется из текущего значения Convert to b/w threshold на закладке Convert). При этом формат файла не изменяется, просто заданный кусок преобразуется в b/w и возвращается на место, т.е. снова становится как бы grey. Что это и зачем это?
Аналогично работает и Convert to bitonal (т.е. dithering): страницы с худ.картинками сканируем в grey, преобразуем иллюстрации (т.е. отдельные фрагменты страницы) в bitonal, нажимаем Preview (при этом т.к. выходной формат задан b/w, получаем исходный файл уже как b/w), сохраняем его и в итоге на входе кромсатор уже имеет b/w-файл, но с иллюстрациями, почти не попорченными прямым конвертированием в b/w. Не понятно ничего...
Я бы в таких случаях порекомендовал картинки переводить в псевдо-b/w. Для этого прямо в окне с исходным сканом выделяем картинку и в меню выбираем команду convert to bitonal (надо ещё чтобы use error dithering был включен, там же, в меню).
При этом к выделенной области применяется dithering и она становится как-бы b/w. "Как-бы", потому что сам файл-то остается серым, а вот в области картинки остаются только два чистых цвета - белый и чёрный.
После этого сохраняем файл (т.е. меняем исходник).
После этого можно кромсать.
Одно замечание - юзать dithering конечно лучше когда скан стал уже 300 dpi, а не 150. Но с этим будет морока, если вы плохо ориентируетесь в кромсаторе. Т.к. для этого нужно нажать Preview, включив предварительно don't change out color.
В итоге в окне у вас уже будет картинка на 300dpi, потом dithering и сохранить.
НО: т.к. для всех задано увеличивать разрешение вдвое, а данный файл уже стал на 300dpi, то нужно для него в special... задать DPI=original.
42. Впервые столкнулся с задачей сканирования книги, в которой используется дополнительный (синий, например) цвет для части текста и рисунков. Как решить проблему: сохранить цвет при минимуме размера дежавю? Мухлевал в Irfan View с количеством цветов и с палитрой. На выходе вроде ничего получается. Перегоняю в дежавю, фон вместо белого светло-фиолетовый - плохо смотрится, и размер на страницу ~25к, слишком большой. Что посоветуете?
Во-первых, переведите файл в 256 цветов - ничего
не потеряете.
Потом в кромсаторе есть одна фича - удаление (или
усреднение монотонным цветом).
Сейчас у вас фон не чисто белый.
В окне Result view выделите на фоне прямоугольник
(чтобы в него не попал текст, а только фон). Затем в
контекстном меню команду Draw->set clear color.
Кромсатор подсчитает средний цвет в заданной
области.
После этого выделите всю страницу (желательно,
чтоб рисунки только не попадали, синий текст -
можно). И нажмите delete. Кромсатор заменит в
выделении все пиксели, имеющие
цвет=подсчитанному ранее среднему плюс/минус 50 (50
- можно изменить в меню clear options) на белый (по
умолчанию). Подсчитанный средний цвет кромсатор
запоминает, так что и на других страницах можно
просто выделять и delete. В итоге у вас фон станет
чисто белый, при этом все остальное не изменится.
Кстати, чистить можно не только белым, но и
заменять на средний подсчитанный. Я так
выравниваю цвет на обложках, после чего они
ужимаются на порядок лучше, т.к. исчезает цветной
шум. Для замены на средний нужно в меню выбрать
CleanColor =>Magic.
Я сам попробовал эту операцию, и у меня размер После_Ирфана_и_Кромсатора размер tif'а упал с 3,451,894 до 854,038.
43. По случаю хочу уточнить работу функции Clear shadow. Она чистит фон в тени сгиба, это понятно. А как с яркостью текста в тени, она её корректирует? Хотелось бы, чтобы корректировала. Поскольку в противном случае происходит ужирнение текста, что нежелательно как для восприятия, так и для качества последущего кодирования в дежавю. И вообще, как лучше поступать, чтобы лучшим образом убрать тень (на выходе серые сканы)? Тень хорошо удаляется на светлых и темных сканах, если я включу Enhance image и укажу чистку фона. При этом понижается яркость всего скана.
Clear shadow - это только для b/w сканов и в основном для теней, сливающихся с текстом! Там специальный алгоритм, который пытается удалить тень на ч/б сканах. Часто это не очень хорошо получается, но это и понятно, в b/w сканах определить, где буквы, а где рваные куски тени, алгоритмически практически невозможно.
Удаление тени для grey-сканов делается через Convert -> Gray enhance... -> Background cleaner. Яркость там не корректируется. Только убирается фон.
Я думаю, здесь дело не в яркости, а в общем
падении контраста в области сгиба, когда буквы
слегка расплываются (из-за тени, и возможно, из-за
геометрических искажений на сгибе) и поэтому
ужирняются при переводе в b/w. Здесь уже ничего не
поделаешь. Вы же спрашиваете о случае, когда
имеется дальнейший перевод в b/w?
Если же имеете ввиду grey-случай, то действительно,
буквы в тени должны получаться темнее. Над этим
надо подумать. Кстати, BookRestorer уменьшает их
яркость при выравнивании освещенности?
Совсем забыл.
Там есть опция Protect black (по умолчанию включена).
Она как раз контролирует, будет ли понижаться
яркость темных букв. Снимите галку и посмотрите,
может поможет. Без этой галки тень вообще
убирается лучше, особенно темная. Эта опция
пришла из старых версий кромсатора, когда не было
exclude-зон, и удаление тени могло вредить
иллюстрациям.
44. bolega: Вот ввёл contrast-zone. Сканировал недавно книгу в grey, в которой все номера страниц были голубым цветом. При переводе в b/w они практически все исчезли. Повышать порог нельзя - сильно ужирнялся текст. В итоге я расставил зоны, и нумерация вся сохранилась в лучшем виде. Можно конечно это делать в диалоговом ручном режиме, но у него есть один недостаток - если нужно перекромсать страницу, то операцию придётся делать повторно. А так ни о чем не заботишься.
Подскажите, как этим пользоваться (т.е. contrast-zone), как установить порог?
Значение контраста (не порога) берется из закладки Contrast. Причем на этой закладке должна быть отключена галка Enabled, иначе изменение контраста будет применяться ко всей странице сразу, а не к зонам (это и понятно: если мы меняем общий контраст, то смысла менять в отдельной зоне практически нет).
45. В какой момент обработки лучше расставлять зоны? Как сделать это быстро?
Зоны я расставляю в самую последнюю очередь, после того, как расставлю все другие опции. Затем включаю режим Mouse-Up mode = (exclude,contrast,...) и иду по всем файлам. Выделяю зону мышкой и в момент отпускания её клавиши создается зона (не нужно вызывать меню). Если нужно выделять на каждой странице, в одном и том же месте, то я делаю одно выделение (при отключенном mouse-up), нажимаю Ctrl + Insert (форма выделения запоминается в карман), включаю Mouse-Up mode, затем на каждой странице нажимаю Shift + Insert (выделение вставляется из кармана), делаю одинарный щелчок на зоне и иду на следующую страницу, и т.д. Всё выходит очень быстро.
46. Dithering-иллюстрации - это когда мы серые фотографии аккуратно преобразуем в битовый ч.б. через Irfan View?
Да, так. Но и иногда они и в книгах уже такие.
Бывают, что и обычные иллюстрации содержат
местами мелкие облачки точек. Например, пляж, а на
нем песочек. Тоже ж надо защитить. :)
7. Разное
47. Если вы отсканировали и обложку, то её, как правило, не стоит делать такого же размера, как все остальные страницы (у неё и размер обычно больше, и dpi другое). Поэтому для неё нужно до обработки сразу же задать на закладке Pages, кнопка special, параметр ignore gaps - взвести галку. В итоге её размеры будут целиком определяться только резаками. Там же можно задать для неё не менять цвет (или лучше color256 если скан обложки цветной) и не менять dpi.
48. Из нового одной из последних версий: на выходе теперь можно получать файлы с разными dpi и color. Это как делается? Кое-какие параметры также можно задавать индивидуальными для разных страниц (например, Dpi,despeckle,ручное задание угла deskew, и т.д.) - это делается на Pages -> special... (Exclusive page options).
49. Как объединить автоматом в сдвоенный разворот уже разрезанные страницы? Саму книгу делал какое-то время назад, проект не сохранил.
Загрузите все файлы.
Нажмите правой кнопкой мыши в свободной области
на закладке Pages.
В контекстном меню выберите Clear all options & mark all.
В результате все файлы пометятся и сбросятся все
опции кромсания.
Взведите опцию merge pages after split.
Т.е. тем самым дали задание ничего не кромсать, а
просто объединить.
Запустите кромсание (Process!).
Здесь не важно, являются ли исходные файлы
разворотами или нет. Половинки для новых
merge-листов набираются кромсатором по мере
движения по списку файлов. Т.е. в исходном списке
допускается смесь одиночных страниц и
разворотов.
Для merge-режима ещё важно, чтобы все файлы были
одного dpi (точнее все пары файлов, которые попадут
на один итоговый лист; dpi же между этими парами
могут и отличаться). Если это не так, то для тех
файлов, где dpi отличается, нужно задать то
значение, которое имеют все оставшиеся файлы. Это
делается на закладке Pages, кнопка Special, где можно
задать индивидуальное dpi для любого файла,
отличное от общего выходного dpi, которое задано
на закладке Files.
Если хотите на выходе pdf-файл, можно ещё проще -
merge можно не задавать, а просто на закладке pdf
выбрать Page layout = two images per page.
Здесь уже допускается, чтобы dpi у разных файлов
было разным.
50. Скажу, как быстро подготовить задание для pdf.
Обычно я сначала кромсаю в тифы, потом делаю отдельное задание для pdf, причем так: находясь в 1-м задании, после его завершения, щелкаю правой кнопкой мыши на кнопке открытия файлов и выбираю команду "Open task output dir", выделяю все файлы, загружаю их. Сразу же щелкаю правой кнопкой мышки на любом свободном месте странички "Pages" и выбираю команду "Clear all options & mark all". В результате все файлы сами пометятся и сбросятся все опции. Осталось только задать output format = pdf, имя файла и вперед.
51. Выделение участка скана может быть не только прямоугольным. В одной из версий также была введена возможность использовать выделение произвольной формы.
Помню, когда я обрабатывал Eberly из полностью серых сканов, там почти на каждой странице был нарисован CD-диск (в изометрии). При прямой конвертации в b/w он превращался в чёрноту. Поэтому я на каждой странице выделял эллипс и конвертил dithering-ом. После третьего десятка вырисовывания эллиптического выделения меня уже трясло.
Поэтому я сделал в кромсаторе так: по Ctrl-Insert запоминалась форма текущего выделения, по Shift-Insert она снова восстанавливалась. Поскольку CD-эллипсы были одинаковы на всех страницах, дело пошло очень быстро (их было несколько сотен в общей сложности).
52. Наблюдается один глюк: на некоторых файлах после обработки текст уменьшился в 4 раза и занимает только четверть листа, все остальное - белый фон. У меня и раньше такое бывало. Что это и как с этим бороться?
Нет, это не глюк. Это значит, что у вас в задании
смесь файлов с разными dpi.
Поскольку на выходе по умолчанию Кромсатор
приводит все файлы к единому размеру в пикселях,
то, естественно, что файлы с меньшим dpi
увеличиваются в размере.
Выход - на закладке Book выбрать единицу измерения -
10*мм и поля задать в соответствии с этим, т.е. в
долях мм. Тогда будет всё нормально.
Да, так и оказалось. Помню, Вы как-то советовали размеры полей в пикселах для разных дпи. А какие размеры в долях мм стоит выставлять для 300 и 600 дпи?
В мм поля будут одинаковыми для любого dpi, поэтому это и работает для смеси dpi. На Ваш вкус, поставьте например 1 cм, т.е. 100 в долях мм.
53. При вставке изображения из буфера в окне Result view вставляемый фрагмент прыгает на 1-2 пикселя вверх при вставке. Нельзя ли увеличить точность вставки?
Уберите фильтр (контекстное меню окна Result view ->
Options... -> Linear Zoom Filter замените на No Zoom Filter). И будет
вам точность. То, что вы видите на экране -
облагороженное фильтром изображение,
обработанное фильтром с окном 1-3 пикселя.
Кроме того, погоня за пиксельной точностью
абсолютна бессмысленна на мониторах с размерами
640 - 1200 пикселей. Сами посчитайте, сколько точек
изображения помещается в одну точку на экране. И
тогда поймёте, что указывая какую-либо точку на
экране, вы на самом деле тыкаете в интервал от 1 до
10 пикселей, соответствующий реальному
изображению.
Здесь собрана вся имеющаяся информация по одной теме:
"Улучшение качества серых сканов на вкладке Quality".
Эта тема пока что остаётся единственной совершенно не изученной и совершенно не понятой мною темой относительно работы Кромсатора. Другими словами, содержимым части 2 пользоваться пока едва ли возможно, т.к. ничего не понятно. Поэтому эти материалы тут практически никак ещё не упорядочены - это дело будущего.
54. Как вытягивать текст, плохо различимый на фоне?
В Quality включить Enhance image.
Нажать Gray enhance.
На закладке Background cleaner подбирать параметры. cleaner
passes=1, correct low contrast=On.
Потом играться значением sensitivity (от 10 до 30 c шагом
5). Не сохраняя (применяя) опции, можно сразу же
нажимать Preview (или Preview with resample если увеливается
dpi) и смотреть результат. Если текст сливается с
фоном, и при этом сам скан бледноват, то
дополнительно увеличить слегка контраст (там же,
на закладке Contrast), единиц этак 8-15, не больше.
Для примера, для файла 18 книги Дынкина (стр.34-35) я
подобрал так: контраст=+9, sensitivity=25, для файла 17
контраст=+18, sensitivity=10, для файла 16 контраст=+9,
sensitivity=35. Как видите все индивидуально. Но все
просто просто.
Если текст бледноват, ставлю контраст примерно
15-20. Потом подбираю sensitivity.
Если текст виден хорошо, то ставлю контраст 9-10,
подбираю sensitivity. На самом деле тут есть
взаимосвязь, и с опытом начинаешь быстро на глаз
определять, что ставить.
55. Как убрать фон с серых сканов?
Для начала нужно поставить галку на "enhance image". В противном случае все enhance-настройки при обработке будут игнорироваться (но будут срабатывать при preview). Потом нажать кнопку "gray enhance". Или hotkey = "B". Все основные фичи будут на закладке "background cleaner".
Чтобы убрать фон, достаточно задать Cleaner passes = 1. Если текст сильно сливается с фоном (т.е. очень малый контраст между текстом и фоном) (редко, но бывает), то он может пострадать при этом. В этом случае ставится галка на correct low contrast и методом подбора подбирается чувствительность распознавания текста на фоне (sensitivity).
Обычно я начинаю с 20-25 и уменьшаю последовательно на 5. Это значение по сути задает в % имеющийся контраст между фоном и текстом. Когда кромсатор убирает фон, он проверяет (для каждой точки найденного фона), имеется ли в нем текст, такой, что его контраст по отношению к фону >= заданного порога (sensitivity). Если имеется, то цвет этой точки не меняется (если не стоит галка на опции increase black) либо вообще заменяется на чисто чёрный (если на increase black галка стоит). Таким образом и фон убирается, и текст остается.
Замечу, что данная процедура плохо работает для очень светлых сканов, т.к. сильно начинает вылазить всякий мусор, т.к. его цвет сравним как с цветом фона, так и с цветом текста. Значение sensitivity можно задавать различным для левой и правой половинок разворота. Только нужно, чтобы были уже выставлены внутренние резаки (int1 или int1+int2). Preview по ним будет судить о том, где левая половина разворота, а где - правая.
56. Возможность убирать фон с серых сканов:
На закладке Quality кнопка enhance. Задать там Cleaner
passes=1.
Лучше убрать галку с Protect black pixels.
Если на скане есть иллюстрации, залитые серым или
градиентным цветом, то их нужно заключить в
exclude-зону, чтобы не повредить.
Если тень наползает на текст и очень темна (текст
на фоне её плохо различим), то можно включить
галку на Correct low contrast и поиграться значением
Sensitivity (5 - 30).
Результат можно наблюдать если нажимать на
закладке Quality кнопку Preview или Preview with resample (в
последнем случае будет выполнено изменение dpi,
если задано. В первом же случае оно будет
игнорироваться).
Если там же взвести Don't change out color, то при preview не
будет проводиться и изменение цветности (т.е.
grey->bw не будет). Это влияет только на preview.
А насчёт тени - там все просто, достаточно включить Clearner passes = 1 (ну и не забыть на закладке quality включить enhance image, иначе все опции будут просто проигнорированы). Если на странице нет монотонных рисунков-областей, то можно убрать галку с protect black pixels, тогда зачистится получше. Остальные опции (correct low contrast и ниже) нужны, если тень очень темная и буквы еле видны на её фоне.
Подбором sensitivity (от 5 до 30) можно добиться убирания фона и "спасения" сливающихся с ним букв. Чем больше в скане контраст между фоном и буквами, тем больше можно задавать sensitivity. Если sensitivity стал>30 и при этом ещё заметно некоторое улучшение, то это говорит о том, что то же самое можно сделать и увеличением значения convert threshold, например, с normal до lowdark. Опции ignore light pixels и increase black лучше никогда не трогать.
А как с яркостью текста в тени? Там есть опция Protect black (по умолчанию включена). Она как раз контролирует, будет ли понижаться яркость темных букв. Снимите галку и посмотрите, может поможет. Без этой галки тень вообще убирается лучше, особенно темная. Эта опция пришла из старых версий кромсатора, когда не было exclude-зон, и удаление тени могло вредить иллюстрациям.
В окошке Gray enhance есть неприметная опция Protect black pixels. По умолчанию она включена. её нужно отключать! Тогда убирание теней будет намного лучше (эта опция устарела и пришла из старых версий кромсатора).
57. Как выполнять подбор параметров при улучшении серых сканов?
Поставить галку на "don't change out color" (это повлияет только на preview, но не на обработку), чтобы не тратить время на конвертацию gray->bw. Либо не ставить, чтобы увидеть уже конечный результат. Нажать на preview или на preview with resample. В первом случае при preview не будет увеличиваться dpi (если это конечно задано), во втором - dpi увеличится как задано на закладке Files. Потом Undo и снова подбираем.
В последней версии глубину Undo я сделал практически неограниченной. Чтобы перенести подобранные опции на все (или на группу) файлов нужно в контекстном меню закладки background cleaner выбрать соответствующую команду. Если же нужно перенести вообще все опции enhance, то нужно снять галку с "enhance image" и держа нажатым Alt, снова её взвести.
И еще: при работе с preview лучше отключать режим автопринятия опций, т.к. при смене dpi кромсатор положения резаков не корректирует.
Еще пара замечаний. Там есть опция protect black pixels. Это когда имеются однотонные иллюстрации, например чёрные квадраты и т.д. Такие области кромсатор будет трактовать как фон, и вычистит их. Чтобы этого не произошло, ставится защитный порог цвета, выше которого цвет не считается за фон. К сожалению, значение порога жестко зашито в программу, со временем я дам пользователю и его задавать. Пока только просто галка.
В новой версии будет ещё один способ защиты - через exclude-зоны. Сейчас такие зоны есть, но они защищают только от despeckle, который может определённым иллюстрациям нанести ущерб.
Второе замечание: если gray-сканы имеют разрешение <300 dpi, то обязательно нужно увеличивать выходное dpi вдвое, иначе при конвертации в bw качество сильно пострадает. А так за счет учетверения каждого пикселя появится возможность хоть как-то интерполировать переходы gray-оттенков.
Еще в новую версию добавил управление контрастом и,главное, вытягивание слабого контраста (для gray), при котором буквы практически сливаются с фоном. Небольшие эксперименты во время отладки показали неплохие результаты по вытягиванию текста из фона при разнице в их цвете всего лишь в 3-4%. Вот это я сделал независимым для левой и правой половинок разворота.
Еще влияет convert threshold, если он высокий, то контраст можно делать поменьше, и наоборот.
58. Какие параметры используются при улучшении сканов и каковы их значения?
Кол-во проходов клинера как правило хватает одного. В редких случаях повторные проходы слегка улучшали. Это можно легко проверить: выставить выходной формат как original (чтобы не конвертилось в b/w), либо в последней версии можно просто поставить галку на "don't change out color" (это повлияет только на preview - и не надо переключать тогда все время Out color), задать cleaner passes = 1, нажать preview. Картинка очистится, но останется Gray. Снова нажать preview - т.е. сделать ещё один проход для _текущей_ видимой картинки (preview выполняется не для оригинала, а для отображаемого в данный момент). Если визуально видно, что ничего не поменялось, значит проход уже излишен. Если же одновременно задано изменение контраста, то подряд нажимать preview будет уже не корректным - получится такая последовательность: clean,contrast + clean,contrast вместо clean,clean,contrast (именно так будет при настоящей обработке). Поэтому после каждого preview нужно делать Undo и увеличивать clean passes.
Correct low contrast используется тогда, когда интенсивность текста и фона почти равны (буквы еле различимы на фоне тени). если оставить только клинер, то он вместе с фоном почистит и текст. Изменение контрастом тоже не особо выручит - тень тоже на столько же потемнеет. Если же включен CLC, то при удалении фона кромсатор будет анализировать цвет фона и цвет малой окрестности точки. Если их разница будет больше Sensitivity (=5..25), то он эту точку чистить не будет (при отключенном increase black) либо даже сделает полностью чёрной (при включенном increase black - по умолчанию), а окрестность почистит. Мусор немножко конечно останется, но буквы уже можно будет свободно читать. Здесь все будет зависеть от подбора значения Sensitivity.
Есть ещё опция protect black pixels. Она нужна вот когда: клинер может начисто зачистить чёрные области, которые таковыми и являются на самом деле (побочный эффект). При включенной же опции он не будет чистить очень темные точки.
Есть ещё опция ignore light pixels. Когда CLC не дает клинеру чистить текст, то из-за того, что Sensitivity является относительным значением, то "спасаться" будут все пиксели, чьи соседи имеют с ними разницу в цвете равной Sensitivity. В итоге почернеют не только буквы, но и сам фон. Поэтому ignore light pixels гарантирует, что вытягивание контраста будет применяться только к тексту, а не к неравномерностям фона. Но я оставил возможность отключать эту фичу. Вот из-за чего: у меня был чистый скан, но часть текста была отпечатана не чёрным, а синим и желтым цветом. такой текст в скане стал очень бледным. Простое повышение контраста для всей картинки спасало, но сильно ужирняло нормальный чёрный текст. Поэтому я использовал здесь CLC, который действует избирательно. В итоге простой текст не менялся, а бледный улучшался. Хотя контраст улучшал все-таки лучше. (В новой версии я сделаю улучшение контраста в выделении по типу autoclear).
59. Можно ли в выходных файлах сделать выделение, применить к нему Enhance..gray (конкретно - гистограмму) и применить это (в фиксированных координатах выделения) к группе файлов, +смещать при необходимости область выделения с заданными параметрами Enhance?
Сразу скажу, что операции, связанные с улучшением (или ухудшением ) _отдельных_ участков изображения, мною не планировались ввиду того, что это больше подходит графическим редакторам (и по интерфейсу и по возможностям, любой существующий граф. редактор сделает это в сто раз лучше чем кромсатор). Поддержка таких фич потребует значительного изменения интерфейса и очень много времени. Однако кое-что в кромсаторе со временем появлялось, но с убогим интерфейсом и делалось исключительно для себя.
Поэтому я считал и считаю, что кромсатор - это пакетный обработчик, и подобные selection-ориентированные фичи ни к чему хорошему не приведут. Скрестить selection и много файлов - думаю, малоперспективна, т.к. на каждом файле местоположение областей будет всегда различным (ни разу ещё не видел таких сканов, чтобы страница была постоянной). По существу же - enhance gray можно применять только ко входным файлам. Можно и к выделению, но только для текущего файла.
Насчёт смещения - вы имеете ввиду плавное изменение параметров для какого-то участка изображения, или изменение от файла к файлу? В любом случае нужно будет делать для этого специальные диалоги и т.д., вообщем опять уйдем в сторону граф.редакторов. Форму выделения можно запомнить в карман (Ctrl-Insert), потом восстановить - на этом же, или на другом файле (Shift-Insert).
60. Пока не совсем хорошо понимаю, на что влияет параметр Sensitivity в Quality -> Gray enhance... -> Background cleaner.
Correct low contrast следует использовать если при
убирании фона очень сильно бледнеют буквы, из-за
того, что они практически сливаются с фоном.
Обычно это происходит в районе разворота, когда
тень там настолько сильна, что буквы плохо или
еле различимы на фоне. В этом случае (и только в
этом) и нужно включать Correct low contrast, а Sensitivity
контролирует чувствительность детекции букв на
фоне. Чем меньше значение Sensitivity, тем более
малоразличимые буквы смогут быть отделены от
фона и поэтому не будут удалены вместе с ним.
Возможные значения: от 5 (буквы не видны на фоне)
до 25-30 (контраст буква-фон нормальный)
Не стоит использовать Correct low contrast просто для
поднятия контраста, для этого есть отдельная
команда, и там это делается намного лучше. Т.е.
если Вы видите, что Sensitivity=30 ещё что-то улучшает,
то это означает, что его лучше на самом деле не
использовать, и применять обычную опцию
контраста.
Да, именно Correct low contrast, похоже, позволил мне "вытащить" из серого наиболее мелкие детали.Но задание параметра Sensitivity от 0 до 100 не влечет за собой никаких видимых изменений...
Все правильно, его влияние проявляется только в
том случае, который я описал. Т.е. если контраст
буква-фон нормальный (как у вас), то он ничего
делать не будет.
Если хотите все-таки увидеть, включите опцию increase
black. Тогда увидите.
Q:
Что обозначает галка "Use average width" на вкладке Book?Автор: monday2000.
10 апреля 2006 г.
E-Mail (monday2000 [at] yandex.ru)