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

Mikhaluch
по всей видимости развивается, но никого не поддерживает, все сами как то обходятся .

При конвертации DJVU файла с помощью SK первые 10 страниц файла конвертируются корректно.
На 11-й и последующих страницах вылетает с ошибкой приложение DjVuDecode.exe (Приложение будет закрыто. Приносим извинения за неудобства).
В чем может быть проблема?

Torino
Попробуйте взять DjVuDecode.exe из DjVuSmall и туда подсунуть. Если проблема останется - тогда попробуйте декодировать DjVu-файл посредством DjvuOCR - он самый устойчивый к такого рода ошибкам (кстати, туда тоже можно подсунуть DjVuDecode.exe из DjVuSmall).

monday2000
Спасибо! Подмена exe-шника помогла.

Еще вопрос:
на одной из страниц расположен сложный рисунок (практически без ортогональных линий) и одна строка текста.
Мне не удается задать настройки для deskew, при которых страница будет выровнена корректно.
Возможно ли задать угол выравнивания для одной страницы вручную?

Torino

Цитата:

Возможно ли задать угол выравнивания для одной страницы вручную?

Да. Pages->Special- ставите галку на deskew, задаете знак угла и сам угол. Угол можно померить прямо на скане линейкой (Ruler в контекстном меню, затем тянете мышкой резиновую линию вдоль строки текста)

Добавлено:
moishe1

Цитата:

И еще вопрос : заметил, что изображение стало немного бледнее. Что с этим можно поделать?

Вы преобразуете в b/w?
Несколько способов. Поднять порог, autolevels, unsharp mask (radius=6, strength=2-3). Кстати, последняя опция хорошо справляется со сканами, на которых есть бледные участки или неравномерная освещенность. Если очень бледные, то strength=4-5

Цитата:

Pages->Special- ставите галку на deskew, задаете знак угла и сам угол

Спасибо! Получилось.

а как (чем) можно максимально автоматизировать преобразование и разбивку по статьям/темам сканов (pdf/djvu) журналов (текст плюс серые/цветные картинки) в html + картинки ?

ukpyr
Во-первых, абсолютно не ясно, зачем это может быть нужно, во-вторых, с такими вопросами лучше сюда, наверное:
http://forum.ru-board.com/topic.cgi?forum=93&topic=1624&glp#lt

AOT: все-таки самое неудобное в последней версии - это некорректная работа Deskew. Придется, видимо, откатиться на 5.91.

1. При импорте DjVu указывал разные виды сжатия (и не сжатый) для выходного tiff. А на выходе всё равно получаю G4Fax. Это баг? Если нет, то как исправить?
2. При импорте PDF был случай, когда вместо страниц импортировались только картинки с этих страниц!!! Вот только сейчас стал подозревать, что этот PDF был сборкой текста и картинок... И всё же это баг импорта.
bolega
3. Опечатка: File - Profiles... Вкладка Options - Вместо "Smart contour" написано "Save contour".

ghosty
ОК, deskew откачу как было раньше.

denver 22

Цитата:

При импорте DjVu указывал разные виды сжатия (и не сжатый) для выходного tiff. А на выходе всё равно получаю G4Fax. Это баг? Если нет, то как исправить?

Посмотрю. Но насколько я знаю, LZW в принципе не предназначен для b/w-сканов, только для серых/цветных. Это как jpg в принципе не может сжимать b/w, а если какая-то прога сжимает, значит, идет автоматическая конвертация в оттенки серого.


Цитата:

При импорте PDF был случай, когда вместо страниц импортировались только картинки с этих страниц!!! Вот только сейчас стал подозревать, что этот PDF был сборкой текста и картинок... И всё же это баг импорта.

Это не баг. Я намеренно не импортирую векторные pdf. Это из области растеризации TTF и PS-шрифтов, а это уже другая песня. Причем эта операция на порядок лучше и быстрее делается самим акробатом, поэтому я не стал это делать. Прог для растеризации PDF хватает. Почему я ввел импорт pdf? Потому что ни одна прога не сможет импортировать сложные страницы в виде зон. Растеризовать всю страницу как единое целое - пожалуйста. Разбить страницу на несколько файлов - пожалуйста. А совместить их как зоны - только в SK.

По поводу "нового" deskew.
Мои наблюдения.
Раньше, если на странице был и рисунок и текст я не думая выставлял Art deskew.
Поворот шел дольше, но практически без ошибок.
Попробовал такой же подход в 5.92.
Теперь при установленном Art, текст полностью игнорируется и выравнивание идет по элементам рисунка.
Убираю Art - работает вроде корректно.

Torino
Art режим не претерпел никакого изменения. То, что Вы в конкретном случае столкнулись с этим, говорит о том, что рисунок внес максимальный вклад в наклон (при art используется Hough transform и выбирается точка максимума).
Если рисунок таков, что его внешняя оболочка близка к выпуклому прямо- или многоугольнику, то тогда при простом deskew он не оказывает никакого влияния на искомый угод наклона, и определяющий вклад остается за текстом. При Art, наоборот, форма оболочки не имеет никакого значения, зато имеет значение наличие и количество составляющих его прямых линий (а точнее, "ориентация полигона" как говорят в геометрии, которую можно определить высчитав собственные векторы фигуры).
Была мысль перед определением skew избавляться от крупных элементов типа рисунков и таблиц, но бывают случаи, когда текста мало, а имеющиеся рисунки и линии таблицы, наоборот, служат хорошим (и единственным) ориентиром для определения угла наклона.
Так что тут как говорится палка о двух концах.

Может есть смысл добавить новый инструмент "Указать приоритетную зону для определения угла поворота" ?
При запуске которого, на странице можно щелкнуть внутри текста, таблицы, рисунка и Кромсатор будет определять угол поворота по данным, лежащим в окрестностях щелкнутой точки?

Torino

Цитата:

Может есть смысл добавить новый инструмент "Указать приоритетную зону для определения угла поворота" ?

Нет, имеет смысл заключить рисунок в exclude-зону. При определении угла в SK содержимое таких зон не учитывается.

Понятно, спасибо.

Даже файнридерный deskew в редчайших случаях ошибается.

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

Небольшой момент:

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

Я не припоминаю, чтобы об этой детали где-нибудь когда-нибудь упоминалось.

Вероятно, это некий типичный приём для просмотрщиков графики.

monday2000
Это и в Photoshop реализовано (сейчас CS10 юзаю). Про AutoCAD я вообще молчу...

SK 5.9 beta
Вроде баг вылазит:

Если выделить в Result View область, потом ее вырезать (Ctrl+X), вставить (Ctrl+V) и передвинуть на новое место, а затем кликнуть мышкой в другое место, чтобы снять выделение, то справа от ранее выделенной области остается мусор в виде пунктирных черточек.

P.S. Область выделял по белому фону, т.е. никак мусор не мог захватить.

P.P.S. Перегонял книгу 300dpi gray -> 600dpi BW

djdtyfhu

Вы не указали, была ли копируемая область Picture зоной и делали вы совмещение Picture зоны и общего фона (Zoes -> Picture zones -> Merge..)?


Добавлено:
А у меня вот какой вопрос, скажи мне пожалуйста, как лучше сканировать 300 dpi или 600dpi? Просто для нового сканера разница не значительная, а с точки зрения Кромсатора - что лучше? могу попробовать, но все-же совет хочу. Кажется, что ворочить 600dpi серого, а уж подавно цветного растра тяжеловато. Или сканить в 600 Ч.Б.?

Добавлено:
P.S.
Вопрос конечно же ко всем, описался!

Gazoved
что за сканер?

Цитата:

Кажется, что ворочить 600dpi серого, а уж подавно цветного растра тяжеловато.

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

Gazoved

Если скан изначально в 600 dpi, то исключается операция ресемплинга.
Т.е. обработка должна быть быстрее.
А вот при просмотре исходников, загрузка сканов медленее будет.
Я сам в 600 gray сканирую на промышленном сканере.

Купил - Plustek OpticPro A360
Кромсатор ворочает 600 ч.б., а не серый, по крайней мере мне так кажется.
Плохо то, что исходники будут место отжирать, сейчас уже несколько сотен гигабайт (приближается к Тб) сожрали (более 200 книг ).

bolega

При клике средней кнопкой мыши в СК маркируется файл.
Логично, что при повторном клике галочка будет сниматься.
Но этого не происходит. Может стоит это изменить?

Есть предложение: добавить в СК возможность сохранения маркировки файлов для последующего восстановления (как в Тотал Коммандере - Save selection).

Gazoved

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

Gazoved

Цитата:

Кромсатор ворочает 600 ч.б., а не серый, по крайней мере мне так кажется

Нет, если исходники - 300 dpi, то сначала идет upsample до 600 dpi серого, и только потом фильтры, т.е. ворочает как правило серый. Ворочать ч/б практически бессмысленно.

Torino

Цитата:

При клике средней кнопкой мыши в СК маркируется файл.
Логично, что при повторном клике галочка будет сниматься.
Но этого не происходит. Может стоит это изменить?

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


Цитата:

Есть предложение: добавить в СК возможность сохранения маркировки файлов для последующего восстановления (как в Тотал Коммандере - Save selection).

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

djdtyfhu
Скорее всего, что точки остаются только на экране, т.е. это ошибка прорисовки измененной области. В само изображение эти точки не попадают. Я так думаю.


Добавлено:
shch_vg

Цитата:

Кстати извлечение нескольких рядом расположенных страниц реализовано в импорте PDF, но вот с полем Numerate from та же беда.

Исправил. И добавил возможность извлечения произвольного набора страниц, например, задать можно так: "2,3,7-10,35"
Аналогично сделаю для djvu


Цитата:

Жаль, что в 5.92 осталась ошибка предыдущих версий при импорте DJVU - не работает поле Numerate from в окне DJVU import. Любое значение этого поля игнорируется, нумерация всегда начинается с 1.

Кстати, если импортируете через Add djvu (или Add pdf) и в папке уже есть файлы с такими же номерами, то кромсатор начнет нумеровать не с 0001 (и не с Num from), а с номера, на единицу больше существующего. Это избавляет от необходимости следить за перезаписью импортированных файлов и задавать Num from.

Напомню, что при Import pdf/djvu создается новое задание. При Add pdf/djvu файлы добавляются в конец существующего задания, при этом СК сам контролирует имена, чтобы не допустить перезаписи уже существующих файлов

Есть 2 вопроса:
1. Как изменить цвет интерфейса программы?
и
2. Когда интерфейс будет переведен на русский язык?
Извините, если кто-то уже задавал такие вопросы. Спасибо.

Dimock

Цитата:

Как изменить цвет интерфейса программы?

О цвете чего именно идет речь? Кое-какие настройки (напр, цвет фона редактора) можно изменить в File->Options


Цитата:

Когда интерфейс будет переведен на русский язык?

Пока не знаю.