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

bolega
Предлагаю отказаться от термина "резак", обозначающего синюю/малиновую "режущую" линию. Это имхо неверный и сбивающий с толку термин.

По смыслу и логике, "резак" более соответствует понятию "блок распознавания" (как в Файнридере) - т.е. Файнридер при распознавании текста сам расставляет блоки распознавания (аналог Draft Kromsate), причём тоже не всегда 100%-но верно (как и Draft Kromsate). (Так что, видите, bolega, как вредно не иметь установленный у себя Файнридер

).

Но, даже когда Automargins выключен (или одна из его подгалок) - даже в этом случае "резак" вовсе не режет по тому месту, где он находится - он лишь задаёт в этом месте соотв. границу контура голого текста, к которой будет прибавлена величина Book -> H.Gap value (или V.Gap value), и только там, в том месте и пройдёт реальная линия отреза.

Так что для того, чтобы "резак" действительно отрезал по тому месту, где он находится, необходимо не только отключить соотв. ему подгалку Automargins, но ещё и установить в ноль соотв. величину добавляемого поля - Book -> H.Gap value (или V.Gap value).

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

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

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

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

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

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

Теперь такой важнейший вопрос: что именно обозначают расставленные Draft Kromsate'ом резаки? Варианты:

1). ТОЧНО контур голого текста (по мнению Draft Kromsate).
2). Контур "рабочей области", где-то внутри которой находится контур голого текста, причём между обоими этими контурами в идеале лежит только белое пространство, без каких-либо чёрных объектов (кроме, конечно, спеклов).

Какой из этих вариантов правильный?

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

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

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

bolega
Вот Вам уже писали об Automargins то же, что я тут только что написал:

Цитата:

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

И Вы в ответ предложили примерно такое же решение, что я тут предложил:

Цитата:

Но Вы подали мне одну идею: если резак двигать, например, с нажатым Shift, то Кромсатор автоматически бы сбрасывал бы под-опцию automargins, всё ж меньше щёлкать.

Только я предлагаю уже сделать блок и двигать так одну из его сторон.

И ещё такой важный вопрос: а зачем вообще нужна общая галка Automargins? По-моему - абсолютно не нужна, и только путает и сбивает с толку. Вполне достаточно подгалок Automargins. Ведь вместо того, чтобы сбрасывать общую галку Automargins, вполне достаточно посбрасывать все подгалки Automargins - эффект будет тот же. Или я чего-то не знаю?

И, кстати, сами подгалки Automargins пусть лучше приобретут противоположный смысл: пусть они станут "подгалки Manual margins" и будут по умолчанию выключены.

И ещё можно сделать такой вывод об алгоритме обрезки:

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

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

3). И только на этом этапе к сканам навешиваются заданные юзером Book -> H.Gap value / V.Gap value.

Интересно, я правильно предположил? Просто я раньше как-то не задумывался о существовании п.2 в этом алгоритме - только сейчас понял, что без него не обойтись. Или я неправ?

bolega По мере знакомства с Кромсатором возникают новые идеи относительно улучшения его интерфейса.

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

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

Заодно станет, наконец-таки, видна панелька с инфо файла.

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

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

И потом - на большинстве вкладок юзер лишь ОДИН раз при использовании Кромсатора выставляет некие параметры - какая нужда всё время держать вкладки на переднем плане?

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

1. Оказалось, что имеется два похожих поля: Pages -> Spec. gaps (со значениями типа Left - Right - Top - Bottom) и Book -> Spec. gap (со значениями типа (0 - 500 (шаг 10))). Очень похоже и сбивает с толку. Как я понимаю, они тесно логически связаны друг с другом? Сама собой возникла мысль о том, что это нерационально и сбивает с толку - разносить Pages -> Spec. gaps и Book -> Spec. gap по разным вкладкам, да ещё и давать им столь схожие имена - будто Вы нарочно поставили цель сбить юзера с толку и запутать его.

2. Думаю, вкладку Options 2 вообще следует ликвидировать - Элементы Text sensitivity перенести в ближайшую окрестность Automargins, а Cutters state перенести на панель управления резаками.

Я бы слил воедино вкладки Pages, Book, Files, Options, Options 2 - думаю, разделение их довольно искусственно.

Отдельно я слил бы воедино вкладки Convert, Quality, ликвидировал бы кнопку Gray enhance..., а содержимое того окна, которое по ней вызывается (Gray image enhance) добавил бы в объединение Convert-Quality.

И вообще я бы поизбавлялся от обеих кнопок, вызывающих окна с элементами управления, перенеся всё это на большие вкладки "супервкладки" - такие кнопки сильно сбивают с толку и непрактичны - Exclusive page options, Gray enhance... .

Т.е. лучше вкладки (причём большие, а не как сейчас), чем кнопки, вызывающие окна с мелкими вкладками. Например, нажав на кнопку Gray enhance... и войдя в окно Gray image enhance, мы однако не избавляемся от зависимости - а что там выставлено на вкладке Quality?

- а стоит ли там галка Enhance image?

Так вот, такая галка в принципе обязана быть в окне Gray image enhance, а вовсе не на вкладке Quality - т.е. окно Gray image enhance должно быть максимально независимым от других окон-вкладок (я бы сказал - подобная зависимость характерна для кромсатора, это имхо просто бич интерфейса кромсатора). Это напоминает "программирование с goto".

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

Вот сейчас из-за тесноты надо часто гадать - а что означает, например, данное поле ввода? Пример: вкладка Files ниже надписи Start from/step находятся 2 соответствующих им поля ввода. Вот и гадай, что это за такие поля ввода, к чему они относятся. А должно быть так: Start from [поле ввода] step [поле ввода] - но разве можно так сделать сейчас из-за той тесноты, которая царит на вкладке Files? Вот так и возникают нелепейшие проблемы с пониманием юзерами работы Кромсатора.

И вообще это можно сказать про вкладку Files: должно быть так: <надпись> [поле ввода], а сейчас сверху надпись, а под ней, или где-то сбоку внизу - её поле ввода... Но оно и понятно: на такой крохотулечной вкладке не разгуляешься - выход один - сделать 1-2 большие по площади окна и там по-человечески разместить все элементы управления с нынешних вкладок. Там Вы сможете, наконец, позволить себе то, что не можете позволить сейчас ни на одной вкладке, кроме Pdf - элемент "рамка" (ну такой серенько-беленький "втопленный" контур) - логически очерчивающий связанные элементы.

Добавлено:
bolega
Ещё простая просьба: подправьте, пожалуйста, по-человечески элементы управления в Task options settings - ну что это такое - всё пляшет вкривь-вкось, слово "TIFF" полуобрезано и т.п.

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

Добавлено:
bolega
И ещё такой вопрос (я уже писал, но вроде бы ответа пока не было):
Зачем вообще нужна кнопка "Apply to current"? Как я понял, она просто ставит жирную зелёную галочку на том файле в списке, на котором стоит фокус в данный момент. Причём повторное нажатие на эту кнопку вовсе не сбрасывает эту галку, как, казалось бы, было бы логично.

Если жирную зелёную галочку можно поставить/снять мышью - то зачем тогда нужна эта кнопка? Может, лучше её выкинуть?

Меня всё время терзает мысль,

что интерфейс Кромсатора можно упростить в 1,5-2 раза как минимум без всякой потери функциональности. Для этого потребуется мужество, чтобы кое-что даже и просто выкинуть из интерфейса. Но основное, что надо саму "глубинную концепцию" интерфейса пересмотреть, сделать его ИНТУИТИВНО-ЯСНЫМ - то, чего сейчас и в помине ведь нету, а я верю, что этого можно достичь.

Добавлено:
Такая мелочь: Quality -> Gray enhance... -> Contrast -> Brightnes исправьте на "Brightness".

Кстати, единственное, в чём я ВООБЩЕ не смог разобраться - это работа с Gray image enhance - из того, что есть, ни черта не удалось понять. Да и вообще надо для начала понять - что такое "контраст"? Это когда ставится порог, и всё, что светлее - светлеет, а всё, что темнее, темнеет? Как работать с гистограммой, что это за зверь?

Самое непонятное - что такое "Correct low contrast" и чем оно отличается от Contrast на вкладке Contrast? Каков принцип работы клинера? Ну и sensitivity - очень смутно представляю себе.

Что значат на вкладке Quality - Smooth, Blur, Sharpen? Впечатление такое, что это первоначальный вариант Gray image enhance, который просто забыли убрать.

Нельзя ли коротенько так и по-простому описать основные элементы управления на Gray image enhance? Сам я точно не смогу тут разобраться, и даже экспериментальным путём. Самое интересное - это вкладки Background cleaner, Contrast, Histogram - остальное можно пока не объяснять.

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