Ru-Board.club
← Вернуться в раздел «Программы»

» Scan Tailor

Автор: Tulon
Дата сообщения: 12.02.2010 10:13
U235
Идея здравая. Пожалуй стоит так и сделать. Думаю стоит и цвет 255 тоже зарезервировать для не-картиночного фона. Для кодирования в DjVu это значения не имеет, так как картинки и некартиночный фон будут кодироваться как одно целое, а вот для возможной пост-обработки - имеет.

amz01
Уйти в игнор - костыльное решение. Хорошее решение - забанить нафиг всех негативщиков. Только кто этим будет заниматься?
Автор: Dashout
Дата сообщения: 12.02.2010 10:17
Tulon

Цитата:
Если бы я уж задался целью поддержки случая с неизвестными и гуляющими DPI (фотоаппарат без штатива?), я бы первым делом попробовал найти доминирующее расстояние между строками с помощью преобразования Фурье. Это и был бы мой масштаб.

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

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



Добавлено:
Tulon
не хотелось бы ни Вам надоедать, ни участвовать в этой сваре.

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

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

Добавлено:
еще добавлю позитива к СТ

у меня XP SP3 32, 2 средненьких процессора, 3 Гб ОЗУ
Вчера обрабатывал на СТ книжку, посмотрел загрузку процессоров - 1 около 50%, второй - 20-30. Дай думаю попробую, подгружу...
Запустил параллельно новый СТ и начал обработку другого проекта - РАБОТАЕТ!
Вывод: при наличии свободной мощности СТ может параллельно обрабатывать несколько проектов!
Как автомат Калашникова!
ну как не согласиться с автором о стройности программы - это факт.
Удачи!
Автор: U235
Дата сообщения: 12.02.2010 11:30
Tulon

Цитата:
Пожалуй стоит так и сделать.

Это было бы просто замечательно!

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

ИМХО, и для постобработки это тоже не имеет значение. По крайней мере, совершенно не представляю себе для чего может быть полезно такое искуственное разделение картиночного и текстового фона (белого) ?? С черным цветом другое дело: разделяются два различных по своей природе графических объекта: текст и растровые рисунки.

Автор: ndch
Дата сообщения: 12.02.2010 12:53

Цитата:
Хорошее решение - забанить нафиг всех негативщиков

Значит читаем это
Автор: Tulon
Дата сообщения: 12.02.2010 13:54
Вот, нашел более технологичное решение для игнора юзеров на ru-board'е:
http://forum.ru-board.com/topic.cgi?forum=13&topic=2577
Уже испробовал - понравилось.

Добавлено:
U235

Цитата:
ИМХО, и для постобработки это тоже не имеет значение. По крайней мере, совершенно не представляю себе для чего может быть полезно такое искуственное разделение картиночного и текстового фона (белого) ?? С черным цветом другое дело: разделяются два различных по своей природе графических объекта: текст и растровые рисунки.

В некоторых случаях все-же будет иметь. Например захотели мы сделать гамма-коррекцию картинки, увести ее в сторону серого. Ну и какую-же часть изображения менять? Не весь же фон, правда? А в картинках могут быть чисто белые элементы, даже по краям. В общем я уже сделал резервирование и чисто черного и чисто белого цвета. Скоро будет в Git.
Автор: ntsx
Дата сообщения: 12.02.2010 15:54
Tulon

Большое спасибо за Scan Tailor. У вас получился красивый продукт.
От его использования получаешь эстетическое удовольствие.
Это просто здорово!

Конечно, есть несколько наблюдений; я надеюсь, что они могут оказаться полезными.

1. Я заметил, что поворот страницы даже на минимальный угол действительно может сильно заблюривать картинку.
Обычно небольшой blur не мешает, но на картинках с мелкими деталями это приводит к ухудшению качества картинки.
В то же время фазу автоповорота пропустить невозможно (не нашел варианта).
А хотелось бы этим процессом управлять - для каких-то страниц пропустить фазу поворота совсем, для каких-то выполнить.
Но не вручную по одной странице, а группами.

2. В качестве исходных я использую сканы с реальным 150-300 dpi.
Вывод текста - в 600 dpi.
С текстом все ОК.

Но вот с картинками - у меня не получилось добиться качества без второго технологического прохода фазы вывода.
Я пробовал работать по методу разделения слоев из результирующих файлов 600 dpi.
Здесь как минимум 3 проблемы:
а) потеря качества картинки с мелкими деталями (blur)! (это очень важно)
б) повышенные требования к ресурсам HDD для работы с серым результатом в 600 dpi
в) требования к временным ресурсам при обработке результата в 600 dpi

Наверное, меня душит перфекционизм :), но я испытываю дискомфорт, когда избыточно затраченное время и сверх необходимого выполненная работа приводят к худшему результату.
Я уверен, вы меня поймете, мне ваши чувства насчет стройности Scan Tailora понятны.

В итоге, путем проб и ошибок я все равно пришел к технологии, используемой anagnost96:
http://forum.ru-board.com/topic.cgi?forum=5&topic=27424&start=1580#5

Таким образом сейчас у меня технология сводится к следующему:
- подготовка пп. 1-5
- быстрый пробный вывод текста с небольшим dpi в режиме "смешанный, только текст"
- правка зон картинок там, где автомату требуется помощь
- оценка качества полученных картинок (и отмена поворота, например)
- вывод текста с dpi 600 в режиме "смешанный, только текст" (медленно)
- вывод картинок с исходным dpi в режиме "смешанный, только изображения" (быстро!)
- сборка djvu (быстро!)

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

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

Спасибо! Желаю Вам неиссякаемой энергии на этом нелегком пути к совершенству. :)

anagnost96

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

all

Не хотелось бы, чтобы мой пост подлил масла в огонь, к чему продукт переводить. :)
А вот найти красивое решение хотелось бы.
Автор: amz01
Дата сообщения: 12.02.2010 16:11
Dashout
Цитата:
Запустил параллельно новый СТ

Да, это классный совет. А я, блин, недопёр. Буду тоже так делать.
Теперь надо посоветовать Тулону использовать в новом STA многопоточность. А-то опять левой пяткой чешемся...
Автор: Tulon
Дата сообщения: 12.02.2010 16:21
ntsx
Хотелось бы посмотреть на примеры, где качество картинок критично.

Блюр от поворота - дело вполне естественное, ведь теряется отношение пикселей один-к-одному, ну или там целое-число-к-одному.

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

Кстати для исходников в 150 DPI наверное нет смысла делать вывод в 600 - хватит и 300. Еще один момент - при ненулевом повороте, вы ничего не выигрываете от кратного соотношения исходного и выводного DPI. То есть разницы между 300 -> 600 и 300 -> 650 вы не заметите.

Еще: в принципе, с новым методом, предложенным U235 (сегодня добавил поддержку со стороны СТ, так что препроцессинга больше не потребуется), вы все равно сможете склеивать текст и фон разного разрешения - так же, как и в STA, только с дополнительным шагом - прогон сепаратора.
Автор: amz01
Дата сообщения: 12.02.2010 16:21
ntsx
Цитата:
быстрый пробный вывод текста с небольшим dpi
Очень ценный совет. Мерси.
Автор: StanFreeWare
Дата сообщения: 12.02.2010 16:23
ntsx
Пожалуйста приведите пример потери качества от блура на апскейлинге. Интересно скорее в плане категории сканов, для которых STA заметно предпочтительнее в плане качества.
Автор: amz01
Дата сообщения: 12.02.2010 16:23
Tulon А где можно взять апдейт ST? На том сайте лежит только прошлогодняя версия.

StanFreeWare А ты своим "костылём" натолкнул на интересную мысль - можно взять инфу из проекта до 5-го шага и обработать сканы в своей проге. Потом прогнать сканы через фокус и блур. Потом твоей прогой ST_XmlPatch закинуть сканы обратно в ST. А, потом, запустить 6-й шаг в многопоточном режиме. На днях сделаю.
Автор: StanFreeWare
Дата сообщения: 12.02.2010 16:28
Tulon
Спасибо за ссылку на игнор-лист. Он же твит. Он же black list. Он же фильтр негативных реплик. Реально помогает
Автор: ntsx
Дата сообщения: 12.02.2010 20:19
Tulon


Цитата:

Еще: в принципе, с новым методом, предложенным U235 (сегодня добавил поддержку со стороны СТ, так что препроцессинга больше не потребуется), вы все равно сможете склеивать текст и фон разного разрешения - так же, как и в STA, только с дополнительным шагом - прогон сепаратора.


Это здорово, что решение уже готово и будет в основном билде.
Хотя, конечно, оно все равно не слишком ориентировано на метод разделенной обработки.
Но уже позволяет ее осуществить, хотя и чуть сложнее, чем STA.

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

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

amz01

Цитата:
Очень ценный совет. Мерси.

Жё ву зан при!

Tulon, StanFreeWare

Цитата:
Хотелось бы посмотреть на примеры, где качество картинок критично.

Цитата:
Пожалуйста приведите пример потери качества от блура на апскейлинге. Интересно скорее в плане категории сканов, для которых STA заметно предпочтительнее в плане качества.


Вот, результирующий djvu: http://www.onlinedisk.ru/file/348410/
На всякий случай - исходные файлы: http://www.onlinedisk.ru/file/348415/
Там обычный лист 150, отвернутый лист 150 и лист, прошедший скайлинг до 600 и обратно.
Если посмотреть на надписи на дереве, мне больше нравится вариант без blur'а.
Автор: StanFreeWare
Дата сообщения: 12.02.2010 20:34
ntsx
Видимо, это не ваш скан, иначе вы бы просто пересканировали в большем разрешении и вывели в режиме только текст. Ведь блюр в данном случае дополнительно усугубляется артефактами сжатия IW44.
Автор: ntsx
Дата сообщения: 12.02.2010 20:45
Совершенно верно, мопед не мой. :) Ну вот приходится вот работать с тем, что есть.
Хотя окончательный результат меня более чем устраивает.
Автор: Tulon
Дата сообщения: 12.02.2010 22:50
ntsx

Цитата:
На всякий случай - исходные файлы: http://www.onlinedisk.ru/file/348415/

Это не исходные, это вывод ST. Меня интересуют именно исходные.
Автор: ntsx
Дата сообщения: 13.02.2010 02:49
Tulon

ОК: http://www.onlinedisk.ru/file/348833/
--
Скажите, а как работает автосегментация?
Я могу на втором прогоне (для измененного dpi) получить другую разбивку на текст/изображения для автоматически определенных сегментов?

Если Вы заметили, в моей иллюстрации (.djvu) не хватает картинки на первой странице.
Похоже, это не случайно.

Если автосегментация зависит от dpi и выполняется дважды, значит сейчас разделение текстов / изображений в разных dpi недопустима.
Потому что выполнив сохранение картинок в меньшем dpi, мы потеряем их часть (моя догадка о работе алгоритма).
Это для STA; а для ST в этом случае просто бессмысленно проверять сегментацию на меньших dpi.

В этом случае нужен п. 5.5 по фиксации сегментации для некоего dpi, которая будет для п. 6 оставаться инвариантной относительно dpi вывода.
Это серьезно; на самом деле, по сравнению с этим фактом и сепаратор представляется отличным парнем, и пара минут на "convert -crop" уже не напрягает.

Tulon, счастье почти в наших руках, оно близко, но зависит от Вас. :)
Автор: Tulon
Дата сообщения: 13.02.2010 11:31
ntsx

Цитата:
ОК: http://www.onlinedisk.ru/file/348833/

Ну что тут можно сказать. Скан порядка 150 DPI, текст не бинаризован, на картинках текст еще меньшего размера, чем основной - буквально 8 пикселей в высоту для заглавных букв. Я удивлен, что DjVu кодер не убил этот текст на картинках под чистую.
Вы нашли способ, хоть и трудозатратный, но все же позволяющий добиться приемлемых результатов - тут вас можно поздравить. Однако для меня спасение таких безнадежных пациенов не является приоритетной задачей. На это можно потратить очень много времени, и все равно большую их часть уже не спасти.


Цитата:
Скажите, а как работает автосегментация?
Я могу на втором прогоне (для измененного dpi) получить другую разбивку на текст/изображения для автоматически определенных сегментов?

Маловероятно. Сама сегментация всегда делается в 300 DPI, и потом масштабируется до нужного размера. Однако на нее может повлиять например качество нормализации освещения, а оно уже зависит от DPI, хотя и не сильно.


Цитата:
Если Вы заметили, в моей иллюстрации (.djvu) не хватает картинки на первой странице.
Похоже, это не случайно.

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


Автор: ntsx
Дата сообщения: 13.02.2010 14:56
Tulon


Цитата:
Маловероятно. Сама сегментация всегда делается в 300 DPI, и потом масштабируется до нужного размера. Однако на нее может повлиять например качество нормализации освещения, а оно уже зависит от DPI, хотя и не сильно.


Понятно, это хорошие новости.
Чтобы закрыть тему, Вы не могли бы посмотреть различие в сегментации моего исходного скана (объявленного как 150 dpi при создании проекта ST) при выводе в 600 или 300 dpi и 150 dpi.
На 150 dpi изображения не определяются.

Вот еще один пример из той же серии: http://www.onlinedisk.ru/file/349121/
На 150 dpi определяется на на пару картинок больше.

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


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


И тем не менее, ST отлично справляется с поставленной задачей.
И ценно вдвойне, что даже на таких данных он позволяет быстро получить достойный результат.
Ну а то, что задачи имеют тенденцию к некоторому выходу за рамки изначальной идеологии - это ведь показатель успешности и жизнеспособности продукта.
Автор: StanFreeWare
Дата сообщения: 13.02.2010 18:52
Хотелось бы отметить, что сканами называть такой первоисточник некорректно. Это явные скриншоты с векторного источника в режиме fullscreen на мониторе шириной 1650 пикселей. Я относительно недавно заметил некоторое повышение количества djvu-книг с такими страницами - скриншотами вектора. Кстати, читаются они и без дополнительной обработки обычно неплохо (особенно на мониторе шириной 1650 пикслей, повернутом на 90 градусов )) ).
Кстати, задача определения dpi для такого источника сродни задаче определения dpi для фотоскана со штатива.
Автор: U235
Дата сообщения: 14.02.2010 06:09
Tulon

Цитата:
Скоро будет в Git.

Спасибо!
Вот неофициальная win32 сборка под MinGW32 (исправленная ссылка, в архиве только exe, без библиотек):
http://www.onlinedisk.ru/file/349707/
ScanTailor snapshot 12 Feb 2010 12:38:57 +0000 (no OpenGL)
Автор: ndch
Дата сообщения: 14.02.2010 08:03
Tulon
Давно хотел спросить:
Довольно часто указывается заниженное и завышенное значение dpi, для этого на входе предлагается исправить значение.

Последствия последнего примера.

В концепцию программы входит "простота для пользователя". Но указания верного dpi приходится запускать внешнюю программу и немного "пошаманить". Что в критерий "простоты" не очень вписывается.

Возможно ли, в диалоге "изменение dpi" изобразить preview и сетку на высотой в один символ и/или окно высотой для вписывания шести-семи строк текста с zoom-ом для "визуального измерения dpi" ?

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

Нечто в духе:
Автор: StanFreeWare
Дата сообщения: 14.02.2010 08:40
ndch
Для полноты картины можно еще и физические размеры при заданных dpi показывать, например так:

Автор: Tulon
Дата сообщения: 14.02.2010 10:12
Хочу напомнить, что фич-реквесты по прежнему игнорируются.
Автор: ndch
Дата сообщения: 14.02.2010 10:16
Tulon
Да, я не про фич-реквест, а про "вписывается ли в концепцию программы" ?
Хочется знать "линию партии".
Автор: Dashout
Дата сообщения: 14.02.2010 10:32

Цитата:
"вписывается ли в концепцию программы" ?

похоже нет, как я понял, для ускорения работы задействованных алгоритмов происходит сжатие обрабатываемого материала
Автор: ndch
Дата сообщения: 14.02.2010 10:41
Dashout, Видимо мы с Вами о разных вещах беседуем.
Автор: Dashout
Дата сообщения: 14.02.2010 10:50
Tulon

Цитата:
2. Алгоритм Select Content медленный, поэтому мы прогоняем его на уменьшенной копии изображения. А насколько его можно уменьшить, так чтобы дыры и углубления в буквах не пропадали (это важно)? По пиксельному размеру этого не оценить, п


ndch

Цитата:
Dashout

Цитата:
Ну тогда тем более не понятно, почему Tulon оставил статический DPI на входе...

Потому что очень ресурсоёмко и очень накладно. Полезность не очень большая. Он неоднократно говорил "есть более приоритетные направления". И это действительно так.

Автор: Tulon
Дата сообщения: 14.02.2010 11:08

Цитата:
Да, я не про фич-реквест, а про "вписывается ли в концепцию программы" ?

Если вы сами это реализуете, то почему нет?
Я бы впрочем начал не с этого. Я бы попытался угадать DPI с помощью все того же преобразования Фурье.
Автор: VidelSamogO
Дата сообщения: 14.02.2010 15:34
amz01
+1

Страницы: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172

Предыдущая тема: Невозможно установить Acronis True Image Home v10.0.4940


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.