» Scan Tailor

U235
Вот только чем labelling поможет для нахождения ближайших соседей?

У меня в классе InfluenceMap для каждого пикселя хранится следующая информация:
1. Номер соединенного компонента, в зоне влияния которго находится данный пиксель. (4 байта)
2. Вектор от данного пиксела до ближайшего пикселя соединенного компонента. (2x2 байта)
3. Квадрат расстояния до ближайшего пикселя соединенного компонента. (4 байта)
Ну а кроме этого я держу вспомогательный массив, где для каждого компонента хранятся его характеристики, например колличество пикселей.
В принципе квадрат расстояния можно было бы исключить, потому как его можно вычислить из вектора. Он хранится для ускорения постороения этой карты влияний, которая по сути дела есть ни что иное, как диаграмма Вороного.
Строится эта карта влияния методом vector propagation.

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

Rev.267:
- Тестирование на проекте последнего моего примера (см. выше) примера: Качество очистки в плане сохранения полезного контента улучшилось. На большинстве "сложных" рисунков сохранилось практически всё. Исчезли единичные точки, что (на мой взгляд) никак не отразилось на качестве рисунка.

Далее - http://narod.ru/disk/5524292000/Scan-Test-267.7z.html:
- aa_0006-стр.8.tif, aa_0007_стр.11.tif, aa_0014-стр.24.tif, aa_0036-стр.69.tif - на указанных страницах в полезную область вкобчены жирные точки, находящиеся на значительном расстоянии от области текста. Хоть таких примеров оказалось достаточно много, но для меня ситуация терпима. Скидываю, так сказать, для профилактики.
- Despeckling: aa_0023.tif, 0042_aa_0023.tiff - пример неприемлемой очистки; aa_0034.tif, 0064_aa_0034.tiff - удалена часть пунктирных линий; aa_0040.tif, 0077_aa_0040.tiff - в нескольких местах текст стал нечитаем. А также, как минимум в 6-ти случаях у двоеточий пропала нижняя точка.
- Вылетает программа. Ошибка воспроизводится. Не знаю как вам её представить, поэтому скидываю всю книгу - (ссылка). Судя по thumbs, ошибка возникает на aa_0176 (последний thumbs - aa_0175).

Цитата:

Не знаю, насколько это вписывается в планы, но мне, как просто пользователю, хотелось бы видеть более тонкий результат. Или, может быть, интерактивный контроль "степени жирности" - регулировку порога при преобразовании в BW.

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

Tulon

Цитата:

Вот только чем labelling поможет для нахождения ближайших соседей?

Сам по себе - никак не поможет. Это больше, ИМХО, вспомогательная операция, с результатом которой можно работать как с базой данных объектов и их свойств + при относительно небольшом числе объектов это возможно еще и сэкономит память.

Нельзя ли в вашем алгоритме все объекты попробовать заменить точкой, в центре масс каждого объекта? Думаю это не сильно скажется на результатах, но упростит вычисления. Хранить данные при этом возможно лучше будет в виде: №объекта, x,y,S-количество пикселей (площадь).

Кстати, возможно бдет интересно:http://rrc.dgu.ru/res/matlab/imageprocess/book3/13/bwmorph.html
рис г. - по сути диаграма Вороного для рис. в., получаемая через бинарную морфологию.

denver 22

Цитата:

- aa_0006-стр.8.tif, aa_0007_стр.11.tif, aa_0014-стр.24.tif, aa_0036-стр.69.tif - на указанных страницах в полезную область вкобчены жирные точки, находящиеся на значительном расстоянии от области текста. Хоть таких примеров оказалось достаточно много, но для меня ситуация терпима. Скидываю, так сказать, для профилактики.

Пока я пожалуй оставлю стадию "Полезная область" в покое. Лучшее - враг хорошего.


Цитата:

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

Исправил.

Arcand

Цитата:

Может имеет смысл добавить возможность смещать по желанию вычисленный порог в Otsu.

Может так и сделаю, но не сейчас.

U235

Цитата:

Сам по себе - никак не поможет. Это больше, ИМХО, вспомогательная операция, с результатом которой можно работать как с базой данных объектов и их свойств + при относительно небольшом числе объектов это возможно еще и сэкономит память.

Labeling в чистом виде у меня тоже есть. Класс называется ConnectivityMap. Для каждого пикселя в ней хранится идентификатор соединенного компонента, к которому он принадлежит. Кстати из нее и строится InfluenceMap - отсюда и дополнительные 4 байта на пиксель.
При желании можно выдирать компоненты один за другим. Для этого есть классы ConnCompEraser (когда не нужно изображение компонента) и ConnCompEraserExt (когда нужно).


Цитата:

Нельзя ли в вашем алгоритме все объекты попробовать заменить точкой, в центре масс каждого объекта? Думаю это не сильно скажется на результатах, но упростит вычисления. Хранить данные при этом возможно лучше будет в виде: №объекта, x,y,S-количество пикселей (площадь).

Можно то можно, но уж больно грубо получается - считать любой объект кругом.



Добавлено:
Еще я сделал отключение despeckle и вручную подобрал параметры смягчения для разных DPI. Это должно повысить скорость вывода на высоких DPI.
Вроде как теперь ничего не мешает сделать оффициальный релиз.

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

Цитата:

Тогда помимо выкладывания в топике, обновляйте пожалуйста и ссылку в шапке.

Можно просто дать в шапке ссылку на директорию, куда у него выкладываются сборки. Так не придется каждый раз обновлять шапку.

Сборка (Rev.271) в шапке

Добавлено:

Цитата:

Пока я пожалуй оставлю стадию "Полезная область" в покое. Лучшее - враг хорошего.

Полностью - ЗА. На данный момент меня вполне устраивает качество. Просто отписываю лишний раз с примерами.

Цитата:

Вроде как теперь ничего не мешает сделать оффициальный релиз.

Полностью ЗА.
В новой версии сделал свой проблемный (с вылетом) проект. Больше не упал.
Качество despeckle порадовало. Не знаю, улучшали ли вы его со сборки 267, но он сохранил практически все точки в полезной области. Только на одном скане получилось так, что в одном рисунке точки сохранились (где он раньше удалил бы их), а на другом рисунке - частично вычистил.
Но теперь, когда despeckle можно выключать для отдельного скана, можно решать подобные проблемы.
От себя могу сказать, что оставшиеся порядка 30 книг скорее всего буду обрабатывать именно в ST!!! Т.к. и качество на уровне, и гибкость настройки стала такой, чтобы справляться с большинством проблем.
Может успеете перед релизом добавить упомянутую ранее функцию, чтобы после Пакетной обработки программа переходила в первому скану?

denver 22

Цитата:

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

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

Admig314
Проверьте, устраиваит ли вас сглаживание при 1200 DPI c новыми параметрами. По мне так стало еще лучше, чем было. И быстрее.

Остальные тоже могут сравнить. На 300 DPI ничего не изменилось, так что тестируйте более высокие разрешения вывода.

Цитата:

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

Хм... Значит мне показалось, что ранее замеченное утолщение текста теперь исправлено? Может просто сканы хорошего качества попались и утолщений не произошло...

Все сделал.

Добавлено:

Цитата:

Хм... Значит мне показалось, что ранее замеченное утолщение текста теперь исправлено? Может просто сканы хорошего качества попались и утолщений не произошло...

Речь идет о разрешении вывода. Если у вас 600, то вполне возможно так и есть.

Я понял про что вы говорили. Но мне показалось, что у меня и на 300 dpi изменения произошли. Ещё до того, как вы об этом написали (см. мои выводы для (Rev.271)). Может мне и показалось. Время покажет.
Сборка (Rev.274) в шапке.

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

Цитата:

Проверьте, устраиваит ли вас сглаживание при 1200 DPI c новыми параметрами. По мне так стало еще лучше, чем было. И быстрее.

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

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

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

Цитата:

Многоточия с деспеклом по-прежнему исчезают.

Решил пока оставить despeckle как есть.


Цитата:

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

Ладно, завтра попробую сделать подстройку порога бинаризации.


Цитата:

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

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


Цитата:

Может быть сделать сетку опорных линий?

Можно. Когда не обещаю. А что, вам попались страницы, где автоматика не справляется?

Цитата:

А что, вам попались страницы, где автоматика не справляется?

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

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

Цитата:

А что, вам попались страницы, где автоматика не справляется?

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

Цитата:

Частично это можно решить, увеличив мастштаб просмотра и сдвинув страницу, но все-таки это не очень удобно. Может быть сделать сетку опорных линий?

+1. Именно в описанном выше случае очень не хватало возможности сместить линю выравнивания вверх/вниз, чтобы вручную выровнять страницу по другим строкам.

Цитата:

Или не сетку

Сетку лучше.

Добавлено:
Tulon
Я уже писал про данный недостаток, но не был устранён, поэтому повторю:
Есть изображение 2 страниц, на правой есть помятость из-за которой линия разреза проходит левее корешка.
Как есть, как должно быть.
Исходное изображение.

CrackMe

Цитата:

Есть изображение 2 страниц, на правой есть помятость из-за которой линия разреза проходит левее корешка.
Как есть, как должно быть.
Исходное изображение.

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

Сделал ручную подстройку порога бинаризации.

Сборка (Rev.275) в шапке.
Tulon
Только что заметил, в Компенсации наклона знак градуса частично закрыт стрелками "вверх-вниз". Может это только у меня...

Цитата:

Только что заметил, в Компенсации наклона знак градуса частично закрыт стрелками "вверх-вниз".

У меня все нормально.
Свои сборки буду выкладывать тут. Номер версии можно узнать тут. Вроде бы автоматизация сборок у меня заработала..

Цитата:

Только что заметил, в Компенсации наклона знак градуса частично закрыт стрелками "вверх-вниз". Может это только у меня...

Бывает такое - это баг Qt. Настолько мелкий баг, что даже репортить его неохота.

savage2000

Цитата:

monday2000 Ответ в твоем персональном топике.

Я не общаюсь с теми, кто обращается ко мне на "ты". (без крайней нужды)
denver 22

Цитата:

Забейте на него 100%-ный ИГНОР и все станет намного проще.

Что это за босяцкие выражения "забейте"? Вы никак не "врубитесь", что здесь не группа студентов-строителей и здесь вообще иные порядки.

Цитата:

100%-ный ИГНОР и все станет намного проще.

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

Цитата:

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

Хелп вы прочитали, пора уже начинать пользоваться.

Добавлено:
Admig314
Жду отзыва по поводу ручной регулировки порога.

Цитата:

Жду отзыва по поводу ручной регулировки порога

Да, обязательно попробую вечером, когда буду дома.
Есть еще одно малозначительное наблюдение по поводу DPI (тоже проверю вечером)

Отчет по rev.276
Само качество бинаризации отличное.
Регулировка *очень* мягкая, на глаз заметить различия непросто. Соответственно наиболее подходящий для меня случай, это уровень -15. Пожалуй, уже можно использовать.
Есть одно небольшое неудобство. Узнать, какой уровень выставил, можно, только *уже* выставив его, наведя мышь на шкалу. В процессе выставления или до него уровень не показывается, т.е. заранее трудно понять куда двигать ползунок для получения нужного уровня (или где щёлкнуть на шкале).

Теперь по поводу DPI.

Такое впечатление, что расчет ведется в точках на сантиметр, а не в точках на дюйм с соотвествующим округлением в каком-то там знаке. Скан до обработки, открываемый в Шопе, показывает разрешение ровно 1200 pixels/inch. Обработанный файл, только загруженный в Шоп, показывает 472.44 pixels/cm. При переводе обратно в pixels/inch вылезают неточности округления - 1199.998 pixels/inch. Понятно, что практического значения не имеет, но все же мелкое неудобство.

Цитата:

Есть одно небольшое неудобство. Узнать, какой уровень выставил, можно, только *уже* выставив его, наведя мышь на шкалу. В процессе выставления или до него уровень не показывается, т.е. заранее трудно понять куда двигать ползунок для получения нужного уровня (или где щёлкнуть на шкале).

Мне тоже хотелось бы, чтобы при движении ползунка тултип сразу показывался. К сожалению в Qt простого способа сделать это нет. Сложный есть. Поскольку его не пробовал, еще не знаю, насколько он реально сложен.


Цитата:

Такое впечатление, что расчет ведется в точках на сантиметр, а не в точках на дюйм с соотвествующим округлением в каком-то там знаке. Скан до обработки, открываемый в Шопе, показывает разрешение ровно 1200 pixels/inch. Обработанный файл, только загруженный в Шоп, показывает 472.44 pixels/cm. При переводе обратно в pixels/inch вылезают неточности округления - 1199.998 pixels/inch. Понятно, что практического значения не имеет, но все же мелкое неудобство.

Время от времени приходится переводить DPI в DPM (dots per meter) и обратно. Это связано с тем, что Qt'шный класс QImage хранит как раз DPM. Поскольку TIFFы я пишу сам, без помощи Qt, то в принципе мог бы писать в них DPI а не DPM. Пишу все-таки DPM потому что получаю его из QImage, и ненужных преобразований стараюсь избегать. В принципе можно ввести эвристику - если DPM, переведенный в DPI дает значение, близкое к целому, то пишем именно DPI, причем округленный. Если сильно будете просить - сделаю.

Цитата:

т.е. заранее трудно понять куда двигать ползунок для получения нужного уровня (или где щёлкнуть на шкале)

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

denver 22

http://scantailor.svn.sourceforge.net/viewvc/scantailor/trunk/?sortby=date&view=log

Revision 278
Show the tooltip for the threshold adjustment slider while it's being dragged.

Что-то ещё нужно ?

Добавлено:
Кто-как считает, полезная ли была такие функции ?

после выделения "полезных областей"
для удобства ручной коррекции размеров "полезных областей"
отсортировать сканы по
1. максимальной площади (x*y)
2. максимальной высоте (y)
3. максимальной ширине (x)

полезно такое ?

Второе:
в "макет страницы"
добавить к двум существующим опциям
'самая большая (по площади x*y) страница'

полезно такое ?