» Scan Tailor

Цитата:

Tulon
Можно конечно выставить эти самые 150 DPI, но какой смысл? Все равно хороших результатов вы не получите

Есть архивные документы в единичном экземпляре, косо отсканированые.
Хочется видеть их нормализованными по горизонтали.

Tulon

Цитата:

По идее под виндой понимаются любые слеши - хоть прямые, хоть обратные.
Для начала попробуйте более старую версию - ту, что на http://scantailor.sf.net/
Если там все в порядке - значит я что-то в последней версии накосячил. Если и там не работает - тогда никаких идей - делайте видео-каст что-ли.

Вот сделал скриншоты создания проекта:

[more]


[/more]
Версию пробавал 0.9.5 и 0.9.6pre1, на обоих одинаково

Спасибо большое за программу.
В общем мне понравилась.
Но ещё много огрехов.
Главный на мой взгляд - часто не хочет вообще определять полезную область.
Приходится руками - это очень долго.

Tulon
Посмотрел я более внимательно имеющиеся доки по СТ. В результате возникла некоторая критика.

У меня вызвали сомнения такие вещи, как "Полезная область" и "Макет страницы".

1. По "Полезная область":

Предполагается, что юзер должен вручную (!) подправлять везде синие прямоугольники - чтобы тем самым скорректировать ошибки алгоритма. А ведь в СК всё намного проще - юзер также подправляет резаки (после Draft Kromsate) - да только вот в СК резаки-то (синие) очерчивают область полезного контента, внутри которой СК потом будет САМ полностью автоматически искать контур голого текста. Да, в СК есть малиновые резаки - полностью аналогичные "Полезная область" в СТ - но в СК малиновые резаки носят совершенно второстепенный характер.

2. По "Макет страницы".

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

В СК для этого служит редактор пост-обработки.

Мне вообще трудно представить, как СТ обходится без редактора пост-обработки (как в СК). Тогда уж, после переходе от "Полезная область" к "Макет страницы", обрезайте сканы по контуру голого текста. Хотя нет; всё равно это не то. "Макет страницы" может быть только после "Вывод" (точнее, после бинаризации, выравнивания освещения и т.п.)

"Макет страницы" - это наиболее финальная операция из всех возможных операций сканобработки.

Как вариант - разделите "Вывод" на 2 части - "Вывод-1" (бинаризации, выравнивания освещения) и "Вывод-2". "Полезная область" поставьте после "Вывод-1". А при переходе от "Макет страницы" к последующим этапам (это будет "Вывод-1") пусть сканы обрезаются по контуру голого текста, и далее пусть уже обрабатываются голые тексты.

Цитата:

Есть архивные документы в единичном экземпляре, косо отсканированые.
Хочется видеть их нормализованными по горизонтали.

Ценой еще большей потери качества. А вообще, для подобных задач лучше подходит Book Restorer. ST создавался для обработки сырых сканов в приличном разрешении. Только на хороших исходниках можно расчитывать на хорошую работу автоматики. Что касается вашего конкретного случая - ну выставьте ему 150 DPI вместо реальных 140. Хуже таким сканам уже не будет

Добавлено:
mic2000
Скорее всего такой тип tiff'ов как у вас просто не поддерживается. Пришлите один такой - интересно посмотреть, что за фрукт.

Добавлено:
sancher

Цитата:

Но ещё много огрехов.
Главный на мой взгляд - часто не хочет вообще определять полезную область.

Дайте угадаю:
* Уже где-то обработанные сканы.
* Разрешение ниже 300 DPI.
* Бледные или размытые буквы.
* Фоновые иллюстрации (в журналах).

Если угадал не больше одного пункта - выкладывайте пример - посмотрю.

Добавлено:
monday2000

Цитата:

Посмотрел я более внимательно имеющиеся доки по СТ. В результате возникла некоторая критика.

Я бы вам все-таки настоятельно рекомендовал основывать критику на реальном опыте работы с программой, а не на чтении документации. Многие претензии отпали бы сами собой.


Цитата:

1. По "Полезная область":
Предполагается, что юзер должен вручную (!) подправлять везде синие прямоугольники - чтобы тем самым скорректировать ошибки алгоритма. А ведь в СК всё намного проще - юзер также подправляет резаки (после Draft Kromsate) - да только вот в СК резаки-то (синие) очерчивают область полезного контента, внутри которой СК потом будет САМ полностью автоматически искать контур голого текста. Да, в СК есть малиновые резаки - полностью аналогичные "Полезная область" в СТ - но в СК малиновые резаки носят совершенно второстепенный характер.

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


Цитата:

2. По "Макет страницы".

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

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


Цитата:

Мне вообще трудно представить, как СТ обходится без редактора пост-обработки (как в СК).

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


Цитата:

к вариант - разделите "Вывод" на 2 части - "Вывод-1" (бинаризации, выравнивания освещения) и "Вывод-2". "Полезная область" поставьте после "Вывод-1". А при переходе от "Макет страницы" к последующим этапам (это будет "Вывод-1") пусть сканы обрезаются по контуру голого текста, и далее пусть уже обрабатываются голые тексты.

И этот человек критиковал СК за неоправданную сложность?

Tulon

Цитата:

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

Этого недостаточно. Необходимо учесть все случаи, а не большинство (как в СК это сделано).

Цитата:

И что вы мне предлагаете? Ввести дополнительную, полностью ручную стадию "Примерная полезная область"?

Да. Но не полностью ручную. В СК этой манипуляции соответствует полностью автоматическая процедура "Draft kromsate" (кнопка с ножницами). После DK резаки выставляются сами так, чтобы "отчертить в сторону" всю грязь по контуру голого текста. А уже внутри этой области делается то, что в СТ называется "Полезная область" (в СК это делает кнопка "Process!") (и в СК, и в СТ эти процедуры полностью автоматически и практически безошибочны - за вычетом нюансов).

И, скорее всего, пусть "Примерная полезная область" будет в виде 4 резаков + ластик (хотя я не настаиваю на этом, но 4 резака + ластик себя хорошо зарекомендовали). Потому что прямоугольная рамка не в силах отсечь прихотливо-расположенную грязь так же хорошо, как 4 резака + ластик. Это видно даже на примере http://www.djvu-soft.narod.ru/scan/st_lesson.htm - когда там наверху соринка попалась неудалённая.

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

А вот зато "Примерная полезная область" нужна, и ещё как - и, скорее всего, не в виде прямоугольной рамки - а в виде 4 резака + ластик (или в каком-либо ином виде - но не уступающем по качеству "4 резака + ластик").

Цитата:

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

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

Цитата:

И этот человек критиковал СК за неоправданную сложность?

Согласитесь, что уж если делать альтернативу СК - то только такую, которая будет превосходить по качеству СК - а иначе - какой же смысл?

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

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

Добавлено:

Цитата:

Таким людям чем меньше опций, тем лучше. В идеале - загрузить файлы и одна большая кнопка "Сделать книгу".

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

1. Программа-унификатор. Функции: разрезание разворотов, deskew, исправление DPI. Цветовая разрядность не меняется.

Смысл этой программы - привести любые разнобойные сканы хоть к какому-то к общему знаменателю - что резко упростит всю последующую обработку.

2. Программа-пакетный графический редактор. Функции: полуавтоматическое вырезание Picture-зон, а затем всевозможные графические манипуляции типа CorelScan http://www.djvu-soft.narod.ru/scan/corel_scan.htm и доки Ивана Сторожева http://www.djvu-soft.narod.ru/scan/clear_scan_trilogy.rar .

3. Программа-обрезчик. Функции: Draft kromsate, Полезная область, Макет Страницы, обратное наложение Picture-зон, Вывод.

Такая 3-х-ступенчатая схема позволяет избежать вредного универсализма (присущего как СК, так и СТ). А также эта схема позволяет делать разные ступени обработки в разных программах (на вкус юзера). И ещё: очень и очень многие стали бы ограничиваться лишь только 1-ой стадией - и сразу дежавючить. Это те, из категории непрошибаемых - которые сейчас просто сырые сканы дежавючат - так пусть хоть разрезали бы развороты и делали deskew хотя бы - чем ничего не делать, как они сейчас поступают.

Именно вот так, ступенчато, например, добывают металл из руды. Нет же такого аппарата - вложил туда кусок руды, а вылез готовый слиток.

Tulon

Цитата:

Может U235 обновит ее для своих сборок?

ок, в ближайшие дни постараюсь.

monday2000

Цитата:

СК плохой - но СТ ещё хуже.

LoL! В мемориз!

Насчет того, что ScanTailor хуже, чем СК, боюсь перерастет в флейм, но недавно нужно было писать инструкцию для людей далеких от сканирования как обрабатывать книги, за основу взята scan and share, но изменена в связи с конкретными условиями (процесс разбит на этапы, выполнение которых находится на разных ПК) описано что является входными данными каждого этапа, что выходными, в начале каждого этапа описан весь процесс этапа кратко, а затем подробно все, что нужно делать. Результат плох. Начал разбираться почему, ответ просто потряс, да мы сделали плохо, но нам нужно было быстро, мы потом обязтаельно (перевожу на человеческий может быть когда нибудь) переделаем. После Портного результат гораздо лучше сразу и не нужно большой документации. Да, возможно, в Сканкромсаторе результата можно было бы достичь лучше.
Но если сложить затраты времени на обучение и приобретение навыков работы в сканкромсаторе значительного количества людей.

На досуге попробуйте лично обучить несколько человек, далеких от сканирования, например обработать брошуру для детей в школе.
Только не сделать за них, а научить, что бы они сами в следующий раз, "не следя пальцем" про прекрасной документации scan and share 1.07 смогли подвиг повторить.
И покажите им ScanTailor, вас удивит разница

А специалисты, на то и специалисты, чтобы пользоваться замечательным очень функциональным инструментом.

zhenyamerezhko, правильно.
Обе программы имеют право на существование. И огромное спасибоTulon за её создание и развитие.
PS хотя у самого первый опыт использования Scan Tailor отрицательный: исходники были сняты фотоаппаратом, причём в ужасном качестве.

Цитата:

- что вы мне предлагаете? Ввести дополнительную, полностью ручную стадию "Примерная полезная область"?

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

monday2000 как всегда в невежливой форме, но пихает имеющую рацио мысль.

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

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

К чему это я ? Фактически, два этапа и получается.

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

Это так. Информация к размышлению.

Чекбоксы может какие сделать можно на логику обрезки ?

Цитата:

dma200899
хорошо бы сделать фичу: руками передвигаешь рамку за черный мусор, а она дальше сама ползет, ищет точный край текста

Ага!
Ещё бы лучше предопределяемый максимальный размер полезной области
и поиск края текста "наружу" если увеличиваем юбласть выделения
и поиск края текста "внутрь" если уменьшаем юбласть выделения.
Но! Кто делать будет ? Не клюйте автора!

dma200899

Цитата:

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

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

Добавлено:
ndch

Цитата:

Но! Кто делать будет ? Не клюйте автора!

Во во. У пользователей такие предложения вызывают мысли вроде: "очень полезная фича, не понимаю, почему до сих пор не реализована". А у меня: "три недели работы, нужна не так часто, обойтись вполне можно".

Цитата:

В идеале - загрузить файлы и одна большая кнопка "Сделать книгу".

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

Цитата:

если прикрутить к СТ утилиту FSD

А зачем что-то прикручивать? Во-первых, это лишняя работа; во-вторых, csepdjvu -- не лучший вариант; в-третьих, на этапе между выводом и DjVu-кодированием может потребоваться дополнительная обработка с помощью других утилит (сейчас она всё равно необходима из-за отсутствия ластика и невозможности указать точный размер страницы в пикселях). IMHO было бы совершенно достаточно реализовать отдельный вывод текста и картинок (или возможность попеременного подавления того и другого при выводе файла), а пользователь пусть потом с этим делает, что хочет.

Так и автору проще, и у пользователя больше свободы.

Новая сборка: 0.9.6pre2
http://www.onlinedisk.ru/file/172582/

Изменений по сравнению с 0.9.6pre1 никаких, кроме новой версии Qt. Баг с вылетом при добавлении файла в проект изчез. Если повезет, изчезнут и случайные падения при сколлинге ленты предпросмотра. Ну а если не изчезнут, попробую откатиться на версию 4.4.3

Какая из всех исорических сборок самая стабильная ?

Цитата:

Какая из всех исорических сборок самая стабильная ?

Должна быть последняя, если новая версия Qt новых багов не добавила.

В концепию программы инструмент "уровни" случаем не может войти ?

Цитата:

В концепию программы инструмент "уровни" случаем не может войти ?

В обозримом будущем - нет.

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

ndch

Цитата:

Но! Кто делать будет ? Не клюйте автора!

Моя критика была нацелена как раз на то, чтобы сократить и упростить объём работы для автора (относится и к СК, и к СТ). В самом деле, значительно легче сделать 3 простые программы, нежели чем 1 сложную и вмещающую в себя функциональность всех 3-х.

zhenyamerezhko

Цитата:

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

Да, это так - но на большинстве сканов. А что делать со сканами поганого качества? Пока что только использовать СК.

nauticus

Цитата:

Обе программы имеют право на существование. И огромное спасибоTulon за её создание и развитие.

С этим нельзя не согласиться. Но всё-таки очень важно смотреть на реальность без розовых очков.

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

А СТ я предлагаю разделить как минимум на 2 полностью независимые программы: программу-унификатор (splipage, deskew, DPI correction, визуальная проверка комплектности сканов) и программу, делающую всё остальное (принимающую на входе унификат). Глупо и нелепо тащить сдвоенные развороты через всю программу - от них нужно избавиться с самого начала.

Ну и "Полезную область" с "Макет страницы" нельзя оставлять так, как есть (об этом я уже ранее высказался).

Хотим мы того, или нет, а общая технология сканобработки налагает свои определённые требования и принципы, и оттого, насколько более полно СТ или СК сможет подстроиться под эти требования, и зависит успешность программы.

И, конечно же, концепция "СТ - только для качественных сканов" совершенно неприемлема (ИМХО). Надо бы все (т.е. некачественные) сканы уметь обрабатывать (как СК это делает).

Tulon большущее спасибо!
Загрузил в программу самую проблемную книжку (фотографировал на мыльницу)
справилась на УРА!
Давно ждали такую программу!
Отличный дизайн! Удобство!
Спасибо!

В последней версии наблюдается следующее:

Структура скана (например, справа):

зона текста - появившаяся после поворота отсутствовавшая зона - добавленные поля

При черно-белом выводе "отсутствовавшая зона" заливается черным.

dma200899

Цитата:

ри черно-белом выводе "отсутствовавшая зона" заливается черным.

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

Tulon
Баян это.
При крутом перекосе скана
и последующем повороте
могут образовываться "несуществующие" области изображения.
При выводе в чб-режиме "несуществующие" области изображения становятся чёрными.

0.9.6pre2
нет обработки недостаточности дискового пространства
в итоге программа работает,работает,работает...

Цитата:

При выводе в чб-режиме "несуществующие" области изображения становятся чёрными.

И это, конечно же, баг.

Цитата:

могут образовываться ...

По-видимому, это и происходит.

http://www.onlinedisk.ru/file/176591/

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

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

Воспроизвел, попробую исправить.

Происходит падение в следующей ситуации
с проектом:
http://www.onlinedisk.ru/file/176904/

Делаю следующие шаги:
1) загружаю файлы.
2) предлагает поправить дпи 200*200 для первых двух страниц, ставлю 300*300

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

Кстати, странно - это реально скан в 200 дпи. Поэтому хорошо бы в встроенной справке к проге иметь объяснение логики выбора. Я помню, что где-то на форуме было, но искать каждый раз, когда она тебе это предлагает - тяжело.
И непонятно, почему 200*200 я задать не могу (хоть это проге и не нравится но ведь это реальная цифра. Просигналило об опасности - я подтвердил, что да это так. Зачем фальшивый дпи 300 рисовать ?)

3) делаю макет на автомате
4) обнаруживаю, что последняя страница больше по физическому размеру
5) иду в "исправление ориентации" и удаляю ее из проекта

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

Увы, поправить дпи для этой обнаруженной страницы в проекте невозможно. Только пересобрать проект заново. Ну и удаляешь ее, чтобы не портила размеры книги, а потом ее отдельно вставим.

6) жму макет
7) падение

(раньше в этой ситуации "залипали" размеры широкие размеры для всех страниц, хотя задавшая их страница удалялась)