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

VadimirTT
Без проблем.
Там все просто: в свойствах зоны задал: Contrast=7, Brightnes=8, Gamma=0.7 (0.6). После обработки получаются сочные цвета (если покажутся что чересчур, можно еще уменьшить гамму до 0.6), а фон практически исчезает. Остатки фона убираются буквально одним кликом в режиме mouse-up-magic-clear. Т.е. на постобработку уходит максимум 1-2 сек на зону.
Качество djvu я намеренно понизил, чтобы получить сопоставимый размер. Если нужно более высокое качество, это сделать теперь в СК очень просто: выбирается более высокое качество, нажимается кнопка и получается новый djvu. Только размер конечно вырастет значительно.

Кстати, меня часто донимают просьбой ввести в СК автораспознавание зон. Недавно попался пример, как это делается в СТ (готовый djvu): http://www.onlinedisk.ru/file/615337/. Одно слово: ужас. Автор сказал, что после автоопределения зон в СТ вручную правил их 30 минут (!!) на первых 20 страницах, потом видимо надоело. Другой человек делал из тех же сканов в СК: http://flibusta.net/b/216934. Далеко конечно не конфетка, но иллюстрации не исковеркались и текст остался текстом.
Кстати, за 30 минут я в режиме mouse-up-zone расставляю зоны на 200-300 страницах. Кому нужно такое авто-определение зон, после которого нужно целый день тра...ся, правя их геометрию?


Добавлено:
slava_kry

Цитата:

то можно сделать подобное

Красиво. Но djvu не png. Чтобы сохранить все детали, придется использовать photo-профиль. Во всех остальных случаях потерь по-любому не избежать.
Поэтому для себя я всегда делаю 2 варианта: djvu и pdf. В pdf, который храню на случай необходимости печати, качество иллюстраций практически не страдает, а размер тем не менее меньше, чем у photo-djvu.

bolega

Цитата:

Красиво. Но djvu не png. Чтобы сохранить все детали, придется использовать photo-профиль. Во всех остальных случаях потерь по-любому не избежать.

То что вы продоставили и есть iw44 в чистом виде.

Добавлено:
iw44 сам по себе формат с потерями.
не мне это Вам говорить.

Добавлено:

Цитата:

Поэтому для себя я всегда делаю 2 варианта: djvu и pdf. В pdf, который храню на случай необходимости печати, качество иллюстраций практически не страдает, а размер тем не менее меньше, чем у photo-djvu.

Было это уже. При одинаковых размерах/потерях iw44 и jpeg200 практически одинаковы.
Разница в основном в контейнере.

ndch

Цитата:

То что вы продоставили и есть iw44 в чистом виде

Это понятно. Речь идет о степени потерь. Мой представленный вариант - с большими (но с терпимыми) потерями. Photo-вариант (будь то родной одноименный профиль DEE, либо МПФ с наилучшим качеством) действительно почти идентичны по качеству, но все-таки разнятся в размере. Оно и понятно: МПФ подклеивает в исходном dpi зоны=300, photo - после слияния зоны со страницей =600 dpi (по другому не сделаешь).
Сделал сейчас pdf. Размер почти как после МПФ, но качество чуть-чуть лучше (меньше размытость в изначально малоконтрастной области). Но это все нюансы реализации кодеков, так что Вы абсолютно правы, что

Цитата:

При одинаковых размерах/потерях iw44 и jpeg200 практически одинаковы

Но! Если я задам для pdf jpg2000 качество=100%, то я получаю практически безпотерьный pdf размером в 1,5 раза больше чем при photo-МПФ. В djvu мне не удалось получить такое же качество в photo-режиме. Возможно, что в djvu такая либеральность просто не предусмотрена.
Именно поэтому предпочитаю делать 2-й вариант в pdf. Для меня оба формата - равнозначны, но два - лучше чем зацикливаться на одном. Кроме того, на некоторых профессиональных цветных принтерах не раз сталкивался с тем, что печать djvu просто падала. В этом смысле драйвер печати pdf сделан более качественно, чем у djvu-программ.

Соглашусь с bolega - если речь идет о том, чтобы сохранить оригинальный документ с минимумом потерь, то JPEG2000 без вариантов. Самому приходилось часто сравнивать для этих целей IW44 и JPEG2000, и всегда "выигрывал" именно последний (какими-то результатами сравнений я делился в топике по сканированию/обработке). Причем этот вывод сделали для себя не только мы, но и множество уважаемых организаций. Например, Archive.org (интегратор нескольких проектов по сканированию библиотек, спонсируемых в основном MS и Google) использует для сохранения оригиналов сканов только JPEG2000.
Оксфордская библиотека Бодлейан для сохранения старинных манускриптов - опять-таки этот же алгоритм. И т.п.
IW44, как ни крути, намного более агрессивен.

Цитата:

Оксфордская библиотека Бодлейан для сохранения старинных манускриптов - опять-таки этот же алгоритм.

Этот файл (по мнению Irfan View) сжат со сжатием JPEG - несмотря на расширение jp2. Действительно, стоит сменить его расширение на "jpg" - как он превратится в обычный полноценный JPEG. Так что данный пример некорректен.

monday2000
Не знаю, XnView открывает их без всяких проблем именно как JP2. Так что Irfan может и ошибаться. К тому же по качеству (отсутствие артефактов) похоже именно на JP2.
Но это не важно. Важно то, что DJVU морально устаревает, несмотря на то, что по многим параметрам по прежнему превосходит PDF. Такой вот парадокс.

ghosty

Цитата:

Так что Irfan может и ошибаться.

А может ли Internet Explorer 6 напрямую открывать JPEG2000? По крайней мере, данный файл он без проблем открывает.

Цитата:

XnView открывает их без всяких проблем именно как JP2.

Попробуйте поставить этому файлу любое "левое" расширение и откроет ли его XnView - интересно. По крайней мере, стандартный Paint открывает этот же файл с расширением "jp3" - и ничего, даже не ругается.

Цитата:

Важно то, что DJVU морально устаревает, несмотря на то, что по многим параметрам по прежнему превосходит PDF.

Подробнее, пожалуйста - в чём устаревание? Если JPEG2000 действительно менее агрессивен, чем IW44 - может быть, достаточно будет просто "подкрутить" вейвлетные коэффиенты в IW44 - чтобы снизить агрессивность.

Цитата:

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

Так это просто глюк, и всё. Источник проблемы, по-видимому, DjVu-просмотрщик, из которого осуществлялась печать. Это реально можно исправить (если это был WinDjView).

bolega
ghosty
Я отправил письмо Леону Боту с вопросом, можно ли ещё снизить агрессивность DjVuPhoto? Вот что он мне ответил:

http://www.djvu-scan.ru/forum/index.php?topic=108.msg1622#msg1622

monday2000

Цитата:

Вот что он мне ответил:

Он действительно ответил на все Ваши вопросы. Причем то, о чем он говорит, касается и формата DJVU в целом.
В принципе, всю разницу в алгоритмах, применяемых в DJVU и PDF можно объяснить, исходя из того, на какое время пришелся пик их развития.
Алгоритмы DJVU были созданы более менее одновременно - когда компьютеры были еще достаточно слабыми. Поэтому все алгоритмы были оптимизированы именно по скорости. К сожалению, в ущерб качеству. Это касается и JB2 (по сравнению с JBIG2 и каким-нибудь CPC), и IW44 (по сравнению с JPEG2000) и даже сегментера (писал об этом недавно в топике по сканированию).
История алгоритмов кодирования растра в PDF более "размыта". Там было больше всяких улучшений, "разветвлений" и т.п. (теперь для текста есть не только JBIG2, но и CS) Причем эта история развития длится и по сей день (в случае с DJVU она давно уже завершилась), соответственно застав тот момент, когда об оптимизации по скорости (якобы) можно не беспокоиться. Т.е. было время позаботиться в том числе и о качестве.
Плюс ко всему поддержка PDF всякими каталогизаторами, индексаторами и прочими удобными программами.

Поэтому и получается, что сейчас часто приходится сохранять как в DJVU, так и в PDF.

Извините, если вопрос будет тупым: я никогда не занималась сканированием книг.
В общем, мне нужно отсканировать словарь. Сканер, которым собираюсь это сделать - HP 7650. Сканировать собираюсь в серой гамме, с разрешением 600, потому что после сканера нужен OCR, а язык с диакритикой, и текст напечатан темно-серым цветом. На выходе получается tiff 32-24 мб (один разворот, несжатый, распознавать его будет другой человек, и я не знаю, что ему нужно). После сканкромсатора файл очень сильно облегчается, но такое ощущение. что что-то происходит с резкостью. То есть объективно я не вижу каких-то изменений, но файнридер делает больше ошибок, чем при распознавании несжатого файла. Я бы отправила файлы несжатыми, но страниц там около 800х32 мб - это даже несмешно. Да, о сканкромсаторе: обрезала мусор версией от Ghosty, которая сделана для 300 dpi. Может надо было полной версией?
В общем, если есть где-то ЧАВО, то может кто-нибудь меня кто-нибудь туда отправит? Инструкцию к полной версии читала, про уменьшение объема ( в моем случае с 34 мб до 150 - 200 кб) не нашла.

nalekhina
Давайте так. Вы обрабатываете 3 странички в СК и сохраняете их в виде "sub-task" (File->Create Sub-Task) - в этом случае обработанные файлы сохраняются с используемыми Вами настройками. Выкладываете "субтаск" здесь. Мы смотрим, составляем профиль для этой конкретной книги и говорим, какие ошибки Вы допустили при определении параметров.
Если не хотите знать об ошибках, то просто выложите 3 наиболее типичные странички для примера

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

P.S. Да, и просто для справки - если будете кодировать в DJVU, то есть возможность встроить в файл словарный индекс для поиска по страницам.
Объем "сырых" сканов можно уменьшить, переконвертировав их в JPEG2000.

Цитата:

Давайте так. Вы обрабатываете 3 странички в СК и сохраняете их в виде "sub-task" (File->Create Sub-Task) - в этом случае обработанные файлы сохраняются с используемыми Вами настройками. Выкладываете "субтаск" здесь. Мы смотрим, составляем профиль для этой конкретной книги и говорим, какие ошибки Вы допустили при определении параметров.

Я сейчас на флэшке в интернете, когда дойду до нормального компьютера - отправлю маску. Это папка "тест", правильно? В Вашей версии я в выходных настройках сейчас поменяла только формат (на несжатый тиф) и цветовую шкалу на серую. Но все равно выходит 3-4 мега. Мне этого за глаза, но я не понимаю, за счет чего уходят 30 мегабайт. Разве что на самом деле выходное разрешение меньше (поскольку Вы оптимизировали под 300) и градаций серого меньше. В версии полной файл кромсатора получается таким же по размеру, как и исходный. Но мне бы как-нибудь такой формат подобрать, чтобы файл был нормального веса, но при этом распознавался с минимальным количеством ошибок. Может я при сканировании накосячила, может серую гамму убрать и выставить черно-белую. Но там сильно обратная сторона просвечивает. А сейчас файнридер даже с необработанным сканом чудит: иногда строчные на прописные буквы строчными заменяет.
А делаю я все под файнридер, поскольку словарь для Лингво будет делаться.

ghosty

Цитата:

Он действительно ответил на все Ваши вопросы. Причем то, о чем он говорит, касается и формата DJVU в целом.

А я так и не понял в пока что самого главного - хуже ли IW44 чем JPEG2000, и если да, то насколько ("количественно", так сказать). Рекомендация насчёт "slice 999" кажется мне весьма сомнительной - выше slice 120 уже ничего не меняется насколько я помню. Нет, тут не так всё просто, как сказал Леон.

Вот если бы кто-то представил 2 образца - можно было бы дотошно визуально сравнить. А так всё голословно очень уж.

Цитата:

- iw44 uses a different wavelet that generates a bit more artefacts but runs much faster.

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

Цитата:

(теперь для текста есть не только JBIG2, но и CS)

Мы уже с пользователями разобрались, что ClearScan имеет смысл исключительно для векторного формата (т.е. PDF, но никак не DjVu), потому что растеризация векторного объекта (коим является CS) (при попадании его из PDF в DjVu) опять порождает несглаженность контура букв.

Для DjVu нужно растровое сглаживание контура - а не векторное (как CS).

Цитата:

соответственно застав тот момент, когда об оптимизации по скорости (якобы) можно не беспокоиться.

Скорее, речь идёт о размере, нежели чем о скорости. Но размер всегда будет иметь значение - потому что понятие "экономическая целесообразность" никто ещё не отменял.

Цитата:

Плюс ко всему поддержка PDF всякими каталогизаторами, индексаторами и прочими удобными программами.

Эта проблема - решаема. Как ни странно, она напрямую зависит от количества имеющихся в Сети DjVu-книг. Если их будет ОЧЕНЬ много - с форматом DjVu уже не смогут не считаться. Пока есть Леон Боту - DjVu будет "на плаву" (в теоретической части, в практической части мы удержим DjVu "на плаву"). Леон уже плюнул на Caminova и сам потихоньку развивает DjVu (в частности, недавно он самолично ввёл поддержку XMP-метаданных в djvused. XMP-метаданные - это то, что есть в формате PDF).

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

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

ghosty
Я ещё думаю, что формат DjVu - это как бы наша "гарантия независимости" от возможного произвола Adobe. Не будь DjVu - PDF был бы полным монополистом - и как следствие, был бы "совсем уж нехорошим". И исчезни сейчас DjVu - через короткое время, в условиях полного отсутствия конкуренции, PDF быстро превратится в полного монстра (ибо жадность наживы не имеет предела) - к которому мы попадём в тотальную зависимость.

Отсюда такой вывод, что DjVu необходимо всемерно поддерживать - это, так сказать, наш "оплот" ИМХО.

monday2000

Цитата:

Вот если бы кто-то представил 2 образца - можно было бы дотошно визуально сравнить. А так всё голословно очень уж.

Для своих целей я сравнивал дотошно и визуально. IW44 действительно может давать неприятные артефакты, например, в случае "крупнозернистого" фона (некачественная/старая бумага) - отдельные зерна он может объединить в точку, линию, кривую и т.п. Когда каждая царапинка имеет значение, подобное поведение алгоритма никуда не годится. У JPEG2000 нет ничего подобного даже в сравнительно более агрессивных режимах (какие-то детали фона, конечно, могут уходить, но так, чтобы появлялись новые - никогда). Некоторые результаты своих "исследований" я публиковал на руборде:
http://forum.ru-board.com/topic.cgi?forum=93&topic=1624&start=1657&limit=1&m=1#1


Цитата:

Скорее, речь идёт о размере, нежели чем о скорости. Но размер всегда будет иметь значение - потому что понятие "экономическая целесообразность" никто ещё не отменял.

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


Цитата:

Отсюда такой вывод, что DjVu необходимо всемерно поддерживать - это, так сказать, наш "оплот" ИМХО.

Оплот, так оплот. Я всего лишь хочу сказать, что оба формата сегодня актуальны - трудно выбрать "лучший". В результате для конечного пользователя лучше иметь оба варианта/иметь выбор между двумя.

Цитата:

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

Я забыла написать, что делается это все под файнридер, т.к. распознаный скан потом будет обрабатываться для dsl для Лингво. Т.е. чем лучше распознается, тем меньше потом ручной работы.
Черный и серый сканы сравнила (оба 600) - у черного углы вылезают.
Папка - тут:
http://mnogofiles.com/1qcxdxusird1.html

nalekhina
Все, как я и предполагал.
1) 300dpi в данном случае вполне достаточно - диакритика сохранится.
2) не стоило крутить настройки в моем профиле - просто верните их обратно (Files->Color: B/W, Output format: TIFF G4FAX)
3) можно немного увеличить порог бинаризации (190-200 по вкусу).

И все, книга готова к пересылке и OCR. Каждая страничка - в районе 100Кб. Если и это для Вас много, могу посоветовать простой упаковщик/распаковщик CPC - запаковываете, пересылаете, адресат запускает батник, получает многостраничный TIF, который и скармливает файнридеру.

Добавлено:

Цитата:

Черный и серый сканы сравнила (оба 600) - у черного углы вылезают.

Как это?

Цитата:

И все, книга готова к пересылке и OCR. Каждая страничка - в районе 100Кб. Если и это для Вас много, могу посоветовать простой упаковщик/распаковщик CPC - запаковываете, пересылаете, адресат запускает батник, получает многостраничный TIF, который и скармливает файнридеру.

Большое спасибо за совет. Мне 100 кб немного, я и по 34 мб могла бы выслать, просто меня не поймет тот, кто будет распознавать. В общем, Вы меня спасли.

monday2000

Цитата:

А я так и не понял в пока что самого главного - хуже ли IW44 чем JPEG2000

Повторю банальную фразу: вещи сами по себе не являются плохими или хорошими, таковыми они становятся в оценке людей.
Во-первых: опредилитесь с критериями.
Во-вторых: ответ от Леона прозвучал.


Цитата:

Вот если бы кто-то представил 2 образца - можно было бы дотошно визуально сравнить. А так всё голословно очень уж.

В чём сложность то ?
Берёте некоторое количество материала.

конвертруете в ppm, кодируете.
http://ovh.dl.sourceforge.net/project/djvu/DjVuLibre_Windows/3.5.23%2B4.6/DjVuLibre%2BDjView-3.5.23c%2B4.6b-Setup.exe
http://www.kakadusoftware.com/executables/Win32.zip (более старая)
http://www.kakadusoftware.com/executables/Kakadu_v64_demo_apps.msi
Конвертируете результаты в tiff (что-то другое) и сравниваете в фотошопе/ThumbsPlus (в чём-то другом).

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

От себя могу добавить про какаду: rate 0.25 ; rate 0.85
В сабже напрямую именно таких чисел для какаду нет.

А что делать с этим?
_http://www.onlinedisk.ru/file/619882/

Цитата:

А что делать с этим?

Зависит от времени, которое вы готовы потратить.
Сколько там этих разворотов? А то я скачал вашу выкладку примеров. 15 разворот у меня получился - 150 кБ в ПДФ. Хочется подсчитать общий вес.
Обработка минимальна: кривые, шумодав.
http://www.onlinedisk.ru/file/619996/

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

VadimirTT

Цитата:

Мне непонятно что делать с "окантовкой" страниц

Резать к чертовой матери... (с)

Но если очень хочется, то можно выделить окантовку в Picture Zone, после чего скопировать эту зону на все остальные страницы.

ghosty

Цитата:

Но если очень хочется, то можно выделить окантовку в Picture Zone, после чего скопировать эту зону на все остальные страницы.

Сомневаюсь, что этот номер пройдет.
В окантовку попадает нумерация страниц, а также текст сверху, который (КАК Я ДУМАЮ! ) тоже меняется.
VadimirTT
Окантовку удастся сохранить только если не лень заключать на каждой странице ее в 3 picture-зоны. Правда и тогда возни будет много, если нужно будет выравнивать размеры всех страниц или какие-то сканы (как приведенный Вами) сделаны с небольшим наклоном.

bolega


Цитата:

меня часто донимают просьбой ввести в СК автораспознавание зон.

Вы знаете я уже как-то высказывал, но могу повторить снова, что стоит, если есть на то возможность, мои предложения по автораспознаванию ввести эту опцию, например для 2-3 типов зон на выбор (указать, что зоны могут быть квадратные, круглые и треугольные) гораздо проще будет тогда вести их правильное распознавание + сделать эту функцию отключаемую не только в пределах всего файла, но и на отдельных страницах

Где можно прочитать ответ на вопрос о том, как установить при драфте чувствительность определения положения границ текста по горизонтали?

ghosty

Цитата:

IW44 действительно может давать неприятные артефакты, например, в случае "крупнозернистого" фона (некачественная/старая бумага) - отдельные зерна он может объединить в точку, линию, кривую и т.п. Когда каждая царапинка имеет значение, подобное поведение алгоритма никуда не годится. У JPEG2000 нет ничего подобного даже в сравнительно более агрессивных режимах (какие-то детали фона, конечно, могут уходить, но так, чтобы появлялись новые - никогда).

Тема получила некоторое продолжение. Оказывается, можно реализовать поддержку JPEG2000 в DjVu! Но нужно ли? Ведь время декодирования JPEG2000 в 3 раза больше, чем таковое у IW44.

Если интересно - см. http://www.djvu-scan.ru/forum/index.php?topic=108.msg1671#msg1671 и далее.

Если кому-то нужна поддержка JPEG2000 в DjVu - напишите письмо Леону Боту.

monday2000

Цитата:

Тема получила некоторое продолжение. Оказывается, можно реализовать поддержку JPEG2000 в DjVu! Но нужно ли?

Тут ведь вопрос в том, доверю или не доверю я кодеру DJVU обрабатывать книги, особенно чувствительные к качеству - например, включающие репродукции, копии манускриптов (там, кстати, если я правильно помню, у IW44 большая проблема с цветопередачей). И понятно, когда я говорю "я", то имею в виду не себя конкретно и не какого-либо другого индивида, а институты и организации, прежде всего. А институты и организации давно уже перешли в массе своей на PDF, так что решение о поддержке JPEG2000 было бы запоздалым.
DJVU так хорошо распространился в России, прежде всего, благодаря его открытости и JB2-составляющей, которая уже и 10 лет назад, можно сказать, была идеальной. Так что добавление JPEG2000 даже в России ему большей популярности не придаст. Опять-таки ИМХО.


Цитата:

Но нужно ли? Ведь время декодирования JPEG2000 в 3 раза больше, чем таковое у IW44.

Возможно, у Леона старая информация. Все-таки JPEG2000 много оптимизировали, и по моим ощущениям все теперь как раз наоборот. Хотя надо делать более корректные "бенчмарки".

Добавлено:
juvaforza

Цитата:

Где можно прочитать ответ на вопрос о том, как установить при драфте чувствительность определения положения границ текста по горизонтали?

По-моему, это невозможно. И для меня это тоже актуально - особенно когда идет нумерация по краям блока текста и драфт отрезает эту нумерацию как мусор.
С другой стороны я понимаю, что в случае такой нумерации очень трудно найти какие-то формальные признаки того, что она мусором не является. Т.е. в этом случае, мне кажется, вполне достаточно опции "Я уверен, что в моей книге мусора нет, и мне нужны все значки по краям блока текста"
Но если я уверен, что мусора в моей книге нет, то я могу и не выполнять кромсание - в ходе обработки блок текста определится корректно со всеми значками. bolega, я правильно рассуждаю?

juvaforza

Цитата:

чувствительность определения положения границ текста по горизонтали

В опциях draft на закладке Advanced есть этот регулятор: Text vert. sensitivity.
Но честно говоря это не совсем чувствительность. Это именно похоже на
ghosty

Цитата:

"Я уверен, что в моей книге мусора нет, и мне нужны все значки по краям блока текста

Тут ghosty абсолютно прав.

На самом деле распознавание значков (номеров страниц, вынесенных буковок и т.п.), расположенных сбоку от основного габарита страницы - это самая сложная и нетривиальная задача. Потому что в этом месте очень часто располагается как раз мусор: маленькие ошметки теней от корешка и разворота книги, пометки читателей, дырки от дырокола, и прочая. СК, анализируя страницу, определяет сначала типовые размеры шрифта на каждой странице (не более 3х). Затем сопоставляет размеры ошметков по бокам страницы с этими размерами. Дополнительно учитывается также их расположение (напр., относительно выявленных на странице строк текста), их удаленность от этих строк, а также взаимное расположение самих ошметков между собой (напр., если они все выровнены по своему левому или правому краю, то это скорее всего столбик текста, а не грязь). Т.е. как вы видите, критерий распознавателя довольно сложный, и каждый парметр в нем имеет свой определенный вес. Если итоговое значение критерия больше некоторого порога, то СК считает блиты текстом, иначе - грязью. Так вот, значение Text vert. sensitivity как раз определяет этот самый порог. При значении High практически все блиты по бокам СК засчитывает как текст.
Иногда при таком вероятностном анализе некоторые параметры настолько весомы (либо вообще отсутствуют), что СК сразу принимает правильное решение и дальнейший анализ не производит. Если же ему пришлось "идти до конца", то, как все наверное заметили, после draft СК выделяет такие файлы в списке жирным выделением (bold). Это означает, что боковые края текста СК определял с помощью описанного мною вероятностного анализа, т.е. на них нужно обратить внимание при проверке расстановки резаков.
Кстати, в версии 5.93 и далее усложнился также анализ горизонтальных краев. СК проводит теперь анализ на наличие номеров страниц, а также некоторых математических символов (интеграла и символа суммирования), т.к. под или над ними могут быть небольшие буковки-циферки (пределы суммирования или интегрирования).