» ScanKromsator СканКромсатор

Кто-нибудь имеет инфу о том, чем 3600 отличается 3600+
На сайте ничего не понять.

bolega

Цитата:

Кто-нибудь имеет инфу о том, чем 3600 отличается 3600+
На сайте ничего не понять.

Я нвмного размышлял над этим- мне кажется там где + немного больше софта дают. Который кстати у нас всех уже давно есть или должен быть

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

Цитата:

я в Германии заказал за 210 Евро
но уже жду 2 недели а его нет...

я тоже мог заказать с ибея за 249 долл.

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

а тут местная фирма и гарантию от себя дала...

bolega
Мне вообще-то очень понятно то что пишете.
(я пишу на с++ и фортране, в основном квантовая динамика) Интерфейса у нас никакого- дело идет в линуксе. файл.in и файл.out (Но никто бы и сдесь не отказался от него)
Ну а если я вам скажу что вы вот сделали 98! шагов к цели и остались эти последние два шага? Посмотреть на него глазами домохозяйки и причесать этот интерфейс наконец?
Вы правильно заметили- конкуренции у вашей программы -никакой.
Потому что вы все равно впереди всех сейчас.

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

Думаю, что число пользователей, при упрощении интерфейса могло бы увеличится на 500-1000%
(Да и не очень сложно это- добавить визард( продублировать панель с опциями но добавить всплывающие подсказки), Ну и добавить прямо в меню выбор темплейтов- Черно белый скан, серый скан, серый с картинками, и тд...?)
Устали?
Организуйте проэкт на sourceforge или им подобным.
Думаю и несколько десятков $ от благодарных пользователей вам не повредят. К тому же это будет неплохим стимулом, не правда ли?

Можно обьявить конкурс- на лучший по функциональности! фейс кромсатора.

Думаю желающие будут

К тому же это поможет вам взглянуть на свою программу глазами простого пользователя, цель которого- превратить кучу тифов в Книгу!

Цитата:

Я нвмного размышлял над этим- мне кажется там где + немного больше софта дают

ага, плюстек анонсировал сканер для слепых

http://www.mybookreader.com


вроде тот же Оптикбук и text-to-speech software

(700 долл)

terminat0r

Цитата:

Ну и добавить прямо в меню выбор темплейтов- Черно белый скан, серый скан, серый с картинками, и тд...?)

Вот и я все ратую за теплейты.
Ведь коммьюнити вполне может взять на себя создание оных.
bolega может сделать минимум - ввести возможность создания темплейтов. Ведь сохранение настроек - вообще, штука важная, а сейчас этой возможности практически нет.
Что можно включить в темплейт:
1) опции/значение параметров;
2) порядок выполнения тех или иных алгоритмов;
3) возможность создания комментария к темплейту (в идеале - формат *.html с картинками);
4) возможность сочетания темплейтов друг с другом (напр., темплейт для текста с неровным фоном + темплейт для плохо пропечатанных литер).
Мне думается, это несложно сделать.

VadimirTT

Цитата:

Costs less than Adobe® Acrobat®

Первый раз вижу, чтобы сравнивали железо и прогу
Т.е. надо понимать, что в 3600+ новшества чисто программные.

Кстати, есть ли в нем возможность как-то отключить сглаживание. Он ведь во всех режимах его втихаря выполняет. И я заметил, что если где-то текст плохо пропечатан, то после его сглаживания (аппаратного или программного - не знаю) он становится еще хуже (в Epson та же страница получается намного разборчивее) . В настройках вроде бы нет, или плохо искал. Аналогично, хуже (по сравнению с Epson) сканируется текст серого или голубого цвета в режиме b/w.
И еще одно наблюдение, но уже не в пользу Epson. У него, как известно есть два режиа - сканирование документов и сканирование фото. В первом случае он очень хорошо чистит слабый фон, например, просвечивающаяся обратная сторона страницы полностью отфильтровывается. Но при этом наблюдаются заметные искажения цветных иллюстраций (я испытывал на репродукциях, где паразитный фон нужно было удалять однозначно). А вот Opticbook сосканировал прекрасно и без всяких искажений цветопередачи.



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

Цитата:

Хорошо, что Вы об этом сказали.
Меня уже давно мучает вопрос, почему при таком повальном увлечении сканированием всего и вся, и немалом спросе на инструменты обработки, до сих пор не появляется ничего альтернативного кромсатору (под windows), во всяком случае в той же ценовой категории?
Для меня это просто загадка. Обычно рынок всегда живо реагирует на спрос. А тут непонятно. Или все так зачарованы FR, что и пытаться боятся. Или боятся наших "законодателей", которые завтра примут "закон" о том, что инструменты обработки копирайтных материалов будут приравниваться к самому копированию таких материалов?
Взять например вьюеры - их полным полно, какие хочешь, и платные, и бесплатные. И OCR-программ предостаточно. А по специализированной обработке книг - ничего. Один BR, да и тот изначально делался как дорогое дополнение к ихним собственным таким же дорогим сканерам.

Уже давно слежу за развитием проекта «Скан Кромсатор». Огромное спасибо как разработчику программы так и всем его добровольным помощникам. Но позвольте высказать свои соображения по данному вопросу, тем более что лично оцифровал не одну сотню книг и часто пользовался при этом Скан Кромсатором.

И соображения эти несколько отличны от узкого обсуждения программных особенностей.

Во первых давайте честно, - Скан Кромсатор настолько тяжел в освоении, что просто отпугивает новичков. И чем дальше, тем более «тяжеловесной» становится программа, она донельзя уже и так перегружена всяческими прибамбасами, с которыми уже и профессионалу разобраться сложно. Про путанный и неинтуитивнопонятный интерфейс, отсутствие толкового Хелпа или непонятная ориентация на англоговорящих – я вообще молчу.

И развитие Скан кромсатора идет в сторону все большего усложнения – а иначе и быть не может, ведь Скан Кромсатор пытается (с перманентным успехом) оперировать исключительно с графическими образами информационного контента. Отсюда и все беды.

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

Например если программа «понимает» (или вычисляет) что в определенном районе на странице может находиться фрагмент графического образа который един для всех страниц (нумерация страниц, например) то значительно облегчается обрезка полей.

Это я к чему клоню? – К ответу на вопрос «– А почему нет аналогов Скан Кромсатору». А их нет по той простой причине, что (это мое личное мнение) – данное направление тупиковое. А соответственно и не имеет коммерческого интереса.

У FR была замечательнейшая опция, которую по непонятным причинам убрали в 8 версии – «что не смог распознать – в картинку». Мне кажется что именно за этим путем, с задействованием интеллектуальных механизмов распознавания, - будущее. И сделать то нужно совсем ерунду – добавить в FR управление по степени достоверности распознавания. Вернее даже не добавить а вывести её как опцию для пользователя.
Почему разработчики FR этого до сих пор не сделали, мало того зачем они убрали «выводить как картинку» из FR8 – вот главный вопрос. Возможно (я так предполагаю) нет принципиальной заинтересованности в массовом появлении в Интернете действительно качественных djvu книг. Возможно (это тоже всего лишь мое предположение) – идет торг с Лизардом и как только он закончится мы прям из FR будем получать отменного качества djvu книги.

А пока затыкая информационные дырки я размещаю в сети откровенно некачественные djvu книги, хотя все сырые сканы сохраняю – в ожидании не новой версии Скан Кромсатора, но нового FR.


C уважением Сергей Ружинский

ALLBETONRU

Цитата:

А пока затыкая информационные дырки я размещаю в сети откровенно некачественные djvu книги, хотя все сырые сканы сохраняю – в ожидании не новой версии Скан Кромсатора, но нового FR.

Ничего не понял. Вы Кромсатор обвиняете, что книги откровенно некачественные получаются?

Цитата:

идет торг с Лизардом и как только он закончится мы прям из FR будем получать отменного качества djvu книги.

А почему Вы думаете, что именно в этом случае качество будет гарантировано?

Добавлено:

Цитата:

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

Одно другому не мешает. Скорее наоборот: улучшение графического образа способствeует более аккуратному распознаванию.

Мой ответ, почему аналогов Кромсатору нет. Дело в том, что в той же Европе над подобными проектами работают целые лаборатории.
Вот пример: DEBORA Project. У них даже формат свой собственный (типа улучшенного DJVU).
Автору Кромсатора удалось объять необъятное. А понять, как работает Кромсатор не в пример легче

ALLBETONRU

Цитата:

Скан Кромсатор пытается (с перманентным успехом) оперировать исключительно с графическими образами информационного контента. Отсюда и все беды

Согласен. Я и сам уже несколько раз писал, что в определенных местах ( и только в них) мне не хватает OCR, но на 95% он не нужен. Если вы почитаете современные (и не очень) зарубежные журналы, то там тема распознавания контента без привлечения OCR существует очень давно и с большим успехом развивается. Этим занимаются многие ученые и вряд ли они считают это тупиковым занятием


Цитата:

Это я к чему клоню? – К ответу на вопрос «– А почему нет аналогов Скан Кромсатору». А их нет по той простой причине, что (это мое личное мнение) – данное направление тупиковое. А соответственно и не имеет коммерческого интереса.

Не согласен. Во-первых, FR - это OCR-программа, функции же SK гораздо проще - убрать грязь, выровнять и привести к одному виду. И Sk с этим прекрасно справляется, проблема лишь в том, насколько он делает это автоматически, и насколько нужно юзеру вмешиваться в этот процесс.

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

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


Цитата:

А пока затыкая информационные дырки я размещаю в сети откровенно некачественные djvu книги, хотя все сырые сканы сохраняю – в ожидании не новой версии Скан Кромсатора, но нового FR.

Учитывая, что FR не занимается улучшением качеством графики, что в этом смысле можно ожидать от FR??? Или он как-от отрежет грязь по другому?? Более ровно? Посмотрите как коряво в нем реализован поворот изображений на малые углы. Оно и понятно - для целей OCR это абсолютно несущественно, а вот для DJVU...
Кажется, это просто оправдание Вашим некачественным книгам.
Проблема SK не в том, что результат некачественный, а в том, что в ряде случаев (точнее, для ряда страниц) еще требуется ручное вмешательство пользователя.
С уважением.


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

ALLBETONRU

Цитата:

Почему разработчики FR этого до сих пор не сделали, мало того зачем они убрали «выводить как картинку» из FR8 – вот главный вопрос.

Предполагаю, что здесь Вы получите ответы на эти и другие вопросы по FR.
Автор того топика
Цитата:

Красноперов Дмитрий
Проектировщик интерфейса FineReader

Цитата:

Учитывая, что FR не занимается улучшением качеством графики, что в этом смысле можно ожидать от FR??? Или он как-от отрежет грязь по другому?? Более ровно?

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

http://allbeton.ru/viewtopic.php?t=8089

ALLBETONRU

Цитата:

В итоге получаются последние 2 стр. которые более чем хорошего качества

У нас видимо разные представления о качестве
Вас не смущает, что строчки на обеих (!) итоговых страницах повсюду разъезжаются, а на последней странице и вообще налазят друг на друга, да и шрифт там вдруг стал какой-то вытянутый. Да и чем описанные Вами там манипуляции с блоками FR лучше манипуляций с резаками в SK?
Да и вообще такой подход мне кажется тупиковым, поскольку любое распознавание предполагает вычитку, а в случае научно-технических книг это неприемлимо.
Более перспективным (хотя не факт) мне кажется подход, который недавно обсуждался в ветке по сканированию - применять FR для распознавания буквенного словаря готового djvu, там тоже понадобится вычитка, но на уровне букв словаря, а не целого текста, а это по моему мнению намного легче (что тоже не факт).

Цитата:

У нас видимо разные представления о качестве

Нет смысла дискутировать эту тему, т.к. понятие «качество» для djvu книг действительно не формализовано. Соответственно и каждый может наполнять это определение своим смыслом. Для меня например высшая характеристика книги – это степень её эксклюзивности. И к черту мне тогда вычищена она или нет, кривая она или косая. Главное что ни у кого нет, даже в Ленинке нет, - а у меня есть. 
Ну и второй мой критерий качественности – читабельность. Мне сложно это объяснить, но вот бывает читаешь книгу – сделана супер – а глаза слезятся, взгляд разбегается. И что самое интересное – распечатаешь, - тоже самое!

Мне кажется нужно каким-то образом внести ясность в данный вопрос и возможно общими усилиями сформулировать критерии степени качественности djvu книги. Или если где эта тема уже обсуждалась – дайте ссылку.

С моей точки зрения «крайние» точки качественной оценки можно определить достаточно однозначно.
Например «Качество – 1» - это чернобелый сырец без какой либо обработки в 300 dpi.
«Качество 10» - это *.doc перегнанный в djvu с распознанным слоем. Между ними – резанные, вычищенные и т.д. варианты.

А пока нет четкого определения что такое качественная djvu книга сложно совершенствовать методологию и технологию их изготовления, согласитесь.




Цитата:

Да и чем описанные Вами там манипуляции с блоками FR лучше манипуляций с резаками в SK?

Я привел в своем примере «самый сложный случай» - и формулы, и рисунки, и таблицы и обилие мат. символов в тексте.
Для такого сложного случая возможности FR по автоматизации всего поцесса действительно еще не дотягивают – потому то и оформлено все в виде «пожелания разработчикам» а не окончательной рекомендации пользователю.
Но та же самая операция над простым текстом (текст + рисунки) позволяет достаточно легко получить результат не в пример лучше. Хотя в любом случае право за выбором той или иной методики – за пользователем.

Ага, я понял, кажется, ALLBETONRU поклонник OCR-подхода
Так, он пишет (в своем FAQ):
А нельзя ли как-то обойти невозможность 100% распознавания программами OSR при создании книг в форматах pdf или djvu ?
– Можно. И в FR до версии №8 (а сейчас вроде бы и в FR8 уже исправлено) есть такая опция для сохранения результатов в pdf – «Заменять неуверенно распознанные слова их изображениями».
В итоге получаем отменного качества djvu книги в которых только малая толика информации сравнительно «некачественная», но читабельность от этого не теряется, и глаз порой даже не замечает подмены.
Вот это именно то, что мы приводим здесь в качестве примера отвратительно сделанной книги. Уж извините

И вообще, я не понимаю, зачем уже отOCRенные книги (векторизованные) конвертировать в *.djvu. Ответьте
И давайте все-таки плавно переходить в более подходящую ветку. Здесь уже в оффтоп сползаем.

Здравствуйте. У меня проблем, с полутоновыми иллюстрациями. СК может рассчитывать «средний» фон. А как именно он это делает, не подскажите.
(когда сканирую, то использую интерфейс FR7. С функцией сканировать несколько страниц. Быстро получается. Вот отсканировал я книгу в сером 400 dpi (кстати, а в каком формате их лучше сохранять на выходе из FR – bmp, tiff (какой именно, сжатый не сжатый). Загрузил сканы (Сырцы) в кромсатор (расставил галки и др. функции). Увеличил dpi. Так как сделать так чтобы убрать серый фон, при этом не повредить полутоновые иллюстрации.
Заранее спасибо.

Per_aspera_ad_astra

Цитата:

Так как сделать так чтобы убрать серый фон, при этом не повредить полутоновые иллюстрации.

Заключить их в exlude-зону (красную). На одну страницу допускается использовать до 32 зон. Такие зоны не трогаются чистильщиком фона и они не подвергаются despeckle.

Цитата:

в каком формате их лучше сохранять на выходе из FR – bmp, tiff (какой именно, сжатый не сжатый)

Оба формата - без потерь, так что подойдет любой (лишь бы не jpg). Только tiff со сжатием LZW сэкономит Вам место на диске. Кроме того, форматы со сжатием быстрее загружаются в кромсаторе.

bolega

Цитата:

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

Так ларчик просто открывается, достаточно посмотреть на гистограмму в Epson Scan. На режиме "документ" сканер часть самых светлых и самых тёмных оттенков по каждому цвету просто отбрасывает - сознательно сужает динамический диапазон. Это видно по положению точки белого и точки чёрного.

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

Melirius

Цитата:

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

Это понятно, я так и делал. Просто на каждой странице (напомню, речь шла о сканировании репродукций, которые сильно отличались по цвету, насыщенности и яркости) приходилось подбирать по новой, что меня не устроило, учитывая их количество. На оптикбуке же все сделалось на автомате, вот что интересно

bolega
Если посмотреть страницу 1 этого топика, то в посте 4 видно, что terminat0r
комментирует цитату из Вашего поста, который отсутствует в этом топике.
По-видимому, обсуждение Вашей программы активно велось и до этого топика.
Есть ли сейчас возможность ознакомиться с этим обсуждением, или оно уже недоступно?
Спасибо.

shch_vg
А, теперь понятно. Я ведь сам не все форумы знаю, где ск обсуждают.
Но здесь видимо речь идет о книжной ветке руборда, посвященной физ.-мат. книгам. Там обсуждался sk до появления здесь топика благодаря уважаемому ghosty. Но там ветка ого-го, придется смотреть за несколько лет
Вот последняя, 17-я
hxxp://forum.ru-board.com/topic.cgi?forum=93&topic=1076#1
Там будет ссылка на предыдущую и т.д.

bolega

Цитата:

Но здесь видимо речь идет о книжной ветке руборда, посвященной физ.-мат. книгам

До этого я додумался . Поднял самую раннюю ссылку по этой теме, но она начинается с 03-12-2004. А в интернете ходят FAQ-и, в которых Вы обсуждаете вопросы кромсатора с июня 2004 года. Спросил у monday2000, но он мне пока не ответил. Хотелось бы подетальнее посмотреть обсуждение.

shch_vg
А еще есть Сканирование и оцифровка текста *.txt, *doc, *.pdf, *.djvu

VadimirTT

Цитата:

А еще есть Сканирование и оцифровка текста *.txt, *doc, *.pdf, *.djvu

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

Цитата:

Автор: bolega, Отправлено:17:46 22-06-2004

max67

Цитата:Напомните, пожалуйста, еще раз эту процедуру. (Извиняюсь за
склероз.)
Например, есть 8-bit скан в 150 dpi. В кромсаторе я просто
устанавливаю на выходе b/w 300 dpi. Результат в принципе получается
неплохой. Но может есть ещё какие-то нюансы? Помнится прделагалось
делать предварительный upsample.

150->300 это и есть upsample.

shch_vg
Я думаю пока (до создания help'a) лучше ограничиться FAQ'ами, и задавать вопросы здесь или в приведенной выше ветке.
А то уже намечается такая интересная тенденция, когда люди вообще забывают о Кромсаторе, увлекшись поиском информации о нем (никого не хочу обидеть - это шутка ).

Вообще, сообразуясь со своим скромным опытом я могу сказать, что Кромсатор проще всего осваивать, решая конкретные задачи. ИМХО, не имеет смысла фраза "освоить Кромсатор в совершенстве". С точки зрения наличия и работы различных функций в совершенстве им овладел, наверно, только сам автор. А с точки зрения алгоритмов обработки и применения тех или иных функций появляется бесконечное множество вариантов: Кромсатор - по сути набор инструментов.
Если же решаешь конкретную задачу, появляются конкретные вопросы, ответы на которые можно получить в FAQ'ах и в соотв. ветках (печать всей ветки + Ctrl-F). А можно на эти ветки и FAQ'и "натравить" мой любимый индексер, и тогда уже точно найдется все

shch_vg
Вот отсюда можно двигаться как вперед, так и в каменный век, к основанию, так сказать, движения
hччp://forum.ru-board.com/topic.cgi?forum=35&bm=1&topic=20561&start=0
Сам я факи не собирал, поэтому где там что разбросано, сказать не могу.
Только не берите в голову такой архаизм как 150 dpi

bolega

Цитата:

hччp://forum.ru-board.com/topic.cgi?forum=35&bm=1&topic=20561&start=0

Прямо в яблочко! . Именно то, что я искал, дальше все понятно!
Большое спасибо!

Уважаемый ghosty!
Согласен почти со всем, что вы сказали, но боюсь, что найти топик, любезно предоставленный мне bolega не удастся не знающему человеку, по крайней мере мне не удалось опуститься до таких глубин .
Мне удалось отсканировать несколько (мало) книг, причем основная работа была проведена именно в Кромсаторе. Метод проб и ошибок, конечно, никто не отменял, но меня все время не оставляет ощущение, что я многое делаю не так, как можно было бы сделать. Ни один FAQ все равно не охватит все нюансы работы программы, а зачастую именно нюансы решают дело. Так что информация - forever!

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 (+ другие люди) постарались и пособирали почти все такие клочки, ну а я тщательно дособирал все остальные неучтённые крохи информации.