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

ghosty

Цитата:

это с большой натяжкой можно назвать сглаживанием

Тем не менее, по сравнению с исходником это сглаживание. И лучшее сжатие по сравнению с СК и Корелом (при обычной обработке) это подтверждает.

Цитата:

Больше похоже на результат неумелого использования параметров размытия - когда кривые превращаются в набор ломаных...

Ага, так приведите пример умелого использования на этом исходнике

Цитата:

А чем в принципе алгоритм сглаживания контуров отличен от стандартного размытия/резкости?

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

Цитата:

Ошибка 404. Документ не найден

Барахлит сайтик. http://www.onlinedisk.ru/file/533137/

Arcand

Цитата:

Тем не менее, по сравнению с исходником это сглаживание. И лучшее сжатие по сравнению с СК и Корелом (при обычной обработке) это подтверждает.

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


Цитата:

Ага, так приведите пример умелого использования на этом исходнике

Зачем Вам мой пример (который я уже привел), если у Вас есть собственный вполне неплохой


Кстати, а в СТ так до сих пор и нет возможности регулировать порог бинаризации?

ghosty
Последнее Ваше задание у меня заработало, но полученный в нем результат все-таки далек от варианта СТ.
Кстати, избавился от "побитости молью", исправив в Вашем задании в четвертой строчке (следующей после [CMNT]=) в конце 0,0 на 1,0.
Однако думаю, что в Вашем случае что-то прописалось в sk.ini (а это знает только bolega), поэтому эта "побитость" будет возобновляться при создании нового задания.
Проще всего убить sk.ini.

Arcand
Цитата:

Для данных сканов он как видно оказался эффективен.

Дело в том, что в книгах 40-60 гг. такие сканы почти типичны (сравнивал еще на одной книге 1965 г.), так что можно сказать, что пока обработка подобного качества книг более эффективна (с точки зрения внешний вид-размер) в Скан Тейлор, как это ни жаль.

shch_vg

Цитата:

так что можно сказать, что пока обработка подобного качества книг более эффективна (с точки зрения внешний вид-размер) в Скан Тейлор, как это ни жаль.

подождите хоронить, может bolega что-то ответит

shch_vg

Цитата:

Последнее Ваше задание у меня заработало, но полученный в нем результат все-таки далек от варианта СТ.

Ну вот опять - почему далек-то? По мне, примерно то же качество и примерно те же размеры - то, что было Вам нужно.
Вот один из DJVU, полученный с подобными настройками (без использования зон):
http://narod.ru/disk/26183961000/filename5.djvu.html

По-моему, выглядит лучше, чем после СТ. В общем, даже не знаю, как Вам еще угодить

ghosty

Цитата:

[По-моему, выглядит лучше, чем после СТ. В общем, даже не знаю, как Вам еще угодить

Вы как-то немного странно все время сравниваете. Я сейчас не беру внешний вид, а только размер. Что я сделал: взял 6-ю страницу, полученную в Вашем последнем задании и 6-ю страницу после СТ (которая есть в моем выложенном архиве) и откомпилировал их вместе одним профилем в одно дежавю. На мой взгляд это самое справедливое сравнение вариантов.
Вот, что получилось.
Соотношение: Ваша страница (первая) - 64 кб, после СТ - 47,9 кб.
Ручная очистка вашего варианта сбросит максимум 2 кб.
Правда, в последнем Вашем примере размер 6-й страницы 52,3, но может быть это за счет компиляции с другим профилем. Лучше бы Вы в свою компиляцию вместо 7-й страницы включили 6-ю после СТ, тогда было бы легче сравнивать.
Можно спорить, какой из вариантов визуально лучше или хуже (хотя мне, к сожалению, больше нравится более светлый вариант после СТ), однако, т.к. пропорция по другим страницам будет при такой обработке сохраняться, то книга получится на треть больше, чем после СТ.

terminat0r

Цитата:

подождите хоронить, может bolega что-то ответит

Боюсь, что он дал обет молчания, очень уж мы его достали глупыми вопросами .

shch_vg

Цитата:

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

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

Разница между 47,9 и 52,3 уже не существенна, и, скорее всего, объясняется именно большей толщиной букв во втором случае.

Вы так и не ответили, в СТ можно менять порог бинаризации? (извиняюсь за этот микрооффтоп)

ghosty

Цитата:

Вы так и не ответили, в СТ можно менять порог бинаризации?

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

shch_vg

Цитата:

Вот, что получилось.
Соотношение: Ваша страница (первая) - 64 кб, после СТ - 47,9 кб.

Так сравнивать не очень корректно, в дежавю из нескольких страниц начинает работать словарь и размер страниц (который в свойствах страницы/документа) меньше, чем закодированных отдельно. И эта разница тем больше, чем дальще страница от начала. При кодировании 00006.tif из архива профилем Bitonal 600 (самое агрессивное сжатие) размер дежавю 48,9 КБ (50 139 байт).
Извиняюсь за офтоп.

Arcand

Цитата:

При кодировании 00006.tif из архива профилем Bitonal 600 (самое агрессивное сжатие) размер дежавю 48,9 КБ (50 139 байт).

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

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

Цитата:

А вот почему такое сравнение не совсем корректно, я не понял.

Цитата:

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

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

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

В 5.93 начались странные глюки - после обработки отдельной страницы процесс подвисает, загружая CPU на 100%. При этом СК остается функциональным, но выйти из него нельзя - только через TM.

ghosty
Работаю только в 5.93, часто обрабатываю отдельные страницы и развороты, но с подобным явлением не сталкивался.
М.б. какие-то проблемы с системой?

Что-то давно меня СК так не расстраивал - как будто рассыпаться начинал вдруг. Теперь он у меня напрочь перестал воспринимать изменения параметров Ill.Corr. Т.е. значение "1" теперь дает ровно такой же результат, как и значение "50".
Думал, этот глюк как-то был завязан на задании. Создал новое - та же история.
Думал, он завязан как-то на установленной версии. Поставил заново в другую папку - то же самое.
Голова болеть начинает
bolega, help!

Добавлено:
melodan

Цитата:

В версии 5.92 у СК был такой глюк - в режиме просмотра результатов обработки после того как воспользуешься инструментом переноса выделенной области (переношу область в разных направлениях) на правой стороне выделения остаются следы символов. В последней версии это исправили?

Удивительно, но только что тоже столкнулся в 5.93...

Добавлено:

Цитата:

М.б. какие-то проблемы с системой?

Не знаю, только с СК проблемы. Да и проблемы специфичны именно для софта, а не для системы, ИМХО.

melodan

Цитата:

В версии 5.92 у СК был такой глюк - в режиме просмотра результатов обработки после того как воспользуешься инструментом переноса выделенной области (переношу область в разных направлениях) на правой стороне выделения остаются следы символов. В последней версии это исправили?

Имеется ввиду команда move selection?
Какой windows? Это проявляется на b/w файлах? Следы остаются в месте выреза или множатся по траектории перемещения?

ghosty

Цитата:

Голова болеть начинает

Я могу Вам дать 5.94 потестировать, я там много багов исправил

bolega
Послал сообщение в ПМ.


Цитата:

Имеется ввиду команда move selection?
Какой windows? Это проявляется на b/w файлах? Следы остаются в месте выреза или множатся по траектории перемещения?

Да, move selection в Results Viewer'e. WinXP SP3. Следы - на месте выреза по правому краю.

bolega

Цитата:

Имеется ввиду команда move selection?

Я это делаю через Ctrl+M

Цитата:

Какой windows?

Наблюдал это и сервер2003, и в вин2к.

Цитата:

Это проявляется на b/w файлах?

Я замечал только на ч/б. Правда, не помню, использовал ли я эту команду на серых.

Цитата:

Следы остаются в месте выреза или множатся по траектории перемещения?

У меня только по правой стороне выреза.
При сдвиге вправо не замечал таких следов.

Цитата:

Следы остаются в месте выреза или множатся по траектории перемещения?

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

А еще, кому интересно, здесь (5,5 Мб) выложил пример отфотканного и закодированного старого журнала. Возможно ли его реставрировать и привести в нормальный вид (естесно с помощью СК), сократив размер новой дежавюшки в разы? Задача усложняется тем, что разрешение исходника небольшое, много затенений, геометрические искажения. В общем - работы море))

melodan
Если нужно перемещать все содержимое, то лучше наверное использовать Ctrl-стрелки, а не move selection

melodan

msepdjvu Вам в помощь.

bolega
Спасибо за совет, но баг таки надо исправить
Melirius
Интересно, спасибо А можно чуть подробнее о возможностях этой проги? Покамест изображения с тремя тонами (и более) я кодирую в режиме Scanned.

melodan

Ну если там у Вас чисто прямоугольник фона для текста - так можно и Scanned, а ежли рисунки многоцветные, так лучше msepdjvu - она, в отличие от documenttodjvu при --jb2-format=color, поддерживает соприкасающиеся символы разных цветов.

shch_vg

А кто тут хотел странички маленькие из-под СканКромсатора, да налетай, пока не разобрали!

spt-файл:

Код: V5.86
1
[CMNT]=
[A]=;C:\!Hi-Fi DjVu\tif\out;;1;0
[B]=1,0,3,2,1,100,0,0,0,0,2,0,0,0,0,0,0,0,0,0,100,0,0,0,2,0,1,0,0,0,1,1,2,4,7,180,160,150,2,0,0,1,3,5,6,10,0,0,0,12880,3,67175426
[MPTIF]=0
[PROCRES]=
[FILES]
[A]=1
[FFNAME]=C:\!Hi-Fi DjVu\tif\_0000.tif
[FNAME]=_0000.tif
[B]=1,1,1,0,23145,0,0,1720,1867,346,3258,1,1,1,1,0,0,0,0,0,1,1,1,1,1,2,2,0,0,0,0,0,0,0,0,0,0,0,91,2368,0,0,1,1,0,0,0,1,1,0,0,0,0,0,1,0,7,0,1,0,0,0,2,0,0,0,0,1,1,0,0,0,0,0,0,0
[E]=1665,3,2,2,2,1,0,164,2,3,20,0,20,20,0,1,0,4,0,3,0,1,2,0,0,0,0,0,1,0,0,17,20,0,2,2,30,255,120,10,70,1,2,10,50,2,1,2,0,3,100,1,0,6,5,1,0,0,2,50,3,12,0,0
[ENDF]

Melirius
Большое спасибо за пример, результат действительно впечатляющий, возвращающий веру в СК .
Для сравнения результаты после компиляции при раздельном кодировании:
после СТ (с определенной очисткой) - 49 кб (50 139 bytes)
после СК (даже без малейшей очистки) - 46,3 кб (47 388 bytes)
Кстати, как Вам удалось закодировать его сильнее, чем я? Использовал самый сильносжимаемый профиль в DEE5.1.
Интересно, Вы долго подбирали эти параметры или уже изначально примерно знали, что может повлиять на размер?

Arcand
Немного странноватый результат получается при совместном кодировании страниц после СК и СТ:
вариант СК+СТ - 45,2 и 47,8
вариант СТ+СК - 47,6 и 45,4,
т.е. нахождение на первом месте уменьшает величину на 0,2 для обоих способов обработки.

Спасибо, Melirius
Нашел еще один глюк в СК, уже в последней версии. На вкладке Book в поле H.Gap value выделяем значение 0, нажимаем клавишу "0" и получаем "00"
А еще большая просьба - убрать окно подтверждения про уеличение выходного разрешения. Когда обрабатываешь страницы по отдельности - постоянно вылезает это окошко. Решение - убрать совсем, либо сделать пункт в настройках, чтобы не появлялось это окно предупреждения.

melodan


Цитата:

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

Оно отключается в настройках: File > Options... > Processing > DPI Resample warning.

shch_vg

Ну я изначально знал, что нужно выровнять освещённость (BG Cleaner или Ill. Corr.) + какое-то размытие + порог подобрать. Ill. Corr. на этой картинке оказалось слишком агрессивным при любых настройках, остался BG Cleaner, размытие пробовал разное, наилучшее зависит от типа порога.

Но Вы сейчас будете смеяться: результат в 31058 (!!!) байт в 600dpi получается следующим образом:
Output 300dpi (!!!)
Background cleaner: Correct low contrast -
Blur: Median filter
Convert threshold: Middle Dark

затем CPCtion, декодирование, upsampling до 600dpi bspline в XnView, кодирование.

Или вместо Median Gauss +, Radius 1, тогда размер 34469, но в короне чёрного короля все 4 точки остаются.

Выкладываю настройки моего профиля кодирования:

#@displayName:Bitonal (600 dpi) new
Bit600new: bitonal600
description=Bitonal (600 dpi) with big dictionary
pages-per-dict=3000
fg-quality=1
render-size=1

+ --disable-halftone в командной строке.

Похоже, что такие книги дают пример для моего символа веры: сканируйте только в 600dpi!

Melirius
Еще раз спасибо за подробные ответы, однако есть в связи с этим несколько вопросов.
1. В описании обработки в 300дпи что делать с Blur: Median filter?
2. Я понимаю, что, привлекая много доп.программ, можно добиться многого, однако хотелось бы минимизировать их количество, чтобы облегчить другим подобную обработку. В связи с этим, в цепочке "затем CPCtion, декодирование, upsampling до 600dpi bspline в XnView, кодирование" что будет, если убрать CPCtion и делать декодирование и upsampling до 600dpi в СК?
Если ответы на эти вопросы выходят за рамки этой темы, не могли бы Вы мне написать в Личный Ящик.
3. Не понял смысл фразы "Или вместо Median Gauss +, Radius 1".
4. Возможно, девиз "сканируйте только в 600dpi!" и верен, но в данном конкретном случае практически невыполним. В нашей теме удается подвигнуть имеющих шахматную литературу на сканирование ее, но на обработку их другими они выкладывают сканы в лучшем случае в 300дпи (больше приводит к резкому возрастанию объема пересылки), заключенные в пдф либо с помощью СК с установками по умолчанию, либо с помощью других программ с еще более крутыми параметрами сжатия в пдф.

P.S. Как реализовать "--disable-halftone в командной строке"?
Без этого параметра результат работы Вашего профиля идентичен моему с точностью до байта.
Я в DEE5.1 работал только в GUI.

shch_vg

1. На вкладке Blur окна Grey Enhance SK настройки на скрине.



3. Аналогично:



2. Много программ не надо. CPCtion - это 148 кб в архиве, и 181 кб в распаковке: http://ifile.it/w41v79t
Внутри инструкция (WinXP и выше надо, на Win98 работоспособность не гарантирую). Как отработает, выбираете наименьший файл - и всё. Upsample после декодирования наименьшего файла, наверное, можно проводить и в SK, но это новое задание будет. Честно говоря, не вижу проблемы и в файле 300dpi - тем более, что он ещё меньше (~20 кб).

4. Тут я Вам не помощник, я технократ, а не психолог . Упирайте на благодарных потомков, IMHO, и научите их хотя бы ставить точки чёрного и белого при сканировании, а то у представленной картинки полезный динамический диапазон практически уполовинен, если не снижен в 4 раза.

P. S.
Смотрите пример в CPCtion.

Melirius, спасибо огромное! =)

А можно реализовать таким же образом отключение сообщения о перезаписи обработанных изображений (во время обработки) Overwrite it? И сообщение Apply option to marked file тоже? И я не нашел возможности назначить горячую клавишу на помечение зоны как Картинки (Picture).

Такой вопросик к создателю Djvu Imager. Можно ли сделать запуск DOSовских окон в фоне, чтобы они не мелькали и не мешали работать в лругих приложениях?