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

Цитата:

Окончательная версия
http://rapidshare.com/files/173680769/sk-5.92.zip.html

Залил к себе:
http://www.djvu-soft.narod.ru/scan_kromsator_v5_92_full.rar (3,40 МБ)

Цитата:

Окончательная версия
http://rapidshare.com/files/173680769/sk-5.92.zip.html
Исправлены баги, включая утечку памяти

Как я вижу слова: Version 5.92beta
Это не окончательная версия?

chesskom

Цитата:

Это не окончательная версия?

Забыл поменять. Правильно в About

bolega

Цитата:

Окончательная версия
http://rapidshare.com/files/173680769/sk-5.92.zip.html
Исправлены баги, включая утечку памяти

Не хочет работать под Win2k, 5.91 работает

bolega
А можно убрать надпись вверху beta и заоодно поставить вот эту супер иконку на кромсатор?
Зеркало

pavel_nik_563
А как это проявляется?

bolega
В Process Explorere вижу что он запускается, но через секунду пропадает и все...

pavel_nik_563
DLL лежат где надо?

bolega
С 5.92beta та же история
Да DLL лежат в папочке с самой прогой

Может проблема в exe-архиваторе (upx)

bolega
После распаковки имеем:

pavel_nik_563
Спасибо, теперь понятно

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

Горизонтальный блочный сдвиг:


Вертикальный блочный сдвиг:


От этого слегка корёжатся буквы - если через них проходят "линии излома".

Буква, через которую прошёл вертикальный блочный сдвиг:

monday2000
Это после стандартной обработки ? или вы использовали какие то фильтры?
Такого раньше не замечал..... Прям как будто файн ридер поработал)))))

MIHMIH007

Цитата:

Прям как будто файн ридер поработал)))))

скорее всего так и есть. Это не визуальный дефект, а дефект самого скана

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

Здрасте давно слышал о кромсаторе но небыло времени начать разбираться поэтому в данный момент накопилось очень много сканов не обработанных и не переведенных в DjVu формат а так жаль книг много и постоянно добавляються новые. Активно заливаю книги на сайты правдо специфическая тематика книг (восновном котлостроение теплоэнергетика и прочие схожие) немного сужает данный круг. Хотел начать пользоваться кромсатором но немного отпугивает англиский интерфейс програмы. Возмозно есть способы русифицировать програму для упрощения работы с ней
подскажите пожалуйста.

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

Но всеже хотелосьбы а хочеться оно извесно хуже чем болит!

Poltava_PGS
ресторатор в руки и вперёд))))
Я начал переводить и даже русик выкладывал к старой версии.... но слилось много недогований))) никому тут русская версия не нужна....
А если честно то уже привыкаешь к английской..... так что лучше посетите все ссылки которые в шапке весят это будет для вас поучительнее и быстрее)))

Если подвести мышку к иконкам в сабже, то во всплывающих окошках нередко написана подсказка и на русском.

Poltava_PGS
посмотрите инструкцию ScanAndShare там все на картинках показано

Не пойму, баг это, или я что-то не так делаю.
1. Делаю DK c такими опциями (выделен первый файл в списке):
Kromsate = From current alternate
Pre-rotate = -90 | Odd |Save after rotate

Все кросает и поворачивает правильно.

2. Теперь выделяю второй файл в списке и вызываю DK, выставив такие опции:
Kromsate = From current alternate
Pre-rotate = 90 | Odd |Save after rotate
(все то же самое, но крутим в другую сторону)

Кромсает, но не поворачивает.

Что делать?

ghosty
Я посмотрю.
А пока можете выделить все нужные через один (Edit->Select group->...) и применить к ним поворот (Service->Rotate and save->selected)

bolega
Видимо, это я перемудрил - дублировал опции: "From current alternate" и "Odd".
Наверно, можно либо удалить один из этих выпадающих списков, либо если задействован один из них, делать недоступным другой.

Сейчас разбираюсь с финализацией.
Пока самое неудобное - отсутствие возможности post-processing'a.

Вы пишете:

Цитата:

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

Я не смог найти команду Book properties в контекстном меню VR.

В контекстном меню команды Select Book size и Rotate selection не могут быть выбраны. В то время как соответствующие им кнопки работают. Попробовал повернуть, но получилось, что блок текста вышел за пределы контура, а контур стал неизменяемым.

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

Добавлено:
Заметил намного больше ошибок Deskew по сравнению с 5.91. Сканы чистые без таблиц и рисунков (взяты отсюда).
Субтаск

Добавлено:
После того, как я сделал финализацию, нужно было переобработать одну страницу. Когда я ее решил финализовать в режиме VR, просто исчез контур, и ничего более не произошло...

Добавлено:
Снял галочку с первого файла, ответил, что да, исправить нумерацию. При этом обработанный ранее первый файл остался в папке "Out" с именем "0001.tif_".

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

Пока, после первого знакомства, есть одно предложение.

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

По моему мнению, такое поведение программы было бы более логично.

ghosty

Цитата:

Я не смог найти команду Book properties в контекстном меню VR

Правильно. Эта команда доступна только тогда, когда уже расчитаны размеры страниц. Сразу после обработки (при page width/height=auto) эти размеры еще не известны, поэтому и команда недоступна.


Цитата:

В то время как соответствующие им кнопки работают

Rotate selection не должен работать. Это я забыл заблокировать значит.


Цитата:

Когда я ее решил финализовать в режиме VR, просто исчез контур, и ничего более не произошло

Все правильно! Когда известны размеры книги, VR сразу же перключается в режим Book preview (кнопка с книгой вверху). Поэтому на экране Вы видите то, как будет выглядить страница, как будто ее уже финализировали! Это кажется, что только исчез контур, на самом деле меняется физически и сам выходной файл (добавляются поля).


Цитата:

Снял галочку с первого файла, ответил, что да, исправить нумерацию. При этом обработанный ранее первый файл остался в папке "Out" с именем "0001.tif_".

Этот вопрос не так давно обсуждался. Я объяснял, почему он остается.

Хочу также всем еще раз напомнить, что контур, который отображается - это не линия, по которой страница будет отрезаться! Сначала прибавятся поля, и только потом отрежется! Поэтому не стоит подгонять контур идеально под каждую бородавку на буквах. Плюс-минус десяток-другой пикселей (при 600dpi) абсолютно ни на что не влияет.

Alexx S

Цитата:

При обработке без финализации не вычищать области за резаками, а маскировать их

В при любом режиме перед обработкой идет обрезка по резакам! (именно по резакам, а не по контуру) Это аксиома, идеология программы (отрезать мусор и тени). Иначе зачем тогда они нужны?? Представьте, что исходный файл - разворот, если ничего не отрезать, а маскировать - sk так и будет его "таскать" по всем алгоритмам и окнам (целиком разворотом) ??? И какие объемы памяти для этого нужны, страшно подумать (не забывайте о 300dpi gray->600dpi gray)


Цитата:

По моему мнению, такое поведение программы было бы более логично

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

bolega
Мне сложно что-либо возразить, не зная дальнейших планов по развитию этой функции. С другой стороны, при длительной работе над проектом зачастую глаз "замыливается", по себе знаю - начинаешь цепляться за устаревшее решение вместо того, чтобы полностью его откинуть (это не про кромсатор, а про мою конструкторскую работу). На данный момент лично для меня наиболее удобной была бы следующая последвательность действий:
1. Работа с макетом страницы.
-расстановка резаков, проверка правильности их положениея, выравнивание блока на странице, определения размера полей.
2. Подбор параметров бинаризаци.
3. Обработка и чистка мусора.

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

Для того, чтобы мои доводы были более понятны приведу пример того, как я работал вчера.
Обрабатывалась книга с большим количеством таблиц, повернутых на 90град.
В результате, на всех таблицах резаки были расставлены неверно, кроме того, каждая 10я-20я страница имела отрезанные номера.
Поскольку я, прежде, всего, хотел опробовать новый режим, то проверку правильности расстановки резаков в основном окне я не производил.
В итоге, мне понравился режим отображения миниатюр в VR , но при обраружении неправильно обрезанных страниц мне приходилось выходить в основное окно, править расположение резаков и заново обрабатывать эти страницы по полному циклу. Более того, поскольку я не видел уже обрезанный текст, то обнаружить ошибку стало сложнее.

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

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

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

К пункту "Do not finalize" добавить пункт "Do not resample". Получится, фактически, аналог "Preview" на вкладке Quality. Качество отображения можно снизить и до 150дпи.
Что это даст:
-появиться возможность реализовать скрытие обрезанного текста и корректировку положения резаков. Да и обрезанный текст можно будет не полнстью скрывать, а сделать серым
-обработка будет гораздо более быстрой, самые ресурсоемкие алготирмы не выполняются.
-финализация, помимо окончательного добавления полей будет в себя включать и ресемлинг с бинаризацией.
-можно будет добавить команду "Preview with resample", для правки параметров бинаризации и визуальной оценки качества страницы не надо будет перезаписывать файл на диске.
-при этом существующий метод не затрагивается, отличия только в том, что при финализации выполняется дополнительный набор команд.
-отсуствует основное существующее противоречие - для исправления положения резака требуется выполить полный цикл с чисткой мусора, поворотом, резапмлингом, бинаризацией и прочими алгоритмами.

Alexx S

Цитата:

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

А я лично это считаю очень ненормальным (по крайней мере если сканы - не ч/б). Мне нужно точно видеть качество скана (букв): гладкие они или рваные (от этого будет зависеть какой despeckle), корявые ли (нужно ли использовать сглаживающий фильтр), есть ли дырки, блеклости и т.д. Это все будет влиять на то, какой мне профиль применить.

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


Цитата:

В итоге, мне понравился режим отображения миниатюр в VR , но при обраружении неправильно обрезанных страниц мне приходилось выходить в основное окно

В финальной версии я ввел возможность просмотра результата обработки прямо в главном окне: Result->Show output files in win. Поверх основного окна появится либо одно, либо два (если есть развороты) окна, в которых будут отображаться выходные файлы, эти файлы автоматически синхронизируются с текущим выбранным сканом. Попробуйте, может это Вам поможет

Добавлено:

Цитата:

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

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

Добавлено:

Цитата:

по себе знаю - начинаешь цепляться за устаревшее решение вместо того, чтобы полностью его откинуть (это не про кромсатор

Это мне знакомо, да, думаю, и каждому знакомо