» Scan Tailor: Часть 2

denver 22
Вроде бы да, актуальная. Сейчас собираю с VC++ 2008. Зависимости собирал где-то месяц назад. Месяца три назад собирал с MinGW32.

Раньше добавлял в начало файла его порядковый номер.
А сейчас этого не делает. В результате не сохраняется ручная сортировка страниц.
Как вернуть фичу?

Добавлено:
Видимо никак
Tulon

Цитата:

А пакетное переименование лучше делать до ST.

Тогда становятся бессмысленны команды Вставить перед... Вставить после..
Логично будет оставить просто команду Вставить...
И отображать страницы в алфавитном порядке, независимо от последовательности вставки.

По-моему, Tulon с СТ переместился на этот форум:

http://diybookscanner.org/forum/viewforum.php?f=8

Релиз кандидат _http://www.onlinedisk.ru/file/450770/
Сборка от Tulon-а.
monday2000, по-моему вы правы. Жаль, что язык английский

scantailor-0.9.9rc3 snapshot Thu, 10 Jun 2010 22:03:38
Добавлены зоны заливки, диалог About.

Ммм... Зоны заливки - аналог ластика. Тулон все таки реализовал эту функцию!
Хотя не очень удобно пользоваться - много точек надо ставить. С другой стороны - есть удобная возможность редактирования и визуального просмотра выполненного действия

Добавлено:
Последняя сборка понравилась. Вроде как пару глюков предыдущей убрали.
Но 1 раз программа вылетела. Багрепорт видимо отослать не получится?

Добавлено:
Напомните кто-нибудь. В последние месяца 4 в разработчик повышал порог бинаризации по-умолчанию? Такое ощущение, что стало лучше без доп. настройки.

denver 22

Цитата:

В последние месяца 4 в разработчик повышал порог бинаризации по-умолчанию?

Это надо смотреть:
http://scantailor.git.sourceforge.net/git/gitweb.cgi?p=scantailor/scantailor;a=shortlog

Цитата:

Багрепорт видимо отослать не получится?

Нет, ждите офф. сборки от Tulon'a, там можно будет отправлять багрепорт.

Цитата:

ждите офф. сборки от Tulon'a, там можно будет отправлять багрепорт

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

Релиз Scan Tailor 0.9.9


Цитата:

* New feature: Fill Zones.
* New feature: ordering pages by content box dimensions.
* New naming scheme for output files.
* Bugfixes, including two possible crashes.

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

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

Просто необходима возможность выделять зоны ТОЛЬКО вручную. Отключать автоопределение зон.

При создании проекта из 1300 сканов 600 dpi grey практически все страницы проекта выводятся как чёрные квадраты за исключением двух, трёх.

Несколько дней назад сделал проект на 400 страниц с теми же параметрами, с тем же сканером, на том же компьютере. Такого бага не наблюдалось.

P.S. От числа страниц в проекте не зависит. Пробовал создать проект на 3 стр. из этих же сканов, результат тот же - чёрные квадраты.

Операционная система Win 7

Помогите.

Terom
Ты забыл выложить образцы сканов. И какая версия ST?

1. Сканы выложу вечером.
2. А как узнать версию?

Цитата:

2. А как узнать версию?

См. заголовок окна программы

Если есть в заголовке окна, то 0.9.9.

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

Тема ИМХО достаточно актуальная, т.к. без этой фичи никак не обойтись, имея дело с журналами.

Такую пакетную обрезку можно сделать в СТ (путём некоторых извращений). Я пока что набросал такую концептуальную схему:

1. Загружаем сканы в СТ, прогоняем их все хотя бы до стадии "Макет страницы".

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

3. Становимся на самый первый скан на стадии "Макет страницы", уменьшаем все поля до нуля, и делаем "Применить ко всем страницам".

4. Теперь нужно вручную подправить координаты и размеры полезной области на каждой странице - сделав их равными размеру обрезающей рамки, определённой в п.2. Это можно сделать путём ручной правки XML-файла СТ-проекта. Там есть такие строки:

Цитата:

<select-content>
<page id="4">
<params mode="auto">
<content-rect width="2680" x="316" y="744" height="4028"/>

Править нужно строку "content-rect". Правда, править нужно как-то достаточно хитро, индивидуально на каждом скане - учитывая выравнивание полезной области относительно скана и желаемое направление выравнивания.

5. Вывод нужно делать в режиме "Цветной/Серый". В результате получаем "полуфабрикат" - который далее уже можно как угодно улучшать в любой иной программе.

Всё это, конечно, весьма муторно. Жаль, что такой механизм не предусмотрен в СТ штатно. Для его реализации было бы достаточно сделать такие фичи в СТ:

1. Отображение координат полезной области (для каждого скана).

2. Возможность установить координаты полезной области (для каждого скана).

3. Кнопку "Применить к..." на стадии "Полезная область".

4. Возможность двигать руками полезную область на скане.

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

Думаю, такая фича, в общем-то, нужна.

monday2000

Цитата:

набросал такую концептуальную схему

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

Но для журналов с заходящим на поля оформлением без, как минимум, возможности 4 (двигать полезную область по скану), имхо, никакая приблуда уже не поможет.

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

В общем, пока похоже, что "малой кровью" задачу обрезки журналов в СТ не решить. И не факт, останется ли СТ сам собою после ее решения. Не исключено, что лучшим решением будет упрощенный клон СТ (некий Magazine Tailor), заточенный исключительно под обрезку журналов.

Версия 0.9.9

Скрин программы: http://www.box.net/shared/static/1r42ku9shx.jpg

Скан: http://www.box.net/shared/static/8hti4hac7c.tif

StanFreeWare

Цитата:

Не исключено, что лучшим решением будет упрощенный клон СТ (некий Magazine Tailor), заточенный исключительно под обрезку журналов.

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

Цитата:

В общем, пока похоже, что "малой кровью" задачу обрезки журналов в СТ не решить.

Да, ИМХО сканировщики журналов пусть уж ждут лучших времён - когда такая спец. программа появится.

Вот ещё идея: возможно, не всегда разумно обрезать все страницы рамкой одинакового размера. Бывает, когда одна-единственная страница имеет несуразно большой размер - а все остальные заметно меньше размером. В основном так бывает в книгах - наверное, и в журналах так бывает.

PS Как-то сама собой всплывает идея, что нужен ещё человек, аналогичный Tulon, кто стал бы делать программу, похожую на СТ. Кто мог бы стать таким человеком? StanFreeWare, Вы не хотите ли? А что - не боги горшки обжигают. В любом случае -даже если бы Tulon всё делал правильно - ему одному физически не разорваться на части - чтобы удовлетворить всем запросам пользователей - слишком уж необъятна тема для одного человека.
StanFreeWare, сделали бы Вы хоть какую-то (пусть даже и плохонькую) свою СТ-подобную программу - ничего, с годами мастерство прийдёт - и Вы сможете её улучшить. Но надо же с чего-то начинать. Делать всевозможные "костыли" к СТ - ИМХО путь тупиковый, лучше уж сразу сделайте чисто свою программу (желательно без .NET, только не Delphi ради бога ).

И ещё одна мысль: жаль, что исходный код из СТ трудно повторно использовать. Было бы хорошо, если бы Tulon в своё время составил бы удобную для повторного использования библиотеку алгоритмов из СТ - по образцу моей такой библиотеки http://www.djvu-soft.narod.ru/bookscanlib/project.htm . Не так уж и много на это надо времени (в смысле, ему вычленить эти алгоритмы из СТ - а нам наоборот, много труда, который глупо-излишен).

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

Terom
Да, есть такой баг.
Видимо это связано с сжатием tif-файла в JPEG.
Переведите Ваши файлы в tif со сжатием LZW, качества это уже не добавит, но ST с LZW работает нормально.

monday2000
Внутрь СТ я не полезу. Даже несмотря на Ваш неуместно снисходительный тон.
Используемой "костылями" (а их пока набралось 3 штуки, не считая сепаратор) технологии правки XML файла проекта мне сейчас хватает для автоматизации обработки любой книги.
Журналы менее интересны в принципе. Как и решение задачи их качественной обрезки.

StanFreeWare

Цитата:

Даже несмотря на Ваш неуместно снисходительный тон.

Прошу прощения, мой тон не был снисходительным, это просто так, видимо, я неудачно выразился (я вообще никогда не пытаюсь кого-то обидеть). Я имел в виду то, что, возможно, некоторые люди не решаются сделать свою программу по сканобработке, стесняясь того, что они не смогут её сразу сделать "на уровне". Действительно, это объективно непростая задача.

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

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

Добавлено:
По поводу идеи Tulon прикрутить minidjvu к СТ:

Я тут нашёл упоминание об использовании DjVu Solo 3.1 в Wine (под Linux): http://hardworm.wordpress.com/2009/12/14/ .

Думаю, это вполне разумная идея. Во-первых, это совершенно легально (а те, у кого Linux, видимо только такое и хотят), а во-вторых - качество гораздо лучше, чем при использовании minidjvu.

Добавлено:
Как-то заглохло дело насчёт dewarping от Рамиза Зейналова. В последний раз он ответил мне, что выложит исходники своего dewarping на http://graphics.cs.msu.ru/science/research/ . На все следующие письма он уже не отвечает. Как жаль, что дело застопорилось.

monday2000, Программист, который знает свое дело никогда не описывает алгоритмы отдельно.
Вы же "запороли" алгоритм Зейналова, поэтому я дальше и не пытался у него выбивать исходники.
Как по мне самым нормальным был бы алгоритм одних азиатов, который в общем выравнивал строки только у корешка книги (центр разворота) - быстрый, качественный, но не универсальный и пригоден только для простых искажений. Я в свое время, когда Tulon еще был на форуме, скидывал алгоритм dewarping -a и он его смотрел. Он сказал, что алгоритм нужный и со временем должен появиться в финале, но у него уже есть некоторые наработки, поэтому и не стал дальше с ним возиться (реализовывать в коде).

Цитата:

Видимо это связано с сжатием tif-файла в JPEG

Я посмотрел свойства tiff сканов, которые у меня есть. Irfan пишет, что tiff без сжатия.
Цитата:

Переведите Ваши файлы в tif со сжатием LZW, качества это уже не добавит, но ST с LZW работает нормально.

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

Terom

Цитата:

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

tiffinfo для приведенного скана выдает:

Цитата:

TIFF Directory at offset 0x627f4 (403444)
Subfile Type: (0 = 0x0)
Image Width: 2550 Image Length: 4180
Resolution: 600, 600 pixels/inch
Bits/Sample: 8
Compression Scheme: JPEG
Photometric Interpretation: min-is-black
YCbCr Subsampling: 2, 2
Samples/Pixel: 1
Rows/Strip: 16
Planar Configuration: single image plane
JPEG Tables: (289 bytes)

Irfan и Xnview тоже говорят, что jpeg.
Перевод приведенного Вами скана в LZW с помощью XnView решает проблему.

Terom, чтобы в дальнейшем не возникало непредвиденных обстоятельств в программах, в частности в ST, сканируйте черно-белое в оттенках серого в формат tif(tiff) с сжатием LZW, цветное в режиме цвета в формате tiff, но без сжатия. Другие форматы не смогут дать подобающего результата. После обработки черно-белые изображения переводите в формат tif с сжатием G4FAX (Group 4 Fax Encoding). Данная операция помогает сэкономить значительно без заметной потери качества. Цветные же можно сохранять в tiff с сжатием LZW. Некоторые сохраняют в jpg для экономии места, далее еще и переводят в djvu(pdf). Это неправильно, если нужно добиться хорошего результата.
Ваш скан по сути это формат jpg. Поскольку о не может столько весить будучи tiff да еще и с разрешением в 600 dpi. Потеря качества существенна имхо. С помощью IrfanView пакетно преобразуйте в формат tif с жатием LZW. Размер каждого файла увеличится в 10! раз.
Вообще я бы назвал такую ситуацию багом программы, которая пока не может правильно прочитать тифки с оригинальным сжатием.
также может быть, что неправильное разрешение (в свое время ST сильно хромал на такой баг, но это было при tiff без сжатия или с LZW сжатием), при пакетном преобразовании принудительно выставите 600 dpi с рэсемплированием. И в программе по опыту могу сказать как 300 dpi. Если переходить по размерам изображения на мегапиксели, так уверен, что 300 dpi. Но подчеркну - это баг программы.

woodyfon

Цитата:

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

Да, ИМХО этот алгоритм уступает букресторерному. Я и приводил пример, где сравнивал выложенный Вами образец и он же обработанный в BR - в качестве доказательства.

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

Но всё равно, иметь его было бы недурно - было бы, что улучшать.

Цитата:

скидывал алгоритм dewarping

В виде PDF-статьи с описанием? Нужны-то исходники...

woodyfon

Цитата:

Но подчеркну - это баг программы.

В очередной раз понимаю почему Tulon ушел. Все это пережевывалось по 10 раз.
В tiff много вариантов сжатия, вложения изображения и т.д.
Какую реакцию от программы надо ожидать на то, что юзер подсовывает экзотический tiff ?

Прочитайте тему целиком, если хочется делать все "по-взрослому", не задавая вопросов и не давая ответов, за которые засмеют.

О чём я ? Не надо быть семи пядей во лбу чтобы сканировать в tiff со сжатием jpeg. Кроме относительно скромных размеров файла - данный вариант ничего положительного не приносит. Говорить не о чем.

monday2000, та статью в формате pdf. Исходники не люблю, по одной простой причине: в них разбираться больше, чем самому написать.
ndch, с вами не согласен. Если программа не принимает экзотические tiff, так виновата обычно сама программа, а не человек, которые выбрал тот или иной вариант сканирования и сохранения.