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

shch_vg

Цитата:

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

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


kordon555

Цитата:

В первый раз об этом слышу. А где скачать эту версию? Я пользуюсь версией 5,93 и не видел там такого.

Еще нельзя скачать нигде - в разработке.

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

Цитата:

Еще нельзя скачать нигде - в разработке.

То есть, это не из области “хотел бы сделать”? С нетерпением буду ждать.

Это уже сделано.
Осталось добавить раскраску зон средствами djvulibre и хорошенько потестировать

Добавлено:
shch_vg
Для скроллинга я как-то добавлял спец. hotkey (zigzag)

shch_vg

Цитата:

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

Напротив, я, возможно, один из самых несчастных людей в этом отношении, именно поэтому и решил взять слово Мне знакомы такие проблемы. И тем не менее настаиваю, что настройки обработки - это главное. Если в книге действительно много грязи, которую нельзя отфильтровать на этапе обработки полутонового изображения, то все равно остается еще возможность настройки деспекла. Например, знаете ли Вы, что размер спекла можно настраивать не только для постобработки (Clear Options), но и для обработки (Options->Processing->Despeckle Sizes). Вообще, хитростей разных довольно много.
Даже в самых запущенных случаях у меня не было так, чтобы все страницы приходилось чистить по всей площади.

ghosty

Цитата:

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

Это сказали Вы, а не я.
Грязь очень часто бывает не по всей площади, а попадаться в любом месте "всей площади" (почувствуйте разницу! . В связи с этим приходится просматривал ВСЮ площадь при большом увеличении.
Кстати, если в буквах имеются лишние детали (даже небольшого количества), касающиеся самой буквы, то никакие настройки не помогут их убрать, кроме ручной очистки. Что касается настройки, то я могу дать возможность попробовать сделать это на конкретном примере, м.б. тогда у Вас несколько изменится мнение.
Желательно перевести этот диспуп в ЛЯ, т.к. он уже имеет мало отношения в этой теме.

shch_vg

Цитата:

В связи с этим приходится просматривал ВСЮ площадь при большом увеличении.

О том, что спеклы можно подсвечивать и даже заставить их мигать, знаете? В этом случае увеличивать не обязательно

Цитата:

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

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

Цитата:

Желательно перевести этот диспуп в ЛЯ, т.к. он уже имеет мало отношения в этой теме.

Да вроде, пока прямое отношение имеет. Нет, если Вам не интересно, то и я замолчу.

bolega

Цитата:

Для скроллинга я как-то добавлял спец. hotkey (zigzag)

У меня по этому ключу происходит переход либо в другой конец страницы, либо на следующую. Я же в своем сообщении писал о другой ситуации.

Цитата:

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

Да, такое бывает. Действительно, "против лома нет приема"

L

Цитата:

не могу импортировать PDF файл, out of memory, версия последняя. поискал по топику, но там про изображения, не pdf. сам pdf прекрасно читается.

Вообще, разобрался я с этим файлом. Спасибо большое за образец.
PDF действительно прекрасно читается, более того, прекрасно потрошится СК на отдельные сканы. Проблема была в другом - первая страница там состоит из комбинации двух сканов. СК, встречая такие страницы, пытается как бы воссоздать в СК их так, как они выглядят в pdf. Делает это он с помощью зон. В данном случае ему это не удалось, из-за того, что одно из составляющих было некорректно описано в pdf. В общем случае такие ошибки акробату по-барабану, так же как и любой другой программе, которая просто отображает, или просто извлекает изображения, не выявляя между ними связи.
Чтобы обойти проблему с этим файлом, в диалоге import pdf поставьте галку на do not use zones. И все будет ОК. СК все извлечет как надо, не заморачиваясь с зонной структурой (в данном случае это на самом деле не надо).
И еще, там некоторые страницы извлекаются инвертированными. Для них на закладке Pages в special->More поставьте опцию invert

ghosty

Цитата:

О том, что спеклы можно подсвечивать и даже заставить их мигать, знаете? В этом случае увеличивать не обязательно

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

Цитата:

Вообще, изначально я пытался лишь помочь

За 4,5 года использования СК я, к сожалению, не пришел к выводу, который Вы сделали в своем сообщении. То, что предварительная правильная настройка просто необходима, с этим я с Вами полностью согласен. Беда в том, что даже потратив на такую настройку массу времени, не всегда удается получить удовлетворительный результат. "В плоть и рядом" (как говорил один мой знакомый) эти настройки различаются даже для соседних разворотов, не говоря уже обо всей книге. Если же к общим проблемам настройки обработки текста добавить еще дополнительную обработку шахматных диаграмм (которая довольно часто несовместима с обработкой текста), то вопрос настройки возрастает минимум вдвое.

Что касается примера, то я забыл предупредить, что это книга на 424 стр., причем исходные сканы занимают более 300 мб.
Если это Вас не испугало, то ссылки можно взять здесь.
Сразу хочу сказать, что это не самый худший вариант из встречавшихся мне, хотя, конечно, есть и гораздо лучшие .

shch_vg

Цитата:

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

Да зачем мне эти 300 мб. Если считаете, что сделали все, что могли, значит, так оно и есть, убедили
Другое дело, бороться с ошибками и браком набора - это все-таки не очень благодарный труд.

ghosty

Цитата:

бороться с ошибками и браком набора - это все-таки не очень благодарный труд.

То-то и оно!
Например, в 80-х годах более-менее ценные книги издательства "Физкультура и спорт" выпускались так, что не приведи господь, зато издательство Воениздат выпускало книги об армейских шахматистах на мелованой бумаге, требующие минимальной настройки при обработке.

Подскажите, каким образом запустить в пакетном режиме несколько предварительно подготовленных задач на кромсание?

За ночь комп мог бы откромсать с десяток книг.

romanef
не знаю как насчет ком. строки у кромсатора, можно было бы это сделать с помощью nnCron.

Добавлено:
shch_vg
Original для сохранения цвета попробовал сразу. не помогло. по вашему совету попробовал Art, тоже не помогает.

bolega

Цитата:

Для кодирования обложек и ч/б страниц СК использует DEE (т.к. он наиболее продвинутый и наиболее управляемый из командной строки).

Правильное решение. А то вот Тулон хотел для этого minidjvu приспособить.

Цитата:

Осталось добавить раскраску зон средствами djvulibre и хорошенько потестировать

В смысле, метод раскраски маски? ИМХО разумно - у Тулона до этого руки не дошли. Кстати, раскраска маски может быть как ручная (а-ля djvumake), так и автоматическая (а-ля сpaldjvu). Ещё, правда есть вариант с чанком FG44 вместо FGbz - но ИМХО непонятно - зачем вообще существует FG44, раз уж есть FGbz.

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

L

Цитата:

по вашему совету попробовал Art, тоже не помогает.

Выложите один разворот и файл spt Вашей обработки этого разворота.

shch_vg, L
Похожие проблемы обсуждались на стр. 24. Опция Art помогает против бага с deskew, а вот что делать с тем, что цветные страницы становятся ч/б - не знаю.

amv
Эти разговоры бессмысленны, пока не будет приведен конкретный пример - разворот + файл spt обработки этого разворота.
Вот тогда и появится почва для обсуждения.

bolega
В Option->Apps можно выбрать JPEG2000. Этот кодек используется как для декодирования, так и для кодирования? Или только для кодирования?
Просто очень хотелось бы улучшить скорость именно декодирования. Можно ли это сделать?

ghosty

Цитата:

Или только для кодирования?

Судя по тому, что при заданном у меня пути к кодеку JPEG2000, декодирование PDF, закодированного этим кодеком, тормозит, то только для кодирования.
Только что проверил, импортируя pdf с прописью пути и без. Разборка идет медленно в обоих случаях.

Только для кодирования.
demo-kakadu имеет ограничения на форматы jpg2000. Поэтоу декодировать им можно не все типы jpg2000.

bolega
Экспериментируя с импортом PDF, столкнулся со следующей проблемой.
В процессе разборки решил прервать этот процесс, нажав клавишу Cancel в окне Processing... Поскольку никаких визуальных действий после этого я не увидел, то повторно нажал на клавишу Cancel. Вот тут-то и началось самое интересное.
Окно Processing... стало пустым, а через некоторое время снова появилось на мгновение и исчезло. После минимизации и максимизации СК через некоторое время окно Processing... снова появилось, по тексту которого стало ясно, что процесс импорта продолжается, правда появилось одно НО...
Вспомогательное меню стало пустым.
После нажатия на Cancel и выжидания определенного момента, появилось окно с вопросом, прервать ли процесс импорта. После подтверждения прерывания через некоторое время окно Processing... исчезло, зато внизу в панели задач окошко Сканкромсатора стало мигать, причем на легальные способы закрытия СК не реагировал, занимал все процессорное время и был удален только через менеджер задач.
Это было как в ХР, так и сервер 2003.
Если же удержаться от повторного нажатия на клавишу Cancel (см.начало моего сообщения), то после появления окна с вопросом, прервать ли процесс импорта, правильно срабатывало как подтверждение прерывания импорта, так и отказ от прерывания.
Однако помнить о том, что нельзя повторно нажимать Cancel, довольно трудно.
Если из-за работы декодера нельзя быстро отреагировать в окне Processing... на попытку прервать импорт, то м.б. в окне свойств импорта pdf давать предупреждение о ненажатии повторно клавиши Cancel при попытке прервать процесс импорта?

P.S. Эти действия делались при импорте PDF, закодированного кодером JPEG2000, поэтому периоды между импортируемыми сканами значительны, и есть время воспроизвести указанные мной действия.
При импорте обычного PDF выход на окно вопроса делается практически мгновенно, поэтому указанной мною проблемы не наблюдается.

monday2000

Цитата:

В смысле, метод раскраски маски? ИМХО разумно - у Тулона до этого руки не дошли. Кстати, раскраска маски может быть как ручная (а-ля djvumake), так и автоматическая (а-ля сpaldjvu). Ещё, правда есть вариант с чанком FG44 вместо FGbz - но ИМХО непонятно - зачем вообще существует FG44, раз уж есть FGbz.

Раскраску сделал. Метод получился универсальный. Т.е. для зон любой формы и возможно, соприкасающихся или пересекающихся между собой.
сpaldjvu не подходит, т.к. исходим из-того, что djvu для ч/б страниц у нас уже есть. В этот djvu и будет подклеиваться фон (методом МПФ) и одновременно выполняться раскраска (если на странице одновременно есть обычные pic-зоны и раскрашенные pic-зоны). Раскраску сделал через чанк FG44. FG44 получаю через djvumake с хитрым параметром PPM. Поддерживается раскраска как текста, так и фона, или оба одновременно.
Применить FGbz мне так и не удалось, т.к. что подавать ему в качестве raw data, я так и не понял. Да и смысла в этом нет. Не применял также и новую возможность последней версии djvulibre, когда можно задать прямоугольные области с цветом. Метод неплохой, но неуниверсальный: не годится для зон сложной формы, для пересекающихся зон, а также для случаев, когда цвета соприкасаются (между собой или даже с черным цветом букв).

bolega

Цитата:

Раскраску сделал через чанк FG44

На мой взгляд, это худшее решение - по сравнению с FGbz. Потому что FG44 по размеру на порядки больше, чем FGbz. Такое решение не сможет конкурировать с DjVu Pal, и поэтому ИМХО бессысленно.


Цитата:

Метод неплохой, но неуниверсальный: не годится для зон сложной формы, для пересекающихся зон, а также для случаев, когда цвета соприкасаются (между собой или даже с черным цветом букв).

Все это можно запрограммировать в djvumake (т.е. убрать эти недостатки). В частности, у меня есть мой клон djvumake - djvumakem (внутри DjVu Pal v1.1) - который умеет сохранять старый FGbz, и рисовать поверх него новый.

Цитата:

сpaldjvu не подходит, т.к. исходим из-того, что djvu для ч/б страниц у нас уже есть.

Не понял - почему не подходит? У нас изначально имеются цветные сырые сканы - где есть как чёрно-белый текст, так и цветной. Чёрно-белый текст - бинаризуется, цветной - постеризуется. Результат скармливается сpaldjvu, который создаёт FGbz (насколько помню, не FG44) автоматически - т.е. как бы "распознаёт" цветной текст. Я думаю, что за таким подходом будущее. Раскрашивать текст врукопашую неудобно - раз уж есть надёжно работающий автоматический алгоритм раскраски.

Цитата:

Применить FGbz мне так и не удалось, т.к. что подавать ему в качестве raw data, я так и не понял.

Массив цветов, сжатый bzz. Смотрите исходники djvumake - там довольно несложно в том месте, где раскрашиваются зоны.

monday2000

Цитата:

Потому что FG44 по размеру на порядки больше, чем FGbz

Это будет интересно сравнить на практике. Только объясните, как получить данные, чтобы скормить их как FGbz. Какой утилитой? сpaldjvu? Я пробовал, не получается. Запускал сpaldjvu, потом вынимал из результата слой с помощью djvuextract и добавлял к осн.файлу через djvumake. Все собиралось без ошибок, но при открытии такого djvu просмотрщик выдавл ошибку (типа что-то не так с палитрой).
Если мне удастся сделать через оба метода, тогда я и буду сравнивать, какой эффективнее для раскрашенных зон.


Цитата:

Раскрашивать текст врукопашую неудобно

Речь идет о раскрашенных ч/б СК-зонах. Вы наверное, не представляете, что это такое в СК. Это обычный ч/б файл, который СК раскрашивает на лету, т.е. заменяет черный цвет на заданный.
Поэтому фраза

Цитата:

У нас изначально имеются цветные сырые сканы - где есть как чёрно-белый текст, так и цветной

не про этот случай.
Т.е. я могу получить в СК пустую страницу (или с ч/б текстом), поместить на нее раскрашенную зону (как правило текст) и теперь мне из этого результата нужно получить FGbz. Как?


Добавлено:

Цитата:

Все это можно запрограммировать в djvumake (т.е. убрать эти недостатки).

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

Добавлено:

Цитата:

У нас изначально имеются цветные сырые сканы - где есть как чёрно-белый текст, так и цветной

В СК перед созданием djvu изначально имеется: покромсанные ч/б сканы + зоны, цветные и ч/б-раскрашенные

И еще. Если я правильно понимаю, FGbz - это раскраска, ориентированная на блиты, в отличие от FG44, ориентированной на пиксели. Поэтому с FGbz вылезают ограничения, о которых я писал, что неприемлимо. Или я не прав?

Добавлено:

Цитата:

Не понял - почему не подходит?

Потому что ч/б составляющая страницы уже закодирована в DEE (с общим словарем). Мне нужно только добавить в нее слой раскраски, не меняя маску (как это делается в МПФ)

bolega

Цитата:

Это будет интересно сравнить на практике.

Я сравнивал на практике. Ответ очевиден - FG44 - это полноценный слой, т.е. изображение, сжатое в IW44. Пусть и в 12 раз уменьшенное, но всё равно это - изображение (вроде одеяла из цветных лоскутов). А FGbz - это всего лишь обычный массив в терминах программирования, да ещё и сжатый архиватором bzz. Так что размеры обычно бывают такие: FGbz - 0,1 КБ, FG44 - 3,4 КБ. Разница - в десятки раз по весу.

Цитата:

Только объясните, как получить данные, чтобы скормить их как FGbz. Какой утилитой? сpaldjvu?

Такой утилиты вроде нет отдельной. Сейчас её роль играет djvumake. Смотрите нужный кусок кода в djvumake, создающий FGbz.

Цитата:

Запускал сpaldjvu, потом вынимал из результата слой с помощью djvuextract

А надо было делать FGbz посредством djvumake и извлекать его с помощью djvuextract - вот тогда проблем с обратной вставкой FGbz не возникло бы. Но вообще странно, что в данном случае возникли проблемы - вроде не должны были.

Цитата:

не про этот случай.

А, понял. Не знал о "раскрашенных ч/б СК-зонах".

Цитата:

теперь мне из этого результата нужно получить FGbz. Как?

Через djvumake.

Цитата:

Вариант править Djvulibre под конкретную задачу - это тупиковый путь.

Можете напрямую написать программу на DjVuLibre API - вот автор WinDjView так и делал в WinDjView. Я бы на Вашем месте просто сделал себе клон djvumake с нужными свойствами - и необязательно при этом вносить этот клон в состав DjVuLibre. Просто такой вариант наименее трудозатратен - djvumake уже есть, нужную работу она уже делает, только чуть-чуть не так, как хотелось бы, но это дело поправимое. Можно, к примеру, внести в djvumake раскраску по растровым шаблонам. Т.е., чтобы все блиты, поверх которых оказывааются пиксели из шаблона, закрашивались цветом из шаблона.

Цитата:

Если я правильно понимаю, FGbz - это раскраска, ориентированная на блиты, в отличие от FG44, ориентированной на пиксели.

Совершенно верно. FG44 - это картинка, а FGbz - это коротенький массив. Каждый элемент массива - это цвет в RGB и массив номеров блитов, имеющих этот цвет.

Цитата:

Поэтому с FGbz вылезают ограничения, о которых я писал, что неприемлимо.

Основное ограничение FGbz в том, что при нём один блит может окрашиваться только одним цветом. На мой взгляд, несущественно. А FG44 позволяет раскрасить один блит более чем одним цветом. Но за счёт роста размера слоя переднего плана в десятки раз (по сравнению с FGbz).

Цитата:

Потому что ч/б составляющая страницы уже закодирована в DEE (с общим словарем). Мне нужно только добавить в нее слой раскраски, не меняя маску (как это делается в МПФ)

А я и не имел в виду применять cpaldjvu непосредственно. Я подразумевал взять из cpaldjvu кусок кода, который автоматически генерирует FGbz. Я давно задумал, к примеру, воткнуть такой кусок кода в minidjvu.

bolega
monday2000
а почему бы не объединять FGbz и FG44 на одной странице?.. тогда и размеры будут приемлемые, и полчанка при необходимости закрасить можно.. конечно, код немного усложнится в плане проверки на полную\частичную заливку чанка, но если FG44 действительно дает существенное преимущество в размерах файла, то может быть стоит попробывать?..

NME

Цитата:

а почему бы не объединять FGbz и FG44 на одной странице?..

К сожалению, djvumake не позволяет это. Допускается либо одно, либо другое. Передок может быть только один.
Переделывать djulibre конечно интересное и поучительное занятие, но не для меня. Это все таки не мой профиль. Я хотел лишь приладить то, что уже есть, а не залезать в дебри djvu-кодирования, хотя это конечно и полезно.
Поэтому выход пока один: если раскрашенные зоны не пересекаются (между собой и с текстом), и имеют прямоугольную форму, то использовать FGbz (такой случай предусмотрен в последней версии djvumake), если нет - то использовать либо FG44, либо делать как делалось всегда ранее - трактовать раскрашенные зоны как обычные цветные зоны. И кодировать их либо стандартным методом (через профиль DEE), либо через метод подклейки фона.
Радует одно: даже если FG44 и больше FGbz на порядок в относительном сравнении, но в абсолютном исчислении - это несколько килобайт на страницу - это немного (по сравнению с обычными цветными зонами, которые дают десятки а то и сотни кб в BG44, в зависимости от выбранных параметров сжатия djvu).
В любом случае кодировать раскраш.зоны в FG44 выгоднее чем трактовать их как обычные цв.зоны и помещать их в BG44. Это особенно актуально если на странице одновременно имеются как иллюстрации так и раскраш.зоны. Выгода в том, что иллюстрации можно кодировать с качеством, независимым от качества кодирования раскраш.зон (там ведь обычно текст и для него качество должно быть выше чем у обычных картинок). Т.е. можно по вкусу деградировать качество иллюстраций до приемлимого, оставляя при этом высоким качество цветного текста. Благодаря тому, что физически они хранятся в разных слоях-чанках.
Кстати, при создании pdf СК также обрабатывает раскрашенные зоны особым способом: в pdf есть для этого возможности, т.е. заносит их в pdf как ч/б и вводит команду красить их при показе. Поэтому там таких проблем не возникает.

bolega
Напоминаю Вам ещё раз, что без автоматического распознавания зон иллюстраций вся Ваша затея не будет иметь ровно никакого смысла - поскольку СТ окажется заведомо ГОРАЗДО удобней (за счёт авто-распознавания зон).

Сделать поддержку авто-распознаваемых зон в СК, наверное, не так уж нереально. Тут Вам помогут и U235, и Arcand (который сделал Corel-плагин из этого алгоритма) и может даже и сам Tulon.

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

Хотя Ваше решение будет представлять из себя чисто академический интерес как экспериментальный пример комбайна "всё-в-одном".

Я сам думаю, что по-хорошему такие комбайны плохи. ИМХО задача сканобрабатывающего софта - создать из сырых сканов так сказать "оригинал-макет" будущей DjVu-книги - т.е. каждый скан облагородить и при необходимости разбить на слои (до 3 слоёв на каждый скан). Для этого в DjVuLibre существует даже специальный sep-формат - он описан тут http://djvu.sourceforge.net/doc/man/csepdjvu.html в разделе SEPARATED DATA FILE FORMAT. Такой sep-формат может быть продукцией скан-обрабатывающей программы и одновременно входным материалом для DjVu-кодировщика.

Такая схема даёт ИМХО наибольшую гибкость и универсальность. Sep-формат может в будущем выступить своего рода "унифицированным интерфейсом" между классом сканобрабатывающих программ и классом DjVu-кодировщиков. И тогда любой новый производитель (появись он в будущем) будет знать, что он должен либо создать SEP на выходе, либо уметь принять SEP на входе.

Как говорится, "если бы SEP не было, то его нужно было бы придумать". А тут даже и придумывать не надо - создатели DjVuLibre это уже сделали за нас.

Можно даже представить себе программу - "sep-вьювер" или "sep-редактор" - такая тоже может понадобиться.

Вместо SEP можно использовать и пАры субсканов - правда, пока непонятно, как там обозначить передний план (цветность текста).