» Scan Tailor

Tulon

Цитата:

а зачем в таком случае вы их вообще в ST грузите?

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

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

Добавлено:
Ну и опять же, если нужно просто повернуть/разрезать без постобработки - т.е. то что нужно monday2000.

monday2000
При всем моем уважении к Вам попробую заступиться за СТ
чем знаменит Г.Форд
сделал простой, дешевый и нужный грузовичек "черного цвета"
Когда на него наседали и говорили, что он консерватор и ущемляет права продвинутых американцев в выборе любимого им цвета Форд выдал знаменитую фразу:
"Любой американец может выбрать автомобиль Форд любого любимого им цвета, при условии что этот цвет черный"! (примерно так по смыслу).
По-моему, это подходит и к СТ
и я благодарен Tulon что это так!

Прогресс, как и потребности профессионалов, стремится к бесконечности.

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

Наверное, было бы неплохо подготовить и общими усилиями собрать библиотеку фильтров, ориентированную на ПРОСТЫХ ПОЛЬЗОВАТЕЛЕЙ. Это была бы как-бы добавка к СТ. Такие библиотеки и файлы по отдельности есть, но надо быть профессионалом чтобы в них разобраться, определиться с программой, ее версией. Нужно ли мне качать 700 Мб COREL чтобы использовать нужный фильтр?
Вот где могут помочь профессионалы! Простая таблица с образцами текста со скана - рекомендуемая программа - результат.
Вот где бы Вам спасибо сказали! С Вашим то опытом!!!
Я занимаюсь макротехнологическими моделями - в этом я специалист - но совершенно не понимаю в терминологии цветоделения и сканирования. Мне это не надо, да и нет времени изучать это. Как и все мы, нужно быстрее, быстрее...

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

Поэтому, еще раз благодарен Tulonу за его труд и выбор ориентации программы на простые потребности Пользователя.
Вот приложил пример книжки, которая мне нужна, но качество ее такое отвратительное, что...
Может, кто сделает доброе дело и приведет ее к читабельному виду
http://slil.ru/28491279
Заранее спасибо

Dashout
Боюсь, с таким же успехом можно было выложить набор абсолютно белых страниц. Миссия невыполнима - такие сканы даже человек не распознает.

woodyfon

Цитата:

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

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

Обнаружение наклона - тут все просто:
1. Бинаризуем картинку.
2. Делаем повороты на разные углы с шагом 1 градус.
3. Для каждого такого поворота вычисляем качество, которое равно сумме квадратов разностей колличества черных пикселей в соседних строках. То есть суммируем пиксели в строках, для каждой пары соседних строк берем квадрат разности от этих сумм, и потом суммируем эти квадраты.
4. Между лучшим поворотм и лучшим из его соседей делаем бинарный поиск для уточнения угла.
Этот алгоритм очень известный, хотя названия я не знаю. Другие задачи как правило выполняются не одним алгоритмом, а длинной цепочкой алгоритмов. Сами алгоритмы находятся как правило в директории imageproc.

Tulon, большое спасибо за столь подробное объяснение. Скажу честно, даже не ожидал . Юзер monday2000 по-моему немножко не то делает. Самое главное - это втулить ХОРОШО отсканированные изображения, а не заниматься обработкой и улучшением. Не берусь учить. monday2000 оцифровкой книг много лет, а же 4 книгами пока ограничился которые, сделал буквально за неделю, но мне так кажется. Я лично немного поигравшись понял, что лучше хорошо отсканировать, чем потом заниматься долго и нудно обработкой во многих программах. Сейчас программа супер - полчаса на установку параметров, а дальше фильм смотреть Если в программе осуществлять все, что может понадобиться, программа потеряет универсальность как ни странно это звучит. Да считаю программу универсальной.
Я наверное, уже задавал вопрос, что вы планируете переделать и добавить?

Цитата:

Кто-то сканирует книги по одной странице (не разворотами)?
Как вы поворачиваете парные (или непарные) страницы? Неужели вручную по одной?

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


Цитата:

Или есть какие-то утилиты, которые делают это автоматом?

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

Сделайте для себя выводы о ресурсоёмкости распознавания и в следующий раз сканируйте так чтобы повернуть было проще.
Да и вообще вся эта тема надумана - хотите комфорта сканируйте подходящим для Ваших запросов сканером.

Tulon

Цитата:

Вы же все равно собираетесь стадии 3-6 делать в ST, и соответственно все равно придется проходить и полезную область и все остальное.

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

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

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

Добавлено:
Tulon
А почему Вы так боитесь разбить СТ на 2 программы, как я предлагаю? Как по-Вашему, какие минусы у этой идеи? Разве это хоть на сколько-нибудь усложнит жизнь пользователей? Если и усложнит - то только на самую малость - за счёт того, что нужно будет лишний раз выгрузить-загрузить сканы. Так ли уж это непосильно для тех же "домохозяек"? Думаю, практически нисколько.

Зато сколько плюсов мы приобретаем! Вот такие:

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

2. Борьба с вредным универсализмом.

3. Появляется возможность использовать СТ в иных целях - не связанных с DjVu-книгосканированием - например, подготовка сканов для распознавания в CuneiForm.

4. Вам же проще будет разрабатывать.

5. Возможность использования сторонних программ до точки разрезания. Например, разрезаем сканы в СК - а докрамсываем в СТ. Или наоборот. А такое вполне может быть - каждая программа в чём-то сильна, а в чём-то слаба.

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

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

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

Я бы сделал разбиение так:

1-я программа: нынешние стадии СТ 1,2,3.

2-я программа: нынешние стадии СТ 3,4,5,6.
Да, 3-ю стадию (Deskew) разумно включить в обе такие программы - так наиболее гибко.

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

Цитата:

Если я правильно понял, большинство из вас използуют СТ, что бы подготовить файлы для DjVu. Поетому и заменили CCITT – из-за проблемов с Painshop.

Мои пять копеек: я всё еще использую 7-й FineReader, который не понимает LZW, но прекрасно понимает G4. Ну и соображение размера файлов тоже, конечно, имеет значение (я имею привычку сохранять обработанные сканы, подготовленные к сжатию в djvu). Так что я тоже предпочел бы, чтобы черно-белые страницы выводились в G4.

monday2000


Цитата:

Хотя, справедливости ради, я не пробовал ещё ни одной такой книги обработать.

А вот у меня большинство таких (фотографии "в лист"). И, честное слово, идеология их обработки в СТ меня вполне устраивает.


Цитата:

В СК однозначно было надо - т.к. они сбивали распознавание контура текста и вообще визуально затрудняли обработку

Ну и в СТ то же самое.


Цитата:

Для случая одиночных сканов есть ещё вариант - как избежать разделения программы на 2: можно, после отрезания ошмётков, на последующих стадиях просто не показывать их

Так они же и не показываются на этапах поворота и поиска полезной области.

Tulon


Цитата:

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

У меня сейчас максимум -- 48, причем это значение -- вполне рабочее. Но вообще-то я согласен с monday2000: доступный диапазон в идеале должен быть избыточным, т. к. иногда удобно идти не от нуля, а от некоего заведомо завышенного или заниженного значения, постепенно приближаясь к приемлемому.

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

В который раз приходится объяснять, что СТ - это инструмент для тех, кто не хочет заморачиваться. Отсканировал, прогнал через СТ, собрал в DjVu - все. Если СТ будет заставлять таких людей заморачиваться, они просто не смогут / не захотят им пользоваться. А поскольку более простой альтернативы нет, эти люди вообще не будут сканировать книги. Что же касается опытных книгосканирователей - они и без СТ не пропадут. Устраивает СТ - пользуются им. Не устраивает - пользуются СК или BR.

Мне непонятна и неприятна критика лично от вас. С одной стороны, вы практически не используете СТ, что видно например по этой цитате:

Цитата:

Для случая одиночных сканов есть ещё вариант - как избежать разделения программы на 2: можно, после отрезания ошмётков, на последующих стадиях просто не показывать их

Как можно было не заметить, что они и так не показываются и не учитываются на стадии рамки контента?
Получается, что вы больше времени потратили на высказывание неудовлетворенности в отношении СТ, чем в попытках с ним разобраться.
Второй момент: хотите что-то поменять в СТ - возьмите и поменяйте, вы же программист в конце концов! Для кого я исходники открывал? Не знаете Qt? Ну так прочтите соответствующую книгу. Я между прочим до СТ тоже с Qt не работал. И в обработке изображений не разбирался. И в математике вряд-ли я больше вас соображаю.

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

Tulon

Цитата:

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

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

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

Добавлено:
Tulon

Цитата:

С одной стороны, вы практически не используете СТ

Да, ранее не использовал - потому что он ИМХО уступал СК, и вообще был практически бесполезен. Но, слава богу, СТ стремительно прогрессирует - и теперь уже я пытаюсь его освоить.

Цитата:

Второй момент: хотите что-то поменять в СТ - возьмите и поменяйте, вы же программист в конце концов!

Нет, я не полезу в СТ. Не до этого мне.

Цитата:

По этой же причине я стал реже бывать на форуме и реже писать сюда. В будущем видимо буду еще реже это делать.

Такова жизнь - не всё в ней приятно. Мне тоже всегда неприятно кого-либо критиковать - но часто это необходимо. А знали бы Вы, как, к примеру, унизительно (и даже оскорбительно) мне было делать Пособие по Кромсатору. Вы просто взялись за решение очень тяжёлой проблемы - потому и так трудно морально. В немалой степени тут и СК "виноват" - он успел здорово дискредитировать идею программы по сканобработке. Но Вы молодец - уже сейчас СТ способен зачастую заменить СК. Более точно - теперь можно всегда начинать обрабатывать сырые сканы в СТ - и по необходимости дорабатывать их в СК после СТ (например, ластик - Auto Clear). Правда, в общем случае (когда есть полутоновые картинки) сам СТ не подойдёт - а только СТ-anagnost96 + ST GreyText.

anagnost96
У меня такой вопрос по поводу Вашего патча: что, если делать вывод различных категорий сканов (цветной/серый, только текст, только изображения) в отдельную папку в папке out? Т.е. каждую категорию - всегда выводить в свою папку внутри out (даже когда режим не "Смешанный"). Тогда было бы проще - не надо будет вручную изымать из out соотв. сканы - чтобы сделать затем вывод другого вида сканов туда же.
И, как насчёт сделать вывод "только текст (в режиме серого)"? Реально ли?

Добавлено:
Tulon

Цитата:

Как вы бы отнеслись к разделению стиральной машины на два агрегата - один стирает, другой выжимает?

Некорректная аллегория: стирка и отжим не нуждаются никогда в переставлении местами или вставке между ними иных стадий. Но даже в стиральной машине есть цикл "только отжим".

Добавлено:
Tulon

Цитата:

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

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

Tulon
Нет желания сделать просто чтобы выделять картинки в оттенках прямоугольниками вручную сквозным методом по всем страницам книги? Быстро и удобно. Где надо - парочкой прямоугольников со слиянием зон. Где непрямоугольные картинки. Это было бы интуитивно понятно и просто в реализации. И чтобы они сразу по ходу вырезались на диск в соответствующие *.sep.tiff рядом с бинарным. И обеспечить возможность регулировать порог авторазделяемых зон. А также работу напрямую с csepdjvu.exe и кодировкой через djvm.exe. Почему бы ScanTailor'у не быть GUI и инструментом полной обработки и сжатия, а не очередной промежуточной утилитой-недоделкой?

VidelSamogO
А вам не кажется, что ваша характеристика отличного программного продукта, особо отмеченного сообществом open-source, способна подавить любое желание, даже если бы оно и было? Вы, видимо, минимум 7-Zip написали..

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

StanFreeWare
Любезный. Учим правила общения в человеческом обществе. Вопрос был адресован не вам.

Добавлено:
Tulon
Примазаться рыпается.

VidelSamogOюноша у Вас с лексиконом проблемы
Цитата:

утилитой-недоделкой,Учим правила общения в человеческом обществе - рыпается!!!

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

VidelSamogO
Всем Junior Members полезно перед тем как что-то писать: подумать хотя бы 5 минут (заодно и горячая кровь поостынет), посмотреть в профиль человека которого так хочется облить

VidelSamogO

Цитата:

Вопрос был адресован не вам.

А что, в Интернет-форумах нельзя отвечать не тем, кому адресован вопрос? А зачем тогда Вы написали свой вопрос к Tulon здесь в топике - написали бы тогда ему в ПМ. Где логика?

Я собачиться здесь не собираюсь. Я задал вопрос разработчику. Это ясно видно из контекста. Вопрос дельный. Не допускающий разночтений в плане адресности. Всех остальных касающийся мало.

Насчет коррекции геометрических искажений - как считаете, имеет ли смысл при фотографировании книги со штатива при использовании простейшего фотосканера - недавно упомянутого на форуме инфанаты - разработать методику коррекции искажений макросъемки, базирующейся на предварительном фотографировании тестовой страницы (сетки).
По этой фотографии некая программа пусть создает набор корректирующих преобразований для данного объектива на данном расстоянии до цели (по заданной сетке это по-идее сделать проще, чем по произвольной странице книги) и применяет их ко всем фотографиям страниц ДО обработки в СТ (или нулевым шагом СТ)?

StanFreeWare

Вы имеете в виду бочкообразные искажения? По моему опыту, они при правильном методе съемки ничтожны и не идут ни в какое сравнение с теми видами искажений, которые в принципе никак не нормализуемы и, главное, от объектива не зависят. Например, позиция фотика на штативе не является постоянной величиной, а при малейшем повороте относительно плоскости листа его прямоугольные пропорции хоть немного, да нарушатся. Еще более важно, что прижатие страниц стеклом неодинаково у обреза и у корешка и опять же зависит от многих факторов. Так что я не представляю, как можно говорить о каком-то универсальном наборе корректирующих преобразований.

anagnost96
Да, я имел в виду бочкообразные искажения. Спасибо за пояснения.

Tulon
1.
Объясню еще раз зачем нужно определение всей полезной области в границах исходника.
Вот есть фото страниц книги. Расстояние фотик-книга скачет. Я обрезаю в СТ по границам полезной области, вывожу без выравнивания страниц полями, и в XnView задаю выровнять ширину всех картинок.
(Просил-просил Вас на натахаус-форуме сделать такую возможность в СТ - Вы никак.)
Затем я гружу эти выровненные картинки обратно в СТ. И при переопределении полезной области, т.к. элементы касаются границ картинки, она определяется неправильно. Т.е. вот мне щас, например, для 1200 страниц руками границы поправлять.
А там поджидает другая засада. Когда я руками поправляю границы полезной области (растягиваю ее до краев), при выводе возникают линии на границе полезная область - скан. То что Вы успешно побороли для других случаев. И мне эти 1200 стр еще руками редактировать: линии стирать.

По-моему на англоязычном СТ-форуме люди как раз фоткают книги. Мне не верите - можно там это обсудить. Насколько это важно и нужно.

2.
Начал пользоваться Вашими зонами. Заметил следующее. Когда граница серой зоны не определяется точно, то как правило (у меня 95% случаев) выводится черная фигня с точными контурами целевого криволинейного объекта.
Когда мы ставим многоугольник - то он неизбежно захватывает фон-паразит.
Может можно сделать такой тип зоны, чтобы СТ в ней сделал черно-белую бинаризацию, а затем из цветного (серого) оригинала взял те пиксели, которые при бинаризации определились как черные.

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

Что же касается вашего оригинального запроса, а именно возможности масштабировать страницы на выводе не до заданного DPI, а до заданной ширины рамки контента в пикселях, то я признаю, что фича была бы полезной, но:
1. Я плохо себе представляю, как эту фичу можно интегрировать с существующей системой.
2. Есть много более приоритетных задач.


Цитата:

Начал пользоваться Вашими зонами. Заметил следующее. Когда граница серой зоны не определяется точно, то как правило (у меня 95% случаев) выводится черная фигня с точными контурами целевого криволинейного объекта.

Давайте пример.


P.S:
По поводу фич реквестов могу сказать, что на данном этапе просить фичи - дело совершенно бесполезное. Разработка идет черепашьеми шагами. Я устал и немотивирован. Ну и естественно не закончив одно, нельзя браться за другое. У меня и так на данный момент три начатых и незаконченных направления.

Цитата:

Наверняка есть способ проще

Если достаточно задания симметричных рамок в пикселях, то можно использовать Пакетное преобразование (F3) - Расширенные настройки - Рамка в FastStone Image Viewer.

Цитата:

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

Вот этого то я и боялся. Неужели так со всеми талантливыми проектами? Начали за здравие... "За полчаса написал ещё одну..." А может это потому, что не видно простых путей радикального улучшения? Путей, реализуемых на раз. Кризис... Ну что ж. Подождём. У меня тоже проект не идёт. Да ещё чуть квартиру сегодня не сжёг. Чужую... Фух. Весь в струпьях вонючего пластика.

Попробывал три версии программы, и старую и новую, и среднюю. Хочу высказаться. Неудобная прога, но это можно исправить. Мешают механизмы автоматизации. Привык ручками делать, как в ФР, там это удобно. Но вот отсканишь журнал, к примеру, цветной или с оттенками серого, а ФР начинает страницы под разными углами вращать, просто беда. В остальном очень всё удобно, если сканы черно-белые.
Вашей программе не хватает этого, не удобная она. Вернитесь пожалуйста назад, попробуйте переоценить задачи. Безполезен в ней механизм автоматического определения полезной области. Полезная область выбираеться один раз на четвертой-пятой странице, затем просто переноситься на остальные, кроме титульной, ну и последней. Поэтому, мне кажеться нет смысла в опции "Макет страницы".
Компенсация наклона несомненно нужна, это плюс. Но в автоматическом режиме принесет тоько зло, ибо привык сканировать аккуратно, ровно. На выравнивание уйдет много времени, если автомат вмешается.
Конечно в сравнении с Кромсатором, она намного выигрывает.
Вы, бесспорно человек талантливый, и у Вас всё получиться. Хочеться сказать спасибо за ваш труд.
С уважением,
pusto1

Это если слушать каждого и реализовывать все, то получится без преувеличения второй ScanKromsator. Как по мне программа сейчас просто класс. Аккуратненько сканируем, а не фоткаем. Она ж называется не photo tailor. И в программу, уделяем установке параметров до часа времени и дальше фильм смотреть. Просматриваем через вьювер какой-нибудь, отмечаем страницы, которые нужно подправить, и снова в ST. Все-таки произвольной прямоугольной области не хватает, ну и ластика.

Tulon

Цитата:

Я устал и немотивирован.

Возьмите тайм-аут со Скан Тейлором. Глядя на программу, я даже удивляюсь, когда это Вы успели проделать такую прорву работы (со Скан Тейлором).

На мой взгляд, сейчас как раз такой момент, когда Скан Тейлор впервые в жизни достиг состояния "реально полезная программа" - т.е. окончательно выйдя из статуса "прототип" (правда, не сам Скан Тейлор, а лишь связка Скан Тейлор-anagnost96 + ST GreyText, но это уже не важно).

Так что сейчас вполне можно и отдохнуть - важная промежуточная цель наконец-таки достигнута.

Добавлено:

Цитата:

По поводу фич реквестов

Их возросший поток ИМХО указывает на рост популярности-совершенства программы.

У меня ещё такая идея: нельзя ли выложить СТ-anagnost96 на оффсайт СТ? Чисто для удобства. Кстати, предлагаю для краткости называть СТ-anagnost96 "СТА" - а то как-то длинно писать.

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

Цитата:

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

Папка out создается при создании проекта, а не при выводе. Попробуйте воспроизвести, создав новый проект с этим multipage tiff'ом.