monday2000
Silver Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
bolega
Цитата:| При кромсании резак режет в самом что ни есть прямом смысле. |
То есть ПРЯМО по "тому месту, где находится"? Я вот представлял, что (в случае сброса нужной подгалки Automargins) резак режет не по "тому месту, где находится", а по "тому месту, где находится" + смещение за счёт усреднения размера скана (как Вы мне только что подтвердили) + Book -> H.Gap value / V.Gap value.
Даже если мы сбросим в ноль Book -> H.Gap value / V.Gap value - то всё равно остаётся усреднение размеров сканов, которое и сдвинет хоть немного реальную линию реза. Правильно? То есть как ни крути, а резак вроде бы НИКОГДА не режет прямо там, где стоит. По крайней мере, чисто формально это так - gap прибавляется всегда, даже нулевой.
Знаете, кажется я уже об этом упоминал - нарезая скриншоты для Пособия, я обратил внимание на некую явную "избыточность функциональности" редактора Result view. То есть, если на него "посмотреть издалека", то он больно похож на само главное окно - как по смыслу, так и по действиям (я имею в виду самый общий, концептуальный смысл).
Отсюда родилась идея: хорошо бы вообще со временем (не сейчас, конечно) отказаться от Result view, т.е. ликвидировать его, а его функциональность перенести в главное окно, умело "вплетя" её туда.
Эту идею я могу так проиллюстрировать: представьте, что мы в Файнридере распознали сканы, и сразу после этого само запускается некое окно постобработки сканов, сильно похожее на имеющийся интерфейс программы - где можно подправить результаты распознавания, например. Неразумно и даже дико как-то, правда? Налицо явная избыточность интерфейса Кромсатора.
Идеал интерфейса - сделать его до такой степени интуитивно-ясным, чтобы вообще исчезла потребность в документации по Кромсатору. Думаю, что этого можно достичь в значительном приближении, и не так уж много для этого потребуется трудозатрат (гораздо меньше, чем Вы сейчас расходуете), нужно лишь немного воображения и смелости (пополам с решимостью) радикально поменять интерфейс, не цепляясь за то, что есть, т.е. не ограничиваясь мелкими поправочками. Ни для кого не секрет, что тот интерфейс, который есть сейчас у Кромсатора, почти что просто никуда не годится (будем честными  ). Но ничего - это как раз-таки можно исправить, надо просто этого захотеть. 
Что толку, что появится (не важно кем написанная) документация по Кромсатору - всё равно плохой интерфейс резко сужает круг пользователей, хоть есть к нему дока, хоть нету. Вот Вам и разгадка потока разгневанных писем из разных стран мира (о чём писалось на КпНемо). Имхо практически не в отсутствии доки тут было дело, а именно в плохом интерфейсе. Да и я тогда воспринял Кромсатор резко негативно, как теперь понимаю, в основном из-за плохого интерфейса (который новичков просто сводит с ума), а уже потом из-за чего-то там ещё. Помню, как мучительно тыкался в эти мириады кнопочек, галочек, чекбоксов, всякий раз бросая это дело с нулевым итогом (а другие, видимо, ещё и слали гневное письмо при этом ).
Так что все думали, что главная проблема Кромсатора - в отсутствии доки, а оказывается (если копнуть глубже), что нет - главная проблема - плохой, я бы сказал, просто никуда не годящийся интерфейс программы (именно отсюда идут все юзерские основные беды и проблемы с Кромсатором). Отсюда вывод: доку пока лучше не пишите и также новые фичи пока не внедряйте, не тратьте время и силы неэффективным образом, а бросьте все силы на самое главное - на глубокую переработку интерфейса. Наверное, даже вообще потребуется пересмотреть саму концепцию программы, ход её работы, используемые логические конструкции и т.д. Жаль, почти никто тут Вам пока не может помочь советом - имхо мало кто знает Кромсатор действительно досконально (во всех мелочах).  Тем более тут ещё потребуется опыт обработки разнообразных книг.
Знаете, у меня лично (в процессе написания Пособия) часто возникало такое ощущение, что Вы, в ряде случаев, вместо того, чтобы пойти простым и понятным путём (в плане интерфейса), почему-то шли каким-то изощрённо-трудным, невероятно-запутанным путём, проявляя чудеса фантазии в деле изощрённого и какого-то "умышленного" запутывания интерфейса (очевидно, тратя при этом огромное количество времени и сил) там, где всё было относительно простым и ясным, где никогда и не подумаешь, что кто-то ухитрится запутать на ровном месте это нечто простое и ясное. Потому и доки так долго не было, кстати - а ну-ка, написать доку к такому монстру!
Вот Вы пишете, что не хотите улучшать интерфейс, потому что это неинтересно, сложно и т.д. А что делать!? Вы уж заставьте себя, пожалуйста. Мне вот, например, тоже ОЧЕНЬ не хочется писать Пособие по Кромсатору, да ещё и вот таким способом - через одно место. (Но я думаю, что это нужно делать, т.к. множество людей его использует во-первых, а во-вторых, наличие документации по Кромсатору открывает дорогу к написанию универсальной методики книгоделания. И тут хочется понадеяться на наших спецов, что они найдут время и желание и напишут такие методики. Я думаю, надо рассмотреть 2 случая там: "экспресс-метод" для дешёвого-плохого сканера и "профи-метод" для дорогого сканера.)
Попробуйте когда-нибудь сесть за компьютер, открыть Кромсатор и подумать: "а как можно сделать интерфейс проще, интуитивно-яснее, эргономичнее". Явно Вы этого никогда не делали. Идеально было бы "перепахать до основания" интерфейс Кромсатора, ограничиться мелкими улучшениями имхо нельзя, точнее - недостаточно.
Я думаю, что пока интерфейс Кромсатора столь несовершенен, то по мере добавления новых фич Кромсатор будет всё больше заходить в тупик - всё меньше и меньше людей будут им пользоваться (я не про зоны - зоны - это хорошо). Ещё такой момент: посмотрите, какие у Кромсатора "гигантско-ветвистые" контекстные меню, несколькоуровневые. Это имхо тоже неправильно - лучше пусть контекстные меню будут поменьше размером, компактные.
И вообще - имхо следует удалить всякую избыточность в интерфейсе. Это как в мат. логике: есть набор аксиом, из которых потом логически выводятся теоремы. И такой набор аксиом МИНИМАЛЕН, там нет ни одной аксиомы, выводимой из других.
И почему это Вы не хотите от интерфейса резаков отказаться (в пользу прямоугольников)? Ведь совершенно же здравое предложение, изрядно упрощающее интерфейс и работу.
bolega
Читая имеющуюся разношёрстную документацию по Кромсатору, я сделал следующее "открытие": Прошу прокомментировать, подтвердить, или опровергнуть:
Оказывается, в Кромсаторе есть не один, как я раньше думал, а два алгоритма автоматического распознавания макета страницы! (page layout)
То есть, разделение такое:
Алгоритм-1 (кнопка Draft kromsate) - "грубый", "малоточный" алгоритм.
Алгоритм-2 (кнопка Process) - "тонкий", "высокоточный" алгоритм. (это и есть собственно "кромсание").
Схема работы Кромсатора мне видится так: сначала мы загружаем сканы, нажимаем Draft kromsate, и Кромсатор применяет Алгоритм-1 - который относительно "грубый", и цель которого - всего лишь подготовить "входную" информацию для Алгоритма-2 (этакое "унифицированное сырьё"). Этот Алгоритм-1 всего лишь приблизительно "распознаёт", где на скане "рабочая область" с текстом, а где окружающая его грязь + режет сдвоенные сканы, если надо. И, по всей видимости, ставит "резаки" (беру в кавычки, т.к. мы уже выяснили, что никакие они не резаки, а "косвенные задаватели отреза") сразу, как только "заканчивается" грязь (если мысленно двигаться от периферии к центру скана).
Таким образом, основная цель Алгоритма-1 - это распознавание грязи вокруг рабочей зоны, т.е. Алгоритму-1 как бы "наплевать на текст", Алгоритм-1 совершенно не интересуется ни текстом, ни тем более, контуром голого текста. Его интересует только грязь и её "отсечение" (распознавание) и всё. Эту важную особенность следует хорошо понимать.
Алгоритму-1 соответствует включённая подгалка (любого) резака, т.е. если эта подгалка включена, то "резак" определяет одну из сторон контура, "отсекающего" грязь.
Отсюда вытекает железный вывод: обработка Draft kromsate - это ТОЛЬКО распознавание точного местоположения грязи на скане, Draft kromsate'у нет никакого дела ни до текста, ни до контура голого текста.
А вот когда мы получаем "резаки", уже расставленные по сканам (то ли в результате работы Алгоритма-1, то ли после ручной расстановки), то мы запускаем Алгоритм-2 - путём нажатия кнопки Process.
Именно Алгоритм-2 и выполняет "кромсание" - то есть, определяет точно контур голого текста. И при этом ему уже не мешает грязь - т.е. она была уже либо распознана Алгоритмом-1 (Draft kromsate), либо (хотя кто так сейчас станет делать ) мы руками поставили "резаки" (при включённых (!) подгалках Automargins).
Алгоритму-2 соответствует выключённая подгалка (любого) резака, т.е. если эта подгалка выключена, то "резак", как оборотень, меняет свою суть: вместо определения одной из сторон контура, "отсекающего" грязь (Алгоритм-1), он задаёт одну из сторон точного контура голого текста, то есть выступает ручной поправкой неправильной работы Алгоритма-2 (в данном месте).
Т.е. подгалка Automargins переключает резак из режима Алгоритма-1 в режим Алгоритма-2 и наоборот. Таким образом, резак с включённой подгалкой Automargins не учитывается при работе Алгоритма-2 (кнопка Process), и наоборот - резак с выключённой подгалкой Automargins не учитывается при работе Алгоритма-1 (кнопка Draft kromsate).
Я бы даже сказал, что термин "Automargins" - не самый лучший и не самый точный. Лучше было бы назвать как-то вроде "Trash margin recognition / raw text recognition".
И вообще обычно в программах для этого используют радиокнопки, а не чекбоксы - чтобы подчеркнуть наличие 2 взаимоисключающих режимов работы, а у Вас всё выглядит как случай "работает/не работает одна и та же опция" (чекбоксы), что неверно и сбивает с толку.
Вот и получается, что во всех случаях (а их два) "резаки" нужны просто для визуального контроля и подправления неправильной работы обоих алгоритмов (в данных местах), никакого другого смысла в "резаках" нет. То есть "резаки" существуют лишь потому, что оба алгоритма работают не всегда точно (что совершенно естественно).
Кстати, о терминах: "Draft kromsate" можно было бы переименовать во что-то вроде "Auto pre-kromsate" - имхо так понятней.
bolega
Вот поэтому я и предлагаю: отказаться от интерфейса "резаков" и заменить их на прямоугольные зоны - пусть одна такая зона обозначает результат работы Алгоритма-1, а вторая - результат работы Алгоритма-2. С зонами имхо будет и проще и понятнее, чем с "резаками". Про резаки всё равно упорно думаешь, что они режут, хотя на самом деле, строго говоря - нет (имею в виду gap). С зонами не потребуется нажимать Ctrl, чтобы двигать 2 резака сразу (зону, кстати, можно двигать целиком ,что эквивалентно двиганию 4 резаков одновременно), и не потребуется нажимать Shift, чтобы закосить "режущую" линию (просто кликнем на угол зоны, появится грип, за него и потянем, и сторона закосится). Зона - это интуитивно-ясный инструмент, а резаки - нет, даже наоборот, путают сильно они (надо помнить, где какой и т.д.), да ещё и интерфейс усложняют. Если будет 2 зоны по результатам работы обоих алгоритмов, то галка-подгалки Automargins можно будет выкинуть (это как если бы сделать 2 комплекта резаков - 1 комплект для Алгоритма-1, 2-ой - Алгоритма-2, но только где разместить их рельсы? и так там тесно). Подозреваю, что и панель управления резаками можно будет заменить тогда на что-то гораздо более простое, но пока не знаю точно.
bolega
Цитата: Если бы после каждого нашего движения резаком кромсатор принимал его за фиксацию, то это был бы ужас. Т.е. я сдвинул резак, чтобы просто лучше отсечь какое-нибудь пятнышко и при этом резак ещё далеко от текста, а кромсатор возьми и зафиксируй этот порыв как край текста. Так нельзя.
...
Но вы подали мне одну идею: если резак двигать например с нажатым Shift, то Кромсатор автоматически бы сбрасывал бы под-опцию automargins, всё ж меньше щёлкать. |
Почему ужас? Имхо так и должно быть. Если действительно "ужас" (скажем, пересчитываются размеры средние, к примеру) - то это можно программно обойти, т.е. сначала выставляем, а потом, например, одним махом как-нибудь особо фиксируем для всех сканов. Для того я и предлагаю сделать 2 зоны вместо резаков. А как надо - сначала выставить резак на границу голого текста и сбросить соответствующую подгалку?
Ещё такой вопрос: После кромсания по кнопке Process Кромсатор вычисляет средние размеры и подставляет их в поля Book -> Page width [поле ввода] и Book -> Page height [поле ввода] (кстати, я ещё так не пробовал, интересно, так ли это). Затем Вы пишете, что "надо вручную переключиться с Page width (height) = Auto на Page width (height) = Fixed". А почему бы не сделать, чтобы это переключение осуществлялось автоматически после Process? (или пусть как ini-опция по-умолчанию будет).
И ещё вопрос: Зачем нужно Page width (height) = None, если можно поставить Page width (height) = Fixed и сбросить H.(V.) Gap value в ноль? Разве результат будет не точно таким же, как и при Page width (height) = None? Хотелось бы поменьше избыточности в интерфейсе.
Из What's new 5.6A:
Цитата:| - возможность применять merge pages after split к отдельно взятому развороту (опция в окошке special... закладки Pages). |
Это где там? Это галка Pages -> special... -> More -> Merged page?
Добавлено:
shch_vg
Цитата:| По-видимому, обсуждение Вашей программы активно велось и до этого топика. |
Да, так и есть, и мне это всегда казалось странным. Я и поднял вопрос о создании этой ветки, видя хаос даже в том, как обсуждается Кромсатор, не говоря уже обо всём остальном.
C большой вероятностью можно утверждать, что 95-98% всей известной информации по Кромсатору содержится в моём Пособии по Кромсатору, т.к. во-первых, Arcand (+ другие люди) постарались и пособирали почти все такие клочки, ну а я тщательно дособирал все остальные неучтённые крохи информации. |
