Ru-Board.club
← Вернуться в раздел «Программы»

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

Автор: izograv
Дата сообщения: 01.03.2006 13:03

Цитата:
Вот ввел contrast-zone. Сканировал недавно книгу в grey, в которой все номера страниц были голубым цветом. При переводе в b/w они практически все исчезли. Повышать порог нельзя - силно ужирнялся текст. В итоге я расставил зоны, и нумерация вся сохранилась в лучшем виде.


Я бы тоже просил (почти как для даунов ) расшифровать, как был для этой ситуации осуществлен процесс расстановки зон по всем страницам. Просто очень типичная ситуация, очень радует введение contrast-zone (без них ну просто тоскливо было, exclude не всегда было удобно), может просто автор как-то их расставляет иначе (быстрее), поэтому и такой вопрос
Автор: ghosty
Дата сообщения: 01.03.2006 13:20
Arcand

Цитата:
bolega не берите их в расчет, они все рано будут все портить.

Обеими руками "за". Ни в коем случае не надо брать в расчет даунов

Если уж совсем честно и напрямую, меня в свое время несколько встревожила надпись на "оф. сайте" о том, что проект закрыт. Поэтому я боюсь, что мы "спугнем" автора своими "хотелками" так, что он опять уйдет в себя надолго
А поддержка такого продукта очень важна.
Автор: bolega
Дата сообщения: 01.03.2006 13:48
monday2000

Цитата:
Это хорошо, если зона одна и та же и в одном месте на всех страницах. Вопрос был - будет ли deskew нормально работать без простановки вручную exclude-зон по всей книге в разных позициях относительно листа? Из документации http://abab.front.ru/QandA_SK.zip так можно было понять, что "если не проставить exclude-зоны, то deskew картинки попортит"

Что-то из области "слышал звон, не знаю где он"
Можете пояснить, где это сказано, что без зон deskew не будет нормально работать???
Вообще-то, если речь и дет об exclude-зонах, то они в первую очередь, предназначены для защиты каких-либо участков от despeckle. Ну а в случае дауна, достаточно наверное просто отключить despeckle для всей страницы. Deskew тут ни при чем.

Arcand

Цитата:
Подскажите, как этим пользоваться, как установить порог?

Значение контраста (не порога) берется из закладки Contrast. Причем на этой закладке должна быть отключена галка Enabled, иначе изменение контраста будет применяться ко всей странице сразу, а не к зонам (это и понятно: если мы меняем общий контраст, то смысла менять в отдельной зоне практически нет).

izograv

Цитата:
может просто автор как-то их расставляет иначе (быстрее)

Зоны я расставляю в самую последнюю очередь, после того, как расставлю все другие опции. Затем включаю режим mouse-up mode = (exclude,contrast,...) и иду по всем файлам. Выделяю зону мышкой и в момент отпускания ее клавиши создается зона (не нужно вызывать меню). Если нужно выделять на каждой странице, в одном и том же месте, то я делаю одно выделение (при отключенном mouse-up), нажимаю Ctrl-Insert (форма выделения запоминается в карман), включаю mouse-up mode, затем на каждой странице нажимаю Shift-Insert (выделение вставляется из кармана), делаю одинарный щелчок на зоне и иду на следующую страницу, и т.д. Все выходит очень быстро.




Автор: monday2000
Дата сообщения: 01.03.2006 14:05
"Дауны" - это иносказательно. Просто желательно, чтобы процесс создания DjVu-книги с нуля до финиша был как можно более доступен любому неквалифицированному юзеру. Собственно, к примеру, все коммерческие программы стремятся к простоте интерфейса. То есть ввиду сложности Кромсатора имхо всё ещё нет должной простоты для рядовых случаев создания DjVu-книг.

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



Описание возможного Kromsator Lite

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

Я бы сказал, что самое важное - это само кромсание + смежное: draft kromsate + split + deskew + despeckle + autoclear. Без всего остального можно выкрутиться так или иначе без Кромсатора. Даже без вытягивания сканов - рядовой юзер не будет это делать. Да, кажется, профили тоже все присутствующие одобрили. И ещё: я давно предлагал - пусть Кромсатор запоминает автоматом все проставленные галочки-опции и при следующем запуске чтобы они сохранялись. Так сделано в Irfan View и это очень удобно.

Насчёт зон ничего не могу пока сказать умного.

Редактор постобработки - разумно бы убрать. Все бы делать в основном интерфейсе - для простоты.

По "левому"-"правому" - уже писал - сделать бы там обязательно сначала разрезание на одиночные, а потом уже спокойно заново загружать и работать с нормальными одиночными (порезанными) сканами. Так ведь проще, чем как сейчас? (т.е. когда везде и всюда видны отдельные опции для L и R)
Автор: bolega
Дата сообщения: 01.03.2006 14:39
monday2000

Цитата:
И ещё: я давно предлагал - пусть Кромсатор запоминает автоматом все проставленные галочки-опции и при следующем запуске чтобы они сохранялись

Сегодня вы кромсаете одиночные страницы, завтра загрузили развороты. И тогда грош цена всем этим запомненным опциям.
Профайлы есть и сейчас, правда количество опций в них немного отстало от имеющихся.
Посмотрите File->Task options settings. Создавайте сколько угодно наборов опций и загружайте любую из них перед кромсанием и draftом. Я ведь об этом уже неоднократно писал.

Цитата:
Цитата:
...
Вопрос в том, насколько обязательно эти зоны ставить, и как там другие программы обходятся без зон? Значит, они (другие программы) портят, что ли, сканы? Просто, блин, так муторно эти зоны ставить, если вдруг окажется, что без этого никак нельзя.


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

А вот от despeckle часто защищать нужно. Приведите хоть одну программу, которая делает despeckle и при этом не портит dithering-иллюстрации (если не знаете, это когда иллюстрация из отдельных разрозненных, близко расположенных друг к другу точек).
Если у Вас нет таких картинок, то и зоны не нужны. Не пойму, в чем проблема.
Автор: monday2000
Дата сообщения: 01.03.2006 14:59
bolega

Цитата:
Сегодня вы кромсаете одиночные страницы, завтра загрузили развороты. И тогда грош цена всем этим запомненным опциям.

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

1. Первичная обработка. Разрезание сдвоенных сканов или отпиливание ошметка.
2. Само кромсание - тут автозапомненные опции и пригодятся.

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

Цитата:
Я ведь об этом уже неоднократно писал.

Да, я знаю и помню - профайлы вещь хорошая.

Цитата:
Это все уже устарело и неактуально.

А-а, так а я ж не знал - в "вопросах" этого не написано...

Цитата:
Если у Вас нет таких картинок, то и зоны не нужны.

Теперь наконец-то понятно. dithering-иллюстрации - это когда мы серые фотографии аккуратно преобразуем в битовый ч.б. - так, чтобы не сильно попортить фотографию? А я думал - что это всех картинок касается. А коли только dithering-иллюстрации - так это ничего, они - большая редкость, я их вообще руками заново вставляю в ч.б. скан непосредственно перед дежавючением - поверх их же попорченных - т.к. они обработками портятся всякими.
Автор: bolega
Дата сообщения: 01.03.2006 15:31
monday2000

Цитата:
Вот, мысль более оформилась: почему бы не сделать официальную установку на обработку в 2 этапа:

Почему у Вас такая тяга к официальным установкам?
А если серьезно, то это вполне нормальный способ, многие им пользуются, например kvk.

Цитата:
Теперь наконец-то понятно. dithering-иллюстрации - это когда мы серые фотографии аккуратно преобразуем в битовый ч.б

Да, так. Но и иногда они и в книгах уже такие.
Бывают, что и обычные иллюстрации содержат местами мелкие облачки точек. Например, пляж, а на нем песочек. Тоже ж надо защитить.
Автор: monday2000
Дата сообщения: 01.03.2006 15:45
bolega

Цитата:
Почему у Вас такая тяга к официальным установкам?

Я имею в виду совершенно конкретную вещь: отказ от всяких там кнопок (или подгрупп опций) "для левой половинки" + "для правой половинки" - вот что значит "официальность".
Автор: ghosty
Дата сообщения: 01.03.2006 15:48
bolega

Цитата:
А вот от despeckle часто защищать нужно. Приведите хоть одну программу, которая делает despeckle и при этом не портит dithering-иллюстрации (если не знаете, это когда иллюстрация из отдельных разрозненных, близко расположенных друг к другу точек).

Нет уж, позвольте тут с Вами не согласиться. Если мы говорим о дальнейшем преобразовании в *.djvu, то от dithering-иллюстраций нужно избавляться в первую очередь. Так как именно они дают самый существенный прирост объема конечных файлов. Их именно что нужно "портить", избавляясь от этих точек, расположенных близко друг к другу. Когда у меня такое было в большом кол-ве, приходилось "размыливать" такие изображения в ФШ, чтобы djvu-кодер вел себя с ними адекватно и посылал в бекграунд, а не в маску.
Т.е. вначале нужно обязательно избавиться от dithering'а, а уж потом делать despeckle, и все будет хорошо
А каков алгоритм определения картинок в Файнридере? Можно ли его воплотить в Кромсаторе?
Автор: monday2000
Дата сообщения: 01.03.2006 15:52
bolega
Мелочь: в default task settings налезают буквы друг на друга:

И таких мест ещё будет 2-3 в кромсаторе.
Автор: ghosty
Дата сообщения: 01.03.2006 16:20
Такого, похоже, раньше не было: ставлю резак ниже номера страницы, а Кромсатор не обращает внимание на резак и все равно отрезает по нижней границе текста...

Добавлено:
А выключаю Automargin для нижнего резака, работает по резаку - т.е. номер страницы жив остается. Так ведь, вроде, если резак установлен, то Automargin работать вообще не должен, или я не прав?
Автор: bolega
Дата сообщения: 01.03.2006 17:17
ghosty

Цитата:
Так ведь, вроде, если резак установлен, то Automargin работать вообще не должен, или я не прав?

Не прав. Все наоборот.
Отсутствие Automargin означает, что Вы сами зададите положение края текста _резаком_. Там, где поставите резак, там и будет край текста (к нему и будет прибавлять поля кромсатор).
Автор: ghosty
Дата сообщения: 01.03.2006 17:38
Ох, а я-то наивно полагал, что после работы DK (и правки результатов вручную) полученные резаки имеют больший приоритет, нежели опции. Оказывается, я зря старался...
Это ведь в любых системах так - если я задаю какие-то параметры вручную, любая другая автоматика должна уважать мой выбор. Т.е. автоматика должна выключаться автоматически

Теперь нужно будет перепроверить все сделанные книжки на предмет ошибок автоматики
Автор: bolega
Дата сообщения: 01.03.2006 18:33
ghosty
Вы плохо представляете себе назначение резаков. Основное их назначение - отрезать мусор, но не определять края страницы (поэтому резаки и не обязательно ставить вплотную точно к тексту, а иначе выставлять их было бы мучением, да и невозможно это бывает при перекосе страницы). И только когда кромсатор не может самостоятельно правильно это сделать, только тогда резаку можно придать дополнительную функцию (что и сигнализируется теперь изменением цвета резака). Если бы после каждого нашего движения резаком кромсатор принимал его за фиксацию, то это был бы ужас. Т.е. я сдвинул резак, чтобы просто лучше отсечь какое-нибудь пятнышко и при этом резак еще далеко от текста, а кромсатор возьми и зафиксируй этот порыв как край текста. Так нельзя.
Собственно, об этом все хорошо написано еще в 1-й доке. С тех пор в поведении резаков ничего не поменялось.
Но Вы подали мне одну идею: если резак двигать например с нажатым Shift, то кромсатор автоматически бы сбрасывал бы под-опцию automargins, все ж меньше щелкать.
Автор: ghosty
Дата сообщения: 01.03.2006 22:38
bolega

Цитата:
Вы плохо представляете себе назначение резаков.

В том-то и беда, что до определенного момента я себе это хорошо представлял...

Цитата:
Основное их назначение - отрезать мусор, но не определять края страницы

... и именно для этого их использовал.
Но дело в том, что я долгое время расставлял резаки вручную. После использования DK, у меня начались нестыковки. Как-то для себя я решил, что DK расставляет резаки именно в тех местах, где и Automargin расставляет границы. Это и сейчас кажется мне логичным. ИМХО, в случае работы DK разница между резаком и невидимой автоматически определяемой границей становится неочевидной.
Может быть, все-таки после работы DK проще совместить границу и резак, обозначив резак малиновым цветом и автоматически отключив Automargin? Или какие-то еще подводные камни тут есть?
Автор: Melirius
Дата сообщения: 03.03.2006 13:57
ghosty

Цитата:
bolega

Цитата:
А вот от despeckle часто защищать нужно. Приведите хоть одну программу, которая делает despeckle и при этом не портит dithering-иллюстрации (если не знаете, это когда иллюстрация из отдельных разрозненных, близко расположенных друг к другу точек).     

Нет уж, позвольте тут с Вами не согласиться. Если мы говорим о дальнейшем преобразовании в *.djvu, то от dithering-иллюстраций нужно избавляться в первую очередь. Так как именно они дают самый существенный прирост объема конечных файлов. Их именно что нужно "портить", избавляясь от этих точек, расположенных близко друг к другу. Когда у меня такое было в большом кол-ве, приходилось "размыливать" такие изображения в ФШ, чтобы djvu-кодер вел себя с ними адекватно и посылал в бекграунд, а не в маску.
Т.е. вначале нужно обязательно избавиться от dithering'а, а уж потом делать despeckle, и все будет хорошо


Нет уж, позвольте тут с Вами не согласиться (C) Ghosty.

- Не люблю кошек!!!
- Вы просто не умеете их готовить... (из рекламы)

Dithering-иллюстрации есть наилучший способ сократить размер получаемого djvu-файла! Для этого достаточно их кодировать в Bitonal профиле, когда вообще нет бэкграунда. Размыленные иллюстрации применяются только в двух случаях: если исходник был отсканирован в 300dpi - тогда иллюстрации будут частично точечными, а частично серые сплошные; или если на сканере был выставлен дескрининг (по-моему, так) - для преобразования точек в однотонные области.
Автор: ghosty
Дата сообщения: 03.03.2006 14:24
Melirius
Именно о bitonal 600 я и говорю. Говорю не голословно.
Сканировал как-то широкоформатную книгу в 600 dpi. Так вот, там, насколько я помню, точечки эти, составляющие рисунок, местами слепливались вместе, образуя самые причудливые формы. У кодера возникла ужасная аллергия на эти фигуры. Он над ними долго думал, а потом выдавал файлы очень большого объема.
Пока я не избавился от точек, нормального *.djvu не получил...
Опять-таки не помню точно, но в режиме scanned объем файла у меня тогда получился меньше, чем в bitonal...
Так что лучше ИМХО все-таки от греха подальше избавляться от них как можно раньше.
Автор: bolega
Дата сообщения: 03.03.2006 16:04
Melirius

Цитата:
дескрининг

А разве это не функция подавления муара?
Автор: Melirius
Дата сообщения: 04.03.2006 00:08
bolega


Цитата:
Melirius

Цитата:
дескрининг     

А разве это не функция подавления муара?


Да, она и есть, но она везде криво работает, а муар как раз при сканировании таких рисунков в 300dpi появляется.

ghosty


Цитата:
У кодера возникла ужасная аллергия на эти фигуры.


А чем кодировали, если не секрет?
Автор: vgugo
Дата сообщения: 04.03.2006 08:30
bolega
огромное спасибо за такую программу

но у меня возник вопрос по интерфейсу кромсатора

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

или эту роль выполняет кнопка с галочкой "Auto-accept option changings"?

спасибо
Автор: ghosty
Дата сообщения: 04.03.2006 10:08
Melirius

Цитата:
А чем кодировали, если не секрет?

Это был еще... DocExpress 4.0.
Автор: bugatti
Дата сообщения: 04.03.2006 11:30
bolega

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

Со сканами вопросов нет, а вот с тиффами сделанными цифровой 6мегапик. камерой
есть. Видимо еще не до конца освоив технику фотканья статей, получаю некоторые развороты крайне размыленными, нечеткими... Как с помощью кромсатора улучшить
резкость? Игра м подменю quality c smooth, sharpen, blur не дают ничего...
Кстати что они вообще делают от 1 до 5? Или тут ск бессилен и путь только в фотошоп?
Автор: VadimirTT
Дата сообщения: 04.03.2006 17:57
bolega
Это мне мерещится, или скорость обработки в новой версии резко возросла .
Автор: Melirius
Дата сообщения: 05.03.2006 10:10
ghosty

Цитата:
Это был еще... DocExpress 4.0.


Тогда не знаю, я сразу начинал с DEE 5.1 - за милую душу пошло, ещё и размер уменьшился солидно.
Автор: ghosty
Дата сообщения: 05.03.2006 10:35
Melirius
Это, конечно, немного оффтоп, но просто представьте себе, что все то, что у нас могло уйти в бекграунд, мы насильно загоняем в маску. И тогда djvu начинает обрабатывать все эти точки и складывать их себе в словарь (что, видимо, и получилось в моем случае).
Т.е. може, размер у Вас и уменьшился, однако не факт, что его нельзя было уменьшить еще больше. Пусть меня поправят, если я не прав.
Автор: Melirius
Дата сообщения: 05.03.2006 10:45
ghosty
Да нет, размер солидно уменьшился именно относительно варианта с размазанными картинками. Книги, на которых это проверено, я заливал к kvk - 2 издания справочника по металловедению алюминиевых сплавов. В этих книгах картинок довольно монго.
Автор: Arcand
Дата сообщения: 05.03.2006 14:25

Цитата:
размер солидно уменьшился именно относительно варианта с размазанными картинками.
В последней моей книге были рисунки по типу Dithering - состояли из разных по размеру точек/спеклов переменной плотности (не растр). Одна страница в дежавю весила ~230 кБ при общем размере книги немного больше 3 метров. Чтобы поправить это, применил к рисунку несколько раз адаптивное размытие, таким образом он стал gray. Закодировал профилем Scanned. Рисунок в основном ушел в фон. Размер стал около 50 кБ, качество нормальное.
У меня не вызывает сомнения, что gray рисунок в дежавю весит значительно меньше чем его Dithering b/w аналог. Оно и понятно, большая часть gray рисунка уходит в фон, разрешение которого в несколько раз меньше, чем у маски (например, в DEE в профиле Scanned600 разрешение фона 100 дпи).
Автор: Melirius
Дата сообщения: 07.03.2006 11:30
Arcand

Опять-таки: чем кодировали?
С нормальным качеством на профиле Scanned, извините, никак согласиться не могу: резкие границы чёрного и жутко размазанное всё остальное - это не качество, это жуть тихая.

Кстати, размер в 150 Кб для Dithering - это нормально при 600dpi. А у Вас 300 или 600?

Не могли бы поделиться методикой, если знаете, как, не получив вышеописанного эффекта, закодировать страницу?
Автор: Arcand
Дата сообщения: 07.03.2006 17:58
Melirius
Кодирую в DEE, 600 дпи. Я стараюсь загнать рисунки в фон, пока получалось это сделать. Если у Вас с этим проблемы, могу посоветовать следующее: 1) применять адаптивное размытие (можно несколько раз), 2) изменить настройки в профиле Scanned (когда-то я говорил какие именно, см. также подсказки в DEE), чтобы побольше уходило в фон. Но, чтобы не пострадал текст, его надо преобразовать в b/w. Если качество рисунков Вас не устраивает, можно увеличить разрешение фона.
Автор: Kiljes
Дата сообщения: 07.03.2006 19:53
Arcand

Цитата:
изменить настройки в профиле Scanned

У меня DEE 6.0.1 Build 1320 (урезанная лайт эдишн- 4 метра) так там такой настройки нет. Может для этого нужна полная версия, что 200 метров?

Страницы: 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667

Предыдущая тема: MSN Search Toolbar with Windows Desktop Search


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.