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

» ScanKromsator СканКромсатор (Часть 3)

Автор: monday2000
Дата сообщения: 19.07.2009 10:29

Цитата:
Вот как выглядит новая иконка SK под Windows 98:

Странно, в другой раз перезагрузился под Win 98 - иконка выглядит уж нормально. Значит, глюк какой-то плавающий.

SK 5.92 что-то не захотел открываться под Win 98. Подумал-подумал - и всё-таки не открылся.

Сегодня вот не смог я что-то некие сканы покромсать ни в одной версии СК - выскакивало сообщение типа "Can not load 0016.TIF". И это сканы после Irfan View. А ACDSee нормально их все открывало. Всё это делалось под Win 98.

Пришлось повторно перегнать через Irfan View и кромсать уже под Win XP - тут всё прошло нормально.

Странно как-то...

Добавлено:
ИМХО в СК сканы вообще довольно медленно загружаются. Если сравнить скорость, с которой сканы листаются в СК по кнопкам q-w и в ACDSee по Page Up - Page Down - то небо и земля.

Так что результаты СК-отбработки лучше (т.е. быстрее) смотреть в ACDSee - а не в редакторе постобработки СК.

Добавлено:
bolega
СК (любой версии) не справился с deskew вот этого простейшего файла:

http://www.onlinedisk.ru/file/181311/ (410 КБ)

А вот deskew CT справился с этим сканом на-ура.
Автор: shch_vg
Дата сообщения: 19.07.2009 17:58
monday2000

Цитата:
SK 5.92 что-то не захотел открываться под Win 98.

SK 5.92 не работает и в win2000, это давно известный факт, так что говорить про Win 98.

bolega
Занимаюсь сейчас импортом сканов из PDF(DJVU). Сейчас извлечение отдельных листов из файла работает по такому принципу: вытаскиваются страницы, указанные в поле "Extract pages:", которые нумеруются подряд, начиная с номера, заданного в поле "Numerates files from". Однако, извлекая вразнобой страницы, очень часто лучше бы было, если бы для более простой идентификации странице присваивался ее номер в книге, т.е., извлекая страницы 5, 8-9, при Numerates files from=1 получались бы сканы с номерами 5,8 и 9. Можно ли это реализовать?
Автор: bolega
Дата сообщения: 19.07.2009 19:20
monday2000

Цитата:
СК (любой версии) не справился с deskew вот этого простейшего файла:

Cпасибо за пример. Завтра проверю на новой версии.
СК делает deskew в несколько раз быстрее СТ. Изначально я пошел на уступки качеству выигрывая в скорости. Сейчас я нашел компромисс.

shch_vg

Цитата:
Можно ли это реализовать?

А что делать, если на странице много изображений (таких книг процентов 30). Поэтому я и нумерую подряд, по мере извлечения. Вот сейчас попался файл, на котором каждая страница состоит из порядка ста кусочков. Из них половина имеет размер 1х1.
Но что-нибудь придумаю.
Автор: shch_vg
Дата сообщения: 19.07.2009 19:33
bolega

Цитата:
А что делать, если на странице много изображений

Тем более хотелось бы знать, к какой странице каждый из этих кусков относится.
Автор: bolega
Дата сообщения: 19.07.2009 20:16
shch_vg

Цитата:
Тем более хотелось бы знать, к какой странице каждый из этих кусков относится

Приделаю к именам префикс из номера страницы в pdf. При условии, что не задан numerate from. Можно сделать и суффиксом. Как лучше?

monday2000

Цитата:
лучше (т.е. быстрее) смотреть в ACDSee

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

Автор: ghosty
Дата сообщения: 19.07.2009 20:28
bolega

Цитата:
Учитывая, что просмотр результатов в СК нужен в первую очередь для пост-процессинга, а не для мульт-просмотра картинок, я решил в свое время не делать упреждающего кэширования.
Небольшая поправка - при проверке резаков также необходимо быстро одну за другой просмотреть все странички.
Автор: Torino
Дата сообщения: 19.07.2009 21:26
bolega
1. заметил такую особенность: создаем прямоугольное выделение
назначаем ему тип picture zone
выделяем вновь созданную зону ЛКМ
теперь при попытке создать новое выделение ничего не получится
как на текущей странице, так и при переходе на следующую
до тех пор пока не снимем выделение с picture zone

2. Предложение (не связанное с предыдущим абзацем):
в окне Picture zone properties есть кнопки Next zone и Previous zone
при достижении последней и первой соответственно зоны на странице дальнейшее нажатие на эти кнопки ни к чему не приводит
Предложение в этих случая сделать переход на ближайшую следующую и ближайшую предыдущую соответственно страницу, содержащую зону

3. Не получается выровнять автоматом эту картинку (1,4 Мб)
Автор: shch_vg
Дата сообщения: 20.07.2009 01:57
bolega

Цитата:
Приделаю к именам префикс из номера страницы в pdf. При условии, что не задан numerate from. Можно сделать и суффиксом. Как лучше?

На мой взгляд нагляднее префикс (тогда при сортировке по имени файла все сканы одной страницы будут расположены рядом).
Что значит, "не задан numerate from"? Наверное, не задан numerate from, отличный от по умолчанию (=1). Хотя не очень понятно, почему нельзя начать отсчет, считая, что первая страница импортируемого файла имеет номер, равный numerate from? В этом случае, если, например, книга из 200 страниц, а первая страница ее (по нумерации книги) является, допустим, 6-ой страницей в PDF, то, задав numerate from = 996, я получу нормальную нумерацию страниц, увеличенную на 1000, т.е. возможность быстро находить нужную мне страницу книги.
Автор: bolega
Дата сообщения: 20.07.2009 07:20
ghosty

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

На входе - тоже редактор. Плюс для каждой страницы нужно еще расставить несколько десятков опций. Если сканы - не ч/б, отключите zoom filter, тогда листать будет довольно быстро. Это уже как-то обсуждалось.

Torino

Цитата:
заметил такую особенность

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

shch_vg
Понятно
Автор: bolega
Дата сообщения: 20.07.2009 09:39
Torino

Цитата:
Не получается выровнять автоматом эту картинку (1,4 Мб)

Новая версия сделала все правильно

monday2000

Цитата:
СК (любой версии) не справился с deskew вот этого простейшего файла:

Вранье.
У меня старая версия сделала нормально. Вероятно, что-то Вы намудрили с опциями обработки или порогом бинаризации. Дайте задание, в котором получилось неправильно.
Автор: Torino
Дата сообщения: 20.07.2009 09:45

Цитата:
Новая версия сделала все правильно


спасибо!
Автор: ghosty
Дата сообщения: 20.07.2009 11:02
bolega

Цитата:
Если сканы - не ч/б, отключите zoom filter, тогда листать будет довольно быстро. Это уже как-то обсуждалось.
Отключил давно уже. Но думаю, что та задержка, которая есть, только на пользу - иначе будем пропускать ошибки расстановки резаков.
Другое дело, при быстром листании (листаю колесом мыши) странички не прорисовываются вообще, а резаки накладываются друг на друга. Поэтому не всегда получается сохранить оптимальную скорость листания и в таких случаях приходится возвращаться назад. Можно ли сделать, чтобы страницы прорисовывались в любом случае?
(Хотя в таком случае могут возмутиться те, кто привык, используя быструю прокрутку перескакивать через несколько страниц).
Автор: monday2000
Дата сообщения: 20.07.2009 12:06
bolega

Цитата:
Вранье.
У меня старая версия сделала нормально.

М-да, странно. У меня на работе правильно проделался deskew с этим примером - в СК 5.92. Но дома почему-то не делался. Попробую дома ещё раз. Может, просто глюк какой-то трудноуловимый (впечатление, что deskew дома на этой картинке просто не запустился).

Добавлено:
Некоторые соображения по картинкам:

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

Дело в том, что зачастую сканы кромсаешь по 2 раза: сначала начерно (с Grey-Enhance, бинаризацией), потом уже начисто (те, которые получились после начерно). Естественно, в этих бурных перипетиях теряется всякая связь между исходными сканами и вырезанными из них картинками - и поэтому невольно приходишь к выводу, что самое практически-реальное - это просто на конечной стадии повставлять картинки (в уже готовые ЧБ-сканы) в Фотошопе вручную назад.

Т.е. все эти благие намерения - постоянно хранить связь между исходными сканами и вырезанными из них картинками, а потом одним нажатием кнопки вернуть их (картинки) назад - ИМХО нежизнеспособны (т.е. реально-непрактичны) - по крайней мере, сейчас.

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

Вот тогда действительно можно было бы полностью автоматически вставить вырезанные картинки назад. А сейчас вот приходится долбиться и вставлять вручную.
Автор: bolega
Дата сообщения: 20.07.2009 12:22
shch_vg
Вспомнил наконец-то, почему при импорте делаю сквозную нумерацию. Все хорошо, когда импортируете один файл. Но когда делаете import-add, т.е. когда в задание добавляется pdf, начинаются большие сложности. Если использовать префиксы, имена (номера страниц) могут повторяться и это чревато перезаписью файлов, что недопустимо. Проверка на перезапись довольно муторна: не в смысле убедиться, что файл с таким именем есть или нет, а в смысле, на что менять имя, если файл уже существует. Тогда придется или менять префикс, или сдвигать его (и опять проверять, что он свободен и т.д. до бесконечности), что резко снижает значимость этого самого префикса, да и вообще все тормозит. Всего этого не нужно, если использовать сквозную нумерацию.

Добавлено:
monday2000

Цитата:
Естественно, в этих бурных перипетиях теряется всякая связь между исходными сканами и вырезанными из них картинками

Наоборот, это абсолютно неестественно.
Никакая связь не теряется, если последующие задания делать не вручную, а с помощью команды Create out-task. Эта команда делает новое задание из выходных файлов текущего задания, при этом сохраняется полная связь с картинками


Цитата:
долбиться и вставлять вручную

Учите матчасть, чтобы не долбаться вручную
Автор: Torino
Дата сообщения: 20.07.2009 12:47
Напомните мне пожалуйста существует ли возможность вращать зоны во Viewer'e ?
Если да, то как? ))
Автор: ghosty
Дата сообщения: 20.07.2009 14:33
Torino

Цитата:
Напомните мне пожалуйста существует ли возможность вращать зоны во Viewer'e ?

В режиме Zones в окне зоны (правом) контекстное меню аналогично меню для всей страницы.
Автор: shch_vg
Дата сообщения: 20.07.2009 15:47
bolega

Цитата:
Всего этого не нужно, если использовать сквозную нумерацию.

Честно говоря, не очень понял Ваши аргументы. А что мешает при добавлении пдф продолжить нумерацию дальше, как будто не два пдф, а одно, состоящее их двух.
Лично для меня, кстати, добавление пдф такая экзотика, что даже не могу сходу вспомнить, использовал ли я его хотя бы раз.
Единственный вопрос - что делать с numerate from при добавлении пдф?
На мой взгляд, ничего, т.е. как и сейчас игнорировать это поле и продолжить нумерацию дальше.
Автор: bolega
Дата сообщения: 20.07.2009 16:09
shch_vg

Цитата:
Лично для меня, кстати, добавление пдф такая экзотика

Давайте договоримся раз и навсегда: не упоминать больше о том, что что-то для кого-то мол, экзотика. Видимо, каждый считает, что его опыт - это истина в последней инстанции, и других вариантов быть не может. Еще как может! Случаи бывают самые удивительные.
Возьмите недавние дебаты по поводу Ctrl+Shift-ALt. У одного одни привычки, у другого - другие. Или совсем свежий пример - в топике по СТ обсуждают, какое действие должен выполнять mouse scroll: один говорит - увеличение, другой - уменьшение, третий - должно быть как в играх, четвертый - мол, какие нафиг игры, должно быть как в gimpe и т.д. Напоминает одну известную басню.
IMHO, спорить тут бессмысленно. Я буду делать по возможности настраиваемым. Но в разумных пределах, графический движок, знаете ли, тоже не резиновый


Цитата:
А что мешает при добавлении пдф продолжить нумерацию дальше, как будто не два пдф, а одно, состоящее их двух

А какже тогда определить на какой странице 2-го (или к примеру 10-го) файла находится изображение, если у меня будет только его номер. Вычитать сумму страниц последовательных файлов, пока не попадешь на нужный?
Автор: monday2000
Дата сообщения: 20.07.2009 16:09
bolega

Цитата:
Никакая связь не теряется, если последующие задания делать не вручную, а с помощью команды Create out-task. Эта команда делает новое задание из выходных файлов текущего задания, при этом сохраняется полная связь с картинками

Только что попробовал я этот Create out-task (в 5.93). Кое-как получилось у меня. Но есть некоторые недостатки. Думаю, лучше сделать так:

1. Записывать -out.spt не в папку с исходными сканами - а в папку с обработанными сканами (т.е. в папку "out"). Поскольку именно обработанные сканы потом будут загружаться заново в СК для вторичной (или всех после неё последующих) обработки. При первичной обработке ИМХО -out.spt не нужен (т.к. нужная информация имеется в СК в данный момент) - он делается как раз для последующих обработок.

2. Указывать пути в -out.spt в относительном - а не в абсолютном виде. Это оправданно, так как в той же самой папке будут "сканы с вырезанными картинками" и "картинки". Сейчас у меня СК заругался на изменившийся абсолютный путь и потребовал указать новое местоположение (это излишняя сложность).

3. Невозможно загрузить -out.spt и просто сделать одно лишь слияние и всё. СК скажет - "nothing to do". Приходится ещё назначать, скажем, deskew.

Добавлено:
Конечно, ещё было бы здорово делать внутри "out" доп. папку для вырезанных картинок (и туда класть -out.spt). Ну да ладно, это можно пока и вручную делать. Сделайте хоть 3 этих пункта - благо, их совсем нетрудно и быстро можно Вам сделать.

Добавлено:
А, вот чуть не забыл важный момент. При загрузке -out.spt СК хочет увидеть в т.ч. вырезанную картинку. Без неё - непонятно, будет ли всё дальше благополучно работать? Хотелось бы так, чтобы без проблем грузилось без вырезанных картинок, и чтобы -out.spt корректировался при необходимости при последующих обработках (если они меняют геометрию сканов). Я-то предполагал, что после первой же обработки вырезанные картинки надо вручную отделить в совершенно отдельную некую папку - и дальше работать уже чисто с самими сканами. И только в самом конце сделать слияние назад. (Хотя, конечно, можно и не отделять картинки в отдельную папку - а просто повторно грузить уже папку "out" на новое кромсание - я пока не пойму, что удобнее).

Способен ли СК сейчас на такое "сопровождение" -out.spt без загрузки вырезанных картинок? А с загрузкой таковых - будет ли СК корректировать -out.spt при выполнении изменяющих-геометрию операций (при повторном и последующих кромсаниях)?

По крайней мере, сейчас все эти манипуляции сопровождаются ворохом неприятной ругани на тему "такой-то файл не найден".
Автор: shch_vg
Дата сообщения: 20.07.2009 19:09
bolega
Честно говоря, не думал, что моя безобидная фраза вызовет такую реакцию с Вашей стороны.

Цитата:
А какже тогда определить на какой странице 2-го (или к примеру 10-го) файла находится изображение, если у меня будет только его номер. Вычитать сумму страниц последовательных файлов, пока не попадешь на нужный?

Чтобы мне пытаться предлагать что-то, нужно знать, а как это реализуется сейчас. Мне непонятно, почему нынешний механизм решения этого вопроса нельзя распространить на предложенный.
Автор: Torino
Дата сообщения: 20.07.2009 19:27

Цитата:
В режиме Zones в окне зоны (правом) контекстное меню аналогично меню для всей страницы.

Ух ты, не знал про этот режим, спасибо )
Автор: shch_vg
Дата сообщения: 20.07.2009 23:07
bolega
А возможно теоретически в один пдф объединить серые сканы с одним значением JPG(2000) quality с цветными сканами с другим значением JPG(2000) quality?
Автор: bolega
Дата сообщения: 21.07.2009 07:44
shch_vg

Цитата:
А возможно теоретически в один пдф

В данный момент это невозможно. Качество сжатия, отличное от глобального, можно задать только для зон.
Можете сделать 2 pdf и потом объединить в Adobe.
Выделите цветные, нажмите process selected.
Поменяйте качество, имя файла, инвертируйте выделение (Edit-> Select group->Invert selection) и снова process selected.


Добавлено:
monday2000

Цитата:
Записывать -out.spt не в папку с исходными сканами - а в папку с обработанными сканами

Логично. При условии, что в File->Options->Save->Def folder=scans folder.


Цитата:
Указывать пути в -out.spt в относительном - а не в абсолютном виде

Бесполезно. При первом же сохранении будут абсолютные пути.
Относительные пути используются только для команды create sub-task, чтобы скрыть дисковую структуру пользователя при передаче задания.


Цитата:
в той же самой папке будут "сканы с вырезанными картинками" и "картинки".

Поясните, что Вы имеете ввиду под "картинками" и "вырезанными картинками".


Цитата:
Невозможно загрузить -out.spt и просто сделать одно лишь слияние и всё. СК скажет - "nothing to do". Приходится ещё назначать, скажем, deskew

Чтобы сделать слияние, нужно получить выходные файлы. Не будет же СК сливать с исходными сканами!
СК поддерживает обработку даже если все опции выключены. Тогда он просто копирует файлы в вых. папку. Только после этого можно сделать слияние.
deskew для этого абсолютно не нужно.
Только я все равно Вас абсолютно не пойму. Зачем делать на предыдущем этапе выделение зон, чтобы потом снова их слить с необработанными файлами???
Автор: slava_kry
Дата сообщения: 21.07.2009 08:04
shch_vg

Цитата:
А возможно теоретически в один пдф объединить серые сканы с одним значением JPG(2000) quality с цветными сканами с другим значением JPG(2000) quality?

Оффтопик, просто для сведения.
Через Акробат это возможно, возможно объединить любые растровые файлы.
Акробат файлы формата JPEG2000 не модифицирует, а импортирует "как есть"
Автор: bolega
Дата сообщения: 21.07.2009 08:08

Цитата:
будет ли СК корректировать -out.spt при выполнении изменяющих-геометрию операций (при повторном и последующих кромсаниях)?

Если под геометрией подразумевается изменение размеров картинок во _ВНЕШНИХ_ программах - то естесственно, нет. Если подразумевается изменение размеров картинок в _ДРУГИХ заданиях (а не в текущем), то тоже нет.
В задании вообще не хранятся физические размеры картинок, хранятся только координаты их областей на странице. Размеры картинок и областей могут быть абсолютно разными, ведь dpi скана и картинок могут отличаться (это допускается). Например, картинка может иметь размер 1х1 пиксель, а отображаться (растягиваться) на пол-страницы к примеру.
Именно поэтому в 5.93 я ввел возможность вызывать непосредственно из СК внешний редактор для редактирования зон. В этом единственном случае СК следит за геометрией, и если она изменилась, правит ко-ты зоны. И то это не всегда поможет. Например, юзер где-то извне отрезал от картинки область слева. Геометрия изменилась. СК по идее должен пропорционально изменить размеры зоны (это просто) и ее положение. Со вторым - полная неопределенность. Куда должен СК переместить верхний угол зоны? Вправо? Оставить как есть? Он этого не знает и знать не может, т.к. не знает, с какой стороны от картинки вы отрезали кусок.

slava_kry

Цитата:
Акробат файлы формата JPEG2000 не модифицирует, а импортирует "как есть"

СК делает также. Вы не поняли вопроса. Проблема не в том, как засунуть в pdf файлы, а как их сперва получить с разным качеством
Автор: slava_kry
Дата сообщения: 21.07.2009 08:16
bolega

Цитата:
а как их сперва получить с разным качеством

тогда каюсь
Но это не может ни одна программа (по крайней мере я не сталкивался ни разу за свою полиграфическую бытность)
Автор: bolega
Дата сообщения: 21.07.2009 09:09
slava_kry
У меня к Вам тогда один вопрос. Acrobat отображает jpg2000 как бы в два прохода, послойно (по крайней мере, после кодека kakadu и СК): сначала размытым, потом уже резким. Это фича формата или acrobata?
Автор: slava_kry
Дата сообщения: 21.07.2009 09:25
bolega

Цитата:
Это фича формата

Да, она самая. Эта же фича используется для быстрого отображения геоснимков, т.е. переход от низкого разрешения к более высокому. Количество этих "отображений" даже можно назначать при кодировании (по крайней мере в Какаду).
Это происходит при любом кодировщике.
Автор: bolega
Дата сообщения: 21.07.2009 10:01
slava_kry
Спасибо.
А можно ли как-то акробат заставить показывать сразу, т.е. чтобы он сначала сформировал картинку, а потом бы уже выбросил ее на экран.
Такой же эффект бывает, когда на странице очень много картинок, они появляются поочередно, по мере прорисовки ее акробатом. Понятно, что делает он это специально, для быстроты листания, но может у него есть и "немигающий" режим?
Автор: slava_kry
Дата сообщения: 21.07.2009 10:38
bolega

Цитата:
но может у него есть и "немигающий" режим?

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


Добавлено:
Кстати, требуемый вами метод реализован в Foxit Reader'е. Значит есть возможность

Страницы: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102

Предыдущая тема: мнение о Maxthon


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