Smokeer Цитата: По-моему подход должен бьіть обратньім:
создать програму в которой можно провести полную обработку сканов.
Такая программа уже есть - это Кромсатор.
Не буду повторятся, почему надо разделить его на части. Хорошо бы сделать всего 2 программы: Kromsator Lite и Grey enhancer. И применять их с сканам в любой последовательности - кому как нравится. Так будет гораздо удобней и практичней. Можно, например, конвертировать сырые сканы Grey->BW (с улучшением) в Gray enhancer
до Kromsator Lite (т.к. BW кромсаются быстрее, чем Grey - простое решение проблемы
ghosty, да уже и других), а можно после (традиционный подход). Последовательность использования этих 2 программ будет сильно зависеть от вида сканов - смотря как проще с данными сканами. Знаете, в чём преимущество "латинских" языков перед "китайскими"? В том, что в 1 случае - 26 букв, а во 2 - тысячи. Но всё оттенки смысла лучше передают именно латинские языки (на все оттенки смысла иероглифов не напасёшься
). Так что нынешний Кромсатор - это в прямом смысле "китайская грамота".
Melirius Цитата: А Punto Switcher или ещё какая клавиатурная "догонялка" не стоит?
Да, стоит! Вот спасибо! Попробую отключать. А то этот глюк наблюдается и дома, и на работе - т.е. на 2 разных компах.
Добавлено: bolega Я обратил внимание на то, что фактически
совершенно непонятно - а когда именно нужно сбрасывать соответствующую подгалку Automargins при просмотре и анализировании результатов DK? Вот Вы везде пишете что-то такое:
Цитата: Вы плохо представляете себе назначение резаков. Основное их назначение - отрезать мусор, но не определять края страницы (поэтому резаки и не обязательно ставить вплотную точно к тексту, а иначе выставлять их было бы мучением, да и невозможно это бывает при перекосе страницы). И только когда кромсатор не может самостоятельно правильно это сделать, только тогда резаку можно придать дополнительную функцию (что и сигнализируется теперь изменением цвета резака).
Эта информация совершенно двусмысленная и ничего толком не объясняющая. А что значит
"когда кромсатор не может самостоятельно правильно это сделать"? Это можно понять двояко. Варианты "понимания" такие:
1. При просмотре результатов DK мы видим на каком-то скане: ага, вот резак неправильно встал после DK, отсекает кусочек текста - значит, подводим его как положено (впритык к тексту, но чтобы текст не отсекал), и делаем резак малиновым. Но совершенно непонятно - резак следует делать малиновым во
всех таких случаях (когда он неправильно был установленом Draft kromsate'ом (подведя его как нужно) или же в большинстве случаев достаточно не делать резак малиновым, а просто подправить синий резак, чтобы он не отсекал текст, и всё?
2. Имеется в виду более сложное понятие - когда в Result view мы просматриваем уже нарезанные листы и видим: вот на этом листе отсёкся при Process кусочек текста - и поэтому нужно вернуться к скану, сделать данный резак малиновым, подправить его "как положено" и перекромсать по новой.
Так что, как видите, наблюдается полнейшая неясность - а когда, собственно, делать резак малиновым? По какому именно критерию тут ориентироваться? Какой из этих 2 вариантов правильный? Подозреваю, что второй.
В связи с этим я подумал: а что, если вообще отказаться от концепции Automargins (т.е. сделать резаки всегда "Automargins = on")? Ведь эта такая ужасно неудобная вещь. Хотелось бы так:
Делаем DK, потом проходим по сканам и вручную приблизительно подправляем резаки, после чего запускаем кромсание. И всё. И никакого геморроя со снятием подгалок Automargins. Причём тут имеется в виду, чтобы резаки подправлять именно приблизительно, т.е. для коррекции результатов DK, а вовсе не
точно, для коррекции последующей работы Process.
Кроме того, в этой связи не только Automargins сложен и труден для понимания юзерами. Ещё и значения Text sensitivity лично мне, к примеру, совершенно непонятны - ну откуда мне знать - на сколько единиц повысить чувствительность Automargins, чтобы DK стал точнее работать? Дайте, что ли, какие-то предельно недвусмысленные рекомендации по значениям Text sensitivity. А иначе что толку от присутствия в программе Text sensitivity? Надеяться на то, что среднестатистический юзер станет ставить эксперименты и, DK-разметив одну и ту же книгу 3-4 раза
с разными значениями Text sensitivity, всё-таки выберет правильное значение Text sensitivity и DK-разметит её уже окончательно?
Да никто и никогда так делать не станет - разве нет? Так что и Text sensitivity по большому счёту можно убрать из программы. Это всё равно, как если бы в Файнридере был ползунок "точность распознавания"
и юзеру предлагали бы: "если Вам не понравилось, как текст распознался, то повысьте чувствительность распознавания и распознайте повторно".
Отказаться от Automargins можно прямо сейчас. Как, спросите Вы? А вот как: пусть после DK юзер проходит по сканам и вручную приблизительно подправляет синие резаки (т.о. корректируя результаты DK). Далее запускаем Process. При этом Кромсатор вычислит среднестатистические размеры и сам навесит поля - а для этого Process предварительно
точно распознает контур голого текста. Так вот, весь трюк тут в том, что погрешности точного распознавания Process'ом контура голого текста (т.н. "оконтуривание") скомпенсируются такими принудительными операциями:
1). Приведение всех результирующих сканов к среднему размеру.
2). Навешивание к этим сканам полей рекомендуемого Вами размера (в зависимости от DPI сканов).
Причём вторая процедура тут гораздо более "компенсирующая", чем первая. И, если задать навешиваемые поля именно рекомендуемого размера, то они окажутся достаточно большими, чтобы скомпенсировать погрешности оконтуривания.
Об этом, кстати, не раз и не два уже говорилось. Новизна идеи тут в том, что ведь всё это даёт возможность вовсе отказаться от Automargins. Главное - чтобы навешиваемые поля были достаточно большие.
Но Вы скажете - а что же всё-таки делать, если и это не поможет и всё равно текст будет отсекаться? Как же тогда отказаться от Automargins? Я предлагаю - ради именно для таких случаев - не выкидывать полностью Automargins из интерфейса. А сделать так: сейчас убрать Automargins из интерфейса. И потом сделать Automargins как некий специальный, особым образом вызываемый (в исключительных случаях) инструмент. А не так, как сейчас - когда Automargins - это ходовой инструмент и всё время на виду и им предлагают пользоваться постоянно. Нет, надо, чтобы пользоваться им предполагалось лишь в исключительнейших случаях.
Конечно, полный отказ от Automargins предполагает решение проблемы ОВ-символов (одиночных выступающих символов). Или хотя бы снижения её остроты до приемлемого уровня. Это, надеюсь, дело будущего. Наверное, тут можно кое-что сделать. По крайней мере, тут у Вас есть одна железная зацепка: если после DK юзер двигает резак (т.е. вообще двигает, хоть как хоть куда), то это должно быть сигналом Кромсатору: ага, с этой стороны скана DK сработал неточно, надо для этого резака Кромсатору увеличить некую внутреннюю переменную - аналог Text sensitivity (а может быть, и вообще программно оценивать бледность скана, разрешение и т.п. и на основании этих данных подбирать её значение), либо применить OCR-подобное сложное определение ближайшей окрестности данной стороны контура голого текста. Посмотрите на GPL OCR-проект
http://jocr.sourceforge.net/ - может, сможете что-то оттуда позаимствовать.
Добавлено: bolega Слушайте, меня осенило: а ведь есть совершенно простой и железный способ вообще полностью отказаться от Automargins! Заодно и практически решим проблему ОВ-символов!
Я Вам уже очень давно и неоднократно предлагал разбить кромсание как бы на 2 ступени: "предварительное" и "окончательное". Поясню: представим себе ситуацию, что вот мы видим в Result view, что на данном скане при кромсании снизу отрезался номер страницы. Сейчас нам надо вернуться в главное окно, подвести резак, сбросить подгалку Automargins и перекромсать по новой данную страницу. А я предлагаю другое: не выходя из Result view, нажимаем Alt и двигаем стрелой скан вверх до тех пор, пока из-за нижней кромки окна не появится отрезанный номер страницы. Сейчас это невозможно - снизу "выедет" не отрезанный номер страницы, а молоко. То есть сделайте, чтобы сканы кромсались "предварительно", с неким хорошим запасом по всему периметру, а мы потом в Result view при необходимости вот так подправляли, прежде чем принять как окончательное.
Вы что-то говорили, что так сделать очень трудно, т.к. скан претерпевает массу сложных преобразований - deskew и т.п. Может быть, нужно просто сделать достаточный "запас" по всему периметру? Как бы там бы ни было, а всё равно - это тысячекратно более лучший способ, чем сброс подгалок Automargins и повторное перекрамсывание. Конечно, предлагаемый способ требует, чтобы все сканы были обязательно предварительно приведены к усреднённым размерам (что уже есть сейчас). Кроме того, скорее всего, предлагаемый способ потребует, чтобы можно было прямо в Result view по месту увеличить размер нарезанного скана (за счёт запаса) (это прийдётся реализовать).
Просто очень хочется уйти от Automargins, которые являются слишком неудачным решением (точнее, слишком заумным). Сделав Automargins, Вы пошли путём больших софтовых фирм, забывая - что Вы один и силы Ваши ограничены и поэтому Вы не можете использовать их "академические" пути (внесение поправок в алгоритм Process перед его запуском вместо простой ручной правки уже его результатов, что я предлагаю) - поэтому Вам лучше выбирать физически посильные решения.
Цитата: 4. После полной проработки сканов задания сбрасывать автоматом размеры страниц на -Fixed-
Я то же самое просил - сделайте, пожалуйста. Кроме того, предлагаю Вам вообще взять на вооружение концепцию пакетов Файнридера (и ещё DEE 5.1 так работает - с папками, а не с отдельными файлами). Для этого нужно добавить опцию открытия папок, а не только по одному скану. Представим: открываем мы папку со сканами. Сканы тут же загружаются, и автоматически в данной папке создаётся папка "Out" и Task-задание, куда автоматически записываются любые изменения опций (а сейчас надо вручную запоминать -
очень неудобно). Юзера же лишить возможности открывать Task-задание и выбирать путь к Out-папке - пусть работает с пакетом целиком. Так будет проще, да и часто забываешь выбрать папку "Out" и Process на это ругается.
Главное - применить имеющиеся силы и средства с максимальным толком - и тогда эффект будет гораздо сильнее, чем сейчас от нынешнего Кромсатора, который всех пугает и отталкивает от "книгоделания", проталкивая мысль, что якобы всё это "неимоверно сложно". 
) А вот ресамплинг который работает в пятеро дольше чем всё остально вместе взятое...