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

msbn

Цитата:

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

Там много чего нет - не так уж часто приходится использовать некоторые функции.

Если видите, что СК не сможет сам определить границы текста И эти границы тем не менее остаются примерно одинаковыми во всей книге, то положение резаков можно просто скопировать.
Для этого щелкаете правой кнопкой по ползунку нужного резака. В контекстном меню: Copy Current Position to: -> Alternate down. Т.е. копируем через одну страницу - например, сначала для нечетных, потом для четных. Вроде, все.

Ребята помогите мне пожалуйста с запуском Skankromsatora в wine. Я пытался запускать программу но никокого результата я не получил. Я в терминале вводил команду "$ wine scan.exe", и никокого результата. Другие же программы запускаются нормально. Может я не знаю какой-то мелочи.

Спасибо заранее

vitaliichirciu29
у меня нормально запускается только версия 5.91

День добрый всей чесной компании!

Я пытаюсь обоработать в СканКромсаторе v5.93 книгу ("Geografīi͡a Bessarabskoĭ gubernīi: uchebnoe posobīe dli͡a srednikh i nizshikh uchebnykh zavedenīĭ"), скачанную с помощью программы Google Book Downloader v. 0.7.0. При этом большая часть страниц отображается неправильно -изображение страницы какбы намотано по диагонали на выводимую картинку (пример).
Что я делаю не так?
Как это можно исправить?

вопрос
есть уже обрезанные и порезанные на страницы из 2х файлы, на подобие которые лежат в папке out
проект был сделан не мной.
есть ли возможность в СканКромсаторе задействовать только модель постобработки (значок с лупой) не создовая проект и занова не нарезая книгу?

pobat

Цитата:

есть ли возможность в СканКромсаторе задействовать только модель постобработки (значок с лупой) не создовая проект и занова не нарезая книгу?

Это смотря для каких целей.
Если Вы вручную хотите чистить или править уже нарезанные сканы, то это можно сделать через Result->Show source files, предварительно загрузив их в СК.

При обработке сканов содержащих цветные изображения в scan kromsator v5.93 они преобразуются к ч/б виду не зависимо от того какой формат выходного файла и цветность я указываю на вкладке files. Может кто-нибудь знает в чем причина? И как с этим бороться?

chemist
Это ошибка этой версии. При галочке в поле deskew поставьте галочку в поле Art.

Скажите, пжлста, где найти Document Express Editor (с лекарством, если нужно).

Antonij72

Цитата:

где найти Document Express Editor

см. в ветке Формат DjVu

Ребята, хоть и не в тему, но подскажите, так как не знаю куда обратиться. Программа BookRestorer TryOut v4.2.1. Нет доступа к реставрационным библиотечным инструментам. Впрочем, как и в остальных версиях, скачанных с этого сайта. Может, подскажете, в чем проблема?
P.S. BookRestorer TryOut v4.2.1. раньше все работало. Переустановка не помогает. На втором компе все работает. Пытался перенести папку с рабочей программой. Эффект нулевой. На обоих компах Windows 7.

Lightkeeper
Здесь рабочая версия должна быть - http://djvu-soft.narod.ru/soft/
Дальше -

bolega
Столкнулся с неприятной вещью.
Обрабатывал книгу в СК.Эту же книгу с тех же исходных сканов другой человек обрабатывал в СканТейлоре. Компилировались оба варианта в DEE5.1 одинаковым профилем. С удивлением увидел, что мой вариант почти вдвое больше.
Выбрал один примерный разворот, у которого левая страница после компиляции скантейлорского варианта занимает почти 42 кб. Перепробовал все известные мне способы уменьшения размера в СК (smooth+blur+sharpen, background cleaner, smooth blur). но меньше, чем 54 мб, получить не удалось. Аналогичная ситуация и с другими разворотами.
М.б. есть еще какие-то возможности по уменьшению размера обработанного скана в СК?

shch_vg
примеры в студию

terminat0r
Пример (2.23 mb).
Описание файлов в архиве.

shch_vg

Цитата:

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

Так уж и неприятная . При обработке в Кореле я могу, повышая интенсивность сглаживания и увеличивая порог бинаризации, делать текст жирнее. При этом при кодировании сжатие увеличивается. Я объяснял это таким образом: при ужирнении текста относительное различие между одинаковыми буквами уменьшается, следовательно, больше таких букв будут признаваться кодером как одинаковые и тем больше будет сжатие. СТ заметно ужирняет текст (на тех примерах, которые я видел). Хотя текст после СТ в вашем примере не назовешь жирным, но все же, насколько я мог разглядеть снапшоты, он немного пожирнее, чем после СК. Поэтому и различие в сжатии.

Поднимите порог бинаризации в СК (можно одновременно поиграться сглаживанием) и ИМХО Вы повысите сжатие.

Arcand

Цитата:

Поднимите порог бинаризации в СК (можно одновременно поиграться сглаживанием) и ИМХО Вы повысите сжатие.

Именно этим я сначала и занимался!
Однако сами исходные сканы изначально грязные, поэтому при поднятии порога резко возрастает количество грязи на выходных тифах, которую вручную чистить очень трудно.
Попытки убрать ее с помощью background cleaner или smooth+blur не дали заметного уменьшения.

All
Может кто-нибудь именно в СК на выложенной мной странице добиться такой обработки, что полученный на выходе тиф при компиляции будет близок к варианту СТ (который тоже есть в примере) не только по размеру (это и я могу ), но и по качеству?

P.S. Пока же получается, что в СТ чуть ли не по умолчанию можно получить результат, который нельзя повторить (я не говорю про улучшить) в СК даже после серьезных подборов настроек.

shch_vg
ИМХО, Вы не совсем корректно формулируете задачу - слишком общо.
Дело в том, что в Вашем конкретном примере довольно много факторов, влияющих как на качество, так и на размер. Причем не обязательно, что те факторы, которые влияют на качество, будут "благотворно" влиять и на размер ("классический" девиз Arcand'a "чем больше блюра, тем лучше качество и тем меньше размер" тут работать не будет).

Действительно, обратите внимание на собственные скриншоты: в случае обработки СК мелкие детали шахматных фигурок (они чаще даны белым на черном фоне) сохранились хорошо. А вот в случае обработки СТ этих деталей осталось намного меньше. Тогда вопрос - а что для Вас входит в понятие "качество обработки" в данном случае?

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

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

В СК мне удалось достичь примерно того же эффекта и качества, что и в Вашем примере с СТ - у меня получилось 51 и 46 Кб соответственно. Но повторяю, это ни о чем не говорит - все зависит от того, что Вы понимаете под качеством, и что Вам дороже - качество или размер.

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

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

shch_vg

Цитата:

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

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

ЗЫ: СК - могучая программа. В умелых руках, да с бутылкой рома - это ого-го...


Добавлено:
ghosty
Вы меня восхищаете! Признаю, мне до таких интеллектуальных высот как до Шанхая (пардон) раком

Arcand
При всем своем "интеллектуальном превосходстве" юмора (иронии?) я, тем не менее, не понял Точнее, не понял, что именно Вас восхитило.


Цитата:

Сжатие одной страницы самой по себе и в книге - две большие разницы.

Кстати, да. Еще важен размер словаря (сколько страниц на словарь).

ghosty
Мне что-нибудь трудно возразить против Ваших доводов, но в данном случае у меня был несколько другой вопрос. Я знаю о недостатках СТ в приведенном мной примере, их даже несколько больше, чем Вы описали. Естественно, когда я обрабатывал приведенный мной скан в СК, я использовал все, чему я научился за четыре с половиной года использования этой программы. Но в данном случае я НЕ СМОГ даже ухудшая качество выходного файла (но стараясь делать не хуже, чем в СТ) приблизиться к размеру, полученному в СТ. Поэтому мне интересны параметры, с которыми Вы получили 51 и 46 Кб, т.к. у меня при компиляции тифа после СТ получилось 49, а при моей обработке я получал минимум 54 мб. И еще хочу добавить, что такое расхождение наблюдается практически на сканах всех страниц.
Что касается качества обработанного тифа, то я его определяю на глаз при просмотре в WinDjView в режиме Fit Width (именно в том, в котором я обычно просматриваю дежавю).
Поэтому в варианте СТ для меня неприемлемы только случаи, когда после обработки исчезают точки, запятые, тире или двоеточия, я не говорю уже о буквах.

Добавлено:
Arcand

Цитата:

надо знать, это сжатие при кодировании одной страницы или же же это сжатие страницы в книге

Естественно, это размер страницы в книге. Но этот вопрос был бы актуален, если бы я не приложил в примере скан после обработки в СТ. Т.к. страница откомпилированная в книге и отдельно имеет разный размер, то я специально приложил этот выходной тиф для сравнения. И свои варианты обработки я сравнивал тоже при компилировании отдельной страницы.

shch_vg
Еще раз, не совсем понятно, какую именно проблему Вы решаете
Насколько я понял: в Вашем случае важны две вещи -
1) общее качество обработки (о критериях оценки Вы так ничего и не сказали, поэтому оставляю решать эту проблему Вам самому ).
2) конечный размер файла. Тут могу сказать, что в данном случае для оценки степени сжатия лучше обрабатывать группу из 20-30 страниц, а не 1-2, как Вы это пытаетесь сделать.

В СК особо мудрить не надо. Как уже сказал Arcand, увеличиваете порог бинаризации и сглаживание.
Файл задания я, похоже, удалил, поэтому воспроизведу по памяти: я плясал от своего профиля по умолчанию ("сборка" в шапке). Изменил Ill.Corr. на Combo 17, несколько урезал гистограмму, чтобы избавиться от слишком резких градиентов фона (Ill.Corr. не всегда справлялся), увеличил порог бинаризации до 220, увеличил Smooth до 2-х. По-моему, все.

ghosty
Жаль, что Вы удалили задание, оно бы мне сказало гораздо больше, чем пространное объяснение (причем не факт, что по нему мне удастся получить Ваш результат).
Проблему я описал в одном из своих предыдущих сообщений - получить в СК на конкретном скане результат, не худший, чем получен в СТ, по следующим параметрам: размер и вид откомпилированного в дежаву скана при просмотре в WinDjView в режиме Fit Width.
Количество обрабатываемых страниц мне кажется в моем случае не важно, т.к. разница в размере страниц наблюдается практически по любой выбираемой странице.
Сейчас ситуация такая: обработанная мной эта книга в 240 стр. весит 12 мб, что само по себе очень много (по крайней мере в моей практике такого еще не было, хотя, конечно, сканы очень далеки от идеальных). В СТ эта книга получилась размером 6 мб, что в данном случае в пределах допустимого. Если предположить, что этот размер получен за счет артефактов (потери точек, двоеточий и тире), то более качественный вариант обработки в СК должен быть в пределах 7-8 мб, а для этого каждая откомпилированная страница должна быть равна или чуть больше соответствующей страницы, сделанной в СТ.
Вот я и хотел этого добиться.
Сразу скажу, что в обоих вариантах компиляции (и для СТ, и для СК) в DEE5.1 применен один и тот же самый сильный профиль сжатия.

P.S. Объяснить более доходчиво цель моей просьбы я вряд ли смогу .

shch_vg
Еще раз повторю: экспериментировать надо с сериями по 20-30 страничек - как с т.зр. оценки качества обработки, так и с т.зр. размера конечного файла. На 1-2 страничках оптимизировать обработку для всей книги сложновато.

http://narod.ru/disk/26157897000/test.rar.html
Это я извращался с зонами Зоны можете удалить, если не интересно.

shch_vg
возможно что после ST использовался cpc tool перед кодированием в djvu

ghosty
Спасибо за пример, но, к сожалению, он мне не помог, а только добавил вопросов.
Откомпилировал я полученную Вами левую страницу вместе со сделанной для СТ и получил большую разницу в размерах (64 и 47,9 кб соответственно).
Решив, что Вы прислали вариант для примера, как использовать указанные в предыдущем Вашем сообщении параметры, запустил Ваше задание, после чего СК выдал ошибку, которую я вроде бы раньше не встречал.
Еще обратило на себя внимание представление исходного скана в главном окне СК.
Он как бы "побит молью" .
После загрузки этого же скана в другой экземпляр СК он выглядит нормально.
Просмотрел все опции Вашего задания, но так и не нашел, что могло так повлиять на его вид.
М.б. в этом объяснение полученной ошибки?

terminat0r

Цитата:

возможно что после ST использовался cpc tool перед кодированием в djvu

Маловероятно. До этого делавший вариант с СТ в качестве компилятора использовал экспресс-эдитор и получал большие размеры. Я ему переслал портабельный вариант DEE5.1 и это была его первая компиляция в DEE, хотя я попробую уточнить этот момент.
P.S. А нельзя ли как-то по тифу определить, обрабатывался ли он cpc tool?

shch_vg
Мне тоже казалось, что мое задание Вас только запутает, отчасти поэтому и не спешил...
А не пробовали экспериментировать с сохранением шахматных досок в виде полутоновых изображений?


Цитата:

Откомпилировал я полученную Вами левую страницу вместе со сделанной для СТ и получил большую разницу в размерах (64 и 47,9 кб соответственно).

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


Цитата:

Он как бы "побит молью"

Это, должно быть, установки рендеринга изображения. Они не влияют на обработку.
Я помню, что переключал рендеринг на "Accelerated" (для быстрой загрузки). Но теперь Options->Main Win я уже не могу изменить этот параметр. Т.е. он "Accelerated" по умолчанию и изменить на "Normal" его уже нельзя. А у Вас как?


Цитата:

Ваше задание, после чего СК выдал ошибку, которую я вроде бы раньше не встречал.

Тут уже ничем помочь не могу - вопрос к автору.


bolega, расскажите хотя бы о своих творческих планах - об СК даже не спрашиваю

ghosty

Цитата:

А не пробовали экспериментировать с сохранением шахматных досок в виде полутоновых изображений?

Это как ?
Если, как делали Вы в своем примере, то я это делаю очень часто, потому что настройки для текста и для диаграмм часто несовместимы.

Цитата:

Нет, серьезно, мне действительно кажется, что это не тот случай, когда имеет смысл экспериментировать только с двумя страничками.

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

Цитата:

Т.е. он "Accelerated" по умолчанию и изменить на "Normal" его уже нельзя. А у Вас как?

А я никогда не трогал этот параметр, но он у меня, как и у Вас "Accelerated" по умолчанию и изменить на "Normal" его уже нельзя.

Аккуратно перенес вручную все Ваши параметры в свое задание, не забыл и опции, вызываемые по Ctrl+B, после чего получил обе страницы, покрытые чернотой.
Если нетрудно, посмотрите мое задание, м.б. я что-то не заметил? пикчер-зоны для диаграмм я не использовал.

shch_vg

Цитата:

Объяснить более доходчиво цель моей просьбы я вряд ли смогу

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

В данном случае, похоже увы... Дело вот в чем. В СТ, насколько я знаю, применяется сглаживание контуров. И это не простое размытие, а именно сглаживание контуров. Для данных сканов он как видно оказался эффективен. Так, в Кореле мне пришлось применить весьма интенсивное сглаживание (по сути это размытие), чтобы приблизиться к результату в СТ http://abab.front.ru/jobс.djvu
Что касается нормальных сканов, то там сглаживание СТ приводит к тому, что текст становится как бы припухлым, что не очень естественно.
Чтобы получить хорошее сжатие после СК, наверное, надо предварительно обработать сканы, чтобы сгладить контуры.

shch_vg
Да, воспроизвел глюк - действительно странный. Посмотрите, это задание должно работать:
http://narod.ru/disk/26172456000/OnceMore.rar.html

Кстати, Вы в курсе, что мы обсуждаем проблему шахматных досок в параллельной ветке?

Arcand

Цитата:

В данном случае, похоже увы... Дело вот в чем. В СТ, насколько я знаю, применяется сглаживание контуров. И это не простое размытие, а именно сглаживание контуров.

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


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

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


Цитата:

http://abab.front.ru/jobс.djvu

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