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

Цитата:

P.S. Как же хорошо, что теперь есть Scan Tailor. На его фоне мне теперь закрытость исходников СК всё больше и больше представляется чем-то постыдно-аморальным, просто непристойность какая-то.

Точно! Даешь в массы исходники СК, Windows 7 и AutoCAD до кучи.
А то работаю в Автокаде и понимаю, что без исходников это просто аморально.

Цитата:

закрытость исходников СК всё больше и больше представляется чем-то постыдно-аморальным, просто непристойность какая-то.

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

хочется пофлудить на эту тему, добро пожаловать.

Цитата:

Спасибо. Исправлю.
dll действительно не нужна, в одном модуле просто забыл удалить ссылку на нее

Когда можно ожидать исправленную версию?

xvii
Подожду до понедельника. Может еще чего вылезет.

В целом работать с СК становится с каждой версией все приятнее, и работает он с каждым разом быстрее и предсказуемее.
Что сразу бросается в глаза - резкое снижение ошибок DK. Даже в самых трудных случаях (перевернутые таблицы) теперь не ошибается.
Давно ждал новых, более аккуратных методов despeckle и illum.corr - для старых книг они могут оказаться незаменимыми.

Становятся менее очевидными настройки пар Blur-Sharpen. C появлением новых методов, думаю, возможно, лучше было бы их упорядочить, выстроив действительно пары и выделив для этих пар одну закладку: Blur+Sharpen. Для каждой пары можно было бы установить рекомендуемые диапазоны парных значений, возможно, с учетом разрешения скана (можно ли такие значения вычислить?).

Режим автоматического расчета порога бинаризации в моем случае всегда очень сильно занижает порог (в среднем на 20 единиц относительно правильного).

P.S. Если говорить о ScanTailor, то я уже высказывал предположение, что ему, возможно, придется пройти тернистый путь СК, чтобы стать, с одной стороны, хоть в какой-то степени универсальным, а с другой, удобным в использовании. В очередной раз попробовал СТ и вновь остановился на бинаризации - абсолютно никакого пространства для маневра. Т.е., ИМХО, СТ подходит только для очень качественных новых книг

bolega
Кто-то собрался плотно потестить на выходных, как же они будут это делать без Grey enhance?
В понедельник будет уже поздно

Arcand

Цитата:

Кто-то собрался плотно потестить на выходных, как же они будут это делать без Grey enhance?

Я из директории дллки не выкидывал, так что у меня все работает прекрасно

ghosty

Понятно, значит я поторопился.

ghosty

Цитата:

Режим автоматического расчета порога бинаризации в моем случае всегда очень сильно занижает порог (в среднем на 20 единиц относительно правильного).

Это хорошо, если всегда. Тогда можно будет предусмотреть просто поправку, типа Auto+10, Auto+20.


Цитата:

Даже в самых трудных случаях (перевернутые таблицы) теперь не ошибается

Но есть еще противные случаи, когда ошибается, напр., если сбоку - вертикальный текст.


Цитата:

более аккуратных методов despeckle

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

bolega

Цитата:

Это хорошо, если всегда. Тогда можно будет предусмотреть просто поправку, типа Auto+10, Auto+20.

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


Цитата:

Но есть еще противные случаи, когда ошибается, напр., если сбоку - вертикальный текст.

Если имеется в виду текст повернутый по вертикали (на 90 град.), то у меня такой уже встречался - ошибки не было. Если имеется в виду текст, вынесенный на поля - сбоку от основного блока текста, то это действительно плохо: при обработке текста с нумерацией строк народ очень мучается. Можно ли ввести в DK наряду с "text vert. sensitivity" также и "text horiz. sensitivity"?


Цитата:

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

Как всегда снимаю шляпу, но как же это можно сделать при отсутствии OCR?
Представьте себе что мы сделали выборку символов, собрав из определенной книги все значительно искаженные "и" и "н". Теперь предъявим их группе людей, попросив определить, где "и", а где "н". Уверен, процент ошибок будет очень велик (~50%). Если же мы предъявим те же буквы другой группе, но уже в составе слов, процент распознавания будет приближаться к 100%.
Если не способен определить человек, будет не способен и любой алгоритм (основанный на анализе битмапа одного символа), разве нет?

Цитата:

В ней имеются страницы с плохо пропечатанными областями

Для таких страниц включайте:
Unsharp 6/5/1
Gauss blur=1
Enhance contour=10/70/1/Auto=on

Не удержался, краем глаза глянул.
Порог действительно ниже нужного на 10-20ед.
Наткнулся на ошибки descrew, причем в одном случае поворот был в разные стороны в зависимости от порга (при отключенном GE). Завтра-послезавтра попробую выловить закономерность на чистой версии (записывал поверх старой версии в сборке от ghostly)

Alexx S
Если сможете выложить файлы, где неправильно deskew, будет хорошо.
Deskew действительно полагается на тот порог, что Вы указали (либо использует адаптивный, если выходной формат - не b/w). Поэтому от фонаря его ставить не стоит. СК предполагает также, что нет теней - удалены либо bckgr clean-ом, либо corr.illum-ом (это не относится к случаю когда на выходе - не b/w). Если оба условия не выполняются, то и смысла в deskew нет - на выходе все равно ничего хорошего не получится. Т.е. если пытаться проверять deskew просто так, по принципу "а если ломом его?", то результат может быть не тот, что ожидается.

Некоторые непонятные аспекты работы програмы:

импорт pdf(если изображение jpeg2000) = чёрный экран.
Странно, pdfimages извлекает нормально.

Ошибка склейки "лоскутной структуры"
http://rapidshare.com/files/248882642/segmented.pdf.html
http://ipicture.ru/uploads/090626/52469/I7w964zf5W.jpg
http://ipicture.ru/uploads/090626/52469/c9CU1EJdDs.png

импорт pdf - если pdf сделано при помощи Adobe Acrobat x.xx, Paper
Capture Plug-in with ClearScan, то непонятно для чего делается
такой импорт.
про лоскутную структуру уведомляет, а про cleanscan нет.
непонятно для чего уведомляет.

если kdu_compress.exe лежит в path (в путях) всё равно ругается
Warning JPG2000 codec are not found!
Но при этом наличае kdu_v61R.dll не проверяется. Странно.

для выбора пути kdu кодека - надпись FRGrab application

Для сохранения в jpeg2000 используется JasPer Version 1.600.0
хотя достаточно давно существует JasPer Version 1.900.1
Непонятно.

bolega
Вот тот файл, на котором споткнулся. Порог, конечно, немного завышен, но версия 5,92 обрабатывает его корректно, 5,93- ошибка поворота, sub-task сделал, вообще пишет ошибку "Floating point division by zero" на smart blur, поэтому включил в задание выходные файлы.
http://www.onlinedisk.ru/file/167723/
Кстати, може заодно посмотрите - как лучше применить фильтры сглаживания на таких вот хороших исходниках? С плохими иногда даже проще - там четко видно в каком направлени двигаться, а тут изначально качество хорошее, сложно поймать набор фильтров, дающих максимально гладкие буквы и минимально "слипшиеся" буквы.

ndch

Цитата:

импорт pdf(если изображение jpeg2000) = чёрный экран

Можно глянуть на файл или лучше на одну страницу из него?

Сразу скажу, что импортировать некоторые pdf средствами СК абсолютно бесполезно. СК при импортировании сохраняет "зонную" структуру оригинала. Но ряд pdf невозможно воспроизвести таким способом (чтобы они выглядели правильно, нужно именно рендерить их, так, как это делает acrobat или некторые другие извлекатели. Т.е. зоны поверх скана - этого мало, нужно еще воспроизвести еще довольно сложные методы наложения их друг на друга, а это СК не подерживает). Пример таких pdf - от google и microsoft. Но надо сказать, что процент таких pdf очень мал. Например, для тестирования я пропускаю через СК все сканированные pdf из гигапедии, процент неимпортируемых из них - 1%.


Цитата:

Ошибка склейки "лоскутной структуры"

Есть такое дело. СК склеивает путем пристыковки одной полосы к другой. До сих пор я только такие встречал. А здесь незнакомый мне случай - перехлест лоскутков (непонятно только, зачем утилита doPDF ver 6.2 так делает. Ну да ладно, ничего не поделаешь).


Цитата:

Plug-in with ClearScan, то непонятно для чего делается
такой импорт.

Clearscan - это уже векторный pdf. А такие pdf СК не импортирует. Иначе придется писать целый GS. А это мне не под силу. СК - это программа обработки сканов, а не всего, где есть текст. Под сканами подразумевается любой граф. формат - изображения, djvu, растровые pdf. Векторные шрифты, так же как и файлы word, СК не обрабатывает.


Цитата:

то непонятно для чего делается такой импорт.

С таким подходом я не согласен. Это как если сказать: на фига мне фотошоп, если он не может открыть векторные autocad-файлы. Clearscan - это вектор, и что там можно улучшать/обрабатывать, мне не понятно.


Цитата:

Но при этом наличае kdu_v61R.dll не проверяется

Не подумал про это. Хотя в whatsnew написал, куда должна быть помещена dll.


Цитата:

для выбора пути kdu кодека - надпись FRGrab application

Здесь Вы что-то путаете - на закладке Apps задается три внешних утилиты: djvudecode, FRGrab и кодек. Так что все правильно. Напротив каждой надписи свое поле ввода пути к утилите.


Цитата:

Для сохранения в jpeg2000 используется JasPer Version 1.600.0

Считайте, что это недоразумение (забыл убрать). Сохранение в jpg2000 я уберу совсем. Это для СК не нужно. Останется только в Services.

Alexx S
Спасибо! Качаю.


Цитата:

как лучше применить фильтры сглаживания на таких вот хороших исходниках

Лично я на хороших исходниках вообще фильтры не использую. В этом смысле я не эстет.

Окошко Grey Image Enhance открывается так, что нижних элементов управления не видно. Это бы не беда, но его размер не запоминается, так что каждый раз приходится его мышкой растягивать. Исправьте этот баг, пожалуйста. Cкриншот проблемы http://ifile.it/0gqoxah .

Цитата:

Окошко Grey Image Enhance открывается так, что нижних элементов управления не видно. Это бы не беда, но его размер не запоминается, так что каждый раз приходится его мышкой растягивать. Исправьте этот баг, пожалуйста. Cкриншот проблемы http://ifile.it/0gqoxah .

Есть такое дело

Melirius
Alexx S
Понятно. Проблемы начинаются, когда в системе выбран крупный системный шрифт. Учту.

Если на скане есть выделенная область, открыто окно Grey Image Enhance и включен Background Cleaner, то попытка применить Preview приводит к ужасающим следствиям - не для слабонервных . Это тоже баг.

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

Добавлено:
Melirius

Цитата:

Это тоже баг.

Заинтриговали, но воспроизвести не удалось


Добавлено:
bolega

Цитата:

Для таких страниц включайте:
Unsharp 6/5/1
Gauss blur=1
Enhance contour=10/70/1/Auto=on

Спасибо. Я понемногу начну составлять профили для новой версии. Буду премного благодарен, если дадите какие-то рекомендации с учетом появления новых алгоритмов.

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



Добавлено:
Да, кстати, если уж значение порога бинаризации отображается теперь для Auto, то нельзя ли сделать подобное для всех пресетов?

ghosty

Полюбуйтесь:

http://ifile.it/crk90a4

У меня стабильно, уже несколько версий так (и на нескольких компах).

Работе, впрочем, не мешает .

Melirius
Странно, у меня такое наблюдалось только на версиях вплоть до... 5.91 (не помню точно) и в том числе при обработке.

Добавлено:
bolega
У меня сложилось впечатление (или мне это только снится? ), что теперь СК сам пытается определить вертикальное выравнивание блока текста по странице. И похоже, делает он это очень даже неплохо.

bolega

Цитата:

Можно глянуть на файл или лучше на одну страницу из него?

http://rapidshare.com/files/249091805/01.pdf.html


Цитата:

Цитата: для выбора пути kdu кодека - надпись FRGrab application

Здесь Вы что-то путаете

Недоработка, врочем как и 80% остального софта (на удивление, за исключением встроеного в ХР просмотрщика) - некорректная работа с jpeg-cmyk.

Странно импортирует повёрнутые объекты.
Пример в чистом виде:
http://rapidshare.com/files/249387867/rotate.pdf.html

ndch

Цитата:

http://rapidshare.com/files/249091805/01.pdf.html

Спасибо за экземпляр. Исправил.


Цитата:

Странно импортирует повёрнутые объекты

А вот это так в СК и задумано. Поворачивать сканы - это прерогатива задания, а не импортера. Пользователь должен видеть оригинальные сканы, а не то, как они развернуты средствами (командами) pdf. Исключение делается только для поворотов на 90 или 180 градусов, потому, что они losseless. Все остальное - lossy, и возможно, пользователь захочет улучшить изображение перед его поворотом, или выбрать нужный метод поворота.


Цитата:

Да, криво описал. Изображаю в лицах:

Понял. Исправил.


Цитата:

Недоработка, врочем как и 80% остального софта

А Вы не думали, что дело здесь не в просмотрщиках, а в самом файле, может в нем неправильно формат указан? Т.е. на самом деле он не cmyk.


Цитата:

Не понял смысла. Не могли бы перефразировать ?

Вы знаете, что такое clearscan? Это векторный шрифт. А векторные шрифты СК не импортирует.

ghosty

Цитата:

У меня сложилось впечатление

Правильное впечатление Об этом я и написал в wahtsnew.

Alexx S

Цитата:

Вот тот файл, на котором споткнулся

Спасибо за интересный экземпляр (многоколоночный текст+рисунок).
Подрегулировал deskew. Стало лучше.

Цитата:

СК сам пытается определить вертикальное выравнивание блока текста по странице. И похоже, делает он это очень даже неплохо.

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

Цитата:

Спасибо за интересный экземпляр (многоколоночный текст+рисунок).
Подрегулировал deskew. Стало лучше.

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

Alexx S
Хорошо бы

Добавлено:
VadimirTT

Цитата:

то все пытался загнать по центру

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