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

bolega
благодарю ещё раз за советы.

Переделал с picture zones по методу с djvu imager. Всё получилось красиво

Arcand

Цитата:

Положение можно немного поправить, если обработать рисунки

Я так и делал, но параметры там неочевидные.
Давно не делал книги со скриншотами, надо будет тоже попробовать с помощью djvu imager.
Последний раз я сделал так: для переведенной на русский язык книги нашел английский электронный векторный вариант, выдрал из него скриншоты и вставил в скан как внешние picture-зоны Метод работает, если в нашем издании не локализовали скриншоты

bolega

Цитата:

надо будет тоже попробовать с помощью djvu imager.

Я понял, что это мм... вариант метода разделенных сканов . Рисунок целиком помещается в фон. Т.е. преимуществ перед кодированием в DEE (и в FSD) ИМХО нет.

bolega

Цитата:

А при чем тут сканирование? Важен формат после обработки, а не до.

Да это касательно ScanAndShare просто мысль мелькнула - я её записал, чтобы не забыть.
Arcand

Цитата:

Т.е. преимуществ перед кодированием в DEE (и в FSD) ИМХО нет.

На вкус и цвет... Зато это ИМХО более гибкий и наглядный для юзера способ - чем муторная подготовка сканов под DEE (для случая полутоновых иллюстраций).

К тому же DjVu Imager позволяет прямо "по месту" (при кодировании в DjVu) "интерактивно" размылить полутоновые иллюстрации до желаемой степени (или, что то же самое, "интерактивно" снизить размер получаемого DjVu). Это удобно, просто и наглядно, в то время как при использовании DEE надо "размыливать" сканы не в самом DEE - а в СК или Кореле (лишний гемор).

DjVu Imager - это удобство и простота (разумеется, для определённой категории сканов).

Добавлено:
bolega

Цитата:

Есть еще один тип иллюстраций, который лучше дизерить, чем делать gray. Это скриншоты окон в компьютерных книгах. Если переводить их в gray, то в djvu они сильно мылятся, даже если использовать специальные (недефолтные) профили DEE.

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

Добавлено:
Nitrofest

Цитата:

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

Разумеется, это по определению гораздо более лучшее качество, чем Picture-зоны + DjVu Imager. Ведь слой маски в DjVu-файле идёт с высоким разрешением - а слой заднего фона - с низким. Но зато размер у варианта с дизерингом, как правило, огроменный получается (+ ещё такие косяки вот с ошибкой кодирования, оказывается, бывают).

Цитата:

в то время как при использовании DEE надо "размыливать" сканы не в самом DEE - а в СК или Кореле (лишний гемор).

Хочу пояснить суть дела для посетителей топика. Кодер размыливает сканы (фон) - это особенность его метода кодирования. В прогах же выполняется удаление растра (это ну никак не размыливание) плюс обработки: тоновая коррекция, (факультативно) контурная резкость. Все это с целью улучшить рисунок и результат кодирования - кодер уже заметно меньше искажает/размыливает такой рисунок.

ЗЫ: Нормальные герои всегда идут в обход

Arcand

Цитата:

ЗЫ: Нормальные герои всегда идут в обход

Оба подхода имеют право на жизнь. Но Ваш подход требует бОльшей квалификации от юзера. DjVu Imager же прост как палка - а результаты выдаёт при этом весьма приличные. Чтобы достичь то же самое Вашим подходом (через СК-Corel-DEE), нужно проявить немалое мастерство (это можно считать сравнительным недостатком Вашего подхода).

monday2000
Цитата:

Чтобы достичь то же самое Вашим подходом (через СК-Corel-DEE), нужно проявить немалое мастерство (это можно считать сравнительным недостатком Вашего подхода).

Неверное утверждение. Интересно, на чем же оно основано?
Кодеры в documenttodjvu, msepdjvu, в phototodjvu, в с44 кодируют фон с помощью алгоритма IW44. Т.е. по идее одинаково! Поэтому, если специально не обрабатывать картинки, то результаты кодирования при одинаковых настройках для фона в DjVu Imager, DEE и FSD будут идентичны (без учета сегментации рисунка в DEE).
Дополнительная обработка рисунков (удаление растра, тоновая/цветовая коррекция, адаптивное размытие, сглаживание, контурная резкость - такие обработки в том или ином сочетании я применяю) позволяет при тех же настройках фона кодера существенно улучшить рисунок в дежавю.

ЗЫ: Как я понял рисунки в DjVu Imager специально не обрабатываются. Тогда как же повышается качество рисунков? Может там кодер фона особый?

Arcand

Цитата:

Кодеры в documenttodjvu, msepdjvu, в phototodjvu, в с44 кодируют фон с помощью алгоритма IW44. Т.е. по идее одинаково!

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


Цитата:

Поэтому, если специально не обрабатывать картинки, то результаты кодирования при одинаковых настройках для фона в DjVu Imager, DEE и FSD будут идентичны (без учета сегментации рисунка в DEE).
Дополнительная обработка рисунков (удаление растра, тоновая/цветовая коррекция, адаптивное размытие, сглаживание, контурная резкость - такие обработки в том или ином сочетании я применяю) позволяет при тех же настройках фона кодера существенно улучшить рисунок в дежавю.

Сомнительное заявление. Особенно "улучшить рисунок в дежавю". Про "улучшить рисунок" могу поверить, а про "в дежавю" - имхо излишнее.

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

Добавлено:
Как обстоят дела в реальности не знаю. Просвятите кто автор(ы) реализации кодеков ? И есть ли в них разница ?

ndch

Цитата:

Как обстоят дела в реальности не знаю. Просвятите кто автор(ы) реализации кодеков ? И есть ли в них разница ?

У меня была гипотеза, что JPEG2000 имеет некую простейшую встроенную шумодавилку. Во всяком случае, при сравнении IW44 и JPEG2000 я получал на шумном материале существенно лучшее качество в пользу JPEG2000. Возможно, это особенность самого алгоритма, и никакой отдельной шумодавилки нет.

Arcand прав в том, что перед кодированием в DJVU обработка ОБЯЗАТЕЛЬНА - как для текстового слоя, так и для картинок. Если кодировать в PDF (JBIG2+JPEG2000), то возможны некоторые исключения, которыми можно пренебречь - например, цветная периодика-однодневка
В общем, лучше всегда проводить предобработку сканов независимо от конечного формата. Обрезать в любом случае нужно, а если обрезать, то почему не обработать.

Что касается раздельного кодирования, проще FSD быть уже ничего не может - тут важно было найти саму возможность (спасибо manfred&Arcand), а реализацию усложнить практически невозможно...

ndch
Цитата:

Сомнительное заявление. Особенно "улучшить рисунок в дежавю". Про "улучшить рисунок" могу поверить, а про "в дежавю" - имхо излишнее.

Мое заявление основано на опыте. А Ваше утверждение на чем?
Именно улучшить рисунок и именно в дежавю. Растр усложняет кодирование.
В случае DEE часть растровых точек попадает в маску, часть в фон - такое ощущение, что сегментер дергается. Результат иногда получается отвратительный. Если растр убрать и подчеркнуть (контурной резкостью) переходы, то рисунок сегментируется и кодируется почти как по маслу. Остается подобрать разрешение фона и его качество, чтобы рисунок в дежавю был как надо.
В FSD (рисунок целиком помещается в фон) ситуация несколько иная. Но все равно, растр кодер размывает не лучшим образом. Иногда это выглядит как если бы на свежеотпечатанный рисунок попрызгали водой - разводы, смазанность. Если растр профессионально убрать, рисунок в дежавю будет уже заметно лучше выглядеть.

Цитата:

Отсюда следует что реализация алгоритма может быть различна. Как например в случае с jpeg2000.

Про различие кодеров возможно. Но если оно и есть, то не принципиальное. Как и в случае jpeg2000.

ЗЫ: Вообще-то здесь все это офтопик. Приношу извинения и закругляюсь.

Arcand
Строго говоря, конечно, не "то же самое".

Я имел в виду, что Ваша методика ( http://www.djvu-soft.narod.ru/scan/corel_scan.htm ) не предполагает использования Picture-зон, а моя ( http://www.djvu-soft.narod.ru/scan/djvu_imager.htm ) - предполагает.

В этом и есть принципиальное различие. Подход "без Picture-зон" требует от юзера на порядок большего уровня мастерства, чем подход "с Picture-зонами". Не спорю - качество Вашего подхода должно быть выше, чем моего. Хотя и при моём подходе никто не мешает обрабатывать в Кореле сканы и вырезанные из них Picture-зоны (раздельно).

Пусть DjVu Imager даёт результат не такой суперэстетичный - но всё же на приемлемом уровне. Зато достигается высокая простота.
ghosty

Цитата:

Что касается раздельного кодирования, проще FSD быть уже ничего не может

Это верно, но FSD требует для своей работы msepdjvu - а DjVu Imager довольствуется documenttodjvu.
Это хорошо, если исходить из концепции "минимум вареза". При моём подходе абсолютно всё многообразие DjVu-программ можно будет сделать практически полностью легальным - за исключением одного-единственного documenttodjvu (используемого как движок). А если применять FSD - то нужно уже 2 варезные программы - documenttodjvu и msepdjvu.

Я вообще стараюсь вести дело к полной легализации (и открытию исходников) всего комплекса DjVu- и сканобрабатывающего софта. Уже вон даже и Файнридер, надеюсь, скоро удастся заменить на легальный CuneiForm. Pdftodjvu потихоньку уже заменяется на легальный pdf2djvu. Document Express Editor можно будет заменить самодельным гибридом WinDjView + DjVuLibre-утилиты (ещё и гораздо лучше получится), а способность кодировать сканы в DjVu (как то проповедует ScanAndShare) этой софтине (Document Express Editor) вообще нахрен не нужна.

Потому что, пожелай кто-нибудь (власти РФ) нас всех "прижать" - ему легко будет сыграть на варезности софта (забавно, что и СК тут не святой ).

Пока лишь только один-единственный documenttodjvu остаётся незаменимым и портит всю благостную картину возможной полной легальности. Но его можно будет на 80-90% заменить связкой miniDjVu+DjVu Imager (особенно, если удастся чуток улучшить miniDjVu).
А если попробовать скрестить алгоритмику CuneiForm + miniDjVu - то, быть может, получится нечто не хуже documenttodjvu.

Так что, как видите, появление на свет DjVu Imager далеко не случайно - оно вписано в общий стратегический замысел "максимальной легализации".

bolega
Возможно ли теоретически реализовать следующее?
Обрабатывалась книга, отсканированная в 600dpi, в конце обработки сохранено задание и исходные сканы, переведенные (для уменьшения объема) в 300dpi.
Через некоторое время возникла необходимость поработать с этими сканами.
Можно ли программно преобразовать запомненные координаты резаков и зон, чтобы они были действительны для 300dpi? Вроде бы остальные параметры не требуют изменения, если для обработки задать апсеймплинг.

Arcand

Цитата:

Мое заявление основано на опыте. А Ваше утверждение на чем?

А моё заявление основано на опыте.


Цитата:

Про различие кодеров возможно. Но если оно и есть, то не принципиальное.

Естественно не принципиальное. Но может быть значительным.

shch_vg
Теоретически можно, и это нетрудно. Но куда вставить такую команду, пока не представляю

bolega

Цитата:

Но куда вставить такую команду, пока не представляю

Действительно, это непросто, тем более в задании могут быть сканы с разным дпи, и изменять нужно только свойства части сканов. М.б. имеет смысл привязать это к выборке конкретного значения в списке "Input DPI" на закладке Files? При такой выборке можно давать окно, предлагающее привести координаты резаков и зон к выбираемому дпи, с возможностью отказаться (а м.б. сделать это опционно?). Правда такое ощущение, что здесь тоже не все сходится до конца.

shch_vg
Проблема немного в другом. Это нужно сделать до открытия задания. При открытии СК может править положения резаков, если они уходят далеко от скана. Т.е. есть задание для 600dpi, его открывают, но там файлы уже 300dpi, резаки оказываются далеко от сканов, СК сразу же может поменять положения резаков. Т.е. команду нужно делать до открытия задания, чтобы к моменту открытия СК уже знал, что ему делать. Но до открытия нельзя будет пометить файлы, если нужна выборочная операция...

bolega
Я понял, что автоматически трудно реализовать, но почему нельзя сделать по-другому. Открываю я такое задание, вижу, что резаки стоят далеко от сканов, вспоминаю(!), что изменилось дпи, выбираю нужное мне дпи из списка "Input DPI", и после подтверждения программа корректирует резаки и зоны только тех сканов, у которых другое дпи.
Или в файле spt нет информации о разрешении скана? Если так, то менять стандартно из выборки по условию.

Цитата:

...Обрабатывалась книга, отсканированная в 600dpi, в конце обработки сохранено задание и исходные сканы, переведенные (для уменьшения объема) в 300dpi....

shch_vg,
Лучшее первое преобразовать файлы из 300dpi на 600dpi ...
Затем будет, как это было в начале!

shch_vg

Цитата:

почему нельзя сделать по-другому

Я же говорю, что СК изменит положение резаков если они стоят далеко. И это так и останется. Потому что, за исключением Вашего случая, это логично и правильно. Если этого не сделать, то исправить их положение будет вообще невозможно, т.к. они не будут отображаться. Да и зачем нужно оставлять резаки в метре от скана, это бессмысленно.
Я хочу сказать вот что. Случай Ваш очень специфический. И ради него одного я не буду переделывать кардинально поведение СК при открытии заданий и трактовать иначе Input dpi. Здесь нужно искать другой путь. Например, между диалогом выбора файла задания и его открытием показать спец. диалог, в котором и ввести параметры преобразования. Естественно, этот диалог должен вылезать не всегда, а только когда юзеру надо. А чтобы СК узнал, когда это наступит, можно держать нажатой какую-нибудь клавишу в момент открытия диалога выбора spt-файла. Пока только это пришло в голову. Устроит?


Добавлено:

Цитата:

Или в файле spt нет информации о разрешении скана?

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

bolega

Цитата:

Устроит?

Вполне!

Когда будет final version SK ??

С форума Инфаната:

http://www.athelstane.co.uk/kromsate.htm

Обновите шапку, вышла уже версия 5.93

Цитата:

вышла уже версия 5.93

раз в шапке нет, значит не вышла

bolega
М.б. эта информация будет Вам полезна, касается она импорта из пдф в win2000.
Вчера обнаружил, что импорт из пдф, сделанных со сжатием JPG2000, работает, пустые файлы получаются, если пдф делался со сжатием JPG.

bolega
Я покрамсал книгу версией 5.93, смотрю в Кромсаторе результаты, на одной странице требуется повернуть текст, я его, как обычно, выделяю и жму "Rotate selection". И вдруг в результате получаю пустую страницу и сообщение "Unsupported clipboard format".
Пробовал с тем же spt-файлом версии 5.92 и 5.91 - то же самое, хотя в них вращение работало раньше. Такая же проблема была у ghosty, но у него с картинкой, а у меня - ещё и с текстом.

Ещё баг (?) 5.93 - цветная picture zone c опцией Color "Original" (или "Color 24bit") превращается в серую.

shch_vg

Цитата:

М.б. эта информация будет Вам полезна, касается она импорта из пдф в win2000.
Вчера обнаружил, что импорт из пдф, сделанных со сжатием JPG2000, работает, пустые файлы получаются, если пдф делался со сжатием JPG.

Спасибо за информацию. Кажется, это происходит из-за отсутствия у Вас gdiplus.dll. Положите эту dll в папку windows\system32. С win2000 эта dll не поставляется, ее можно взять из XP. СК ее на самом деле не использует, но в одной из либ, которая применяется в СК, есть какая-то зависимость от нее. Постараюсь убрать ее.

amv
Баг с карманом уже исправил. Но при помещении в карман больших областей серых/цветных сканов проблема осталась. Исследование показало, что в clipboard не помещаются куски памяти, большие определенного предела. Т.е. winapi-функции windows просто возвращают ошибку типа "слишком много хотите засунуть, товарищ".
Что с этим сделать, я пока не знаю.
Второй упомянутый Вами баг уже исправлен.

bolega

Цитата:

Положите эту dll в папку windows\system32

Поместил рядом со Сканкромсатором, и импорт заработал!
Спасибо!

bolega
Столкнулся с очень странной работой кромсатора.
Обрабатывал сканы журнала из 32 стр. В Draft kromsite расставил резаки и проверил их расстановку. После запуска на полное выполнение с автоматическим определением размера страницы получил страницы с большими полями. Стал просматривать результирующие страницы, и оказалось, что Кромсатор почему-то развернул ОДНУ страницу (с двухколоночным текстом, а таких много) примерно на 45 градусов против часовой и именно по ней рассчитал размер страницы. После того, как я задал именно для этой страницы поворот Art и запустил заново автоопределение размера страницы, все прошло нормально.
В предыдущих версиях я с таким поведением не сталкивался.

shch_vg
И у меня такая беда была в 5.93, не всегда верно deskew работает, тот же прием помогает.