» Scan Tailor

Цитата:

Ответили все трое. Из них интерес проявили двое. Я дал им Ваше мыло на sf.net.

Это радует.


Цитата:

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

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

На этих выходных я сильно продвинулся в реализации следующего фильтра - Page Layout. Думаю через несколько дней закончу его. Ну а там и до вывода рукой подать.

Tulon

Цитата:

Все-таки вьювер и программа обработки изображений - весьма разные вещи.

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

Цитата:

К тому-же меня вполне устраивает то, что есть.

По крайней мере, открытые исходники - это главное преимущество Вашей программы перед СканКромсатором. Электронными книгами в формате DjVu мы все обмениваемся друг с другом свободно - жаль, что этот же принцип не всегда распространяется на исходные коды книгосканировочных и т.п. программ (имея в виду СК в первую очередь, но были и другие случаи). От этого мы все сильно потеряли - потому что нужно всякий раз изобретать велосипед заново. Отговорка, что кто-то начнёт наживаться на этих исходниках (или присваивать себе чужие достижения) ИМХО малоактуальна - например, коммерческих качественных вьюверов всё равно много по-любому (т.е. их разработчикам неоткуда было "содрать") - а зато хороших open-source вьюверов нет и поныне.

Добавлено:

Цитата:

Ну а там и до вывода рукой подать.

У меня такое небольшое пожелание - хотелось бы в будущем видеть исходники Scan Tailor в виде единого архива (zip или tar или т.п.), который можно было бы скачать с Вашего сайта на sf.net.

Добавлено:
Вот некоторые open-source вьюверы под Win, что я смог найти:

http://wxglade.sourceforge.net/extra/cornice.html
http://imgv.sourceforge.net/
http://mapivi.sourceforge.net/mapivi.shtml
http://gqview-win.sourceforge.net/
http://www.imgseek.net/
http://www.codeproject.com/KB/graphics/cximage.aspx
http://www.codeproject.com/KB/graphics/ImageStone.aspx

Все разной степени паршивости.

Цитата:

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

Ну, чтобы еще и с детальным описанием исходников, таких вы точно не найдете. Если я буду документировать каждый метод каждого класса, то на это уйдет больше времени, чем на написание самого кода. Впрочем, особо неочевидные вещи я все-таки документирую. Кроме того, документирую классы, написанные с прицелом на повторное использование. Для таких я даже test case'ы пишу.
GUI писать конечно сложно, особенно хороший GUI. Вы например заметили, что в СТ, GUI не блокируется ни при интерактивной, ни при пакетной обработке? Например вы нажали PgDown и пошла обрабатываться очередная страница. На это уходит 1-2 секунды. В эти две секунды никто не мешает вам нажать PgDown еще раз, или мышкой выбрать другую страницу, или вообще перейти на другой фильтр. За все эти прелести приходится расплачиваться сложностью кода. На данный момент в СТ 38 тысяч строк кода, не считая частей библиотеки boost, которые я включил в дерево исходников.
Если бы не сложность, можно было бы смело рекомендовать СТ как основу для всевозможных программ обработки страничных изображений. Кстати из-за этой самой сложности я совершенно не опасаюсь, что кто-то возьмет мой код и вставит в свою закрытую программу. Ну если только кто-то с нуля будет писать что-то подобное, да и то вряд-ли.
Впрочем, сложность кода не должна сильно мешать новым разработчикам СТ, если таковые появятся. Код, непосредственно участвующий в обработке изображений, достаточно компактный и понятный, а уж архитектурные вопросы я возьму на себя.


Цитата:

У меня такое небольшое пожелание - хотелось бы в будущем видеть исходники Scan Tailor в виде единого архива (zip или tar или т.п.), который можно было бы скачать с Вашего сайта на sf.net.

Когда сделаю вывод, то есть когда с СТ реально можно будет работать, тогда и начну выкладывать исходники в tar.gz. Сейчас они могут быть интересны только разработчикам, а для них не должно быть проблемой выкачать исходники из SVN. Кстати советую посмотреть на программу SmartSVN. Не open-source к сожалению, но даже ее бесплатная версия значительно удобнее, чем все остальные SVN клиенты, которые я видел.

Ещё несколько Open-Source вьюверов под винду:

http://uvviewsoft.com/free_and_pro-ru.htm (Delphi)

http://www.codeproject.com/KB/applications/imageviewer.aspx - малоинтересно, т.к. это GDI+

http://mtpaint.sourceforge.net/

Я их все сам проверил - реально работают, но, конечно, не так хорошо, как хотелось бы.

На всякий случай, я выложил у себя коммерческие Delphi-программные библиотеки для работы с растровой графикой:

ImageEn v2.0.7 for Delphi34567

http://djvu-soft0001.nxt.ru/image_en_2_0_7.rar (11.34 МБ)

ImageLib Corporate Suite 6.0

http://djvu-soft0001.nxt.ru/imagelib_corp_suite_6_0.rar (9.20 МБ)

Вторая библиотека - та самая, которая используется в СК.

Быть может, среди нас найдётся "дельфинист", которому эти 2 библиотеки будут полезны. Я их взял с диска, который купил на базаре несколько лет назад.

Добавлено:
Ещё я сделал некий тестовый скан в формате BW Tif CCIT Fax G4. Назовём его условно "Test BW". Этот скан можно использовать для чисто визуального оценивания качества отображения разнообразных Open-Source вьюверов, ссылки на которые я привёл выше.

Вот ссылка на "Test BW":

http://www.djvu-soft.narod.ru/bookscanlib/test_bw.tif (46 КБ)

Ещё один:

http://sourceforge.net/projects/jpegview

Выпустил новую версию. Забирайте с http://scantailor.sf.net/

Реализовал фильтр Page Layout, других изменений почти нет. Реально использовать его все еще нельзя, поскольку нет вывода, но теперь до вывода рукой подать.

Жду отзывов.

Tulon

Цитата:

Реализовал фильтр Page Layout, других изменений почти нет.

Я пока ещё не врубился в Вашу программу. А что это такое - "Page Layout" ? Ещё непонятно, что есть "Fix Orientation" и "Select Content".

И ещё я присоединяюсь к уже не раз высказанному мнению, что появляющееся при старте программы маленькое окошко, а также следующее за ним окно, возникающее после нажатия "New Project" страшно напрягают. Я бы предложил следующее: пусть программа открывается сразу же после запуска. А в меню "File" предусмотреть пункт "Open File(s)" и "Open Folder" (действующие только в отношении граф. файлов популярных форматов). Далее в какой-то момент предлагать юзеру выбрать папку для сохранения результатов. Тут надо подумать, какой момент лучше всего: быть может, это нужно делать в момент открытия файлов, а может, в момент запуска на выполнение уже сформированного юзером сканообрабатывающего задания. Может быть, следует сделать всё это также, как и в ФайнРидере: пакет по-умолчанию и предложение юзеру сохранить его при выходе из программы (хотя ИМХО это тут не лучшее).

Ещё хотелось бы, чтобы наиболее важные (или все) опции, изменяемые юзером, автоматически сохранялись бы - как в Irfan View. В СК этого нет.

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

Добавлено:
А в целом, всё смотрится довольно любопытно уже сейчас.

Добавлено:
Я предлагаю Вам рассмотреть такой вариант: сделать не одну, а 2-3 узкоспециализированных сканобрабатывающих программ. Смысл в том, чтобы избежать вредного универсализма, который погубил СК. Одной программой нельзя делать всё - это будет монстр (т.е. СК), а не программа. Подробнее см. http://www.djvu-soft.narod.ru/kromsator/alternative.htm .

Цитата:

Я пока ещё не врубился в Вашу программу. А что это такое - "Page Layout" ? Ещё непонятно, что есть "Fix Orientation" и "Select Content".

Ну так попробуйте потыкаться там, рамки всякие мышкой потягать. Так вы все гораздо лучше поймете, чем по моим объяснениям. Если коротко, то:
Fix Orientation - поворот на 90, 180 или 270 градусов.
Split Pages - разделение страниц (для разворотных сканов) / отрезание огрызка второй страницы (для одиночных).
Deskew - компенсация наклона.
Select Content - выделение зоны контента рамкой.
Page Layout - выставление полей и выравнивание по размерам с остальными страницами.


Цитата:

И ещё я присоединяюсь к уже не раз высказанному мнению, что появляющееся при старте программы маленькое окошко, а также следующее за ним окно, возникающее после нажатия "New Project" страшно напрягают. Я бы предложил следующее: пусть программа открывается сразу же после запуска. А в меню "File" предусмотреть пункт "Open File(s)" и "Open Folder" (действующие только в отношении граф. файлов популярных форматов). Далее в какой-то момент предлагать юзеру выбрать папку для сохранения результатов. Тут надо подумать, какой момент лучше всего: быть может, это нужно делать в момент открытия файлов, а может, в момент запуска на выполнение уже сформированного юзером сканообрабатывающего задания. Может быть, следует сделать всё это также, как и в ФайнРидере: пакет по-умолчанию и предложение юзеру сохранить его при выходе из программы (хотя ИМХО это тут не лучшее).

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


Цитата:

Ещё хотелось бы, чтобы наиболее важные (или все) опции, изменяемые юзером, автоматически сохранялись бы - как в Irfan View. В СК этого нет.

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


Цитата:

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

Да, есть такое дело. На разворотных сканах приходиться уменьшать картинки, чтобы втиснуть их в портретную центральную зону. Других вариантов я не вижу. Впрочем эта проблема актуальна только для первых двух фильтров - Fix Orientation и Split Pages, поскольку остальные работают уже с разрезаными одиночными страницами.


Добавлено:

Цитата:

Я предлагаю Вам рассмотреть такой вариант: сделать не одну, а 2-3 узкоспециализированных сканобрабатывающих программ. Смысл в том, чтобы избежать вредного универсализма, который погубил СК. Одной программой нельзя делать всё - это будет монстр (т.е. СК), а не программа. Подробнее см. http://www.djvu-soft.narod.ru/kromsator/alternative.htm .

Может быть так и стоит делать. Scan Tailor в таком случае ограничится разрезкой и выравниванием сканов. Пост-обработку можно будет делать где-нибудь еще. Я на самом деле и не планирую реализовать все что только возможно. Сделаю вывод - а потом пойдет работа над улучшением того, что есть, а не над добавлением новых фич.

Tulon

Цитата:

Вот тут я не согласен. Что пользователь будет делать в программе, не загрузив исходный материал?

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

Цитата:

только искать, как этот самый материал загрузить. А так ему искать не надо - вот вам дилог - добавляйте.

Да ничего искать и не надо - File -> Open Files - так устроены практически все компьютерные программы мира (т.е. программы такого рода).

И не всегда надо указывать выходную папку - я могу захотеть просто загрузить пару файлов, обработать и посмотреть результат прямо в программе - не желая сохранять результат. Сейчас меня с ходу заставляют указать Output directory. И Files in Project / Not in project в 90% случаев никому не нужны - т.к. наиболее часто мы загружаем некую заранее подготовленную папку со сканами, подлежащими обработке. Просто можно поставить там фильтр на автоматический отбор только графических файлов (по расширению) и всё. То есть, сейчас у Вас по-умолчанию все открываемые файлы - Not in project, а правильнее наоборот - все чтобы были по-умолчанию in Project.

Но вообще-то вот это маленькое окошечко при старте смотрится исключительно нехорошо. Думаю, так скажут практически все пользователи. Неужели Вы действительно считаете, что найдётся хотя бы один пользователь, который не догадается, что ему нужно нажать на File -> Open File(s) после открытия программы?

Добавлено:

Цитата:

Page Layout - выставление полей и выравнивание по размерам с остальными страницами.

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

Цитата:

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

Вот как раз без исходного материала там и тыкать-то некуда. Насчет хэлпа - ну предположим кто-то действительно начинает знакомство с программой с чтения хэлпа. Но ознакомившись с программой, ему станет реально удобнее та схема, что реализована сейчас. А хэлп (которого пока и нет) - вполне можно поместить в меню рядом с самой программой.
Я помню каким неудобным был Nero, пока не появился Nero Smart Start. До этого открывалось пустое окно - и давай ищи там в меню то, что ты хотел сделать. Так вот СТ как-раз стремится быть похожим на Nero Smart Start.


Цитата:

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

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


Цитата:

И Files in Project / Not in project в 90% случаев никому не нужны - т.к. наиболее часто мы загружаем некую заранее подготовленную папку со сканами, подлежащими обработке. Просто можно поставить там фильтр на автоматический отбор только графических файлов (по расширению) и всё.

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


Цитата:

Цитата:
Page Layout - выставление полей и выравнивание по размерам с остальными страницами.

Это должно делаться исключительно автоматически - и уж никак не вручную.

И как вы себе это представляете? Откуда программе знать, какие поля вы хотите? Там ручной работы на самом деле минимум. Запускаете пакетный режим, если обобщенные размеры слишком велики (пунктирная линия), кликаете на Widest Page / Tallest Page и либо уменьшаете там поля, либо исправляете зону контента. После этого при желании можно подправить размеры полей на одной странице, и применить их ко всем остальным стнаницам. А главное все визуально, не нужно гадать как в СК, сколько пикселей делать поля.

Tulon

Цитата:

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

1. Там я не лишён возможности сразу же запустить нужную мне программу.
2. Nero Smart Start не заставляет меня сначала всунуть чистую болванку в привод, а уже только потом предлагать что-либо сделать с ней.

Если Вы хотите сделать помощник - то его ведь можно сделать отдельно. А многим захочется просто запускать программу - и без всяких выкрутасов вначале.

Цитата:

Я помню каким неудобным был Nero, пока не появился Nero Smart Start.

Зачем сразу же начинать с создания помощника - когда сама программа ещё не готова?

Цитата:

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

Не убирать, но маленькое окошко при запуске - убрать надо бы непременно и заменить его на File -> Open files(s) - и вот там уже и засунуть этот функционал.

Цитата:

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

Ну тогда пусть юзер указывает выходную папку в том окошке, которое будет открываться по File -> Open files(s). Можно сделать её по-умолчанию подпапкой входной папки (да ещё и с заданным именем) - как в СК.
Цитата:

После этого при желании можно подправить размеры полей на одной странице, и применить их ко всем остальным стнаницам. А главное все визуально, не нужно гадать как в СК, сколько пикселей делать поля.

Примерно ясно - звучит неплохо.

Ещё раз повторюсь: маленькое окошко, появляющееся сразу после запуска программы - это страшно раздражающая вещь. Всё, что нужно сделать - пусть это окошко открывается не при запуске, а после запуска - при нажатии File -> Open files(s). Заметьте, что я как минимум третий, кто об этом говорит. Можем хоть голосование устроить - скорее всего, практически все захотят того же.

По поводу невозможности открыть главное окно без создания или открытия проекта:
Не разделяю вашей точки зрения. Думаю сейчас оно реализовано вполне удобно. Я бы не стал возражать, если бы кнопки New Project и Open Project появлялись бы прамо в главном окне. Показать их пользователю надо, чтобы ему их искать не пришлось, а в главном окне или в отдельном - не суть важно. Но сделать это не так то просто. Есть архитектурные ограничения, которые мешают этому. Я в любом случае буду их решать, потому что это нужно для реализации добавления файлов в проект. Может тогда и перемещу эти кнопки в главное окно, если это не окажется слишком сложно.

Насчет выходной папки:
Ну так ли сложно ее указать в самом деле? Ну я мог бы автоматом забивать туда ${input_dir}/out, или типа того. В любом случае это весьма несущественное неудобство.

Tulon

Цитата:

Не разделяю вашей точки зрения. Думаю сейчас оно реализовано вполне удобно.

Я просто хотел бы, чтобы Ваша программа стала действительно популярной. Но если Вы сами этого не хотите - воля Ваша. В таком виде, как сейчас (с этим маленьким окошком, выскакивающим при запуске) все, конечно, будут пользоваться Вашей программой - но, во-первых, будут всякий раз мысленно Вас материть (по поводу окошка), а во-вторых - будут бомбардировать Вас письмами с просьбой убрать это несчастное окошко (например, в Files -> Open File(s) ).

Цитата:

Насчет выходной папки:
Ну так ли сложно ее указать в самом деле?

ИМХО несложно. В момент указания папки-источника. В этом нет проблемы - проблема в маленьком окошке при запуске, которого не должно быть, о чём уже высказалось 3 человека в 2 форумах.

Цитата:

В любом случае это весьма несущественное неудобство.

Я с этим вполне согласен.

Цитата:

Есть архитектурные ограничения, которые мешают этому.

Я так и знал, что эти кросс-платформенные решения - вредный универсализм, пытающийся совместить несовместимое (Windows и Linux). Вот в чисто Win32-программе это делается элементарно.

Добавлено:
Tulon
Здесь и на форуме Натахаус собрались люди, которые своими руками сделали не один десяток DjVu-книг. Поверьте на слово - мы Вам плохого не посоветуем. И если 3 человека так категорично высказались против выскакивания маленького окошка при старте - значит, к этому коллективному мнению вполне можно прислушаться.

Я даже не поднимаю больше тему отсутствия скроллбаров при зуме и сглаживающего фильтра - хотя совершенно очевидно, что без этих вещей Ваша программа никогда даже и приблизиться не сможет к СК по нужности/полезности. Ну да чёрт с этим - пусть хоть делает более простые вещи - например, пакетный split-page (я это называю унификацией - концепция, увы начисто проигнорированная в СК) или пакетное обрезание (batch-crop) по прямоугольной рамке фиксированного размера (это исключительно нужнейшая задача - для обрезки журналов типа "Техника-Молодёжи" - до сих пор не решённая по-человечески). Или же вот задача: берём группу grayscale-сканов, проходим по ней, руками выделяем каждую grayscale-картинку в прямоугольную зону, и запускаем пакетную обработку - пороговая (хотя бы; но это не лучшее) бинаризация сканов + blurring (или опционально dithering - для эстетов, т.к. даёт лучше качество, но гигантский размер) выделенных в зоны картинок -> на выходе смесь: Tif Fax G4 для простых сканов и Tif LZW для содержащих размытые картинки - далее раздельное кодирование: Tif Fax G4 - через DjVu Small, Tif LZW - отдельно через DE Editor 6, а потом вставляем 2-ые в 1-ые. Эта задача даже пока не имеет названия - можно назвать как "бинаризация с селективной обработкой картинок" (напоминает "Метод разделённых сканов"). Blurring нужен как подсказка для documenttodjvu - "поместить картинку целиком в background, а не размазывать её по 3 DjVu-слоям (порождая при этом артефакты)".
Все эти 3 задачи делает СК - но там не слишком удобно.

Добавлено:
Я занёс ссылки на просмотрщики растровой графики под Windows с открытыми исходниками сюда: http://www.djvu-soft.narod.ru/bookscanlib/

Также нашёл и выложил кем-то скомпилированный экземпляр вьювера Cornice:

Portable Cornice v0.6.1

http://www.djvu-soft.narod.ru/bookscanlib/port_cornice_0_6_1.rar (3,84 МБ)

(Может, кто-то захочет его посмотреть - а на офф.сайте только его исходники и всё).

http://tifftool.sourceforge.net/ - интересно

Tulon

Цитата:

Ну а там и до вывода рукой подать.

Действительно, сделайте уже вывод Чтобы можно было протестировать хоть как-то по полному циклу.
Так и потенциальные пользователи подтянутся, наконец. Иначе топик может утонуть во флуде, как уже не раз бывало, увы...

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

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

Вывод я думаю закончить через неделю-полторы. Сейчас работаю над улучшением качества черно-белых результатов. Попробовал алгоритм kFill - медленный и не слишком эффективный. Сейчас буду пробовать чистку на основе hit-miss transform.

monday2000

Цитата:

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

Какая же тогда это автоматизация, если все руками придется делать?
ИМХО, лучше использовать концепцию слоев, а не зон. Автоматическое деление на слои например на основе морфологии вполне можно сделать. На всякий случай добавить инструмент типа "ластик/кисть" для ручной правки (переноса из одного слоя в другой), если будет неточная сегментация.

Tulon

Цитата:

Вывод я думаю закончить через неделю-полторы.

Не торопитесь слишком уж сильно - ничего, мы подождём.

Цитата:

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

Можно сделать Normal Despeckle - такой же, как в СК. Это ЧБ фильтр "по среднему": квадратное окошко 3 на 3 пикселя ("апертура") пробегает по всем пикселям, белые пиксели сразу пропускаем при проходе (от этого качество чуть снижается, зато скорость - радикально повышается), на каждом шаге находим среднее арифметическое и подставляем его в картинку. По краям - не помню, кажется, просто пропускаем. Именно так и работает Normal Despeckle в СК.
Fine Despeckle в СК - это, т.ск. "геометрический" Despeckle - там апертура пробегает и все пятнышки с размером меньше либо равным пороговому стирает.
U235

Цитата:

ИМХО, лучше использовать концепцию слоев, а не зон. Автоматическое деление на слои например на основе морфологии вполне можно сделать.

В этом я не разбираюсь. Может быть, так лучше. Просто понятно, что "ручной" вариант - наиболее точный.

Добавлено:
U235

Цитата:

Автоматическое деление на слои например на основе морфологии вполне можно сделать.

Сделайте, пожалуйста, это в виде хоть какой-то простейшей демо-программы со сканом-примером - а то на пальцах непонятно. Только - можно не на Матлабе? Попробуйте FreeImage (freeimage.sf.net) - с ней довольно просто работать, скажем, на СИ или на СИ++, и к ней есть прекрасная документация. Вот посмотрите, например - http://www.djvu-soft.narod.ru/bookscanlib/001.htm - ИМХО очень просто для понимания.

Добавлено:
http://alexrey036.narod.ru/graylayers.html - тут мало что понятно, т.к. Матлаб.

Цитата:

Можно сделать Normal Despeckle - такой же, как в СК. Это ЧБ фильтр "по среднему": квадратное окошко 3 на 3 пикселя ("апертура") пробегает по всем пикселям, белые пиксели сразу пропускаем при проходе (от этого качество чуть снижается, зато скорость - радикально повышается), на каждом шаге находим среднее арифметическое и подставляем его в картинку. По краям - не помню, кажется, просто пропускаем. Именно так и работает Normal Despeckle в СК.
Fine Despeckle в СК - это, т.ск. "геометрический" Despeckle - там апертура пробегает и все пятнышки с размером меньше либо равным пороговому стирает.

Мелкие пятна удалить - не проблема. Мне бы хотелось еще и удалять зазубрены на буквах. С однопиксельными зазубренами kFill нормально справляется, а для двух пиксельных буду пробовать hit-miss transform.


Цитата:

http://alexrey036.narod.ru/graylayers.html - тут мало что понятно, т.к. Матлаб.

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

Tulon

Цитата:

А FreeImage тут не подойдет - там вообще никакой морфологии нету.

А что подойдёт? Явно ведь не Матлаб - он же "вещь в себе". Т.е. не будут же книгосканировщики себе Матлаб ставить. А то, что там нет морфологии - надо искать этот алгоритм где-то на стороне и добавить его в FreeImage (не нравится FreeImage, можно взять другую графическую библиотеку).

Цитата:

А что подойдёт? Явно ведь не Матлаб - он же "вещь в себе".

leptonlib подошел бы. Тут еще проблема что не все знают C/C++. Так или иначе матлабовские скрипты там совсем небольшие, и разобратся в них без самого матлаба вполне реально.

Tulon

Цитата:

leptonlib подошел бы.

А где именно это там? Кстати, практический любой алгоритм оттуда можно "перебить" под FreeImage.

Цитата:

Так или иначе матлабовские скрипты там совсем небольшие, и разобратся в них без самого матлаба вполне реально.

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

Добавлено:

Цитата:

Мелкие пятна удалить - не проблема. Мне бы хотелось еще и удалять зазубрены на буквах.

Просто Normal Despeckle - исключительно быстрый алгоритм, и в этом ИМХО его главное достоинство (хотя это не настоящий Despeckle, а более загрублённый и более радикально-чистящий, чем настоящий, потому что настоящий не пропускает при проходе белые пиксели).

Добавлено:
U235
То есть я клоню к тому, что не могли бы Вы перенести свои матлабовские скрипты с Матлаба на какую-то более низкоуровневую библиотеку (например, leptonlib или какую-то другую) - чтобы этот материал стало возможно интегрировать в любительские программы?

Добавлено:
А доступны ли исходники вот этих высокоуровневых матлабовских функций? Если они есть, тогда всё гораздо проще.

Цитата:

Кстати, практический любой алгоритм оттуда можно "перебить" под FreeImage.

Можно-то можно, только никто этим заниматься не будет. Это далеко не пятиминутное дело.
Кстати есть надстройка над FreeImage - FreeImageAlgorithms: https://code.launchpad.net/~glennpierce/+junk/main
Там есть бинарная морфология. Серой нет.

Я на самом деле планирую реализовать алгоритм, предложенный U235, но он в итоге будет завязан на Qt и на мою библиотеку обработки изображений. Для этого мне придется cначала реализовать гауссово размывание и dilate, erode, seedfill в серой морфологии.

Tulon

Цитата:

...seedfill в серой морфологии

Есть в leptonlib.
monday2000

Цитата:

А доступны ли исходники вот этих высокоуровневых матлабовских функций?

Да, доступны, и лежат где-то на этом сайте: http://djvu-soft.narod.ru/

U235

Цитата:

лежат где-то на этом сайте

Я их вчера смотрел - http://www.djvu-soft.narod.ru/bookscanlib/mipt_u235.rar (235 КБ) - там нет всего, что нужно. Возьмём, например, функцию imdilate из http://alexrey036.narod.ru/graylayers.html - её исходников нет, и она даже и не упоминается в этом наборе исходников.

Хотя, в целом кое-какие сишные исходники там есть любопытные.
Tulon

Цитата:

Я на самом деле планирую реализовать алгоритм, предложенный U235, но он в итоге будет завязан на Qt и на мою библиотеку обработки изображений.

Можно узнать в 2 словах, какой там принцип действия?

monday2000

Цитата:

Я их вчера смотрел - там нет всего, что нужно.

Все там есть.

Цитата:

Возьмём, например, функцию imdilate её исходников нет.

В архиве есть m-функция imdilate, открываем ее в блокноте и видим что она в конечном итоге (после всех проверок аргументов) вызывает другую функцию: morphop(A,se,'dilate',mfilename,varargin{:})
эта функция есть в файле morphop.m из папки private, смотрим ее и видим, что она вызывает morphmex, это dll, там же ее исходники .h и .cpp и файлы dilate_erode_gray_flat.cpp

U235
Здорово. Видимо, именно так был сделан pagetools.sf.net (наверно).

У меня возникла идея по поводу обработки сканов с картинками: предположим, Tulon сделает вариант (то ли ручной, то ли автоматический по способу U235) бинаризации серых сканов с селективным размытием картинок. Тогда, скажем, ST мог бы выдавать на выходе 2 папки: одна - с ч.б.бинаризованными сканами, а 2-я - с grayscale-сканами, содержащими картинки. Тогда можно было бы так модифицировать, допустим, DjVu Small, чтобы он сначала скопом кодировал все готовые ЧБ сканы в один многостраничный DjVu, затем кодировал бы по одному grayscale-сканы, содержащие картинки, и далее автоматом вставлял бы "DjVu-сканы с картинками" в нужные места в полученном многостраничном ЧБ DjVu-файле (посредством djvused). "DjVu-сканы с картинками" можно перед вставкой просматривать - насколько хорошо они получились.

Т.е. можно автоматизировать закодирование в DjVu смесь разнородных по глубине цвета TIF-файлов - это не так сложно чисто технически. Насколько я помню, это умеет делать JRA Publish (т.е. кодировать такую разнородную смесь), чем Джим Райли особенно гордился.

Чем выводить по две версии каждого файла, проще выводить в черно-белом файлы где нет картинок, и в сером / цветном - где есть. После чего научить DjVu Small или какой другой кодировщик выставлять оптимальный режим для каждого типа файлов. Я вообще удивлен, что они такого до сих пор не умеют.