Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Компьютеры » Программы » Scan Tailor

Модерирует : gyra, Maz

Widok (17-02-2010 12:17): Лимит страниц. Продолжаем здесь.  Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107

   

Tulon

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Scan Tailor

 
Скриншот:

В разработке находится новая альтернатива СканКромсатору. Разработчик - ваш покорный слуга.
Задача программы - пост-обработка сырых сканов с целью их последующей сборки в PDF или DJVU.
 
Уже есть на что посмотреть, и возможно присоединиться к проекту. Проект с открытыми исходниками и кросс-платформенный (Windows + Linux).
 
По сравнению со СканКромсатором планируется большее удобство использования, большая интерактивность, но при этом не меньшая автоматизация процесса.
 
Сайт проекта: http://scantailor.sf.net     Скриншоты
 
Топик программы на форуме Натахаус       Англоязычный топик по ScanTailor

Документация
 
Документация (Wiki)              Зоны картинок в ScanTailor
 
Статья: Scan Tailor. Программа для обработки отсканированных книг
 
Видеоурок: Создание DjVu с помощью Scan Tailor (зеркало)
 
Методика использования STA совместно с Djvu Imager

Дистрибутивы
 
Версия СТ с функцией выпрямления искривленных строк (dewarp от Rob)
 
Патч от anagnost96 Вариант ScanTailor с этим патчем (STA)  Зеркало
 
ScanTailor для Mac
 
Последние изменения в дереве исходников - для сильно любопытных и владеющих английским.
Там же можно подписаться на rss/atom - для нетерпеливых.
 

Дополнительно
 
ST GreyText v1.0 Программа для генерации вывода как бы "Только текст (в режиме серого)" - для Scan Tailor от anagnost96.
 
LayerTailor Программа для разделения сканов (после "Смешанный режим) на foreground и background слои с целью последующего раздельного кодирования в djvu. Принцип работы: Все черные пиксели (яркость==0) переносятся в foreground, остальное - в background. Функция layer принимает на входе 3 параметра: исходное имя файла TIFF, имя файла для foreground и имя файла background. Автор: U235.
 
Предложения к anagnost96 по поводу улучшения его модификации СТ
Сравнение выпрямления искривленных строк в СТ и в BR

Статья О возможности альтернативы СканКромсатору     Полезные ссылки по теме топика
ArtScan - ещё одна программа для сканобработки.

Всего записей: 718 | Зарегистр. 07-05-2008 | Отправлено: 21:37 15-06-2008 | Исправлено: ndch, 22:37 12-02-2010
usrnd

Newbie
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
rev 262
при попытке создать проект содержащий
 
http://rapidshare.com/files/194256240/diff2.rar.html
 
ПРОГРАММА ЗАКРЫВАЕТСЯ
bug.

Всего записей: 8 | Зарегистр. 09-01-2008 | Отправлено: 23:42 05-02-2009
Tulon

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
denver 22

Цитата:
2-й раз мне такое говорят. А как вообще это проверяется? И какие признаки (чтобы заподозрить неладное)?  

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

Цитата:
Ну уж на моих примерах выше наверное не DPI сказался на качестве очистки.

Deskpeckling - самая чувствительная операция по отношению к DPI.  Так что неправильный DPI всегда сказывается на качестве deskpecling.
 

Цитата:
Теперь в CMake сразу нажимаю Configure, потом OK. Правильно? По идее все компилится. Только вот сейчас делаю новую сборку, и на п.9 после 9% сразу 22% стало. Вот и засомневался... уже и 30% - 35%. Так может быть?  

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

Цитата:
Вы на нас все методы будете испытывать? Или я неправильно понял?

Это реализация того, о чем я говорил выше.  Теперь учитывается и тот же класс символов.  Кстати с тех пор я еще изменений внес.  Теперь вот хочу сделать чтобы предельное расстояние до соседей зависило от точного размера объекта - а не только от его класса.  Тот метод, что у меня реализован, такое позволяет.
 
Добавлено:

Цитата:
rev 262
при попытке создать проект содержащий
 
http://rapidshare.com/files/194256240/diff2.rar.html
 
ПРОГРАММА ЗАКРЫВАЕТСЯ
bug.

А у меня зависала.  Баг исправлен в Rev 263, а последняя на данный момент - 264.

Всего записей: 718 | Зарегистр. 07-05-2008 | Отправлено: 23:59 05-02-2009
denver 22

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
собираются только те вещи, которые изменились, а также те, которые от них зависят.  

Да, сборки теперь собираются ещё быстрее.
Новая сборка (Rev.264) в шапке.

Всего записей: 602 | Зарегистр. 28-07-2005 | Отправлено: 00:21 06-02-2009
Tulon

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Да, сборки теперь собираются ещё быстрее.
Новая сборка (Rev.264) в шапке.

А на многоядерных машинах можно давать mingw32-make опцию -j2 (или сколько там у вас ядер) - будет еще быстрее собираться.

Всего записей: 718 | Зарегистр. 07-05-2008 | Отправлено: 00:31 06-02-2009
usrnd

Newbie
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
А у меня зависала.  Баг исправлен в Rev 263, а последняя на данный момент - 264.

А что было, если не секрет ?
 
Добавлено:
Теперь другая беда.
вылетает на куче разных сканов, если указать в опциях вывода
 
+цветной-серый
+белые поля

Всего записей: 8 | Зарегистр. 09-01-2008 | Отправлено: 00:41 06-02-2009
Tulon

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Возвращаясь к своей идее сделать предел расстояния до соседних объектов зависимым от точного размера рассматриваемого объекта, а не только от его класса.  Сделать это элементарно, только не знаю, какую функцию выбрать.
Первое, что пришло в голову:
предельное_расстояние = корень(количество_пикселей)
Результат - недостаточная чистка.
У кого какие идеи на этот счет?
 
Добавлено:
usrnd

Цитата:
А что было, если не секрет ?  

TIFF в оттенках серого, c количеством битов на пиксель, отличным от 8.  Такие мне раньше не попадались.  Код для такого случая был, но никогда не тестировался - не на чем было.  Отсюда и баг.
 

Цитата:
Теперь другая беда.
вылетает на куче разных сканов, если указать в опциях вывода
 
+цветной-серый
+белые поля  

Опа - точно.  Это я исправив один баг, внес другой.  Сейчас поправлю.

Всего записей: 718 | Зарегистр. 07-05-2008 | Отправлено: 00:53 06-02-2009
usrnd

Newbie
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Созданю проект
 
в имени директории имеются пробелы > путь заключается в кавычки
("C:\SCAN\scantailor-0.9.1 Rev.264 denver-install.exe\x\TEST")
сабж не понимает такое.
 
И очень хочется (там же) автопроверки изменения содержимого "input directory"
(чтоб не надо было нажимать browse-ok)
 
Будте так любезны, поправьте !
Понимаю-не первоочередное, но очень хочется.
 
Добавлено:
исходник
tiff +lzw
(24 BitsPerPixel)
 
Потребность 24Bits обусловлена наличаем в страницах кроме b-w (1bit) литер,  
линий важных цветов
 
 
Добавлено:
извиняюсь, бага воспроизводится и с  8bit-color
 
http://rapidshare.com/files/194433745/256-.rar.html
 
Добавлено:

Цитата:
Опа - точно.  Это я исправив один баг, внес другой.  Сейчас поправлю.

не, оно и до этого было

Всего записей: 8 | Зарегистр. 09-01-2008 | Отправлено: 00:59 06-02-2009
Tulon

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
usrnd

Цитата:
Созданю проект
 
в имени директории имеются пробелы > путь заключается в кавычки
("C:\SCAN\scantailor-0.9.1 Rev.264 denver-install.exe\x\TEST")
сабж не понимает такое.  

А у меня кавычки не появились.  И странный какой-то путь - как бы внуть exe файла.
У кого-нибудь еще это воспроизводится?
 

Цитата:
И очень хочется (там же) автопроверки изменения содержимого "input directory"
(чтоб не надо было нажимать browse-ok)  

Не уверен, что в Qt есть такой функционал, но даже если есть - это низкоприоритетная задача.
 

Цитата:
извиняюсь, бага воспроизводится и с  8bit-color
 
http://rapidshare.com/files/194433745/256-.rar.html

С последней версией нормально грузится.
 

Цитата:
Цитата:
Опа - точно.  Это я исправив один баг, внес другой.  Сейчас поправлю.
 
не, оно и до этого было

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

Всего записей: 718 | Зарегистр. 07-05-2008 | Отправлено: 01:39 06-02-2009
usrnd

Newbie
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
А у меня кавычки не появились. И странный какой-то путь - как бы внуть exe файла.  
У кого-нибудь еще это воспроизводится?

из фара путь копирую.
у меня уже вошло в привычку, :
например mkdir "c:\try to scan"
 
наверное неправильно сформулировал
если при создании проекта указать директорию, заключенную в кавычки, то ерунда получается: открывается диалоговое окошко "обзор папок" и в нём выбирается %USERPROFILE% а вовсе не "c:\try to scan"
 

Цитата:
С последней версией нормально грузится.

где - как брать новую версию,  инструкцию по сборке?
 

Всего записей: 8 | Зарегистр. 09-01-2008 | Отправлено: 01:50 06-02-2009
Tulon

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
наверное неправильно сформулировал
если при создании проекта указать директорию, заключенную в кавычки, то ерунда получается: открывается диалоговое окошко "обзор папок" и в нём выбирается %USERPROFILE% а вовсе не "c:\try to scan"  

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

Цитата:
где - как брать новую версию,  инструкцию по сборке?  

Поищите в этом топике упомянания SVN, TortoiseSVN, trunk.  В общем вам нужен SVN клиент и SVN URL.  И то и другое давалось в этом топике.  Ну скачав исходники из SVN, находите инструкцию в файле packaging/windows/readme.ru.txt - и следуете ей.
 
Добавлено:
Отвечаю на свой же пост.

Цитата:
предельное_расстояние = корень(количество_пикселей)
Результат - недостаточная чистка.  

Недостаточная чистка - из-за бага.  Пофиксил баг, и получил весьма неплохие результаты с формулой:
предельное_расстояние = 2*корень(количество_пикселей)
Этот код уже в SVN (Rev 267)
 
Прелесть этого метода в том, что он не зависит от DPI.  Впрочем разделять на классы все равно приходится, и разделение таки зависит от DPI.  А разделять приходится потому, что скажем если между двумя крупными объектами есть один или несколько мелких, которые не должны по идее мешать удалению более крупных, то из-за них на диаграмме Вороного эти два крупных объекта не будут соединены - а они как раз должны мешать удалению друг друга.

Всего записей: 718 | Зарегистр. 07-05-2008 | Отправлено: 02:04 06-02-2009 | Исправлено: Tulon, 02:05 06-02-2009
denver 22

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Прелесть этого метода в том, что он не зависит от DPI.  Впрочем разделять на классы все равно приходится, и разделение таки зависит от DPI.

Что означает сея фраза? Что при 300 и 600 dpi будет разное качество очистки?
Новая сборка (Rev.267) в шапке.

Всего записей: 602 | Зарегистр. 28-07-2005 | Отправлено: 06:26 06-02-2009
Arcand

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
denver 22
Цитата:
2-й раз мне такое говорят. А как вообще это проверяется? И какие признаки (чтобы заподозрить неладное)?
Дпи прописывается (не во всех форматах), чтобы перевести пиксельный размер изображения в линейный. В Ирфане несложно изменить дпи (в пакетном режиме тоже). Некоторые проги всегда прописывают при сохранении свое дпи, например, стандартный виндовый Paint 120.
Сканы 300 дпи стандартного формата (А5) имеют пиксельный размер около 1500х2400. Если размеры скана (по виду стандартного формата) заметно отличаются от этих значений, значит у них другое дпи. Чтобы прикинуть реальное дпи я смотрю сколько пикселей приходится на 7 строк - это и есть дпи. Это правило опытное. При печати в один интервал на дюйм приходится строго 6 строк. В книгах плотность выше - на дюйм приходится около 7 строк.

Всего записей: 2493 | Зарегистр. 28-05-2004 | Отправлено: 06:42 06-02-2009
monday2000

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Tulon
Я почитал документацию - http://scantailor.wiki.sourceforge.net/
Оформлена весьма прилично - даже со скриншотами. Радует то, что теперь в отношении хелпа Вы превзошли bolega по всем статьям. Очень хорошо.
Теперь по существу: как-то неожиданно воспринимается следующая фраза:

Цитата:
поскольку в отличии от конвейера на заводе, где "сначала все изделия проходят одну стадию, потом следующую", в Scan Tailor "сначала одно изделие проходит все стадии, потом следующее".

Довольно непривычно. И, строго говоря, это не конвейер - потому что, как Вы правильно заметили, краеугольный принцип конвейера именно в том и состоит, что "сначала все изделия проходят одну стадию, потом следующую". Я не просто так умничаю - дело в том, что это и есть главный секрет высокой производительности конвейера. Иначе бы на всех заводах делали бы, как Вы - "сначала одно изделие проходит все стадии, потом следующее". Наверняка существует даже какое-нибудь теоретико-научное обоснование, почему "сначала все изделия проходят одну стадию, потом следующую" гораздо производительнее и удобнее во всех смыслах, чем "сначала одно изделие проходит все стадии, потом следующее".
Но даже и чисто в житейском смысле - гораздо удобнее делать многократно одну и ту же манипуляцию - по ходу дела сам подстраиваешься под неё.
 
Далее:
 
Меня сильно смущает Ваш подход - "сначала полный цикл обработки, и только потом вывод". А что, если мне нужно, например, просто разрезать сдвоенные развороты пополам - и я больше ничего не хочу делать со сканами? Не секрет, что многие горе-книгоделы именно так и поступят - всегда в будущем - как бы мы ни упрощали последующую (после разрезки) интеллектуальную обрезку а-ля СК-Draft Kromsate - Process!.
 
PS Всё же меня лично радует такой неплохой прогресс в отношении Вашей программы. Надеюсь, в дальнейшем Вам удастся преодолеть все возникающие трудности и довести программу до ума.

Всего записей: 2841 | Зарегистр. 13-01-2005 | Отправлено: 09:29 06-02-2009
Tulon

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
denver 22

Цитата:
Цитата:
Прелесть этого метода в том, что он не зависит от DPI.  Впрочем разделять на классы все равно приходится, и разделение таки зависит от DPI.
 
Что означает сея фраза? Что при 300 и 600 dpi будет разное качество очистки?  

Это означает, что такой метод более толерантен к неправильному DPI.  В прочем зависимость от DPI все равно осталась при классификации объектов по размерам.
 
Arcand

Цитата:
Некоторые проги всегда прописывают при сохранении свое дпи, например, стандартный виндовый Paint 120.  

Скорее всего эти 120 DPI - разрешение монитора.
А насчет семи строк - полезный совет.  Надо будет делать соответствующий инструмент для СТ, но это уже после редактирования списка файлов проекта.
 
monday2000

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

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

Цитата:
Меня сильно смущает Ваш подход - "сначала полный цикл обработки, и только потом вывод". А что, если мне нужно, например, просто разрезать сдвоенные развороты пополам - и я больше ничего не хочу делать со сканами? Не секрет, что многие горе-книгоделы именно так и поступят - всегда в будущем - как бы мы ни упрощали последующую (после разрезки) интеллектуальную обрезку а-ля СК-Draft Kromsate - Process!.

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

Всего записей: 718 | Зарегистр. 07-05-2008 | Отправлено: 12:44 06-02-2009 | Исправлено: Tulon, 12:52 06-02-2009
Admig314

Newbie
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Несколько наблюдений.
 
Во-первых с последними билдами вылетов больше на моих сканах не наблюдалось. Ура!
Субъективно все стадии обработки вплоть до вывода производятся заметно быстрее.
Последняя, преобразование в BW и собственно вывод - очень долго. Оно и понятно, разрешение все-таки 1200. Качество результата просто отличное!
Однако визуально картинка кажется несколько жирноватой, контуры букв утолщенные против желаемого. Дело здесь, думается, в том, что когда электронный макет печатается в типографии, краска в зависимости от сорта бумаги слегка расплывается. Если теперь результат отсканировать, обработать "by ST" и снова напечатать, ужирнение будет еще больше.
Не знаю, насколько это вписывается в планы, но мне, как просто пользователю, хотелось бы видеть более тонкий результат. Или, может быть, интерактивный контроль "степени жирности" - регулировку порога при преобразовании в BW.
Для сравнение выкладываю две обработки одной и той же страницы. Одна в ST, другая ручная в фотошопе: Remove Noise (NeatImage) - Smart Blur - Curves - Convert to BW (50%).
Обратите, например, внимание на слившийся перенос в 17-й строке снизу.
ScanTailor
Photoshop
 
Далее, на последней стадии обработки очень сильно тормозятся вообще все остальные процессы на компе. Параллельная работа становится практически невозможной. Понятно, что идет интенсивная математика, но с другой стороны тот же фотошоп не самая легкая прога, и даже если обработка в нем идет долго, то работу других процессов это не настолько сильно тормозит. Возможно ли ожидать какой-либо подвижки в этом направлении?
 
И еще. В корне диска C: при успешном завершении проекта регулярно создается пустая папка cache, при том что проекты у меня находятся на другом диске.
 
Добавлено:
И кстати, в приведенном скане после обработки ST Rev.267 пропали многоточия - например 21, 22, 23 строки снизу

Всего записей: 17 | Зарегистр. 19-12-2005 | Отправлено: 15:28 06-02-2009
Tulon

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Admig314

Цитата:
Последняя, преобразование в BW и собственно вывод - очень долго. Оно и понятно, разрешение все-таки 1200. Качество результата просто отличное!  

Сейчас при увеличении разрешения вывода в два раза, производительность падает аж в 16 раз!  Просто ужас.  А все из-за того, что я когда-то подобрал идеальные параметры для полиномиального фильтра (тот самый Savitzky-Golay) для 300 DPI, а для более высоких разрешений просто увеличиваю размер окна фильтрации.  А ведь можно вместо увеличения размера окна понижать степень полинома, а можно и то и другое сразу.  В общем я сейчас как раз занимаюсь подбором хороших параметров для разных разрешений, чтобы размер окна держать в разумных пределах.
Также пробовал для поднятия производительности генерировать код, заточенный под конткретные размеры окна и под конкретный процессор прямо во время выполнения программы (с помощью LLVM).  Получил ускорение в четыре раза, в независимости от разрешения.  Но архитектура этого LLVM показалась мне настолько убогой, что желание его использовать быстро пропало.
Кому сильно интересны мои претензии (а поймут это только программисты, да и то далеко не все), вот:
1. Почему ExecutionEngine может быть только в одном экземпляре?  Разработчики утверждают, что ради производительности.  А я, как Станиславский скажу "НЕ ВЕРЮ!".
2. Ладно, допустим поверил.  Тогда почему он не Singleton а обычный класс?
3. А почему он не делает межпотоковую синхронизацию, а вместо этого просто выставляет свой мьютекс в публичный доступ?  Надо полагать тоже ради производительности?
4. Не люблю фабричные методы, которые возвращают мне объекты по указателю.  Люблю чтобы по умному указателю, пусть даже по auto_ptr.  А то совершенно непонятно, кто владеет этим объектом и кто должен его удалять.
В общем такой многообещающий проект, но такая говеная архитектура.
 

Цитата:
Однако визуально картинка кажется несколько жирноватой, контуры букв утолщенные против желаемого. Дело здесь, думается, в том, что когда электронный макет печатается в типографии, краска в зависимости от сорта бумаги слегка расплывается. Если теперь результат отсканировать, обработать "by ST" и снова напечатать, ужирнение будет еще больше.  

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

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

Регулировка порога есть в планах, но в отдаленных.
 

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

Да, тут на одном только despeckle потребляется 12 байт на пиксель + еще черыре байта на одном из его этапов.  Итого имеем: картинки 10000 на 14000 пикселей,   Выходит 10*14*10^6*16 = больше двух гигабайт.  Ого - сам не ожидал такого.
 

Цитата:
И еще. В корне диска C: при успешном завершении проекта регулярно создается пустая папка cache, при том что проекты у меня находятся на другом диске.

Это интересно.  У кого-нибудь еще такое наблюдается?

Всего записей: 718 | Зарегистр. 07-05-2008 | Отправлено: 16:17 06-02-2009
Tulon

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Создание папки C:\cache исправил - она создавалась при закрытии проекта.
 
Deskpeckle сделаю опцию отключить.  Можно было бы сделать ползунок уровня deskpeckle, но в таком случае потом будет проблематично изменить алгорим - может измениться смысл этого ползунка.  А в будущем можно даже специально защитить круглые объекты (точки) от удаления.
 
Уменьшить потребление памяти при deskpeckle в принципе можно (обрабатывать изображение частями), но это не так то просто сделать.  Отложу это на потом.

Всего записей: 718 | Зарегистр. 07-05-2008 | Отправлено: 20:35 06-02-2009
denver 22

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Однако визуально картинка кажется несколько жирноватой, контуры букв утолщенные против желаемого.

Я давно заметил, что ST утолщает буквы. Но по сравнению с остальными проблемами, на этой внимание не акцентировал. Теперь поддержу: +1. Хотелось бы, чтобы толщина букв оставалась как на оригинале.

Всего записей: 602 | Зарегистр. 28-07-2005 | Отправлено: 21:59 06-02-2009
savage2000

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Olive77

Цитата:
Если намек не был понят, то дверьку я уже указывал.
Спасибо за дверку!
 
monday2000 Ответ в твоем персональном топике.

Всего записей: 102 | Зарегистр. 07-12-2002 | Отправлено: 11:11 07-02-2009 | Исправлено: savage2000, 11:11 07-02-2009
denver 22

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Ребята, давайте возьмем пример Tulon - побольше медитации. Просто не обращайте внимание на этого человека. По себе скажу, мне намного легче стало. Пусть живет в своём мирке. Он ведь все равно не успокоится, а тема засоряется припираниями. Забейте на него 100%-ный ИГНОР и все станет намного проще.
Лучше мы поможет Tulon-у в тестировании и развитии программы. Вместе с этим поможем и себе, получив прекрасную программу сканобработки.

Всего записей: 602 | Зарегистр. 28-07-2005 | Отправлено: 12:02 07-02-2009
   

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107

Компьютерный форум Ru.Board » Компьютеры » Программы » Scan Tailor
Widok (17-02-2010 12:17): Лимит страниц. Продолжаем здесь.


Реклама на форуме Ru.Board.

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.B0ard
© Ru.B0ard 2000-2024

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru