» ScanKromsator СканКромсатор

bolega

Вот хочу вернуться к этому вопросу:


Цитата:

Цитата:иначе почему приходится в постообработке то и дело двигать текст по картинке влево-вправо (вверх-вниз) на 8-16 пикселей

Хе-хе. Определяет то он неплохо. А вот располагает потом на странице именно с такой точностью. Абсолютно не вижу никакого смысла в пиксельной точности.

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


Цитата:

приходится в постообработке то и дело двигать текст по картинке влево-вправо (вверх-вниз) на 8-16 пикселей

?

Казалось бы, раз контуры голого текста у нас определены ТОЧНО, то что же мешает Кромсатору спозиционировать голый текст на белой странице тоже ТОЧНО, т.е. чтобы слева-справа (сверху-снизу) были поля ВИЗУАЛЬНО ОДИНАКОВОЙ ширины. Сейчас же получается визуально поля довольно-таки ГРУБО РАЗНОЙ ширины. В чём тут проблема? Почему же текст не позиционируется точно? Действительно приходится ведь КАЖДЫЙ скан двигать туда-сюда (в редакторе постобработки Кромсатора), пока не добьёшься полей ВИЗУАЛЬНО ОДИНАКОВОЙ ширины (я не преувеличиваю - каждый скан так и просится, чтобы его подвинули куда-то, иногда намного, иногда немного) - а это ведь ОБЕССМЫСЛИВАЕТ преимущество Кромсатора по сравнению с полностью ручной обрезкой, где я делаю то же самое - позиционирую голый текст на глаз на белом шаблоне.

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

А может быть, пусть Кромсатор выдаёт на входе сам голый текст, вообще без полей? Может, это будет гораздо наглядней, чем как сейчас? Так нам и обсуждать Кромсатор будет легче, объективнее получатся суждения. И будет гораздо лучше видно - правильно сканы обрезались или нет, гораздо нагляднее. Просто полученный голый текст должен будет без зазора прилегать к краям полученного тифа - и мы сразу увидим, получилась обрезка или нет.

А потом отдельным проходом просто добавить автоматически поля выбранной ширины - это можно хоть в Irfan View сделать.

Добавлено:
Контур голого текста в моём понимании - это воображаемый прямоугольник, описанный вокруг текста так, чтобы буквы текста с 4 сторон касались изнутри сторон этого прямоугольника ВПЛОТНУЮ, без зазоров (пусть и за вычетом "проблемы номеров страниц"). Может ли Кромсатор столь хорошо обрезать сканы? Пока что субъективно кажется, что нет. Если же всё же "да", то как в этом удостовериться? Если бы Кромсатор выдавал голый текст без полей на выходе (хотя бы как опция) - тогда такие вопросы исчезли бы, всё было бы и так видно чисто визуально.

monday2000

Цитата:

А может быть, пусть Кромсатор выдаёт на входе сам голый текст, вообще без полей? Может, это будет гораздо наглядней, чем как сейчас? Так нам и обсуждать Кромсатор будет легче, объективнее получатся суждения. И будет гораздо лучше видно - правильно сканы обрезались или нет, гораздо нагляднее. Просто полученный голый текст должен будет без зазора прилегать к краям полученного тифа - и мы сразу увидим, получилась обрезка или нет.

А потом отдельным проходом просто добавить автоматически поля выбранной ширины - это можно хоть в Irfan View сделать.

Nu dak i delajte! GAP = 0; PAGE WITH/HEIGHT - None. I poluchite to, kak Kromsator obrezal.
Tam vse realizovano, prosto nado kopatjsya! Dokhodit - cherez ruki. I perestanjte, pogalujsta,
chmaritj dejstviteljno otlichnuyu programmu. Skoljko v kolkhoze knig? Skoljko iz nikh proshlo
cherez Kromsator? - Poverjte mne, ochenj mnogo!
A to, chto Vy ne mogete razobratjsya s programmoj - Vashi problemy. Poprobujte sami napisatj
chto-to (na Vash vzglyad) luchshee... Pomnitsya Vy zatevalisj sozdatj otkrytyj algoritm DJVU-
kodirovaniya... Nu i chto iz togo poluchilosj?

A obsugdatj tam nechego - nado prosto uchitjsya...

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

Всё равно так будет нагляднее, чем сейчас.

Добавлено:
ging

Цитата:

Nu dak i delajte! GAP = 0; PAGE WITH/HEIGHT - None. I poluchite to, kak Kromsator obrezal.

Попробую.

Цитата:

Tam vse realizovano, prosto nado kopatjsya! Dokhodit - cherez ruki. I perestanjte, pogalujsta,
chmaritj dejstviteljno otlichnuyu programmu.

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

monday2000

Цитата:

Сейчас же получается визуально поля довольно-таки ГРУБО РАЗНОЙ ширины. В чём тут проблема?

В данный момент работаю в Кромсаторе, подчищаю сканы. Так вот, поля слева и справа ВИЗУАЛЬНО СОВЕРШЕННО ОДИНАКОВЫ, поле сверху указанного мною размера (установлено выравнивание по верху). Никак не могу понять, что у Вас за проблемы с Кромсатором. Случались и у меня затруднения, но они от незнания/непонимания тонкостей его работы. Может быть и Ваши тем же объясняются?

Arcand

Цитата:

Так вот, поля слева и справа ВИЗУАЛЬНО СОВЕРШЕННО ОДИНАКОВЫ

Да вот у меня тогда на контрольной книге так хорошо не получилось. Может быть, и вправду, какая-то не такая книга попалась? Вот попробую получить непосредственно голый текст, надеюсь, так будет нагляднее. Ведь это же всё довольно субъективные суждения. Я имею в виду, что когда я пробовал обрезать Кромсатором, то потом в редакторе постобработки, при смещении скана стрелками влево-вправо (вверх-вниз) поля становились БОЛЕЕ РАВНОЙ ШИРИНЫ.

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

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

Я ещё попробую на другой книге на днях (получить голый текст) и напишу, что из этого вышло. Я, естественно, пытаюсь быть максимально объективным и беспристрастным по отношению к Кромсатору, и конечно мне тоже очень соблазнительно уйти от ручной обрезки из-за её трудоёмкости. Может, я и вправду придираюсь? Вроде бы нет, я просто сопоставляю Кромсатор с ручной обрезкой и ищу подходы, как добиться от Кромсатора такого же результата, что при ручной обрезке. Не забывайте, что руками получается лучше, чем любой возможной прогой, потому и требования выглядят завышенными, видимо.

Добавлено:
ging

Цитата:

Pomnitsya Vy zatevalisj sozdatj otkrytyj algoritm DJVU-
kodirovaniya... Nu i chto iz togo poluchilosj?

А получилось то, что появился DEE 5.1 и обессмыслил эту затею. Я думал тогда о том, как ПАКЕТНО кодировать в djvu лучше, чем это делает кодировщик с djvulibre. Не исключено, что в будущем я займусь вопросами такого рода. Пока что более актуальная текучка на повестке дня. Кромсатор ведь тоже годами делался, и начинался тоже издалека, не сразу.

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 файлах обрезку вчера - не буду же я сотни файлов для примера обрабатывать - тяжело.

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

monday2000

Цитата:

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

Посмотрел я их и сделал deskew. У второго скана почистил ужасные полосы (а чего вы от него хотели), установил Ortho для 2-го и 3-го скана и, несмотря на жуткий перекос, Кромсатор все выровнял. Такое впечатление, что Вы ищете недостатки, которых нет. Я все более убеждаюсь в том, что Вы Кромсатор не знаете и не желаете его изучать.

Добавлено
И вообще, Ваше сравнение deskew ФР и СК некорректное. Вы подсунули СК сканы после ФР, который часто их портит (в Вашем случае испорчен 2-й скан) - дабавляет паразитные полосы, залезающие в область текста.

Всё это конечно понятно. Я вот тоже хочу изучать Кромсатор, но кроме хелпа к 1-й версии ничего нет, за исключением скудных комметриев автора на различных форумах. Ну, неужели так трудно сделать help нормальный?
Почему я должен узнавать всё методом тыка? Я понимаю, что у boleg-и времени нет, но вот такие пользователи как я, наприер, тоже не обладают достаточным временем на освоение Кромсатора вслепую и хоть чувствуют большой потенциал у программы, вынуждены обращаться к другим, может быть менее удобным, но простым способам решения задачи кромсания - к Фотошопу, к ФайнРидеру и проч...

Кромсатора больше не будет?
Я что-то не понял, автор закрыл проект?
По ссылке сайта так и написано

Arcand

Цитата:

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

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

Цитата:

И вообще, Ваше сравнение deskew ФР и СК некорректное. Вы подсунули СК сканы после ФР, который часто их портит

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

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

Ещё раз извинясь, если что не так. Я как умею, так и пробую Кромсатор.

bolega


Цитата:

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

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

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


Цитата:

Ну, неужели так трудно сделать help нормальный?
Почему я должен узнавать всё методом тыка?

Вот видите, как проблема назрела? И что уж Вы вправду этот хелп-то не напишете? Вам 3-4 вечера - и всех дел-то. Вы же лучше всех знаете там все детали, я вот почти ничего не знаю к примеру.

bolega
Нужна Ваша помощь. Вот типичная страница отсканированного словаря - http://rapidshare.de/files/6437101/0001.rar.html
Многие буквы в русских словах слишком жирные, вплоть до того, что трудно понять, какая где буква. Можно ли с помощью Кромсатора сделать их более "худыми", но так, чтобы при этом не пострадал нежирный текст? Если да, то как?

vitaly1

Цитата:

Можно ли с помощью Кромсатора сделать их более "худыми"

Если я не ошибаюсь - такая фича есть в Растериде.

Цитата:

но так, чтобы при этом не пострадал нежирный текст?

Это не знаю - возможно, там можно и отдельные области скана выделять и обрабатывать так.

monday2000

Цитата:

такая фича есть в Растериде

А как называется?

Цитата:

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

Это не прокатит - как я отдельные слова выделю?

Цитата:

такая фича есть в Растериде.

Есть-то есть. Но все мои попытки улучшить ч/б сканы не дали удовлетворительного результата. По всякому исхитрялся, толку мало. Безнадежное ИМХО это дело.
Надо сканировать в gray, тогда можно что-то сделать.

А кроме Растера есть еще какие-то варианты?

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

Цитата:

А кроме Растера есть еще какие-то варианты?

Есть еще фильтры enhance в БукРесторере и СканКромсаторе, но они работают с gray. Что касается Вашего примера, то он безнадежен, ИМХО конечно.

monday2000

Цитата:

Можно так сказать, да - действительно ищу там недостатки.

Мне это напомнило один старый анекдот.
Купил один деревоперерабатывающий завод японский станок.
Работяги побросали свои ножовки и пошли проверять.
Сунули в него древесину метром в диаметре. Станок распилил. "Ах так!"-сказали возмущенные рабочие. Сунули двухметровый ствол. Он и его распилил. "Ах так!" - опять возмутились рабочие. Сунули бетонный столб. С трудом, но распилил. Сунули рельсу. Станок накрылся... "То-то же"- удовлетворенно сказали рабочие и разошлись.

bolega

По Кромсатору 2 самых "горячих" запроса на внедрение:

1. Превратить редактор постобработки ещё и в просто редактор обработки.

2. Сделать возможность двигать там скан вправо-влево стрелками клавиатуры, а не нажиманием экранных кнопок мышью.

Вправо-влево - может быть, и не попиксельно, но тогда хотя бы по 4 пиксела для начала минимум (а не по 8, что много) думаю следует сделать.

Оба эти предложения, думаю, возможно реализовать относительно быстро. Что скажете?

3. И более трудное - чтобы сканы не сразу окончательно обрезались, а в 2 этапа:

а. Предварительная обрезка. На этом этапе сканы просматриваются в редакторе и ПОДВИГАЮТСЯ РУКАМИ влево-вправо - и, САМОЕ ГЛАВНОЕ, из-за кромки обреза при двигании сканом влево-вправо вылезает не "молоко", а первоначальная скрытая область скана.

б. Окончательная обрезка. Просто принимаем результаты пункта а.

Пункт 3 даст синтез моего метода - ручного - с Кромсаторным. Пока же вылезает "молоко" при двигании сканом влево-вправо.

P.S. Когда-то давно я писал в ABBYY, чтобы и они тоже сделали обрезку сканов - опираясь на свою технологию распознавания. Мне тогда ничего не ответили - я подумал - разозлились. Кстати, добавить формат DjVu я им предлагал 3 раза - отвечали "не планируем".

bolega
Вам, наверное, уже надоели с просьбами о Хэлпе...
Я - новичок в сканировании и вообще случайно за это взялся - понадобилось один ч/б многостраничный (~640 стр) tif в более удобочитаемый вид перевести. Безусловно, на Вашу программу в тематических сайтах наткнуться можно сразу - это плюс.
Но какое же мучение ее осваивать без описания к текущей (для меня 5.51b) версии... Я только после третьего подхода (два раза брался и бросал нафиг) смог что-то более-менее удобоваримое получить на выходе.
Обычно интерфейс хоть в какой-то степени располагает к интуитивному освоению. нов Вашей программе мне (безусловно, как новичку и ламеру) разобраться с наскоку было сложновато. И, действительно, крупицы нужных сведений приходится находить по различным форумам.

Но зато какое чувство, когда после 3х-часового бдения (за один присесет) над клавой и мышой и 5 минут обработки Кромсатором получается какой-то (пусть и далекий от того, какой бывает у Гуру) результат

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

bolega
Столкнулся с такой неувязкой. Беру серые сканы 300 дпи (разворот). Установил простую разрезку, повышающий ресемплинг до 600 дпи, Deskew (Auto shear), чистку фона. На выходе серые сканы. Но частенько в буквах вижу ступеньку в один пиксель. Досадно, так как вынужден отказаться от данной обработки в Кромсаторе. В БукРесторере такая обработка ОК.

Arcand

Цитата:

Столкнулся с такой неувязкой

Ни в коем случае не стоит для случая, когда на выходе non-b/w, использовать autoshear deskew. Только interpolate или antialias. И тогда про ступеньки можете забыть.

bolega
Хорошо . По случаю хочу уточнить работу функции Clear shadow. Она чистит фон в тени сгиба, это понятно. А как с яркостью текста в тени, она ее корректирует? Хотелось бы, чтобы корректировала. Поскольку в противном случае происходит ужирнение текста, что нежелательно как для восприятия, так и для качества последущего кодирования в дежавю. И вообще, как лучше поступать, чтобы лучшим образом убрать тень (на выходе серые сканы)?

Arcand

Цитата:

она ее корректирует?

Нет. Только убирает фон.
Я думаю, здесь дело не в яркости, а в общем падении контраста в области сгиба, когда буквы слегка расплываются (из-за тени, и возможно, из-за геометрических искажений на сгибе) и поэтому ужирняются при переводе в b/w. Здесь уже ничего не поделаешь. Вы же спрашиваете о случае, когда имеется дальнейший перевод в b/w?
Если же имеете ввиду grey-случай, то действительно, буквы в тени должны получаться темнее. Над этим надо подумать. Кстати, BR уменьшает их яркость при выравнивании освещенности?



Добавлено:
Совсем забыл.
Там есть опция Protect black (по умолчанию включена). Она как раз контролирует, будет ли понижаться яркость темных букв. Снимите галку и посмотрите, может поможет. Без этой галки тень вообще убирается лучше, особенно темная. Эта опция пришла из старых версий кромсатора, когда не было exclude-зон, и удаление тени могло вредить иллюстрациям.

bolega
При предварительном кромсании сырых серых сканов в СканКромсаторе (или БукРесторере) мне нужно разрезать разворот на половинки, сделать deskew, повышающий ресемплинг, убрать тень (можно дополнительно и фон) и получить серые сканы для последующей обработки в РастерИД.
У меня при сканировании первая по ходу головки сторона сгиба темнее, чем основная часть скана (особенно, если бумага серая), вторая сторона сгиба - более светлая. Перед обработкой серых сканов в РастерИД мне нужно, кровь из носа, убрать тень - иначе от нее после финального кромсания (Кромсатором) остается много мусора. Желательно также подкорректировать яркость текста в тени, если этого не сделать, то после обработки в РастерИД он ужирняется, что плохо.

Цитата:

Кстати, BR уменьшает их яркость при выравнивании освещенности?

Да, у меня неплохо работает 2D коррекция (чувствительность на максимуме), от 1D коррекции толку мало - плохо убирает тень.

Цитата:

Там есть опция Protect black (по умолчанию включена). Она как раз контролирует, будет ли понижаться яркость темных букв.

Спасибо за совет, буду пробовать.

Добавлено
Тень хорошо удаляется на светлых и темных сканах, если я включу Enhance image и укажу чистку фона. При этом понижается яркость всего скана. А опция Clear shadow в случае серых выходных сканов похоже не работает. Было бы неплохо, чтобы работала.

Все что я говорил, касается именно clean background (который и выполняет удаление тени). Я не имел ввиду clear shadow. CS - это только для b/w сканов и в основном для теней, сливающихся с текстом! Там специальный алгоритм, который пытается удалить тень на ч/б сканах. Часто это не очень хорошо получается, но это и понятно, в b/w сканах определить, где буквы, а где рваные куски тени, алгоритмически практически невозможно.

bolega

пользую версию 5.03
вопрос.

создаю новое задание.
в task options убираю галки с deskew, automargins, despekle
Сохраняю под именем, ставлю галку use as default options.

Потом запускаю drafst cromsate, а он все равно после завершения предкромсания проставляет мне галки
deskew, automargins, despekle на большинстве страниц.

И еще. Ладно, пусть он проставил. Но как мне убрать эти опции на уже предоткромсаных страницах, сразу скопом?

ув. bolega!
никак не могу запустить Кромсатор (5,52бета), скаченный с РапидШары по ссылке в шапке
Если архив и не битый, то сам sk.exe при запуске вылетает с ошибкой "Access violation". Платформа ВинИнтел (2000, ХР). Может быть, этот вопрос уже рассматривался, но я , к своему стыду, не смог найти ответ.
заранее благодарю.

romanef

Цитата:

нужные мне натстройки в пункте enhance - > gray enhance?

A razve oni ne dlya vsekh fajlov srazu prostavlyayutsya? T.e. mo-moemu oni ne zavisyat ot togo,
stoyat uge galki ili net.