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

bolega
Ложка дегтя в бочке меда.
Переводил в ТИФФ ПДФ, содержащий кроме ч/б три цветных страницы. Одну страницу Ваша программа взяла, две другие сделала черными с серой полосой вверху совсем с другим разрешением.

P.S. При более внимательном рассмотрении все оказалось еще хуже. Не удалось перевести еще 24 черно-белые фотографии, тоже получились все черные с серой полосой вверху. Программа PDFtoTIFF корректно вытащила эти страницы в тифы сс 150 дпи в цвете 24в.

P.S.S. По ходу этого нашел ошибку (?) в Вашей программе. При попытке вытащить из ПДФ отдельные страницы и при указании в окне PDF Import в поле Numerate from значения, большего 1, нумерация все равно делается с 1.

bolega
Столкнулся еще с одной неприятностью в версии 5.9. Просматриваю в Result view страницы, обработанные в ч\б 600дпи. При установленном выравнивании по низу страницы нумерацию страницы помещает ниже остальных. (в 5.8 то же самое) Пытаюсь передвинуть текст всей страницы вверх, заключив его в прямоугольную зону, но при нажатии в контекстном меню пункта Move selection или нажатии Cntrl+M получаю окно с текстом Cannot open clipboard. Причем забивается clipboard и у параллельно запущенной версии 5.8 и у остальных приложений. После закрытия версии 5.9 работа с clipboard восстанавливается и версия 5.8 на том же самом задании делает то же самое перемещение.
Кроме того в версии 5.9 вышеупомянутая ошибка происходит только тогда, когда я захватываю весь текст на странице. Стоит мне не включить в захват номер страницы внизу, как перенос срабатывает нормально.
Еще две интересные детали: перенос текста без номера страницы + последующий перенос номера страницы сработал нормально, НО справа от текста на полях появился какой-то мусор, который пришлось уберать отдельно.

bolega
В опциях Кромсатора у меня стоит Priority=Ниже среднего. Запускаю экземпляр, Windows Task Manager показывает у sk59 Set Priority=Normal.
Это normal?

shch_vg

Цитата:

Одну страницу Ваша программа взяла, две другие сделала черными с серой полосой вверху совсем с другим разрешением.

Такое происходит если в pdf для каких-либо изображений используется wavelet-сжатие (если открыть pdf в текстовом редакторе, например по F3 в wincommander, то о наличии такого сжатия говорит присутствие строк /Filter/JPXDecode. Посмотрите есть ли она в Вашем случае). Я уже писал, что пока кромсатор не может импортировать такие сканы. Скоро я это исправлю.


Цитата:

Столкнулся еще с одной неприятностью в версии 5.9

Посмотрю. А почему Вы не используете для сдвига всей страницы (ничего не выделяя) просто Alt-стрелки? Шаг сдвига задается в тулбаре.


Цитата:

В опциях Кромсатора у меня стоит Priority=Ниже среднего

С этими приоритетами одна беда. Использую Win-api функции для его изменения. Windows возвращает, что все ок, т.е. ошибку не возвращает. А ничего не меняет...
Кажется, срабатывает только "очень низкий".
Пока что я не знаю, что делать.

Добавлено:
skrt

Цитата:

заметилл такую вещь (может она уже описывалась)

Такого вроде бы никогда еще не наблюдалось. А какие именно параметры поменяли?

bolega

Цитата:

Посмотрите есть ли она в Вашем случае

Встретилась ровно столько раз, сколько было неудачных сканов!

Цитата:

А почему Вы не используете для сдвига всей страницы (ничего не выделяя) просто Alt-стрелки? Шаг сдвига задается в тулбаре.

Потому что не знал об этом. А ведь действительно работает.
А для каких целей в тулбаре присутствует кнопка со звеном цепи?

bolega

Цитата:

Такого вроде бы никогда еще не наблюдалось. А какие именно параметры поменяли?

кое-где расставил "Page h.align"
и на закладке convert выставил опцию lowlight

попробую смоделировать - тогда точно скажу. Но не уверен - потому как сколько работаю - такого не было никогда.
Хотя таски запомненные вроде бы не загружал

skrt
Используете версию 5.9? И сканы - мультистраничный тиф? И включен режим use threads? Если так, то тогда понятно

shch_vg

Цитата:

А для каких целей в тулбаре присутствует кнопка со звеном цепи?

Синхронизирует файлы в главном окне с файлами в окне просмотра результата.

bolega

Цитата:

Синхронизирует файлы в главном окне с файлами в окне

Это-то я смог перевести.
А что это значит содержательно?
Зачем их нужно синхронизировать?

bolega

версия 5.6а
сканы - тифф но не мультистраничные.


Цитата:

И включен режим use threads?

а это что за опция и где она??

skrt

Цитата:

а это что за опция и где она??

File->Options..., закладка Processing окошко Use threads

Цитата:

shch_vg:
А что это значит содержательно?
Зачем их нужно синхронизировать?

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

xitsa

Цитата:

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

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

Поработал тут немного с Кромсатором (v. 5.9), в первый раз столкнулся. Прога - супер! Но почему она не работает под Win98? При обработке изображений вылезает окно с ошибкой: мол, указан неправильный параметр. Более редкий вариант: не хватает памяти, чтобы завершить опреацию. Под ХР на том же компе с тем же кол-вом оперативы все проходит нормально. Как я понял, прога нормально обрабатывает изображения и под Win98, затык происходит при попытке записать результат на диск. Почему тут такое игнорирование Win9х?

XPEHOMETP
Может у автора проги 98-ые банально на комп не ставятся, дровишек не хватает, FAT`а на винте нет и пр .
Кстати, кто нибудь под WINE кромсатор запускал?

VadimirTT
Цитата:

Кстати, кто нибудь под WINE кромсатор запускал?

Я запускал под crossover'ом -- внешне всё работало замечательно, но после обработки иногда оказывались сильно започены 1-2 страницы на книгу. Видимо что-то в процессе обработки не срабатывает. Поскольку особо тесной интеграции Кромсатора с другими программами не требуется, я решил, что надёжнее пускать его под чем-то вроде virtualbox.

bolega
Версия 5.9 не смогла импортировать PDF-файл версии 1.5.
Выдается сообщение:"Ошибка при открытии файла ХХХХХХ.pdf!
Возможно файл открыт другим приложением или запаролен"
Файл в этот момент не используется другими программами его можно просмотреть Акробатом.

Разобрался! Файл был read-only.

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

shch_vg

Цитата:

Разобрался! Файл был read-only.

Я уже сам столкнулся с этим. Уже исправлено, теперь read-only не является препятствием.
А что за файл? Название можно, может у меня такой тоже скачан.


Цитата:

кнопка в тулбаре со звеном цепи

Это чтобы например, опустить окно просмотра резултата мышкой, посмотреть на исходник и вернуть окно обратно.

bolega

Цитата:

А что за файл? Название можно, может у меня такой тоже скачан.

Пост vmik http://forum.ru-board.com/topic.cgi?forum=93&topic=2486&start=180#14

P.S. Первый ПДФ, который мне не удалось разобрать до конца никакими программами, включая Вашу.

shch_vg
Там опять же JPXDecode

bolega

Цитата:

Там опять же JPXDecode

Это так, но первая страница-обложка вообще Вашей программой пропускается.
Именно из-за JPXDecode?
Программа pdftotiff выделила почти все страницы кроме почему-то 3-х фото (причем не последних).

shch_vg

Цитата:

Именно из-за JPXDecode?

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


Добавлено:
Хотя нет, похоже pdftotiff похоже не извлекает изображения, а рендерит их, т.е. как бы печатает в тиф-файл. Мне такой подход не нравится, я предпочитаю извлекать из pdf оригинальные изображения (т.е. в том виде, в котором они были туда засунуты), а не рисовать их.

bolega
Я уже задавал интересующий меня вопрос, но получил ответ на другой. Меня интересует, как Ваша программа при импорте определяет, с каким разрешением записана та или иная страница. Дело в том, что в других программах разбора pdf на tiff-ы в опциях можно задавать вертикальные и горизонтальные установки DPI, в Вашей эти параметры не задаются, а при разборе pdf тем не менее получаются разные разрешения для текста и обложек. Конечно, меня интересуют не технические детали этого, а возможность хотя бы приблизительно самому определять, с каким DPI содержится информация в конкретном pdf. М.б. это можно делать при просмотре, допустим, в Акробате? Часто встречаются pdf, в которых при просмотре размеры страниц скачут от размера на весь экран до маленького прямоугольника, как, например, в книге Решевского (следующий пост за постом vmik-а) на развороте 53.
Можно ли в этом случае оценить на глаз разрешения 52 и 53 разворотов?
Кстати, разобрав эту книгу Вашей программой, я вижу 96 DPI, что явно неверно, т.к. размер разворота 3507х2480.

Цитата:

PIRASOFT
We tried helping you. But what can we do if you tend to make your work even harder.
The whole technology is optimized for grey scans. If you scan in grey mode, I am ready to write a short instruction with only 3 or 4 short sections.
But if you want to go on scanning in BW, I cannot help you. Alas!

Academician Ghosty:

I am trying to read all english posts. I see this post by you and pirasoft.

Please explain me in detail what you mean by:

The whole technology is optimized for grey scans.

Which technology is optimized and in what sense. Give some concrete examples
of how the algorithm is optimized for grey scan ?



automatically translated to russian:
[q] PIRASOFT
Мы старались помочь вам. Но что мы можем сделать, если вы, как сделать вашу работу еще труднее.
Вся технология оптимизирована для серой сканирует. Если сканирование в режиме серой, я готов написать короткое обучение только 3 или 4 коротких раздела.
Но если вы хотите перейти на сканирование в BW, я не могу вам помочь. Увы! [/ q]

Академик Ghosty:

Я пытаюсь читать все должности английский. Я вижу эту должность вы и pirasoft.

Пожалуйста, объясните мне подробно, что вы имели в виду по:

Вся технология оптимизирована для серой сканирует.

Какая технология оптимизирована и в каком смысле. Дайте несколько конкретных примеров
о том, каким образом алгоритм оптимизирован для сканирования серого?

mengzhiyong

Цитата:

Which technology is optimized and in what sense. Give some concrete examples
of how the algorithm is optimized for grey scan ?

By happy coincidence I have just written about that here.
Here is a quotation from that forum: [more]The fact is the man, who tried to make the e-book, actually spoiled it from the beginning by using JPEG for encoding pages with text. Let us zoom in:

We can see a sort of haze around each symbol - that is known as JPEG-artifact. These sort of artifacts along with low resolution of the images make greek symbols sometimes totally unreadable.
So:
1) If you want to scan a book, the minimal resolution must be no less then 300 dpi 8-bit GREY!!!
2) NEVER USE JPEG for encoding book pages!!!
3) YOU MUST NOT USE GREY IMAGES to make a book. Look at this book: it's size is 106Mb - CRAZZY!
SO THAT MEANS YOU MUST ALWAYS PROCESS your scans. And this, in its turn, means you have to crop them, clean up, despecle, binarize, deskew, (most often) resample to 600dpi and so on. Yes, it seems to be a lot of work, but 1) you can do most of these tasks automatically; 2) YOU MUST DO IT to make your book readable!
Here is the same book (the same scans) that someone (not me) tried to recover:
hxxp://r@pidshare.com/files/72609072/Greek_-_Smith__Melliush._Teach_yourself_Greek__1968__T__335s_.djvu.html
I do not think he managed to make it much better. But its size now is ONLY 5Mb and the decoding speed is much, much faster. Feel the difference!!![/more]

shch_vg

Цитата:

как Ваша программа при импорте определяет, с каким разрешением записана та или иная страница

Очень просто. Из pdf я получаю 2 значения: размеры изображения и размеры области на странице (в пунктах, которые легко перводятся в дюймы), в которые это изображение выводится. Поделив одно на другое, получим dpi. Здесь есть одна неприятность. Если изображение занимает всю страницу, то размеры области в общем случае не имеют никакого значения. Т.е. при создании pdf можно указать хоть метр, хоть километр, в обоих случаях acrobat (и любой другой просмотрщик) все равно правильно покажет страницу (за счет простого масштабирования в процессе вывода на экран). Главное - лишь бы соблюсти пропорции. Теперь понятно, почему может получиться 96 dpi. Если программа, которая создавала pdf, описала неправильно размеры страницы, и области тем самым, (т.е. как бы "натянуло" скан на те размеры, которые указаны и взяты возможно с потолка), то несмотря на правильное отображение, правильное dpi уже не узнать (только методом тыка).
Теперь как узнать эти параметры. Размеры в пикселях хранятся в pdf непосредственно в символьном виде, их можно увидеть, открыв pdf в текстовом редакторе (тэги Width, Height после каждого /Image).
Размеры области, в которую выводится скан, напрямую в pdf не хранятся вообще. Вместо этого хранится матрица, которая переводит логические координаты сканы (а они всегда принимаются равными 0..1) в физические координаты страницы. Эта стандартная 4х4 однородная матрица линейных преобразований содержит в себе результат поворота, смещения, масштабирования и сдвига (shear) изображения. Т.е. в общем случае описывает непрямоугольную область вывода скана. Матрица в pdf может задаваться не единожды (часто так и бывает), в этом случае чтобы получить окончательную матрицу, нужно их все собрать и последовательно переменожить.
Таким образом, чтобы получить физические координаты области скана, нужно перемножить координыты 4-х точек изображения на эту матрицу, в результате получим четыре точки (left, top, right, bottom), которые и описывают область скана в дюймах. Как я говорил, в общем случае (при наличии поворота) это может быть ромб.
Визуально увидеть в текстовом редакторе матрицу практически невозможно, во-первых, из-за того, что она разбита на несколько подматриц, которые еще нужно найти и объеденить (перемножить), а во-вторых, в отличие от тэгов, она сжимается (методом deflate)
Вроде бы все.

Добавлено:
Еще подрбно объясню, откуда взялось именно 96dpi в том файле.
Как обычно задется физический размер pdf-страницы, состоящей из скана? Берется скан, из него берется dpi, умножается на размеры скана и получается физический размер. Этот размер и устанавливается как размер pdf-страницы (бывают правда и извращения, когда размер страницы берется A4 или A5, и в него уже помещается скан). Теперь представим, что в скане не было прописано dpi, например, это был gif. Обычно в этом случае программы берут dpi монитора, т.е. 96. Исходя из этого и получается неверный размер страницы. Повторюсь, для отображения такого pdf это не играет никакой роли.
То, что кромсатор восстановил 96dpi, говорит как раз о том, что он сделал все правильно, другое дело, что оно уже при создании pdf было неправильным. Также это говорит о том, что сканы скорее всего были гифами. Вообще-то, из pdf можно многое узнать о самом сканировщике (пол, возраст), но это уже другая история

bolega
Возникла серьезная проблема с sk 5.9: при повторной обработке книги (с перезаписью ранее уже созданых страниц) sk доходит до определенной страницы и молча слетает. Я попытался обработать эту же книгу, но записывая результаты в другой (пустой) каталог. sk проходит в обработке чуточку дальше и приостанавливает работу с сообщением Fail to save file. Пытаюсь зайти в File->Options и вижу последовательно два сообщения
---------------------------
ScanKromsator 5.9 [res2]
---------------------------
Access violation at address 7C9122BA in module 'ntdll.dll'. Read of address 036F8070.
---------------------------
OK
---------------------------
и далее
---------------------------
ScanKromsator 5.9 [res2]
---------------------------
Failed to retrieve tab at index 0.
---------------------------
OK
---------------------------
кроме того было одно сообщение по поводу access violation in user32.dll (я их сохранил, могу выложить позднее)

Что прикажите делать? (я могу выложить в сеть обрабатываемые мной файлы - это около 5Мб) Не связан ли этот глюк с мой ОС (т.е. не с sk)?

PS обработку веду с отключенной галкой Use threads

Добавлено:
bolega
Похоже, проблема все же в sk: я попытался обработать ту же книгу на другом компьютере - эффекты те же ;(

bolega
Большое спасибо за столь подробный ответ на мой вопрос. К сожалению, я из него для себя извлек мало пользы, но это потому, что я никак не могу более точно сказать, что же мне нужно.
Попробую еще раз сформулировать. Ваша программа сама разбирает пдф на тифы и ставит в них дпи (какое ей удастся определить). Меня же интересует, как поступать в случае работы, допустим, с программой pdftotiff, для которой нужно задать установки DPI по горизонтали и вертикали. Я понимаю, что можно задать любые, и тогда программа будет переводить, но как я понимаю, любое повышение/понижение разрешения, мягко говоря, не способствует улучшению тифов. Хотелось бы как-то определить, каким было разрешение у большинства тифов в момент помещения их в данный пдф.
Уф, вряд ли мне удастся объяснить более толково.

shch_vg
Я Вас прекрасно понял.
Из моего ответа следует, что внутри pdf dpi никак не хранится, оно акробату сто лет не нужно. Определить его можно единственным способом, который я описал. Если pdftotiff не предоставляет информации, которая нужна для расчета dpi (размеры изображения, и главное, область в дюймах, занимаемую изображением), значит определить его с помощью нее невозможно никак. Поскольку как я понял, pdftotiff не извлекает изображения, а рисует их, то есстественно, он будет спрашивать у пользователя dpi, чтобы отрисовать в тиф именно в таком dpi. Т.е. то dpi, которое он получает от вас, ничего общего с реальным dpi не имеет, а определяет лишь качество отрисовки.

Добавлено:
kontiky

Цитата:

я могу выложить в сеть обрабатываемые мной файлы - это около 5Мб

Выложите, и задание тоже. Спасибо

Вопрос для Bolega.
Извиняюсь, можно внести предложения по улучшению работы при редактировании обработанных листов после операции Process! в окне Result View?

bolega

Цитата:

Выложите, и задание тоже. Спасибо

Вот. Посмотрите пожалуйста, что там за напасть (смотрите задание res2).

kontiky
Похоже, какой-то баг закрался в deskew ч/б сканов.
Точно причину пока установить не могу, т.к. баг проявляется не сразу, а только через некоторое время опосредствованно. У меня Ваше задание сбоит в самых непредсказуемых местах, каждый раз в разных. Из-за этого и причину найти пока не удается. От usethreads не зависит.
Попробуйте поставить для всех файлов Art deskew. Должно помочь.

bolega
Почему-то введение exclude или picture zone на странице ухудшает качество upsample при использовании размывания и сглаживания, причем на обеих страницах разворота. Возможно, это тот же эффект, что недавно описывал shch_vg? Задания для версии 5.9:
http://rapidshare.com/files/73085287/zone_influence.rar