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

bolega
Попробовал одну задежавюченную в сырых сканах книжку перекромсать. Возникли проблемы:

1. Во время Process Кромсатор выдавал ошибку при deskew 2 раза на неких сканах (эти сканы прилагаю):

Цитата:

Программа SK вызвала сбой при обращении к странице памяти
в модуле ISP2000.DLL по адресу 0167:038475e2.
Регистры:
...

Глюк проявился только в Win98SE, в Win2000 Prof всё нормально работает.

2. Некоторые сканы получились на четвертушке листа, остальные - нормального размера. Известное лечение - выставить единицы измерения в 10*mm - НЕ помогло. Фотошоп показывает, что все сканы в 300 dpi (может, это чисто формально?), а размеры в пикселях разнятся примерно в 2 раза - на нормальных и "четвертушечных" сырых сканах. (эти сканы прилагаю) Как такую смесь сырых сканов обрабатывать? Ведь они же все в 300 dpi (по крайней мере, так показывает Фотошоп). Предлагаю такое решение: пусть кромсатор автоматически определяет, что на готовом листе текст будет занимать лишь четвертушку площади, и будет в таком случае автоматически увеличивать текст на таком листе в 4 раза.

3. Нередко Кромсатор резко ошибочно делает deskew на файлах с картинками, проставление Art не помогает, помогает только exclude zone. Хотя Файнридер без проблем тут deskew делает. Нельзя ли подправить кромсаторный deskew в нужной степени? Вот что в Пособии сказано про Exclude region:

Цитата:

Исключает воздействие (в выделенных регионах) следующих операций:
...
Deskew (Auto Shear, Interpolate, Antialias - не будет участвовать в определении skew-угла (например, именно изображения приводят к неправильной детекции угла наклона). Зона будет поворачиваться без использования интерполяции, чтобы не внести дополнительный муар. Exclude region для Deskew очень редко бывает нужным.

Вообще, визуально впечатление такое, что при exclude-выделении картинки и последующем применении deskew скан поворачивается, а картинка - нет. Или это просто так кажется?

4. На сканах после файнридерного deskew частенько возникает характерное некорректное проставление резака по Draft kromsate - когда сверху вниз идёт "белая полоска-чёрная полоска-белая полоса-текст" - Draft kromsate ставит резак ДО чёрной полоски. Это очень характерная и частая ошибка для таких сканов.

Примеры, относящиеся ко всем этим 4 пунктам (в одном архиве):

webfile.ru/950455 (1,10 МБ) доступен до 23.05.2006 22:56.

Читайте там ещё readme в каждой папке, всего 4 шт.

monday2000

Цитата:

На сканах после файнридерного deskew

Так и зачем его для этого использовать, Файнридер-то?

У меня тоже есть один вопрос и одно предложение.
Вопрос: что должен делать Page V. align с опцией по умолчанию "A". Я, к примеру, давно уже привык вручную выставлять опцию "B" во всех случаях, когда блок текста выровнен по нижней части (в начале главы). Если я этого не делаю, текст выравнивается по верху. Но ведь "А" по идее обозначает "Automatic"

Предложение: все чаще приходится кромсать достаточно большие файлы (15-30Mb). DK тормозит очень сильно. Так, в последний раз одна только работа DK заняла около полутора часов. Конечно, если бы я расставлял резаки вручную, это заняло бы больше времени (учитывая долгое время открытия каждого такого файла).
Но ведь для работы DK достаточно и обычных BW файлов.
В том же VueScan, к примеру, есть возможность сохранять отсканированную страницу одновременно в RAW и в BW.
Можно ли сделать следующим образом?
Указываем путь к малоразмерным BW файлам и к RAW. DK работает с малоразмерными файлами, после чего резаки переносятся на RAW.

Выложил старую версию, давно на винте болталась:

http://www.dstu2204.narod.ru/djvu/scan_kromsator_v4_0pre_full.rar (1,52 МБ)

ghosty

Цитата:

Так и зачем его для этого использовать, Файнридер-то?

Это из моих старых запасов. Да многие делают с Файнридером книги - ведь простота высокая, это людей привлекает, а минусы Файнридера далеко на всегда проявляются.

Цитата:

Вопрос: что должен делать Page V. align с опцией по умолчанию "A".

Присоединяюсь к вопросу. Давно ломаю голову над этим. Это явно не эквивалентно "С" (только я о Page Н. align говорю). А по идее должно так быть.

Добавлено:
bolega
И ещё вопрос: нельзя ли научить Draft kromsate ставить только один резак - разрезающий развороты? Как я понял, сейчас такого нет (или есть?). Есть лишь возможность выкинуть в опциях Draft kromsate все резаки, оставив только "Internals" - но это 2 резака, "вырезающих" серединку между сдвоенными сканами, а хочется, чтобы именно только 1 резак был.

Хотелось бы делать обработку многопроходно: первым проходом по Draft kromsate + Process режем сдвоенные развороты на половинки (а то и, может быть, в случае одинарных сканов, отпиливаем ошмётки). Затем загружаем уже стандартизованные сканы и обрабатываем их с меньшим для себя напрягом. Я вот попробовал 8 резаков подправлять после Draft kromsate на сдвоенных сканах - легче застрелиться имхо.

И ещё у меня возникла такая, довольно теоретическая идея: может быть, в идеале, имело бы смысл разделить Кромсатор на 3 программы:

1. "Kromsator Lite" (о котором я уже писал - это только обрезка + смежное).

2. "Gray enhancer" - всякие обработки, не относящиеся именно к нарезке сканов.

3. "Pdf processor" - сюда всё, что касается Pdf.

Вот мы говорили, что хорошо бы резаки заменить на прямоугольники, а Вы ответили, что будут мешать тогда exclude-зоны, что очень трудно будет определить, где какой прямоугольник. Так при описанном подходе можно будет вынести все зоны в "Gray enhancer", и тогда в оставшемся "Kromsator Lite" уже ничто не помешает замене резаков на прямоугольники.

Это же известный технический приём - борьба с излишним универсализмом (одна из основ принципа конвейера).

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

Это я к тому, что вовсе не так уж и хорошо воплощать, что бы кто ни попросил. С точки зрения развития массовости кромсания (хотя я знаю, что Вы этим не руководствуетесь ) нужно как-раз таки наоборот, максимально снизить количество фич, насколько это возможно.

Конкретно предлагаю: фичу "чистить за резаками" убрать в интерфейсе (просто выкинуть жаль, а имхо не мешало бы) куда-нибудь подальше (например, в ini-файл). Пусть большинство и не догадывается о её существовании, а кому надо - тот полезет в ini и включит себе.

monday2000
Спасибо за исчерпывающий отчет!


Цитата:

Некоторые сканы получились на четвертушке листа, остальные - нормального размера. Известное лечение - выставить единицы измерения в 10*mm - НЕ помогло. Фотошоп показывает, что все сканы в 300 dpi (может, это чисто формально?), а размеры в пикселях разнятся примерно в 2 раза - на нормальных и "четвертушечных" сырых сканах.

Раз разнятся - значит, так и есть, разные dpi. Оно и глазом видно, что 2-й скан - 600 dpi.
В кромсаторе есть специальная команда на этот случай - Image->Correct dpi. Пометить красным все "плохие" файлы и для них задать правильное dpi по этой команде, которая просто пропишет в файл нужное значение.


Цитата:

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

Ни в коем случае! А если на листе будет просто одна строка текста? Тогда кромсатор, что, должен отмасштабировать ее в 10 раз?


Цитата:

Нередко Кромсатор резко ошибочно делает deskew на файлах с картинками, проставление Art не помогает, помогает только exclude zone. Хотя Файнридер без проблем тут deskew делает. Нельзя ли подправить кромсаторный deskew в нужной степени

Цитата:

Это очень характерная и частая ошибка для таких сканов.

Спасибо за пример файла. Теперь у меня есть на чем тренироваться

ghosty

Цитата:

что должен делать Page V. align с опцией по умолчанию "A". Я, к примеру, давно уже привык вручную выставлять опцию "B" во всех случаях, когда блок текста выровнен по нижней части (в начале главы). Если я этого не делаю, текст выравнивается по верху. Но ведь "А" по идее обозначает "Automatic"

На самом деле это означает default Это из разряда исторических казусов
Поменять на D вроде бы тоже плохо - все уже привыкли к A. Я даже и не знаю, что лучше сделать.


Цитата:

Можно ли сделать следующим образом?
Указываем путь к малоразмерным BW файлам и к RAW. DK работает с малоразмерными файлами, после чего резаки переносятся на RAW.

Если размеры и имена у них одинаковые, то нужно сделать так. DK к BW. Сохраняем задание. Потом в папку, где BW, переносим RAW-файлы. Снова открываем задание, и кромсатор даже не почувствует подмены, что и требовалось.

monday2000

Цитата:

нельзя ли научить Draft kromsate ставить только один резак - разрезающий развороты? Как я понял, сейчас такого нет (или есть?). Есть лишь возможность выкинуть в опциях Draft kromsate все резаки, оставив только "Internals" - но это 2 резака, "вырезающих" серединку между сдвоенными сканами, а хочется, чтобы именно только 1 резак был.

Можно. Оставьте, как Вы и пишете, только Intarnals + в опциях драфта взведите галку Don't use int2 cutter.
Здесь Вы противоречите сами себе. С одной стороны - требуете убрать малоиспользуемые опции подальше или совсем, с другой - сами ведь сталкиваетесь с нестандартными ситуациями, когда без таких редких опций не обойтись. (Ср. с предыдущим пожеланием ghosty - довольно экзотическое, но при этом вроде бы и нужное. Или по смене носителя сканов на DVD)


Цитата:

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

Цитата:

Конкретно предлагаю: фичу "чистить за резаками" убрать в интерфейсе (просто выкинуть жаль, а имхо не мешало бы) куда-нибудь подальше (например, в ini-файл).

Тот уважаемый колхозник отсканировал для меня книг столько, сколько не сделали все, кто появляется здесь, вместе взятые. Причем книги он заказывал из другой страны! И фичей этой он пользуется до сих пор.

bolega

Цитата:

На самом деле это означает default Это из разряда исторических казусов
Поменять на D вроде бы тоже плохо - все уже привыкли к A. Я даже и не знаю, что лучше сделать.

Я- "за поменять"
Ведь многие думают(как и я) что А- это автоматически т.е. "как кромсатору видней и нужней"

Вы не ответили на

Цитата:

bolega

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

Вопрос
А почему это не организовать вообще без шифта?
Ведь если я трогаю резак, значит что-то там не так на автомате и пользователь знает что делает? (я надеюсь) Или для этого есть какая-то причина?

Сейчас при нажатой шифт идет перекос резака под углом.


У меня еще одна идея. Если б вы вынесли весь текст в какой-то *.lng файл, нашлось бы несколько человек и перевели бы все на несколько языков.
Но! обязательно вывести также туда возможность добавления подсказок в этот файл для каждого контрола
Тогда при наведении на него можно было бы сразу увидеть что это за фигня и для чего она.
И конечно сделать эту опцию отключаемой, так- как после некоторого времени это будет страшно раздражать


monday2000

Цитата:

Конкретно предлагаю: фичу "чистить за резаками" убрать в интерфейсе (просто выкинуть жаль, а имхо не мешало бы) куда-нибудь подальше (например, в ini-файл).

Ничего не надо выбрасывать. По мере усвоения кромсатора будут востребованы все фичи. Надо просто понемногу работать с ним.


bolega
Ах да, абсолютно прикольно "применение для всех" в окне Grey Enhance
Если не знать, что надо кликнуть правой клавишей по окну, никогда не догадаешся о этом просто так,-во всяком случае первый раз когда я это пробовал- я просто нажал "enable" думая, что это будет сделано для всех отмеченых, может быть добавить какую-то flat button
или еще что-то, чтобы было понятно, что здесь можна выбрать, к каким файлам этот cleaner нужно применить

bolega
Спасибо за ответ.

Цитата:

На самом деле это означает default Это из разряда исторических казусов
Поменять на D вроде бы тоже плохо - все уже привыкли к A. Я даже и не знаю, что лучше сделать.

А в чем именно состоял исторический казус? В том, что автоматически определять положение блока текста относительно страницы оказалось трудно? Мне кажется, это возможно.

Цитата:

Если размеры и имена у них одинаковые, то нужно сделать так. DK к BW. Сохраняем задание. Потом в папку, где BW, переносим RAW-файлы. Снова открываем задание, и кромсатор даже не почувствует подмены, что и требовалось.

Сейчас попробовал сканировать сразу в два файла. Проблема в том, что файлы всегда сохраняются в одну папку. Соответственно, с разными именами (напр., a001.tif и b001.tif). Поэтому придется еще и переименовывать. Мне кажется, было бы здорово, если бы Кромсатор умел работать с такими двойными файлами (или, м.б. даже сам их мог генерировать). Конечно, если это нужно только одному человеку, думать над этим не имеет смысла. Что скажут другие участники?

Не подскажет ли кто-нибудь такую программу, в которой можно было бы также сканировать сразу в несколько форматов, но в разные директории?

Добавлено:
terminat0r

Цитата:

Ничего не надо выбрасывать. По мере усвоения кромсатора будут востребованы все фичи. Надо просто понемногу работать с ним.

Подписываюсь под каждым словом

ghosty

Цитата:

Не подскажет ли кто-нибудь такую программу, в которой можно было бы также сканировать сразу в несколько форматов, но в разные директории?

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

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

Думаю, реализация этого в кромсаторе не помешала бы -именно работа с двойными файлами- то есть- проверка соответсвия размеров сканов, драфт на бв и подмена на тифы. Хотя для bolega видней как всегда.

terminat0r

Цитата:

Сейчас при нажатой шифт идет перекос резака под углом

Я тогда о shift совершенно забыл, поэтому и не сделал. Ctrl тоже занят. Осталось Alt использовать.


Цитата:

У меня еще одна идея. Если б вы вынесли весь текст в какой-то *.lng файл, нашлось бы несколько человек и перевели бы все на несколько языков.

Я этого до сих пор не сделал по одной причине - мне нравится английский язык своей компактностью. Напр., русские надписи во многих случаях просто бы не влезли в теперешние размеры контролов.
monday2000 прав насчет того, что automargings не совсем точно отражает свое назначение. Правильнее было назвать impliсit margins, но тогда бы пришлось здорово бы расширять закладку, а я все-таки хотел бы оставить по максимуму места для самого изображения.


Цитата:

Ах да, абсолютно прикольно "применение для всех" в окне Grey Enhance

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

ghosty

Цитата:

что автоматически определять положение блока текста относительно страницы оказалось трудно? Мне кажется, это возможно.

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


Цитата:

Сейчас попробовал сканировать сразу в два файла. Проблема в том, что файлы всегда сохраняются в одну папку. Соответственно, с разными именами (напр., a001.tif и b001.tif).

Если они отличаются только префиксом, то это не трудно реализовать. Я сделаю. Если при загрузке задания SK не найдет файлы, он попросит не только указать новое расположение, но и предложит искать по новому префиксу.

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

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

bolega

Цитата:

Он будет нормально работать только при соблюдении некоторых условий, которые к сожалению выдерживаются не всегда (если условия не выполнены, то я просто не знаю, как это сделать). Условия такие: резаки не должны отрезать белые пространства (по которым можно судить о выравнивании, точнее, резаки должны отрезать так, чтобы по остатку можно было однозначно судить о выравнивании;

Тут, на самом деле, большое пространство для маневра. А почему Вы считаете расстояние от резака? Есть ведь граница блока текста (margin). Далее, если мы возьмем самый распространенный вариант - когда сканируется книга/журнал/брошюра и все размеры страницы примерно одинаковы - то лучшим вариантом, ИМХО, будет просто явно указать координаты по Y (а можно и по X) для краев страницы.
Тогда алгоритм был бы примерно таким:
Если координаты краев не указаны, то кромсание выполняется не по "А", а по "D" принципу
Если координаты краев указаны, то
если расстояние от верхней границы блока текста до указанной верхней границы страницы существенно меньше расстояния от нижней границы блока текста до указанной нижней границы страницы, то тип выравнивания - "T";
если существенно больше - "B";
если примерно равно - "С".

Край страницы можно находить и автоматически в каждом случае - это либо граница белого/черного, либо край рисунка.

Теперь привожу мои выкладки по поводу "файлов-болванок".
Сегодня как раз мне попалась книга, которую пришлось сканировать в наилучшем качестве - 600dpi 8-bit RAW (старая пожелтевшая бумага, карандашные пометы и пр.).
Общий размер всех файлов - 4Gb
Средний размер файла - около 28Мb.

По моим прикидкам один только процесс DK занял бы у меня более 2-х часов. Но внимание: ведь после DK мне нужно еще проконтролировать правильность расстановки резаков, расставить где надо опции "A", "B", "C" и пр. Если бы я это делал на 30-меговых файлах, то и этот процесс растянулся бы более чем на час. Т.е. болванки оказываются нам нужны в таком случае не только для расстановки резаков, но и для навигации по файлам!
Теперь "хронометраж":
1. Поворот готовых сканов в IrFan'e с сохранением в папку А - 8 мин.
2. С помощью того же IrFan'a конвертация этих сканов в BW с сохранением в отдельную папку B - 10 мин.
3. DraftKromsate этих BW файлов - 12 мин.
(4. Проверка кромсания - примерно 10-20 мин.)

Далее меняю местами названия папок А и В - прекрасно! Все резаки на своих местах!
Итого (без учета проверки расстановки резаков) - 30 мин. против 2-3 часов. Может, кто-нибудь и раньше догадывался так делать, но я дошел до этой простой мысли только сегодня. В таком случае, я жираф, а те, кто знал, но молчал... нехорошие люди

Теперь насчет авто-DK новых сканов: в этом случае Кромсатор сможет автоматически выполнять и пункты 1, 2. Что высвободит целых 20 мин. времени на предобработку!
А если при всем при этом будет возможность переключать режим чтения: файлы-болванки (для навигации)/ оригиналы, то это будет просто песня

Добавлено:
Что делать, чтобы резаки не сдвигались в случае preview, напомните, пожалуйста.

Цитата:

Киньте в папку с .exe'шником .dll'ки
http://bolega.hotmail.ru/dlls-rename-to-zip.jpg (нужно сменить расширение и распаковать)
Должно начать запускаться.

Запрашиваемая Вами страница не найдена

Smokeer
http://rapidshare.de/files/6819398/sk_dlls.rar.html

Что-то совсем неладное с резаками творится в последней версии. Раньше только при Preview with resample они съезжали, а теперь и при Preview

bolega
При перекрамсывании ещё одной "плохой" djvu-книги возникла очередная проблема. Суть в том, что я не смог задать навешиваемые поля желаемого размера - пришлось довольствоваться полями такого размера, какого получилось само собой. Сканы были цветные в LZW. Вот образец скана + кромсаторное задание к нему:

webfile.ru/952126 будет доступен до 25.05.2006 00:07. (500 КБ) (Читайте readme внутри)

Всё это похоже либо на глюк, либо на ощутимый недостаток программы.

Ещё заметил такой глюк: когда после Draft kromsate я перемещаюсь со скана на скан по кнопке "]", то частенько вскоре после начала такого листания при нажатии на "]" Кромсатор задумывается на некоторый миг, затем быстро-быстро, почти молниеносно прокручивает вперёд не 1 скан, как должно быть при нажатии на "]", а 3!

Далее: При кромсании книги готовые порезанные сканы в 30-50% случаев получаются недостаточно точно отцентрованы по ширине. В этом случае в Result view нужно вручную доцентровывать сканы через "левый Alt + стрелка" (кстати, просто "стрелка", без Alt тут была бы имхо неизмеримо более удобна, т.к. часто случайно нажимаешь Alt, а стрелку забываешь, а нажатый Alt отнимает фокус, и надо лишний раз кликнуть на скан).

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

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

То есть сейчас мы визуально оцениваем в Result view равенство монотонных (белых) полей (слева и справа, главным образом). Идея в том, чтобы сделать специальные рабочие условные немонотонные "поля" (с небольшим залезанием на текст) - так, чтобы визуально было гораздо нагляднее - равны или нет реальные левое и правое поле. Тут, наверное, могут быть и другие конкрентные варианты реализации этой общей идеи.

ghosty

Цитата:

Тут, на самом деле, большое пространство для маневра. А почему Вы считаете расстояние от резака?

Потому что первое, что делает SK - отрезает по резаку. Анализировать можно только то, что осталось.

monday2000

Цитата:

Всё это похоже либо на глюк, либо на ощутимый недостаток программы

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

В новой версии я уже изменил метод центрирования, так что подождите новой версии.
Сдвиг без Alt сделаю. Будет настраиваемым.

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



Добавлено:
monday2000

Цитата:

Кромсатор задумывается на некоторый миг, затем быстро-быстро, почти молниеносно прокручивает вперёд не 1 скан, как должно быть при нажатии на "]", а 3!

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

bolega
Может быть я пропустил, и это уже кто-то просил, но нельэя ли в окне Edit -> Draft kromsate убрать по умолчанию галку из чекбокса Save after rotate?
Часто забываешь про нее и в результате сканы на диске перезаписываются, а хотелось бы исходники иметь первичные. К тому же при кромсании с CD или DVD лишнее сообщение о невозможности изменить эти сканы. По-моему, проще поставить эту галку тому, кто хочет сохранить развернутые сканы!
Та же просьба по галке в чекбоксе Preview в окне File -> Open ( Add files), если сканы большие то долго выполняется превью, кому нужно, можно включить его после выбора файла.

ghosty

Цитата:

Проблема в том, что файлы всегда сохраняются в одну папку. Соответственно, с разными именами (напр., a001.tif и b001.tif)

Пока можно воспользоваться функцией find and replace из любого редактора, напущенной на соответствующий .spt
Офтопик: как во vuescan получить сразу и грей и ч/б? Что-то я не соображу
Неужели поставить две галки на raw и tiff?

shch_vg

Цитата:

Может быть я пропустил, и это уже кто-то просил, но нельэя ли в окне Edit -> Draft kromsate убрать по умолчанию галку из чекбокса Save after rotate?

Хорошо. Оставлю как есть, но опция будет сохраняться в Ini и не нужно будет каждый раз отщелкивать.

Цитата:

Та же просьба по галке в чекбоксе Preview в окне File -> Open ( Add files), если сканы большие то долго выполняется превью, кому нужно, можно включить его после выбора файла.

Это я уже сделал. Аналогично.


Добавлено:
ghosty

Цитата:

Далее меняю местами названия папок А и В - прекрасно! Все резаки на своих местах!
Итого (без учета проверки расстановки резаков) - 30 мин. против 2-3 часов. Может, кто-нибудь и раньше догадывался так делать, но я дошел до этой простой мысли только сегодня.

В таком случае мне не надо ничего городить с подменой префиксов?


Цитата:

Теперь насчет авто-DK новых сканов: в этом случае Кромсатор сможет автоматически выполнять и пункты 1, 2.

Пункт 1 он и сейчас по умолчанию делает (save src after rotate)
Переключение наверное возможно, но зоны, имеющие смысл только для grey, sk не даст поставить на b/w-скане. Тем более, что уже появились новые picture-зоны
Это которые вырезаются и сохраняются отдельно, возможно, с другим dpi и цветом (индивидуальными для каждой из зон). В окне view result с ними можно делать все что угодно. Мучаюсь я с этим уже долго, в основном из-за необходимости синхронизации положения зон на выходе и на исходном скане (из-за обрезок, deskew, другого dpi, crop, merge pages и т.д.)

bolega

Цитата:

В кромсаторе есть специальная команда на этот случай - Image->Correct dpi. Пометить красным все "плохие" файлы и для них задать правильное dpi по этой команде, которая просто пропишет в файл нужное значение.

Для этого ведь нужно уметь подсчитывать реальное dpi. Обычный юзер это делать не захочет/не сумеет. Я вот смотрел в Фотошопе: оказывается, у тифа есть размеры одновременно в пикселях и в дюймах, а dpi = (пиксели * пиксели) / (дюймы * дюймы) (я так понял, я ведь в этих вещах тёмен абсолютно - не знаю пока, например, что такое "ресемплинг", и почему он удваивает количество пикселей и т.д.).

Я сделал проще - через Irfan View: отобрал отдельно все четвертушечные готовые сканы, пакетно увеличил их в 4 раза, пакетно примерно отрезал белое, полученные сканы вставил обратно в папку к нормальным и перекромсал всё заново. Геморрой, конечно, но зато не нужны спецзнания.

Цитата:

Предлагаю такое решение: ... Кромсатор ... будет в таком случае автоматически увеличивать текст на таком листе в 4 раза.

Цитата:

Ни в коем случае! А если на листе будет просто одна строка текста? Тогда кромсатор, что, должен отмасштабировать ее в 10 раз?

Я, наверное, неясно изложил свою мысль: как я понял, в результате кромсания разнобойных сканов получаются готовые листы 2 видов:
а. Нормальные.
б. Четвертушечные.
Третьего вида ведь не бывает? Если так, то, наверное, Кромсатор смог бы полностью программно отличить четвертушечные листы и автоматически преобразовать их в нормальный вид (в самый последний момент кромсания данной страницы).

Цитата:

Нередко Кромсатор резко ошибочно делает deskew на файлах с картинками, проставление Art не помогает, помогает только exclude zone.

Цитата:

Спасибо за пример файла. Теперь у меня есть на чем тренироваться

Эта проблема вообще имхо часто бывает на самых разных сканах - главное, чтобы там была картинка, и побольше. Найдите на КпНемо книжку "Перельман. Занимательная астрономия" 5 938 738 байт в серых поганых сканах - пример оттуда, там ещё с десяток таких примеров наберётся на всю книжку.

Цитата:

Но ведь "А" по идее обозначает "Automatic"

Цитата:

На самом деле это означает default

А что означает "default"? Как тогда текст выравнивается? Кстати, мне кажется, что хорошо бы сделать по-умолчанию выравнивание "С", а не "А". Если бы не дефицит места, то имхо лучше бы вообще вместо этих невнятных буковок поставить полные обозначения - "Left, Right, Center" и т.д - помню, как я ДОЛГО думал, что эти буковки значат.

Цитата:

Ведь многие думают(как и я) что А- это автоматически т.е. "как кромсатору видней и нужней"

Да-да, вот именно.

Цитата:

Здесь Вы противоречите сами себе.

Точно, не заметил. Борьба с четвертушками действительно экзотика. Можно так сделать: разделить в интерфейсе по группам фичи на:

1. Постраничные. (Должны остаться на виду, т.е., например, на нынешних вкладках. Это вкладка Pages, кажется, Quality, панель резаков, инфо файла.

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

3. Редко-экзотичные. (Это сырая идея, пока ничего не могу сказать. Возможно, в ini загнать).

Важно: В результате такого разделения будут достигнуты важнейшие результаты, а именно:

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

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

ghosty

Цитата:

Мне кажется, было бы здорово, если бы Кромсатор умел работать с такими двойными файлами (или, м.б. даже сам их мог генерировать).

А нельзя ли исходные цветные тифы перегнать в TIF-LZW и только с ними дальше и работать? (я, правда, не знаю - сжатие TIF-LZW - с потерей качества?) А вообще, думается, не самая плохая идея - генерировать Кромсатору временные BW-файлы для DK (правда, наползающие на текст тени будут становиться чёрными пятнами и мешать).

Но, имхо - эта идея - не для Кромсатора по той простой причине, что в кромсаторном интерфейсе надо бы сначала упорядочить более простые вещи, а уже потом добавлять что-то такое посложнее. Иначе к существующей интерфейсной каше добавится ещё новая.

Имхо, если такое делать грамотно, то надо вводить пакеты, как в Файнридере, а это грозит серьёзными потрясениями всему интерфейсу Кромсатора (хотя я был бы "за" ). Так что проще, как советует bolega - просто попеременно подсовывать Кромсатору то временные BW, то цветные тифы.

Цитата:

Не подскажет ли кто-нибудь такую программу, в которой можно было бы также сканировать сразу в несколько форматов, но в разные директории?

Да чего там - сканировать в Grey, а потом Ирфаном быстренько пакетно перегонять в BW.

Цитата:

Тут, наверное, могут быть и другие конкрентные варианты реализации этой общей идеи.

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

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

monday2000

Цитата:

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

а вот это очень и очень неплохая мысль?
или хотя бы цветом надписей выделить какие глобальные, а какие нет.

monday2000

Цитата:

А нельзя ли исходные цветные тифы перегнать в TIF-LZW и только с ними дальше и работать? (я, правда, не знаю - сжатие TIF-LZW - с потерей качества?)

У меня они в LZW по 30 мегов весят

Цитата:

А вообще, думается, не самая плохая идея - генерировать Кромсатору временные BW-файлы для DK (правда, наползающие на текст тени будут становиться чёрными пятнами и мешать).

Вы говорите правильно. Мне потому и пришлось сканировать в таком разрешении, что оригинал был очень плохого качества - в первую очередь, из-за сильного непостоянного фона. Естественно в первичных BW файлах он вылезал кое-где. Но тут нужно отдать должное алгоритмам boleg'и - DK ошибался лишь в редких случаях.

Цитата:

Но, имхо - эта идея - не для Кромсатора по той простой причине, что в кромсаторном интерфейсе

В интерфейсе ничего менять не придется. Ввести одну единственную кнопку: "Show original file".
В чем я хочу убедить вас, уважаемые коллеги, так это вот в чем. При необходимости обработки больших файлов введение BW-дубликатов существенно экономит время. Эта экономия складывается из снижения временных затрат на первичное кромсание (DK) и на переход от одного файла к другому при просмотре.
В случае DK прекрасно работает предложенный мной вариант. А вот если бы время перехода оставалось таким же коротким на всем протяжении работы...
У меня, к примеру, процесс перехода от одной страницы к другой занимает около 15 сек. Это ж повеситься можно Сразу скажу, машина не слабая (PIV3000, 1Gb).
Я предлагаю (на мой взгляд) очень простой вариант: если при обработке используются BW-дубликаты, то при переходе от файла к файлу (нажатие стрелок вверх/вниз, выбор файла мышью) производится чтение и отображение BW-дубликатов. В том случае, если мне нужно работать с оригиналом, я нажимаю "Show original file". Можно предусмотреть галочку "Always show original file".
Неужели никто с большими файлами не мучился?

ghosty
Полностью поддерживаю! Я мучился Действительно, когда сканируешь в сером 300 дпи, приходится очень долго ждать перехода с файла на файл и т.п. Думаю, Ваше предложение - отличное решение этой проблемы. По крайней мере с точки зрения пользователя, не знаю, насколько легко это технически реализуемо.

bolega

Цитата:

Пункт 1 он и сейчас по умолчанию делает (save src after rotate)

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

Добавлено:
vitaly1

Цитата:

Действительно, когда сканируешь в сером 300 дпи, приходится очень долго ждать перехода с файла на файл и т.п.

Ура! Спасибо за поддержку. 300дпи серого (по крайней мере, на моей машине) - это еще семечки по сравнению с 600дпи серого в RAW TIFF. С тех пор, как купил себе большой винт, все чаще использую RAW.

ghosty
Могу себе представить - мне как-то цветные пришлось ворочать, разрешение правда поменьше, но вначале мегабайт то ли 30, то ли 50 каждый весил. В общем проблема насущная, очень хочется, чтобы решение нашлось и реализовалось

shch_vg

Цитата:

Офтопик: как во vuescan получить сразу и грей и ч/б? Что-то я не соображу
Неужели поставить две галки на raw и tiff?

А Вы попробуйте

Господа, не опишет ли кто-нибудь подробно (и, желательно, в
расчете на полного идиота), как обрабатывать сканы книги,
в которой очень много карандашных помет?

Тут уже этот вопрос слегка обсуждался, но большими мастерами,
поэтому я (по скудоумию своему) не понял. Понятно только, что
сканировать нужно с помощью VueScan в RAW. Я так и делаю
всегда. А дальше-то как обрабатывать - какие параметры на каких
закладках в Кромсаторе выставлять?

Особо привлекательным кажется закладочка Histogram на Grey Enhance.
Для исчерканной страницы эта гистограмма у меня имеет два красивых
горба, один побольше, другой поменьше. Наверное, один соответсвует
типографской краске, другой карандашу. Смотрю и любуюсь. А что
дальше делать - не знаю...

Kazakalitopus

Цитата:

Тут уже этот вопрос слегка обсуждался, но большими мастерами,
поэтому я (по скудоумию своему) не понял.

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

Добавлено:
С гистограммой все просто: ставите галочку "Threshold", после чего выделяете на странице характерный фрагмент, включающий как буквы, так и карандаш. Этот фрагмент отобразится в окне Grey Enhance (справа). Двигая ползунки, подбираете нужные границы отсечения справа и слева, пока не отфильтруется весь карандаш на фрагменте. Обращайте особое внимание на сохранность всех элементов символов.

Насущная проблема частично решается отключением фильтра. Для grey сканов показ без фильтра вполне приемлим.
При включенном линейном фильтре для прорисовки каждой точки берется линейная комбинация из 3xNxN соседних точек, где N зависит от zoom и размера окна (примерно =5-10 точек, 3 означает три составляющие RGB). Можете представить, сколько выполняется вычислений при рендеринге.
При отсутствии фильтра на экран выводится просто каждая N-я точка.

bolega

Цитата:

Насущная проблема частично решается отключением фильтра.

Image->No zoom filter?
Да, спасибо, действительно полезная вещь. Время открытия снизилось с 15 до 6-7 сек.
Однако и это многовато, да и на скорость DK не повлияет...

ghosty

ghosty

Цитата:

У меня, к примеру, процесс перехода от одной страницы к другой занимает около 15 сек. Это ж повеситься можно

Я не работал с такими огромными файлами, поэтому мне интересно, сколько времени занимает переход в других прогах (e.g. ACDSee), Вы не сравнивали?


Цитата:

Image->No zoom filter?

Да. И еще недавно я писал про опцию в ini, которая заставляет кромсатор насильно сбрасывать фильтр для не-b/w файлов задания, даже если в меню она включена. Т.е. стали на b/w - фильтр работает, стали на grey - фильтр сам отключился.

bolega
Обрабатывая страницы с ч/б небольшими фото и текстом, воспользовался Вашим советом заключать все, кроме фото, в bitonal region и кромсать в сером. На мой взгляд, ч/б фото смотрятся гораздо лучше, чем при кромсании в ч/б.
Но в связи с этим возникает пара моментов, которые бы не помешали в новой версии ScanKromcator'а.

1. Реализовать возможность, заключая фото в region, задавать режим внешнего bitonal, т.е. что не попадает в область, то обрабатывается как bitonal.
Здесь, правда, придется реализовывать возможность заключения в такую зону нескольких мелких фото на странице.
Кстати, в Mouse-Up mode не хватает варианта Mark as bitonal region.

2. Т.к. приведенное выше кромсание в сером обрабатывается Document Express Editor-ом с теми же параметрами, что и ч/б страницы, хотелось бы в рамках одной задачи иметь возможность менять на вкладке Files список Color только для отдельных страниц (на которых есть ч/б фото).

И последнее, столкнулся с непонятной ситуацией:
кромсаю страницу 600дпи в сером, заключаю всю страницу, кроме 2 ч/б фото в bitonal region, ставлю дпи Half smaller или 300 (кстати эти два варианта отличаются тем, что в случае 300 предлагается понизить дпи у исходного тиффа), на вкладке Convert устанавливаю User=170 и получаю нормальный результат, только текст грязный. Уменьшаю User=160 и User=Normal, в обоих случаях фото обрабатываются как bitonal, а вместо двух неохваченных bitonal region областей появляется одна серая область лишь частично задевающая одно из двух фото. Странно!

bolega

Цитата:

Я не работал с такими огромными файлами, поэтому мне интересно, сколько времени занимает переход в других прогах (e.g. ACDSee), Вы не сравнивали?

Кстати, да. В том же IrFan'e переход занимает 1,5 - 2 сек, а в ACDSee 2.44 осуществляется практически мгновенно (с дорисовкой в теч. 0,5 - 1 сек).