» Scan Tailor

ukpyr
так я и посмотрел)), а потом решил, что правильнее решить задачу копеечным скриптом.

Добавлено:
alpopo
А полноэкранный режим вас бы устроил? Про такой режим разговор уже велся и Tulon вроде бы не видел особых препятствий для этого.

непонятно почему и в СК и в СТ разрезание страницы сделано на основе резаков.
выделение страниц полигонами и разрезка по bounding rectangle более логичны, нет ?

Цитата:

А полноэкранный режим вас бы устроил

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

alpopo
Не знаю как насчет левой области - перекомпоновывать кнопки сложно, да и удобство из-за которого данная программа - супер, упадет, а наезд на кнопки не особенно имеет смысл..
А вот насчет правой области - это вы ловко подметили - только вот проблемка - когда видны развороты страниц (и максимально нужна ширина рабочего пространства) в правой области тоже будут развороты.
А когда можно будет сузить полосу предпросмотра на эти 100 пикселей, уже работаем с отдельными страницами, и им ширина не так уж нужна.

monday2000

Цитата:

Нет ли смысла интегрировать патч в основную программу?

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

StanFreeWare

Цитата:

Поясните такой способ заливки зон, пожалуйста:
http://www.onlinedisk.ru/edit_image/266351/

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

monday2000

Цитата:

1. Чтобы в СТ была возможность вывода после любой стадии обработки (как в СК).

Я уже не раз писал, что думаю по этому поводу. Не надо заставлять меня повторять это еще раз.

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

Цитата:

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

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

StanFreeWare

Цитата:

В Гимпе мне гаусс показался более качественным. По крайней мере резульаты моих попыток сделать гаусса на базе найденных в сети алгоритмов не дали такого эффекта. Проверял на вышеупомянутой странице-убийце - так вот она после гимповского гаусса + бинаризации по порогу стала наиболее читаемой.

В СТ есть реализация Гауссова размытия, портированная из Gimp. Только для серого режима правда - не было необходимости делать для цветного.

alpopo
То, что вы просите - не актуально, потому что на любой стадии, начиная с Deskew, вы работаете с одиночными страницами. Соответственно вас ограничивает уже не горизонтальный, а вертикальный размер. Сделать тоже не просто. Если тупо разрешить изменять размеры ленты миниатюр, то при ее малейшем сужении будет появляться горизонтальая полоса прокрутки.

ukpyr

Цитата:

непонятно почему и в СК и в СТ разрезание страницы сделано на основе резаков.
выделение страниц полигонами и разрезка по bounding rectangle более логичны, нет ?

А вы попробуйте автоматически вычислить этот полигон. Да и вручную его править - тоже мало приятного.

Tulon
В вики-документации странички только вы имеете право создавать?
А то, может быть, пора завести страничку про зоны. Глядишь, общими усилиями и опишем инструмент.
Спасибо за Гаусса. Может быть тоже всуну в свой костыль-сепаратор.

Tulon
загрузил несколько файлов, где СТ не справляется.
http://www.onlinedisk.ru/file/266970/
p0135, p0222, p0591 - неправильное определение полезной области, причем казалось бы (и хотелось бы), что на таких страницах ошибок происходить не должно.

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

Два предложения:
1) наверняка, всегда найдутся какие-нибудь страницы, где полез. область будет определена не правильно. Почему бы на этом этапе не ввести два режима. В одном показываются все страницы, в другом только те, где СТ "не уверен" в правильности выбора полез. области.

2) На этапе "output" также предоставить возможность переключаться между всеми страницами и только теми, которые содержат картинки/графики/гистограммы.

Olive77

Цитата:

p0135, p0222, p0591 - неправильное определение полезной области, причем казалось бы (и хотелось бы), что на таких страницах ошибок происходить не должно.

На самом деле ничего удивительного тут нет. СТ априорно предполагает, что за границами скана - мусор. У вас сканы обрезаные, так что с точки зрения СТ, краевые элементы расположены весьма близко к мусору. В такой ситуации единственная возможность для них не быть удаленными, это быть распознанными как текст. Формулы и горизонтальные линии текстом естественно не являются, а в случае большого шрифта и малого колличества букв, ошибается уже сам алгоритм.
Да, тут есть что улучшать, и даже есть кое-какие идеи, но сейчас я настроился на доведение до ума Deskpeckle, и отвлекаться не собираюсь.


Цитата:

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

А вот их убил как раз Deskpeckle.


Цитата:

1) наверняка, всегда найдутся какие-нибудь страницы, где полез. область будет определена не правильно. Почему бы на этом этапе не ввести два режима. В одном показываются все страницы, в другом только те, где СТ "не уверен" в правильности выбора полез. области.

Он никогда не бывает уверен


Цитата:

2) На этапе "output" также предоставить возможность переключаться между всеми страницами и только теми, которые содержат картинки/графики/гистограммы.

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

Tulon

Цитата:

У вас сканы обрезаные,

ничего не резалось. Это так выглядят сканы при сканировании OpticBookом.

Tulon

Цитата:

В таком виде - нет

А в виде галочки "Разложить составляющие смешанного режима по разным папкам (только для опытных пользователей)" рядышком с выключателем 3D-режима? Обычный пользователь даже не узнает, что она там есть..
Пусть даже эти папки будут в дебрях папки cache, главное, что они будут. И, конечно, пусть по-умолчанию этот режим будет выключен. А я, со своей стороны, попытаюсь в Вике объяснить как и зачем этими папками пользоваться... Глядишь, и востребованность в этой фиче вырастет до более, чем пресловутых "трех" человек.

И про зоны страничку создайте в Вике...

Tulon


Цитата:

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

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


Цитата:

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

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

StanFreeWare


Цитата:

А в виде галочки "Разложить составляющие смешанного режима по разным папкам (только для опытных пользователей)" рядышком с выключателем 3D-режима?

Уважаемый Tulon, конечно, и в таком виде не реализует , но я от себя добавлю, что данное предложение неприемлемо всё по той же причине: оно не дает возможности отдельного контроля над разрешением картинок. К тому же вывод всего контента в двойном объеме (а Вы ведь предлагаете именно это) может оказаться весьма накладным с точки зрения дискового пространства.

Olive77

Цитата:

ничего не резалось. Это так выглядят сканы при сканировании OpticBookом.

В определенном смысле скан все равно обрезан, просто это произошло прямо при сканировании, а не при пост-обработке.


Цитата:

А в виде галочки "Разложить составляющие смешанного режима по разным папкам (только для опытных пользователей)" рядышком с выключателем 3D-режима? Обычный пользователь даже не узнает, что она там есть..
Пусть даже эти папки будут в дебрях папки cache, главное, что они будут. И, конечно, пусть по-умолчанию этот режим будет выключен. А я, со своей стороны, попытаюсь в Вике объяснить как и зачем этими папками пользоваться...

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

Кому не хватает фич, могут либо использовать альтернативные программы, либо, как это сделал anagnost96 - самостоятельно добавить необходимые фичи в СТ. Ну а раз кто-то патчит СТ для себя, то и другие могут воспользоваться этой сборкой. Сборка кстати будет сегодня.


Добавлено:
anagnost96

Цитата:

Ну нет никакого смысла поручать сегментацию кодировщику djvu или jbig2, коль скоро мы это уже один раз сделали в ST.

Чистое решение этой проблемы - встраивание DjVu кодировщика прямо в СТ. Ваше решение кажется мне грязноватым.


Цитата:

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

Эти проблемы нужно решать в кодировщиках, а не в СТ - тем более что есть открытые кодировщики. Если было бы возможно чистое решение в рамках СТ - я был бы двумя руками за, а так - простите, нет.
Кстати предполагаю, что слои из TIFF'ов легко можно выдрать скриптом на базе convert из ImageMagick. Это конечно добавит работы тем трем энтузиастам, которым это надо, но на то они и энтузиасты, чтобы преодолевать сложности.

anagnost96

Цитата:

может оказаться весьма накладным

Если СОВСЕМ мало места, то можно перед запуском вывода при нажатой галке "в разные папки" стереть файлы в паке OUT - они были нужны только для настройки зон.

Я на самом деле слабо представляю, чем конкретно Tulon'у не угодила предложенная вами в патче реализация, просто мне кажется что на данном этапе программная реализация вывода 600dpi в две разные папки может быть сделана за минимальное время, практически не задумываясь. И поэтому теоретически еще может быть реализована.

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


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

StanFreeWare

Цитата:

И про зоны страничку создайте в Вике...

Новые страницы в Wiki создаются так:
1. Сначала создается линк на несуществующую страницу. Просто редактируете существующую, и добавляете туда что-то вроде:

Код:
[[Редактирование Зон]]

StanFreeWare


Цитата:

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

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

Добавлено:
Tulon

Цитата:

Чистое решение этой проблемы - встраивание DjVu кодировщика прямо в СТ.

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

Но ведь Вы же сами совершенно сознательно отказались от вывода djvu/pdf. И, по-моему, это совершенно правильно, т. к. где-где, а уж на этом этапе никак не получилось бы избежать изобилия настроек.


Цитата:

Кстати предполагаю, что слои из TIFF'ов легко можно выдрать скриптом на базе convert из ImageMagick.

Да можно, кто же спорит. Но ведь слои в TIFF, если я не ошибаюсь, должны иметь одно и то же разрешение? А это как раз и есть главная проблема, которой хотелось бы избежать.

К Вике добавлена страничка про зоны:
http://sourceforge.net/apps/mediawiki/scantailor/index.php?title=%D0%97%D0%BE%D0%BD%D1%8B_%D0%BA%D0%B0%D1%80%D1%82%D0%B8%D0%BD%D0%BE%D0%BA

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

anagnost96
Давайте уже закончим эти бесмысленные споры. Мне идея вывода раздельных слоев не нравится - я ее считаю костылем, в котором к тому же нет особой необходимости. Уменьшать разрешение слоя картинок - всяко задача кодера, и я подозреваю, что тот же DEE таки делает это.
Вот сборка с вашем патчем: http://www.onlinedisk.ru/file/267401/

StanFreeWare

Цитата:

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

Давайте сначала посмотрим, насколько популярной будет сборка с патчем от anagnost96.

Tulon

Цитата:

Давайте уже закончим эти бесмысленные споры.

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


Цитата:

Мне идея вывода раздельных слоев не нравится - я ее считаю костылем, в котором к тому же нет особой необходимости.

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


Цитата:

Уменьшать разрешение слоя картинок - всяко задача кодера, и я подозреваю, что тот же DEE таки делает это.

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

Выпустил релиз 0.9.7.1 официально. Бинарник тот же, что постил сюда вчера. За списком изменений - на официальный сайт.

очепятка в п2 списка изменений.
А что, на руборде ЛС не работают? .. ни с оперы, ни с хрома не могу отправить..

Вопросы от ответственного за пакет scantailor в ALT Linux - меня.

1) Есть ли возможность как-то извлечь документацию по Scantailor из Wiki, чтобы положить её на законное место - в /usr/share/doc/scantailor?

2) Можно ли в меню заменить пункт "Файл" на пункт "Проект"? Чтобы радикально упростить подпункты: например, вместо "Открыть проект" писать просто "Открыть"?

3) Я могу безболезненно собрать scantailor с любым патчем под ALT Sisyphus. Точно нужно собрать
его с патчем anagnost96? Кому и куда выслать результат?

> Выпустил релиз 0.9.7.1 официально.

Ну ёлы-палы, а я только rpm 0.9.7 закинул в репозитарий ALT!

vkni

Цитата:

Точно нужно собрать его с патчем anagnost96?

Это дело Вашего предпочтения: патч несколько расширяет функциональность, но противоречит идеологии программы, как ее понимает автор.

По моему мнению, сборка под Linux всё-таки должна делаться с патчем. Смысл патча в раздельном выводе текста (маски) и картинок (фона), что под Linux особенно актуально, т. к. там просто нет кодировщиков djvu, которые были бы в состоянии выделить эти слои самоятоятельно.

Небольшая поддержка теоретической дискуссии о раздельном выводе картинок.
Сделал маленький проект на реальных сканах. Протестировал размер djvu-файла и качество картинки для различных способов вывода СТ, постобработки и кодирования в djvu. Кодировал с помощью djvu small.
Таблица с результатами: http://www.onlinedisk.ru/image/267797/Таблица.png
Некоторые образцы изображений: http://www.onlinedisk.ru/file/267799/

Примечание: все iw44 файлы нужно еще склеить с jb2(text.djvu).
Кстати, anagnost96, подскажите поподробнее, как использовать djvumake. У меня пока дальше ошибки
http://www.onlinedisk.ru/image/267800/djvumake.png
на следующих исходниках:
http://www.onlinedisk.ru/file/267801/
дело не дошло.

Основной вывод: вполне достижимо получить размер файла, сравнимый с Default_Document.djvu, с приемлемым качеством картинок без jb2-артефактов от djvu-кодера.

StanFreeWare

Цитата:

Кстати, anagnost96, подскажите поподробнее, как использовать djvumake.

Я так понимаю, у Вас djvumake из последнего релиза, а она нужной функциональности еще не поддерживает. Можно взять более новую версию с сайта monday2000 или воспользоваться его же утилитой DjVu Imager (см. http://www.djvu-soft.narod.ru/scan/djvu_imager.htm ), где весь процесс более или менее автоматизирован.

anagnost96
Спасибо, получилось. Правда, в вашу ссылку закрывающая скобка с запятой вошли..
Кому интересно - вот размеры результирующих файлов с текстовым слоем (600dpi обработанные гауссом не вошли за ненадобностью):
http://www.onlinedisk.ru/image/267888/Andtextresult.png
А это первые 5 мест одним архивом:
http://www.onlinedisk.ru/file/267893/

Интересные факты -
1. Буквы в файле DjvuSmall.djvu пожирнее, чем в остальных файлах, сделанных на базе text.djvu, хотя делалось, по сути, из одних источников, только в источниках для DjvuSmall была также и составляющая в градациях серого.
2. DjVu Imager как-то сам понял, как нужно склеивать 300dpi-шный image-слой, и 600dpi text. Т.е. можно обходиться и без предварительного апскейлинга (в моем случае производимого с помощью FastStrone Image Viewer). Или convert нужен еще для чего-нибудь?

Цитата:

DjVu Imager как-то сам понял, как нужно склеивать 300dpi-шный image-слой, и 600dpi text. Т.е. можно обходиться и без предварительного апскейлинга

Ну дык я ж Вам и талдычу, что он не нужен. И это не DjVu Imager что-то там понял, а просто формат DjVU так устроен: когда мы склеиваем два слоя, то отображаемый размер страницы определяется разрешением маски, а фон уже растягивается под нее, как нужно.


Цитата:

Или convert нужен еще для чего-нибудь?

Там есть небольшая засада с пиксельными размерами: чтобы склейка прошла нормально, нужно, чтобы размеры маски были строго кратными размерам фона, т.е. соотносились, например, как 2:1 или 3:1. Так вот, СТ этого не гарантирует: поскольку размеры страницы задаются в сантиметрах, то при пересчете в пиксели вполне может получиться небольшая погрешность. Поэтому приходится использовать convert, чтобы отрезать или нарастить недостающие несколько пикселей.

Кстати, в PDF этого ограничения нет: там фоновое изображение может растягиваться как угодно, в том числе и в разных пропорциях по x и y.

Еще немножко результатов:
http://www.onlinedisk.ru/file/268046/
где
1. ST_default.png - это типичный djvu, получаемый без дополнительной обработки путем создания djvu в режиме "Документ" программы Djvu Small.
2. ST_default_gauss.png - это djvu, получаемый программой DjVu Small после фильтрации изображений фильтром Гаусса, выделяя зоны картинок в Гимпе вручную (правда, вручную это делать - крайне трудоемко, а для автоматической обработки уже нужны изображения в отдельных файлах).
3. gauss_3_pix_twice.png - дважды фильтрация радиусом 3 пиксела.
4. gauss_1_pix_three_times.png - трижды фильтрация радиусом 1 пиксель.

Все изображения еще проходили через автовыравнивание контраста.

Для 1 и 2 использовался вывод в режиме изображение+текст
для 3 и 4 - вывод в режиме изображение отдельно (в оригинальном разрешении 300 dpi), текст отдельно, текст собирался в текстовую djvu в режиме "Документ" программой Djvu Small, изображения после обработки переименовывались в *.sep.tiff и подключались к текстовой djvu c помощью Djvu Imager.

Для фильтрации и автовыравнивания контраста использовался скрипт в Gimp.

С точки зрения размера результирующего djvu:
размер страниц 1 и 4 около 100 кбайт, страниц 2 и 3 - около 50 кбайт.

Tulon
А вы не думали переключать режимы не через выпадающий список, а кнопками, как на других стадиях? Или экономите место под будущие фичи?
Например, так:
http://www.onlinedisk.ru/image/268503/Outputmodes.png
Ну и плюс подсказка в статусе.
Честно говоря, неудобная штука - выпадающий список. Особенно для трех параметров.

Цитата:

А вы не думали переключать режимы не через выпадающий список, а кнопками, как на других стадиях? Или экономите место под будущие фичи?
Например, так:
http://www.onlinedisk.ru/image/268503/Outputmodes.png

Мне больше нравится выпадающий список. Эти иконки не слишком очевидны.

Tulon
А если что-нибудь в вашем же стиле?
http://www.onlinedisk.ru/image/268537/Outputmodes2.png
Заостряю вопрос, т.к. я довольно часто переключаюсь между типами вывода. И от необходимости выбирать в выпадающем списке вместо простого щелчка по кнопке испытываю явное неудобство.
Один клик как-то проще, чем клик + выбор + клик...