ScanKromsator СканКромсатор - [7] :: Программы :: Компьютерный форум Ru.Board

SOV32
Если сканы из-под фотика, то наверняка буквы имеют мелкозернистую или очень неравномерную структуру (по цвету), в том числе и после поднятия контраста в CS.
Тогда лучше использовать Art deskew. Возможно, ошибка исчезнет. Но я еще посмотрю, нет ли глюка какого.
Если у Вас в файлах прописано 180dpi, то крайне нежелательно ставить выходное dpi фиксированным (напр. 300dpi), так как получается не-кратное 2 масштабирование. Лучше поставить вых.dpi=twice greater.

Цитата:

- бывает и такое, что кромсатор как бы "зависает" постоянно работая с винчестером и при этом процессор загружен всего на 20...30%, а не не 100% как всегда.

Кромсатор для плохих сканов часто делает откат при своей работе (промежуточные данные он сохраняет на диске), отсюда наверное и усиленная работа с винтом. Замирание бывает и при изменении dpi.

Цитата:

Возможно нюанс в том, что работаю с кромсатором на ноутбуке (IBM PII-300, чипсет intel, WinXP SP1 engl)

PII-300 слабоват конечно для таких дел.

monday2000

Цитата:

Я ещё раз хочу обратить Ваше внимание на мой пост про "паразитную полосу".

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

Цитата:

Помнится, Вы писали, что испытываете затруднения с обработкой в Кромсаторе сканов вот с этой полосой сбоку

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

Добавлено:
monday2000

Цитата:

Если бы Кромсатор выдавал голый текст без полей на выходе

Задайте оба гапы=0 и page height/width = nonе

Цитата:

Вот Вы утверждаете, что Кромсатор точно определяет контур голого текста, я правильно понял?

Как я говорил, с точностью 4-8 pixels, в зависимости от разрешения. (Могу конечно, заложить и пиксельную точность, но как я уже раньше говорил, по всем законам статистики она будет _недостоверна_, поэтому бессмыслена). Плюс нечувствительность к небольшим выступающим частям букв. Вы можете теперь регулировать чувствительность с помощью бегунка на закладке Options2.

Цитата:

Да вот у меня тогда на контрольной книге так хорошо не получилось.

Тут возможны две причины.
Первая - Вы задали гориз. выравнивание текста по центру. Так как выравнивание в кромсаторе выполняется с точностью 8 бит, то для b/w-сканов оно не идельно. В принципе можно и идеально выравнивать.
Вторая - ширину книги кромсатор определяет статистическим методом, при этом вполне возможно, что получившаяся ширина не будет в реальности равна ширине текста (а что это вообще такое, если в книгах всегда имеются страницы с более узкой и более широкой шириной содержимого) + 2*gap. В этом случае, если задано выравнивание по левому краю, то поле справа будет везде больше или везде меньше, чем поле слева, именно из-за того, что выдерживание ширины книги, т.е. страницы, является более приоритетным, чем выдерживание правого поля. Почему правого? Потому что если вы листаете книгу, то не очень приятно, когда начало столбика текста страницы (т.е. левый край страницы) пляшет от страницы к странице. Поэтому кромсатор корректирует ширину только за счет правого поля, и только если его приходиться слишком укорачивать (более 50%), то "займет" кусочек от левого.
Если Вам такой подход не нравится, Вы можете сделать так. Замерить типичную ширину текста страницы, прибавить поля и задать ширину книги как фиксированное значение. Т.е. не полагаться на то, как кромсатор статистически вычислит ширину и высоту.

Добавлено:
Замерить можете и на самой книге с помощью линейки в мм. Только не забудьте на закладке Book задать единицу измерения в 10*мм.

Добавлено:
Кстати, Вы свои опыты проводите на всей книге или только на ее маленькой части? Ведь учтите, что статистический расчет кромсатором ширины книги будет очень неточным, если Вы обрабатываете мало страниц, да еще с разной шириной текста на них. Если это так, то проблема с сильно различными полями теперь понятна, я описал выше почему.

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

То есть сам алгоритм не безнадёжен.

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

Я бы так выразился: если скрестить Adobe Photoshop с алгоритмикой Кромсатора - то был бы толк. То есть, конечно, полностью автоматической обрезки всё равно не получится. Я думаю, что в лучшем случае можно добиться полуручной, полуавтоматической обрезки - это если очень и очень усовершенстовать интерфейс Кромсатора и прочие детали реализации. Но даже это, конечно, имело бы смысл - внести какую-то долю автоматизированности в ручную обрезку.

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

С включённым фильтром - отчаянно тормозит.

Конечно, совершенно необходимо в редакторе постобработки сделать, чтобы стрелки клавиатуры двигали скан по 1 (да, 8 много) пикселю при нажатии. Надо подвинуть, скажем, на 4 пикселя - нажимаем левую стрелку и держим, а скан пусть себе ползёт влево попиксельно. bolega Это сделать АБСОЛЮТНО необходимо и именно вот так. И нельзя другим кнопкам это назначить - только стрелкам.

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

И по интерфейсу: можно объединить многочисленные вкладки "Book", "Pages", "Options" и т.д. объединить в одну-две вкладки - чтобы не надо было циркаться и переключаться по куче вкладок.

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

Пока же ручная обрезка хороша вот чем:

1. Исключительная простота.

2. Высокая точность.

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

Недостатки:

1. Долго обрабатывать.

2. Приходится нажимать кучу лишних кнопок.

Но всё же пока, с учётом недостатков реализации Кромсатора, я всё-таки всё равно выбираю ручную обрезку. Посмотрим, как изменится Кромсатор в будущем.

Добавлено:
Вот ещё обнаружил недостатки в deskew Кромсатора. См. пример:

webfile.ru/556774 (380 КБ)

Там несколько файлов отдескьюированных в Файнридере и в Кромсаторе. Хорошо видно, что для этих конкретных примеров файнридерный deskew гораздо лучше кромсаторного (auto(shear)).

Может быть, надо было выбрать другой режим deskew в Кромсаторе, не auto(shear)? Но пользователь не обязан в общем случае быть способным правильно выбрать режим deskew - в файнридере вот не надо об этом заботиться, и это правильно. То есть, хорошо, что в Кромсаторе можно выбрать вид deskew, но плохо, если от правильности этого выбора зависит ошибочность/неошибочность результата.

То есть файнридер таких косяков никогда не выдаёт при deskew - как в этом конкретном примере выдал Кромсатор.

Таким образом, иногда файнридерный deskew лучше кромсаторного - см. пример.

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

Добавлено:
Вот я тут схемку начертил - как Кромсатор не очень хорошо обрезает перекособоченные сканы. Красная линия - это контур голого текста, а синяя - линия обреза Кромсатором. Я, конечно, ОЧЕНЬ сильно утрирую - для наглядности. Это то, о чём я писал - когда отсекается ошибочно до половины ширины буквы. Видимо, это одно из проявлений "проблемы распознавания номеров страниц".

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

Добавлено:
Забыл добавить: всё это делалось на Кромсаторе v5.07 - т.к. он может открывать файлы под Win98, а Кромсатор v5.51 - только под Win2000, о чём я уже писал. И я пробовал на 40 файлах обрезку вчера - не буду же я сотни файлов для примера обрабатывать - тяжело.

Модерирует : gyra, Maz
Widok (17-08-2007 15:16): лимит страниц. продолжаем здесь	Версия для печати • Подписаться • Добавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101