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

monday2000
У нас получается разговор слепого с глухим или наоборот Выбирайте, что Вам ближе .

Цитата:

если обрабатывать книги по ScanAndShare - или же по СorelScan - то что лучше?

Это зависит, в чьих руках эти инструменты окажутся

Цитата:

ScanAndShare и СorelScan - это взаимоисключающие методики в плане улучшения grey-сканов

ИМХО это две близкие по духу методики. Это как два стиля плавания. Плывете тем, который вы освоили лучше или вам удобнее.

Цитата:

Есть ли возможность делать в СК 5.91 такие же обработки по улучшению grey-сканов, о которых говорится в СorelScan? Или же sas-апсемплинг - потолок того, что можно выжать из СК 5.91 в плане улучшения grey-сканов

Вы словно не читаете мои посты. Есть, Blur+Sharpen. Это или подобное осуществляет сглаживание в СК. Повторюсь, мы же не задаемся вопросом какой стиль плавания лучше, поэтому не спрашивайте, что лучше. Нюанс, СК - специализированная программа по кромсанию и обработке сканов. Корел - графический редактор. Поэтому, в Корел нет специфицеских функций по кромсанию сканов, СК проигрывает Корелу в плане широты спектра фильтров и гибкости в их применения.

Цитата:

Просто для удобства - чтобы не повторять каждый раз фразу: "тот апсемплинг, который делается посредством sk - с 300 dpi grey до 600 dpi grey с одновременным применением (сканкромсаторных) Blur + Sharpen

Вы же не считаете, что прописанные в скриптах Корела обработки выполняются одновременно. С чего Вы взяли, что в СК они выполняются все сразу, т.е. являются по сути неким суперфильтром. Совершенно уверен, что в СК ресемплинг Blur и Sharpen выполняются последовательно. Поэтому никакого смысла в термине sas-апсемплинг нет. Конечно, повышающий ресемплинг в разных прогах несколько отличаются по причине различных алгоритмов интерполяции - добавляемым пикселям надо присвоить какие-то значения тона/цвета. Вопрос, в какой проге делается ресемплинг, ИМХО практического значения для обработки сканов не имеет.

VadimirTT

Цитата:

раз и получается среднестатистическое отличие в 2 раза.

Что и требовалось доказать.

Попробуйте (если есть возможность) ещё методику CorelScan - на тех же самых сканах - и сравните с sas-апсемплингом. Это очень ИМХО интересно.

Добавлено:
Arcand

Цитата:

Совершенно уверен, что в СК ресемплинг Blur и Sharpen выполняются последовательно.

Да, это понятно.

Цитата:

Поэтому никакого смысла в термине sas-апсемплинг нет.

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

В общем, надо бы постараться сравнить на одних и тех же сканах ScanAndShare и CorelScan - интересно, что же получится (сравнить бы качество и размер результирующих ЧБ DjVu-600).

monday2000
Цитата:

В общем, надо бы постараться сравнить на одних и тех же сканах ScanAndShare и CorelScan - интересно, что же получится (сравнить бы качество и размер результирующих ЧБ DjVu-600).

Как же Вы не заметили - ИМХО в этом топике и топике по сканированию постоянно идет негласное соревнование, кто кому утрет нос
Последняя схватка: хук слева и хук справа .

ЗЫ: В целом же
Цитата:

если обрабатывать книги по ScanAndShare - или же по СorelScan - то что лучше?
Это зависит, в чьих руках эти инструменты окажутся

Прошу прошения у bolega, но хотел бы все же высказать свое мнение о двух вариантах обработки книги, т.к. основная обработка происходит именно в Сканкромсаторе.
После объективных результатов сравнения вариантов (размеры полученных книг) мое субъективное (основанное на зрительном восприятии) мнение, которого я придерживался ранее и буду придерживаться впредь такое:
для себя можно делать книгу в любом разрешении от 50 до 1200 dpi, но для выкладывания для всеобщего пользования вариант 600 dpi ОБЯЗАТЕЛЕН (за небольшими исключениями, которые указывались ранее в обсуждении, и в которых нет практического (субъективного) различия между 300 и 600 dpi кроме размера).
Если размер книги книги в 600 dpi сравнительно небольшого размера (для меня это до 3 мб), то этого достаточно. При бОльших размерах ЖЕЛАТЕЛЕН дополнительный вариант этой книги в 300 dpi (визуально худший), чтобы дать возможность желающему ознакомиться с книгой самому решить (скачивая оба или умозрительно), какой вариант его больше устроит.

P.S. Еще раз повторяю, что это мое личное субъективное мнение.
Дальнейшее мое обсуждение этого вопроса в этой теме исключено, готов его продолжить только через Личный Ящик.

Arcand

Цитата:

ИМХО в этом топике и топике по сканированию постоянно идет негласное соревнование, кто кому утрет нос

Лично я к сожалению уже стал слишком стар для соревнований (не в смысле возраста).
Поэтому участвовать в них перестал. Приму любой результат. Если конечно этот результат в пользу sk

Arcand

Цитата:

Последняя схватка: хук слева и хук справа

Ваш вариант как раз и делался в CorelScan? Т.е. практически, в умелых руках, что ScanAndShare и CorelScan - результат приблизительно одинаков?
Если так, то я двумя руками за sk only. Люблю, знаете ли, удобство и единообразие.

Добавлено:
bolega

Цитата:

Приму любой результат. Если конечно этот результат в пользу sk

Маэстро, мысленно я вам рукоплещу

bolega
Цитата:

Поэтому участвовать в них перестал.

Жаль . Я отношусь к сравнению вариантов не как кто кого, а чтобы поразмыслить, что можно улучшить у себя. Хотя, пожалуй, я тоже залягу на печку, тепло и спокойно

kontiky
Цитата:

Если так, то я двумя руками за sk only.

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

ЗЫ: Прогресс питает дух соревнования, а так стагнация. За сим умолкаю.

Arcand
Дело не в стагнации.
Я приводил достаточно много своих результатов, и опять делать то же самое на том же самом инструменте мне уже просто неинтересно (говоря вашими словами, "не греет"). Это уже превратилось в жвачку. Вот если в sk появится что-то новое, тогда другое дело.
Да и у Вас методика не меняется... Так что кто из нас склонен к теплой печке, еще стоит поглядеть

bolega
Подобные результаты нужно выносить куда-то в шапку. На видное всем место. Или в FAQ.

А ещё примеры и результаты имеют свойство на файлообменниках умирать.
Читаешь дискуссию, видишь ссылку на файл, а его и нету.

Вот так ценное знание и пропадает.

Вопрос знатокам: сделал draft kromsate для книги и в ряде страниц нижний резак пропускает номера страниц - я поправляю его вручную, но может как-то можно это настроить автоматическа? Может стоит сменить значение Text vert. sensitivity (у меня щас по умолчанию стоит там Normal)?

И еще вопрос: нет ли в sk возможности развернуть изображение вокруг оси (иногда хочеться вручную выполнить выравнивание перед выделением зон мышью)?

kontiky

Цитата:

но может как-то можно это настроить автоматическа? Может стоит сменить значение Text vert. sensitivity (у меня щас по умолчанию стоит там Normal)?

Вначале рекомендуется поставить галочку Safe Top/Bottom, а затем, если это не поможет, установить и значение чувствительности по вертикали.
Для того, чтобы проверить, как работает DK, не обязательно делать полный прогон - можно обработать 5-10 страниц, после чего остановить процесс.

При обработке в СК 5.91 8-битного цветного изображения по методу разделённых сканов (МРС) - при использовании Picture-зон на выходе получаются тоже два 8-битных цветных субскана - их не переваривает напрямую ни pnmtodjvurle, ни fi_sep, приходится их преобразовывать в 24-битные.

monday2000
Задайте в свойствах этих зон format=color 24bit и никаких преобразований не нужно будет.
И еще один нюанс. Если зона непрямоугольная, то на выходе sk создает файл зоны в виде мультистраничного тиф, точнее, двухстраничного. На 2-й странице содержится маска прозрачности. Возможно, что многие утилиты ожидают увидеть тиф одностраничным. Это я говорю на случай, когда выходные файлы зон будут где-то использоваться/открываться, чтобы 2-я страница тифа не пропала в результате пересохранений. Это не относится к случаю после выполнения Merge.

bolega
Кстати, по поводу зон. Сделал Contrast zone - как мне изменить ее свойства? С Picture zones все понятно - там в локальном меню есть соответствующий подпункт. А здесь как?

bolega

Цитата:

Задайте в свойствах этих зон format=color 24bit и никаких преобразований не нужно будет.

Это не работает - наверное, глюк. Вот можно на образце попробовать:

http://www.djvu-soft.narod.ru/scan/cla_pic.gif (64 КБ)

Но не беда - можно на лету конвертировать в 24-color.

Цитата:

Это не относится к случаю после выполнения Merge.

Как раз только такой случай меня и интересует - для МРС.

P.S. ИМХО МРС малоприменим для малоцветных сканов вроде http://www.djvu-soft.narod.ru/scan/cla_pic.gif - всё запихивается целиком в маску, и от этого размер DjVu получается большим. Научиться бы влиять на размер маски - на размер фона мы уже здорово умеем влиять.

monday2000

Цитата:

Это не работает - наверное, глюк

Все работает. Значит, все дело в формате lzw-tif, который sk использует для серых/цветных зон. Не все утилиты понимают такой формат.

kontiky

Цитата:

Сделал Contrast zone - как мне изменить ее свойства?

Ее свойства задаются в gray enhance->contrast. Там такое правило: если стоит галка на enabled, то контраст применяется ко всей странице, а contrast-зоны если есть, игнорируются. Если же галка не стоит и контраст отличен от нуля, то считается, что это значение для contrast-зоны (если конечно таковые имеются на странице). Я не стал делать отдельный контраст для зон, т.к. мне ни разу не встретился случай, когда понадобилось бы использовать и то, и другое одновременно.

bolega

Цитата:

Все работает.

Неважно - я уже подправил fi_sep так, что он воспринимает и 8-битные цветные в т.ч.

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

Страничка: http://rapidshare.com/files/138052278/Image_0222.rar.html

Добавлено:
Только что понял, что такое происходит именно с полигональной зоной. Выделил обычный прямоугольник - все нормально...

ghosty
У меня такое один раз тоже было. Причина - в коде отсечения зоны резаком при очень малом угле наклона одной из сторон полигона (видимо, в этом случае очень сильно влияют ошибки округления). Еще пока не разбирался с этим глюком

У любого СК есть такой недостаток, о котором обычно мало говорится: после того, как сканы оказываются готовыми (полностью покромсанными) я лично ВСЕГДА прохожусь по ним и вручную сдвигаю каждый скан на 2-10 пикселей вправо (значительно реже - влево) - чтобы чисто визуально текст смотрелся отцентрованным точно посередине.

Интересно, в чём причина такой проблемы? Можно ли её полностью устранить? (Чтобы не надо было вручную центрировать) Может быть, причина в том, что блок текста всегда бывает слегка искривлен/изогнут по вертикали и правый-левый обрез текста не вертикальны?

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

bolega
Есть проблемка, если при обработке СК 5.91 страницы преобразовывать из 150 в 300 дпи, а Picture Zone при этом оставлять 150 и они будут полигонные-СК вываливает ошибку, если Picture Zone прямоугольные все нормально

pavel_nik_563
Да, про этот баг я знаю. Он уже исправлен. Исправленная версия будет в ближайшее время выложена.
Баг проявляется только на полигон-зонах с dpi<300

bolega

Цитата:

Исправленная версия будет в ближайшее время выложена.

Сделайте, пожалуйста, те несложные доработки, о которых я говорил недавно:
1. Сохранение в отдельную папку всех "картиночных" субсканов (например, out/sep).
2. Придайте всем субсканам, парным sep-субсканам (0001.sep), какой-нибудь суффикс (0001.fg, например) - чтобы эти файлы проще было отличить по имени от просто обычных сканов.
3. Переименуйте файлы "pic.0001" в "0001.pic" - чтобы упростить сортировку.
4. Опция сохранения Picture-зоны в выбираемом режиме цветности сейчас не работает.
5. Опция пост-удаления файлов "pic.0001" сейчас не работает.

И, наконец, самая главная и самая важная просьба:

6. Сделайте так, чтобы в той папке, где лежат разделённые сканы (допустим, out/sep), ВСЕГДА присутствовал текстовый ini-файл со следующей информацией:

а. Список имён разделённых сканов.
б. КООРДИНАТЫ местонахождения вырезанных картинок "pic.0001" на соответствующих исходных сканах.

И пусть эти координаты подправляются (если надо) на каждом этапе обработки в СК. Такой ini-файл даст неоценимую возможность обрабатывать разделённые сканы в любой сторонней программе - на любом этапе обработки разделённых сканов в СК.

Может быть, есть смысл не просто отделить разделённые сканы в отдельную папку out/sep, но ещё и внутри out/sep разделить их по видам по раздельным папкам.

monday2000

Цитата:

1. Сохранение в отдельную папку всех "картиночных" субсканов (например, out/sep).

OK, но в следующей версии (если таковая будет).


Цитата:

2. Придайте всем субсканам, парным sep-субсканам (0001.sep), какой-нибудь суффикс

Ничего не понял


Цитата:

3. Переименуйте файлы "pic.0001" в "0001.pic" - чтобы упростить сортировку

Во-первых, это невозможно. Иначе ни я, ни кто-либо другой не сможет больше открыть уже существующие задания. Во-вторых, наличие впереди "pic" и было специально сделано, чтобы картинки шли после выходных файлов, а не вперемешку. Иначе это был бы просто кошмар: запускаете DEE, открываете в нем папку out, и о ужас, страницы идут вперемежку с ненужными для djvu файлами-картинками.
Вопрос по данному пункту закрыт и не подлежит больше обсуждению


Цитата:

а. Список имён разделённых сканов.
б. КООРДИНАТЫ местонахождения вырезанных картинок "pic.0001" на соответствующих исходных сканах.

А зачем Вам координаты на исходных сканах??? Может быть, на выходных все-таки?


Цитата:

6. Сделайте так, чтобы в той папке

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

bolega

Цитата:

Иначе это был бы просто кошмар: запускаете DEE, открываете в нем папку out, и о ужас, страницы идут вперемежку с ненужными для djvu файлами-картинками.

Так именно для борьбы с этой проблемой и предлагается:

Цитата:

1. Сохранение в отдельную папку всех "картиночных" субсканов (например, out/sep).

Цитата:

Цитата:2. Придайте всем субсканам, парным sep-субсканам (0001.sep), какой-нибудь суффикс
Ничего не понял

После того, как сформированы файлы "pic.0001.tif", мы нажимаем Create separate files for non-b/w zones - создаются файлы "0001.sep.tif", а из исходных файлов "0001.tif" картинка вырезается. Я предлагаю переименовывать такие "0001.tif", из которых вырезана картинка, в "0001.fg.tif" - т.к. это уже не полноценный скан, а один из субсканов для МРС.

Цитата:

А зачем Вам координаты на исходных сканах??? Может быть, на выходных все-таки?

1. Да, на выходе, конечно же.
2. Если такой файл есть на входе - то не "терять" его после обработки и на выходе (корректируя координаты, если это необходимо по результатам обработки).
(Именно это нужно для обработки МРС-сканов в сторонних программах).

Цитата:

Могу добавить спец. команду для генерации такого файла.

Ну хоть так.

Добавлено:

Цитата:

Цитата:1. Сохранение в отдельную папку всех "картиночных" субсканов (например, out/sep).

OK, но в следующей версии (если таковая будет).

Это довольно важно для МРС. Зачем тянуть до следующей версии? Лучше сделайте сейчас. Это же совсем несложно. Введение такой папки позволит избежать всякой путаницы в выходных сканах. Юзер будет чётко знать: папка out подсовывается DEE, а папка out/sep - подсовывается FSD. И всё, и никаких проблем - не нужно будет следить, не попали ли случайно "pic.0001.tif" на вход DEE. А как Вы себе представляете сейчас - что юзеру делать, чтобы отсечь на входе в DEE файлы "0001.sep.tif", если они сидят в той же самой папке, что и простые сканы? Сейчас это можно сделать только вручную (или же я могу модифицировать DjVu Small, чтобы она автоматом отсекала на входе). A файлы "0001.tif", из которых вырезана картинка - их ведь тоже надо отсечь на входе в DEE.

Цитата:

A файлы "0001.tif", из которых вырезана картинка - их ведь тоже надо отсечь на входе в DEE.

А, понял зачем это. Но с другой стороны, удалять их и переименовывать тоже нельзя. В следущий раз задание не откроется, в sk все завязано именно на таких именах.
Могу сделать только одно: создать в процессе генерации sep-файлов батничек, который, если запустить, переместит нужные вых. файлы в спец. папку out/sepbckgrnd. После кодирования можно будет вернуть их обратно, чтобы не пострадало задание


Цитата:

мы нажимаем Create separate files for non-b/w zones - создаются файлы "0001.sep.tif", а из исходных файлов "0001.tif" картинка вырезается

Картинка вырезается раньше - еще в процессе обработки, на выходе она просто показывается поверху страницы.

bolega
В принципе, если я правильно понял выступающего, некое рациональное зерно в переименовании/разделении на разные папки есть.
Вчера делал книжку. Решил вставить текстовый слой, загоняю в FR, а там винегрет из "000?.tif" и "0001.sep.tif". Ну я вначале сделал нужный мне список файлов в Екселе. Вставляю в соотв. поле в FR, а там ограничение на кол-во знаков Только тогда додумался использовать стандартный файловый поиск по критерию "000?.tif". Полученный список вставил в FR

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

bolega

Цитата:

Могу сделать только одно: создать в процессе генерации sep-файлов батничек, который, если запустить, переместит нужные вых. файлы в спец. папку out/sepbckgrnd.

Это кто угодно может сделать. Это не имеет смысла.

Добавлено:
ghosty

Цитата:

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

А как же по-другому-то? DEE создаёт многостраничный ЧБ DjVu-файл без страниц, содержащих полутоновые картинки. Таковые страницы создаются отдельно в FSD - а потом вставляются в нужные места многостраничного ЧБ DjVu-файла.

Добавлено:
PS Про Файнридер я не подумал. Тогда остаётся единственный вариант:

1. Папку out/sep всё же делать.
2. Класть туда после обработки такие файлы:

а. Файлы "0001.sep.tif".
б. Файлы "pic.0001.tif".

3. Файлы "0001.tif", из которых вырезана картинка, пусть остаются на прежнем месте - в папке out.

4. Я могу подкорректировать DjVu Small так, чтобы при указании ей на входе папки out программа проверяла существование папки out/sep, находила в папке out файлы "0001.tif", из которых вырезана картинка, и отсекала их на входе (Это для создания многостраничного ЧБ DjVu-файла без страниц, содержащих полутоновые картинки).

5. Попросить модифицировать FSD так, чтобы при указании ей на входе папки out программа проверяла существование папки out/sep, находила в папке out файлы "0001.tif", из которых вырезана картинка, и сами вырезанные картинки - и делала из всего этого одностраничные МРС-DjVu.

monday2000

Цитата:

1. Папку out/sep всё же делать.
2. Класть туда после обработки такие файлы:

а. Файлы "0001.sep.tif".
б. Файлы "pic.0001.tif".

Я ж говорил, что расположение файлов-зон менять нельзя. Да и зачем они там нужны. Ведь Pic-файлы нигде больше не используются, только в sk.

Я вообще поступаю проще. Сохраняю out-папку. Делаю merge, потом FR, потом восстанавливаю out-папку. Если в зонах только иллюстрации, без цветного текста, то merge вообще не делаю, зачем зря напрягать FR не-текстовыми данными.


Цитата:

Это кто угодно может сделать

Я бы не сказал, что это банально. Перемещать нужно ведь только те файлы вида XXXX.TIF, для которых существуют XXXX.sep.tif