» Scan Tailor
Цитата:
Диапазон значений прописан прямо в UI файле: filters/output/ui/OutputOptionsWidget.ui
Спасибо, действительно всё просто. А ведь и правда, доступный диапазон, с одной стороны, недостаточен, а с другой -- шаг в единицу слишком мал, чтобы можно было почувствовать разницу. Практически я до сих пор использовал только три настройки порога бинаризации: минимум, максимум и по умолчанию. Может, имело бы смысл либо расширить диапазон (я сейчас сделал maximum 36, minimum -36, pageStep 12, singleStep 3), либо оставить как есть, но умножать полученное значение на некий коэффициент?
anagnost96
Такие предложения нужно подкреплять конкретными примерами. Оригинал + порог = результат.
Такие предложения нужно подкреплять конкретными примерами. Оригинал + порог = результат.
Цитата:
Такие предложения нужно подкреплять конкретными примерами
Хорошо. Выложил одну страничку вот здесь:
http://www.thessalonica.org.ru/downloads/pgb_040.tif
Что мы имеем в данном случае: с одной стороны -- довольно мелкий контрастный шрифт на глянцевой бумаге, с другой -- вполне качественный скан на 400 dpi. Нетрудно убедиться, что для правильной обработки порог бинаризации должен быть очень высоким: практически все небелые участки можно смело считать черными. 36 дает приемлемый результат, на 15 уже идут сплошные разрывы в контурах букв.
Tulon
Я говорю только за Linux. На Windows желательно, чтобы кто-нибудь другой собрал и проверил.
Цитата:
Нет, в Linux не совсем так мрачно. Там просто нет понятия "процесс", как "пучок" нитей. Все нити программы рассматриваются планировщиком совершенно отдельно. И когда я меняю приоритет (nice уровень) нити WorkerThread (из её функции run), основная нить оказывается совершенно незатронутой. Она как работала, так и работает.
В результате, когда запущен один Scantailor с обработкой единственной книги, в программе top, отображается 4 или 5 скантейлоров. И только один из этих "процессов" имеет пониженный приоритет - это пакетная обработка.
А нить интерфейса работает всегда с нормальным приоритетом!
Цитата:
Я ни в коем случае не хочу ставить IDLE на основную нить ST. Приоритет IDLE, если его ставить ТОЛЬКО на нить пакетной обработки, на мой взгляд - наилучший. Другие приоритеты нужны только в специфических случаях, когда есть другая времяёмкая задача. Обычно, с IDLE на WorkerThread получается очень отзывчивая система, отзывчивый интерфейс ST, причём несмотря на это обработка жрёт всё процессорное время!
Цитата:
Большое спасибо за совет. Посмотрю.
Цитата:
Это бы очень не хотелось. Мой идеал - это приоритет IDLE на пакетную обработку и нормальный приоритет на интерфейс и все связанные с ним нити (прорисовка, анимация и т.д.).
А сейчас у вас разве под пакетную обработку не выделена отдельная нить?
Цитата:
Я, к сожалению, не очень понимаю, куда это вставить. В BackgroundTask?
Я говорю только за Linux. На Windows желательно, чтобы кто-нибудь другой собрал и проверил.
Цитата:
Поскольку под Linux приходится менять приоритет всего процесса
Нет, в Linux не совсем так мрачно. Там просто нет понятия "процесс", как "пучок" нитей. Все нити программы рассматриваются планировщиком совершенно отдельно. И когда я меняю приоритет (nice уровень) нити WorkerThread (из её функции run), основная нить оказывается совершенно незатронутой. Она как работала, так и работает.
В результате, когда запущен один Scantailor с обработкой единственной книги, в программе top, отображается 4 или 5 скантейлоров. И только один из этих "процессов" имеет пониженный приоритет - это пакетная обработка.
А нить интерфейса работает всегда с нормальным приоритетом!
Цитата:
Приоритет IDLE я бы вообше исключил - он слишком опасный. При выставлении такого приоритета ST просто зависнет, если кто-то еще грузит проц.
Я ни в коем случае не хочу ставить IDLE на основную нить ST. Приоритет IDLE, если его ставить ТОЛЬКО на нить пакетной обработки, на мой взгляд - наилучший. Другие приоритеты нужны только в специфических случаях, когда есть другая времяёмкая задача. Обычно, с IDLE на WorkerThread получается очень отзывчивая система, отзывчивый интерфейс ST, причём несмотря на это обработка жрёт всё процессорное время!
Цитата:
Я бы предпочел менять приоритет не через настройки, а прямо из режима пакетной обработки. Там уже есть чекбокс "звуковой сигнал по окончании", и вполне можно рядом с ним поставить выпадающий список с приоритетами.
Большое спасибо за совет. Посмотрю.
Цитата:
Беспокоит меня правда один момент - технически приоритет будет влиять не только на пакетную, но и на обычную обработку (это когда анимация посреди экрана)
Это бы очень не хотелось. Мой идеал - это приоритет IDLE на пакетную обработку и нормальный приоритет на интерфейс и все связанные с ним нити (прорисовка, анимация и т.д.).
А сейчас у вас разве под пакетную обработку не выделена отдельная нить?
Цитата:
В принципе не так сложно сделать, чтобы приоритет влиял только на пакетные задачи - нужно чтобы сама задача несла информацию о приоритете.
Я, к сожалению, не очень понимаю, куда это вставить. В BackgroundTask?
vkni
Цитата:
По моему все как раз мрачно. Планировщик может быть и рассматривает потоки отдельно (не в контексте процесса), что нам даже на руку, но при этом не существует способа задать приоритет для конкретного потока. По крайней мере в мане по setpriority(), который вы используете, нет ни слова о том, что он влияет только на текущий поток, а не на весь процесс.
Цитата:
А вот этого не должно происходить. Так было до NPTL, но сейчас должен отображаться только один процесс. Скриншот в студию, pls.
Цитата:
Тут важно не путать фоновую обработку с пакетной. Этот поток занимается исключительно обработкой изображений, но при этом для него нет разницы, пакетная это обработка, или же вы вручную перешли на другую страницу.
Цитата:
Да, туда. Таким образом в том месте, где создается BackgroundTask, можно будет указать, с каким приоритетом данное задание должно запускаться. А создаются они в MainWindow, который знает, пакетная это обработка или просто фоновая.
Цитата:
Нет, в Linux не совсем так мрачно. Там просто нет понятия "процесс", как "пучок" нитей. Все нити программы рассматриваются планировщиком совершенно отдельно. И когда я меняю приоритет (nice уровень) нити WorkerThread (из её функции run), основная нить оказывается совершенно незатронутой. Она как работала, так и работает.
По моему все как раз мрачно. Планировщик может быть и рассматривает потоки отдельно (не в контексте процесса), что нам даже на руку, но при этом не существует способа задать приоритет для конкретного потока. По крайней мере в мане по setpriority(), который вы используете, нет ни слова о том, что он влияет только на текущий поток, а не на весь процесс.
Цитата:
В результате, когда запущен один Scantailor с обработкой единственной книги, в программе top, отображается 4 или 5 скантейлоров. И только один из этих "процессов" имеет пониженный приоритет - это пакетная обработка.
А вот этого не должно происходить. Так было до NPTL, но сейчас должен отображаться только один процесс. Скриншот в студию, pls.
Цитата:
А сейчас у вас разве под пакетную обработку не выделена отдельная нить?
Тут важно не путать фоновую обработку с пакетной. Этот поток занимается исключительно обработкой изображений, но при этом для него нет разницы, пакетная это обработка, или же вы вручную перешли на другую страницу.
Цитата:
куда это вставить. В BackgroundTask?
Да, туда. Таким образом в том месте, где создается BackgroundTask, можно будет указать, с каким приоритетом данное задание должно запускаться. А создаются они в MainWindow, который знает, пакетная это обработка или просто фоновая.
Tulon
Цитата:
Вот что кажет top до запуска пакетной обработки:
666 vkni 20 0 3968 1612 1260 S 0.0 0.3 0:00.11 bash
708 vkni 20 0 122M 48M 16M S 0.0 9.7 0:02.74 scantailor
732 vkni 39 19 122M 48M 16M S 0.0 9.7 0:00.98 scantailor
733 vkni 20 0 122M 48M 16M S 0.0 9.7 0:00.02 scantailor
736 vkni 20 0 122M 48M 16M S 0.0 9.7 0:00.50 scantailor
20023 vkni 20 0 3300 520 432 S 0.0 0.1 0:00.00 dbus-launch
20024 vkni 20 0 2276 796 724 S 0.0 0.2 0:00.01 dbus-daemon
24277 vkni 20 0 3112 180 176 S 0.0 0.0 0:00.00 ssh-agent
Вот - во время пакетной обработки (Макет страницы):
708 vkni 20 0 107M 34M 17M R 54.4 6.8 0:11.64 scantailor
732 vkni 39 19 107M 34M 17M S 21.9 6.8 0:12.44 scantailor
666 vkni 20 0 3968 1612 1260 S 0.0 0.3 0:00.11 bash
733 vkni 20 0 107M 34M 17M S 0.0 6.8 0:00.02 scantailor
736 vkni 20 0 107M 34M 17M S 0.0 6.8 0:00.50 scantailor
20023 vkni 20 0 3300 520 432 S 0.0 0.1 0:00.00 dbus-launch
20024 vkni 20 0 2276 796 724 S 0.0 0.2 0:00.01 dbus-daemon
24277 vkni 20 0 3112 180 176 S 0.0 0.0 0:00.00 ssh-agent
---------------------
Приоритет WorkerThread - IDLE.
И
[vkni@altair ~]$ getconf GNU_LIBPTHREAD_VERSION
NPTL 2.10.1
---------------------
В общем, спасибо за замечания, буду посмотреть дальше. Гляну в течение пары дней на последний OpenSuse.
Добавлено:
Tulon
Всё, извиняюсь. Похоже это top меня дурит. В ps Скантейлоровский процесс ровно один - с PID = 708. Т.е. 732, 733 и 736-ой - мнимые, добавляемые top'ом (на самом деле, нити). Т.е. 733 - это не PID, а SPID.
Тем не менее, NPTL, как я нарыл, позволяет задавать приоритет нитям по-отдельности, игнорируя POSIX'овскую дурь по-поводу одного приоритета. Это, как утверждается, единственное место, где NPTL отличается от POSIX:
http://www.clearfoundation.com/docs/man/index.php?s=7&n=pthreads
Узнать идентификатор нити можно вызвав gettid() <=> get Thread ID.
Ну и top показывает, что nice уровень изменился только для одной нити, которая производит пакетную обработку (я делал снимок переключившись на ST и обратно, поэтому на нём основная кушает больше процессорного времени, перерисовывая окно ST).
Замечания учту и ещё по-разбираюсь с этим.
Цитата:
А вот этого не должно происходить. Так было до NPTL, но сейчас должен отображаться только один процесс. Скриншот в студию, pls.
Вот что кажет top до запуска пакетной обработки:
666 vkni 20 0 3968 1612 1260 S 0.0 0.3 0:00.11 bash
708 vkni 20 0 122M 48M 16M S 0.0 9.7 0:02.74 scantailor
732 vkni 39 19 122M 48M 16M S 0.0 9.7 0:00.98 scantailor
733 vkni 20 0 122M 48M 16M S 0.0 9.7 0:00.02 scantailor
736 vkni 20 0 122M 48M 16M S 0.0 9.7 0:00.50 scantailor
20023 vkni 20 0 3300 520 432 S 0.0 0.1 0:00.00 dbus-launch
20024 vkni 20 0 2276 796 724 S 0.0 0.2 0:00.01 dbus-daemon
24277 vkni 20 0 3112 180 176 S 0.0 0.0 0:00.00 ssh-agent
Вот - во время пакетной обработки (Макет страницы):
708 vkni 20 0 107M 34M 17M R 54.4 6.8 0:11.64 scantailor
732 vkni 39 19 107M 34M 17M S 21.9 6.8 0:12.44 scantailor
666 vkni 20 0 3968 1612 1260 S 0.0 0.3 0:00.11 bash
733 vkni 20 0 107M 34M 17M S 0.0 6.8 0:00.02 scantailor
736 vkni 20 0 107M 34M 17M S 0.0 6.8 0:00.50 scantailor
20023 vkni 20 0 3300 520 432 S 0.0 0.1 0:00.00 dbus-launch
20024 vkni 20 0 2276 796 724 S 0.0 0.2 0:00.01 dbus-daemon
24277 vkni 20 0 3112 180 176 S 0.0 0.0 0:00.00 ssh-agent
---------------------
Приоритет WorkerThread - IDLE.
И
[vkni@altair ~]$ getconf GNU_LIBPTHREAD_VERSION
NPTL 2.10.1
---------------------
В общем, спасибо за замечания, буду посмотреть дальше. Гляну в течение пары дней на последний OpenSuse.
Добавлено:
Tulon
Всё, извиняюсь. Похоже это top меня дурит. В ps Скантейлоровский процесс ровно один - с PID = 708. Т.е. 732, 733 и 736-ой - мнимые, добавляемые top'ом (на самом деле, нити). Т.е. 733 - это не PID, а SPID.
Тем не менее, NPTL, как я нарыл, позволяет задавать приоритет нитям по-отдельности, игнорируя POSIX'овскую дурь по-поводу одного приоритета. Это, как утверждается, единственное место, где NPTL отличается от POSIX:
http://www.clearfoundation.com/docs/man/index.php?s=7&n=pthreads
Узнать идентификатор нити можно вызвав gettid() <=> get Thread ID.
Ну и top показывает, что nice уровень изменился только для одной нити, которая производит пакетную обработку (я делал снимок переключившись на ST и обратно, поэтому на нём основная кушает больше процессорного времени, перерисовывая окно ST).
Замечания учту и ещё по-разбираюсь с этим.
Tulon
Цитата:
может не совсем в тему, но если хочется потестить на ОЧЕНЬ плохих сканах, то пожалуйста
http://www.onlinedisk.ru/file/306853/
P.S.: на авторство не претендую.
Цитата:
Слишком стерильные сканы - там нечего чистить.
может не совсем в тему, но если хочется потестить на ОЧЕНЬ плохих сканах, то пожалуйста
http://www.onlinedisk.ru/file/306853/
P.S.: на авторство не претендую.
Прежде всего, большое спасибо Tulon за отличную программу, с которой теперь работается быстрее и веселее 
Хочу набраться наглости и немного разбавить обсуждение технических вопросов парой рацпредложений и вопросов к автору и другим пользователям, возникших по ходу знакомства с программой:
1. При удалении одной из страниц проекта, полученной при разрезании пополам скана разворота книги, на этапах 3-6 (после этапа разрезания) обычно (часто? иногда?) отображается только она, определённая часть разворота. То есть в ситуации, когда разворот книги поделили на две страницы, левую и правую, а затем, например, удалили левую, вместо оставшейся правой появляется левая. Приходится откатываться обратно на 2-й этап и вручную это править, передвигая нож.
2. В том случае, если одна из страниц проекта содержит, к примеру, только колонтитул или номер страницы или заголовок посреди листа, при определении макета страницы и подготовки к экспорту проекта приходится либо вручную возвращаться и расширять полезную область, либо устанавливать особое выравнивание для страницы относительно других (например, чтобы нижнее поле и расположение номера страницы не сильно скакало при переходе от "заполненной" страницы к "пустой"). Может, стоит добавить опцию определения расположения полезной области на листе и, соответственно, автоматически предлагать наиболее оптимальное выравнивание (например, для листов только с номером страницы по нижнему левому/правому краю, для листов только с верхним колонтитулом -- вверх по центру и т.п.)
3. После всех операций текст в выходных файлах смотрится бледнее, замыленнее, с расплывчатыми границами по сравнению с исходными. Исходные сканы были получены со сканера в режиме улучшения фокуса текста. Это особенности программы (режим сглаживания?) или неизбежные артефакты, возникающие при кручении-верчении?
4. Очень жду режим исправления кривых строк (вроде он заявлен в будущих версиях).
5. Хотелось бы технических разъяснений по поводу эффекта опций "Белая рамка"+"Выравнивание освещения" в режиме вывода. Работают они хорошо, затемнённый корешок убирают, однако не понятен алгоритм их работы. Если в затемнённую область попадает полутоновое изображение, пострадает ли оно от такого вытягивания освещения?
Хочу набраться наглости и немного разбавить обсуждение технических вопросов парой рацпредложений и вопросов к автору и другим пользователям, возникших по ходу знакомства с программой:
1. При удалении одной из страниц проекта, полученной при разрезании пополам скана разворота книги, на этапах 3-6 (после этапа разрезания) обычно (часто? иногда?) отображается только она, определённая часть разворота. То есть в ситуации, когда разворот книги поделили на две страницы, левую и правую, а затем, например, удалили левую, вместо оставшейся правой появляется левая. Приходится откатываться обратно на 2-й этап и вручную это править, передвигая нож.
2. В том случае, если одна из страниц проекта содержит, к примеру, только колонтитул или номер страницы или заголовок посреди листа, при определении макета страницы и подготовки к экспорту проекта приходится либо вручную возвращаться и расширять полезную область, либо устанавливать особое выравнивание для страницы относительно других (например, чтобы нижнее поле и расположение номера страницы не сильно скакало при переходе от "заполненной" страницы к "пустой"). Может, стоит добавить опцию определения расположения полезной области на листе и, соответственно, автоматически предлагать наиболее оптимальное выравнивание (например, для листов только с номером страницы по нижнему левому/правому краю, для листов только с верхним колонтитулом -- вверх по центру и т.п.)
3. После всех операций текст в выходных файлах смотрится бледнее, замыленнее, с расплывчатыми границами по сравнению с исходными. Исходные сканы были получены со сканера в режиме улучшения фокуса текста. Это особенности программы (режим сглаживания?) или неизбежные артефакты, возникающие при кручении-верчении?
4. Очень жду режим исправления кривых строк (вроде он заявлен в будущих версиях).
5. Хотелось бы технических разъяснений по поводу эффекта опций "Белая рамка"+"Выравнивание освещения" в режиме вывода. Работают они хорошо, затемнённый корешок убирают, однако не понятен алгоритм их работы. Если в затемнённую область попадает полутоновое изображение, пострадает ли оно от такого вытягивания освещения?
Возникает ошибка при компиляции версии 0.9.7.2 на openSUSE 11.1, Qt версии 4.4.3.
Код: [ 88%] Building CXX object CMakeFiles/scantailor.dir/DebugImageView.cpp.o
[ 88%] Building CXX object CMakeFiles/scantailor.dir/TabbedDebugImages.cpp.o
[ 88%] Building CXX object CMakeFiles/scantailor.dir/ImageId.cpp.o
/usr/src/packages/BUILD/scantailor-0.9.7.2/TabbedDebugImages.cpp: In constructor 'TabbedDebugImages::TabbedDebugImages(QWidget*)':
/usr/src/packages/BUILD/scantailor-0.9.7.2/TabbedDebugImages.cpp:25: error: 'setDocumentMode' was not declared in this scope
make[2]: *** [CMakeFiles/scantailor.dir/TabbedDebugImages.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [CMakeFiles/scantailor.dir/all] Error 2
make: *** [all] Error 2
Код: [ 88%] Building CXX object CMakeFiles/scantailor.dir/DebugImageView.cpp.o
[ 88%] Building CXX object CMakeFiles/scantailor.dir/TabbedDebugImages.cpp.o
[ 88%] Building CXX object CMakeFiles/scantailor.dir/ImageId.cpp.o
/usr/src/packages/BUILD/scantailor-0.9.7.2/TabbedDebugImages.cpp: In constructor 'TabbedDebugImages::TabbedDebugImages(QWidget*)':
/usr/src/packages/BUILD/scantailor-0.9.7.2/TabbedDebugImages.cpp:25: error: 'setDocumentMode' was not declared in this scope
make[2]: *** [CMakeFiles/scantailor.dir/TabbedDebugImages.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [CMakeFiles/scantailor.dir/all] Error 2
make: *** [all] Error 2
trickster7
Цитата:
Это был баг. Надо было при удалении пол-страницы из проекта устанавливать разделительную линию в ручной режим. Поправил в Git.
Цитата:
Самому мне сейчас не до этого, но не так давно один товарищ собирался реализовать как раз эту фичу. В общем надежда кое-какая есть.
Цитата:
Я так понимаю, вы говорите о режиме Цветной / Серый? В этом режиме явного сглаживания не делается, так что можно считать это неизбежным результатом геометрических преобразований.
Цитата:
Вторая версия алгоритма dewarping'а от Rob'а работает довольно неплохо. Я сейчас как раз переношу ее в ST. Как перенесу, выпущу неофициальный релиз, как раз для тестирования этой фичи. Поначалу будут серьезные ограничения, вроде работы только при черно-белом выводе в 600 DPI, но постепенно они будут сняты. Кроме того, я работаю над алгоритмом определения строк текста без бинаризации, и если все получится, он позволит делать dewarping на сканах низкого качества, где буквы в словах сливаются.
Цитата:
Только в клинических случаях - обычно нет. Алгоритм строит математическую модель изменения освещения в рамке контента. Для этого он первым делом должен отбросить весь контент - и текст и картинки, оставив только пустые области на бумаге. Так вот, когда картинка переходит в тень, это конечно затрудняет ее удаление, и в итоге портит качество математической модели. Однако я специально тестировал именно такие случаи, и результат обычно получается приемлемый.
Добавлено:
LazyKent
Цитата:
Очень легко заюзать какую-нибудь новую фичу Qt, и даже не заметить этого. В данном случае вызов setDocumentMode() вполне можно просто закомментировать - он влияет только на внешний вид, а именно убирает бордюр из tabbed widget. Вот только вполне возможно, что это была лишь одна из многих новых фич Qt, которые я уже успел заюзать в ST.
Цитата:
1. При удалении одной из страниц проекта, полученной при разрезании пополам скана разворота книги, на этапах 3-6 (после этапа разрезания) обычно (часто? иногда?) отображается только она, определённая часть разворота. То есть в ситуации, когда разворот книги поделили на две страницы, левую и правую, а затем, например, удалили левую, вместо оставшейся правой появляется левая. Приходится откатываться обратно на 2-й этап и вручную это править, передвигая нож.
Это был баг. Надо было при удалении пол-страницы из проекта устанавливать разделительную линию в ручной режим. Поправил в Git.
Цитата:
2. В том случае, если одна из страниц проекта содержит, к примеру, только колонтитул или номер страницы или заголовок посреди листа, при определении макета страницы и подготовки к экспорту проекта приходится либо вручную возвращаться и расширять полезную область, либо устанавливать особое выравнивание для страницы относительно других (например, чтобы нижнее поле и расположение номера страницы не сильно скакало при переходе от "заполненной" страницы к "пустой"). Может, стоит добавить опцию определения расположения полезной области на листе и, соответственно, автоматически предлагать наиболее оптимальное выравнивание (например, для листов только с номером страницы по нижнему левому/правому краю, для листов только с верхним колонтитулом -- вверх по центру и т.п.)
Самому мне сейчас не до этого, но не так давно один товарищ собирался реализовать как раз эту фичу. В общем надежда кое-какая есть.
Цитата:
3. После всех операций текст в выходных файлах смотрится бледнее, замыленнее, с расплывчатыми границами по сравнению с исходными. Исходные сканы были получены со сканера в режиме улучшения фокуса текста. Это особенности программы (режим сглаживания?) или неизбежные артефакты, возникающие при кручении-верчении?
Я так понимаю, вы говорите о режиме Цветной / Серый? В этом режиме явного сглаживания не делается, так что можно считать это неизбежным результатом геометрических преобразований.
Цитата:
4. Очень жду режим исправления кривых строк (вроде он заявлен в будущих версиях).
Вторая версия алгоритма dewarping'а от Rob'а работает довольно неплохо. Я сейчас как раз переношу ее в ST. Как перенесу, выпущу неофициальный релиз, как раз для тестирования этой фичи. Поначалу будут серьезные ограничения, вроде работы только при черно-белом выводе в 600 DPI, но постепенно они будут сняты. Кроме того, я работаю над алгоритмом определения строк текста без бинаризации, и если все получится, он позволит делать dewarping на сканах низкого качества, где буквы в словах сливаются.
Цитата:
5. Хотелось бы технических разъяснений по поводу эффекта опций "Белая рамка"+"Выравнивание освещения" в режиме вывода. Работают они хорошо, затемнённый корешок убирают, однако не понятен алгоритм их работы. Если в затемнённую область попадает полутоновое изображение, пострадает ли оно от такого вытягивания освещения?
Только в клинических случаях - обычно нет. Алгоритм строит математическую модель изменения освещения в рамке контента. Для этого он первым делом должен отбросить весь контент - и текст и картинки, оставив только пустые области на бумаге. Так вот, когда картинка переходит в тень, это конечно затрудняет ее удаление, и в итоге портит качество математической модели. Однако я специально тестировал именно такие случаи, и результат обычно получается приемлемый.
Добавлено:
LazyKent
Цитата:
В openSUSE 11.2 с Qt 4.5.3 компилируется нормально. В Wiki написано, что достаточно Qt версии 4.4.0.
Что делать?
Очень легко заюзать какую-нибудь новую фичу Qt, и даже не заметить этого. В данном случае вызов setDocumentMode() вполне можно просто закомментировать - он влияет только на внешний вид, а именно убирает бордюр из tabbed widget. Вот только вполне возможно, что это была лишь одна из многих новых фич Qt, которые я уже успел заюзать в ST.
Tulon
Цитата:
Большое спасибо. Получилось.
Хотелось бы, чтобы сохранялась совместимость с не самыми последними, но актуальными дистрибутивами.
Собрал пакеты для openSUSE и SLE.
http://software.opensuse.org/search?q=scantailor
Цитата:
Очень легко заюзать какую-нибудь новую фичу Qt, и даже не заметить этого. В данном случае вызов setDocumentMode() вполне можно просто закомментировать - он влияет только на внешний вид, а именно убирает бордюр из tabbed widget. Вот только вполне возможно, что это была лишь одна из многих новых фич Qt, которые я уже успел заюзать в ST.
Большое спасибо. Получилось.
Хотелось бы, чтобы сохранялась совместимость с не самыми последними, но актуальными дистрибутивами.
Собрал пакеты для openSUSE и SLE.
http://software.opensuse.org/search?q=scantailor
Что-то давно я тут не был.
Скажите, где скачать самую последнюю версию под win32 ?
Добавлено:
От 30.11.2009 с sourceforge ?
Добавлено:
В каком состоянии dewarping ?
Скажите, где скачать самую последнюю версию под win32 ?
Добавлено:
От 30.11.2009 с sourceforge ?
Добавлено:
В каком состоянии dewarping ?
Tulon
Подскажите, в какой момент на стадии вывод в смешанном режиме СТ решает, что нужно перегенерировать файл в папке Automask. Дело в том, что я хочу подменить файл автомаски другим файлом, полученным по альтернативной методике, но каждый раз после того, как я подменяю этот файл, при формировании файла в папке Out (например, если я спровоцировал вывод небольшим перемещением специально заведенной для этого ручной зоны) мой файл автомаски затирается вновь сгенерированным.
Подскажите, в какой момент на стадии вывод в смешанном режиме СТ решает, что нужно перегенерировать файл в папке Automask. Дело в том, что я хочу подменить файл автомаски другим файлом, полученным по альтернативной методике, но каждый раз после того, как я подменяю этот файл, при формировании файла в папке Out (например, если я спровоцировал вывод небольшим перемещением специально заведенной для этого ручной зоны) мой файл автомаски затирается вновь сгенерированным.
ndch
Цитата:
Оттуда.
Цитата:
А вы не ленитесь - почитайте хотябы последнюю страницу. А если вы имели в виду, как идет процесс портирования, то отвечаю - сделал больше половины, но после работы у меня нет особого желания кодить, так что закончу в лучшем случае на выходных.
StanFreeWare
Цитата:
Подменять файл автомаски бесполезно - он используется только для визуализации в редакторе зон.
Цитата:
От 30.11.2009 с sourceforge ?
Оттуда.
Цитата:
В каком состоянии dewarping ?
А вы не ленитесь - почитайте хотябы последнюю страницу. А если вы имели в виду, как идет процесс портирования, то отвечаю - сделал больше половины, но после работы у меня нет особого желания кодить, так что закончу в лучшем случае на выходных.
StanFreeWare
Цитата:
Подскажите, в какой момент на стадии вывод в смешанном режиме СТ решает, что нужно перегенерировать файл в папке Automask. Дело в том, что я хочу подменить файл автомаски другим файлом, полученным по альтернативной методике, но каждый раз после того, как я подменяю этот файл, при формировании файла в папке Out (например, если я спровоцировал вывод небольшим перемещением специально заведенной для этого ручной зоны) мой файл автомаски затирается вновь сгенерированным.
Подменять файл автомаски бесполезно - он используется только для визуализации в редакторе зон.
Tulon
У меня Scan Tailor падает на openSUSE Factory (11.3) x86_64 при загрузке эскизов (вроде бы). Там Qt 4.6, если это важно.
Как можно отследить причину падения?
У меня Scan Tailor падает на openSUSE Factory (11.3) x86_64 при загрузке эскизов (вроде бы). Там Qt 4.6, если это важно.
Как можно отследить причину падения?
Tulon
Иными словами, правильно ли я понял, если сделаю вывод, затем сохраню проект, выйду из СТ, удалю файл из папки out, открою проект и сделаю вывод заново, то СТ проигнорирует информацию об автозонах из файла в папке automask и перегенерирует эту информацию (и файл в automask) заново?
Иными словами, правильно ли я понял, если сделаю вывод, затем сохраню проект, выйду из СТ, удалю файл из папки out, открою проект и сделаю вывод заново, то СТ проигнорирует информацию об автозонах из файла в папке automask и перегенерирует эту информацию (и файл в automask) заново?
LazyKent
Проверьте, финальный ли там релиз Qt 4.6. В пререлизах был баг, из-за которого ST падал.
Найти место падения можно так:
Код:
gdb /path/to/scantailor
run
[вызвать падение]
bt
Проверьте, финальный ли там релиз Qt 4.6. В пререлизах был баг, из-за которого ST падал.
Найти место падения можно так:
Код:
gdb /path/to/scantailor
run
[вызвать падение]
bt
Tulon
Вот такое выдаёт:
Код: Program received signal SIGSEGV, Segmentation fault.
0x00007ffff617fc3a in QGLEngineShaderManager::getUniformLocation(QGLEngineShaderManager::Uniform) () from /usr/lib64/libQtOpenGL.so.4
(gdb) bt
#0 0x00007ffff617fc3a in QGLEngineShaderManager::getUniformLocation(QGLEngineShaderManager::Uniform) () from /usr/lib64/libQtOpenGL.so.4
#1 0x00007ffff618ac81 in ?? () from /usr/lib64/libQtOpenGL.so.4
#2 0x00007ffff618c2d4 in ?? () from /usr/lib64/libQtOpenGL.so.4
#3 0x00007ffff618c9f3 in QGL2PaintEngineEx::drawPixmap(QRectF const&, QPixmap const&, QRectF const&) () from /usr/lib64/libQtOpenGL.so.4
#4 0x00007ffff746a941 in QPainter::drawPixmap(QRectF const&, QPixmap const&, QRectF const&) () from /usr/lib64/libQtGui.so.4
#5 0x000000000042d746 in PixmapRenderer::drawPixmapNoXRender(QPainter&, QPixmap const&) ()
#6 0x000000000042d800 in PixmapRenderer::drawPixmap(QPainter&, QPixmap const&) ()
#7 0x000000000044b374 in ImageViewBase::paintEvent(QPaintEvent*) ()
#8 0x00007ffff7363e15 in QWidget::event(QEvent*) () from /usr/lib64/libQtGui.so.4
#9 0x00007ffff7706076 in QFrame::event(QEvent*) () from /usr/lib64/libQtGui.so.4
#10 0x00007ffff6bf3737 in QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*) () from /usr/lib64/libQtCore.so.4
#11 0x00007ffff730ebbc in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib64/libQtGui.so.4
#12 0x00007ffff731521d in QApplication::notify(QObject*, QEvent*) () from /usr/lib64/libQtGui.so.4
#13 0x00007ffff6bf431c in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib64/libQtCore.so.4
#14 0x00007ffff736c3bd in QWidgetPrivate::drawWidget(QPaintDevice*, QRegion const&, QPoint const&, int, QPainter*, QWidgetBackingStore*) ()
from /usr/lib64/libQtGui.so.4
#15 0x00007ffff751f99c in QWidgetPrivate::repaint_sys(QRegion const&) () from /usr/lib64/libQtGui.so.4
#16 0x00007ffff735d7a4 in QWidgetPrivate::syncBackingStore() () from /usr/lib64/libQtGui.so.4
#17 0x00007ffff7364525 in QWidget::event(QEvent*) () from /usr/lib64/libQtGui.so.4
#18 0x00007ffff613f461 in QGLWidget::event(QEvent*) () from /usr/lib64/libQtOpenGL.so.4
#19 0x00007ffff730ebec in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib64/libQtGui.so.4
#20 0x00007ffff731521d in QApplication::notify(QObject*, QEvent*) () from /usr/lib64/libQtGui.so.4
#21 0x00007ffff6bf431c in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib64/libQtCore.so.4
#22 0x00007ffff6bf6a97 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib64/libQtCore.so.4
#23 0x00007ffff6c1dd73 in ?? () from /usr/lib64/libQtCore.so.4
#24 0x00007ffff4f87f6e in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0
#25 0x00007ffff4f8b938 in ?? () from /usr/lib64/libglib-2.0.so.0
#26 0x00007ffff4f8ba60 in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#27 0x00007ffff6c1d8b3 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4
#28 0x00007ffff73bb9ce in ?? () from /usr/lib64/libQtGui.so.4
#29 0x00007ffff6bf2c42 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4
#30 0x00007ffff6bf301c in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4
#31 0x00007ffff6bf6d5b in QCoreApplication::exec() () from /usr/lib64/libQtCore.so.4
#32 0x000000000042c879 in main ()
Вот такое выдаёт:
Код: Program received signal SIGSEGV, Segmentation fault.
0x00007ffff617fc3a in QGLEngineShaderManager::getUniformLocation(QGLEngineShaderManager::Uniform) () from /usr/lib64/libQtOpenGL.so.4
(gdb) bt
#0 0x00007ffff617fc3a in QGLEngineShaderManager::getUniformLocation(QGLEngineShaderManager::Uniform) () from /usr/lib64/libQtOpenGL.so.4
#1 0x00007ffff618ac81 in ?? () from /usr/lib64/libQtOpenGL.so.4
#2 0x00007ffff618c2d4 in ?? () from /usr/lib64/libQtOpenGL.so.4
#3 0x00007ffff618c9f3 in QGL2PaintEngineEx::drawPixmap(QRectF const&, QPixmap const&, QRectF const&) () from /usr/lib64/libQtOpenGL.so.4
#4 0x00007ffff746a941 in QPainter::drawPixmap(QRectF const&, QPixmap const&, QRectF const&) () from /usr/lib64/libQtGui.so.4
#5 0x000000000042d746 in PixmapRenderer::drawPixmapNoXRender(QPainter&, QPixmap const&) ()
#6 0x000000000042d800 in PixmapRenderer::drawPixmap(QPainter&, QPixmap const&) ()
#7 0x000000000044b374 in ImageViewBase::paintEvent(QPaintEvent*) ()
#8 0x00007ffff7363e15 in QWidget::event(QEvent*) () from /usr/lib64/libQtGui.so.4
#9 0x00007ffff7706076 in QFrame::event(QEvent*) () from /usr/lib64/libQtGui.so.4
#10 0x00007ffff6bf3737 in QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*) () from /usr/lib64/libQtCore.so.4
#11 0x00007ffff730ebbc in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib64/libQtGui.so.4
#12 0x00007ffff731521d in QApplication::notify(QObject*, QEvent*) () from /usr/lib64/libQtGui.so.4
#13 0x00007ffff6bf431c in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib64/libQtCore.so.4
#14 0x00007ffff736c3bd in QWidgetPrivate::drawWidget(QPaintDevice*, QRegion const&, QPoint const&, int, QPainter*, QWidgetBackingStore*) ()
from /usr/lib64/libQtGui.so.4
#15 0x00007ffff751f99c in QWidgetPrivate::repaint_sys(QRegion const&) () from /usr/lib64/libQtGui.so.4
#16 0x00007ffff735d7a4 in QWidgetPrivate::syncBackingStore() () from /usr/lib64/libQtGui.so.4
#17 0x00007ffff7364525 in QWidget::event(QEvent*) () from /usr/lib64/libQtGui.so.4
#18 0x00007ffff613f461 in QGLWidget::event(QEvent*) () from /usr/lib64/libQtOpenGL.so.4
#19 0x00007ffff730ebec in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib64/libQtGui.so.4
#20 0x00007ffff731521d in QApplication::notify(QObject*, QEvent*) () from /usr/lib64/libQtGui.so.4
#21 0x00007ffff6bf431c in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib64/libQtCore.so.4
#22 0x00007ffff6bf6a97 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib64/libQtCore.so.4
#23 0x00007ffff6c1dd73 in ?? () from /usr/lib64/libQtCore.so.4
#24 0x00007ffff4f87f6e in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0
#25 0x00007ffff4f8b938 in ?? () from /usr/lib64/libglib-2.0.so.0
#26 0x00007ffff4f8ba60 in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#27 0x00007ffff6c1d8b3 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4
#28 0x00007ffff73bb9ce in ?? () from /usr/lib64/libQtGui.so.4
#29 0x00007ffff6bf2c42 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4
#30 0x00007ffff6bf301c in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4
#31 0x00007ffff6bf6d5b in QCoreApplication::exec() () from /usr/lib64/libQtCore.so.4
#32 0x000000000042c879 in main ()
LazyKent
Какая-то фигня с 3D ускорением. Отключите его в настройках.
Какая-то фигня с 3D ускорением. Отключите его в настройках.
Цитата:
Какая-то фигня с 3D ускорением. Отключите его в настройках.
Помогло.
Tulon
ИМХО выравнивание освещённости в СТ ещё пока что неудовлетворительно - по крайней мере, по сравнению с Book Restorer 4.1. Кстати, в СК та же проблема (о чём я когда-то писал в топике по СК). После конечной бинаризации остаются "пересвеченные" (более бледные) пятнообразные участки текста (а после Book Restorer 4.1 - никогда).
Может, Ваши друзья на DYI-форуме возьмутся ещё как-нибудь сделать крутой алгоритм выравнивания освещённости?
Вот если бы в СТ существовала штатная возможность в течение всего цикла сканобработки передать сканы в Book Restorer 4.1 и назад в СТ (как это позволяет сделать СК, потому что сохраняет на диск промежуточно-обработанные сканы) - тогда проблемы бы не было.
Может, тоже сделаете (в отдалённом будущем) промежуточное сохранение сканов на диск (на каких-то этапах сканобработки) - как в СК (чтобы эти сканы можно было обрабатывать попутно в Book Restorer 4.1)? Почему бы и нет?
Единственная альтернатива - реализовать в СТ алгоритмы выравнивания освещённости и выпрямления искривленных строк не хуже, чем в Book Restorer 4.1. Реально ли это? ИМХО пока что сомнительно.
Меня вот, кстати, именно эти недостатки отвращают от СТ в сторону СК - ну не могу я никак смириться ни с кривыми строками, ни с пересвеченными пятнами текста. СК ведь не так "тоталитарен", как СТ.
Даже если ожидаемый алгоритм выпрямления искривленных строк окажется идеальным на 100% (?) - всё равно останется недостаточно качественный алгоритм выравнивания освещённости (а значит, всё насмарку - идём от СТ к СК).
Кстати, я вот подумал: СК, в отличие от СТ, может быть использован не только для самостоятельного создания DjVu-книг, но также и для улучшающей переделки чужих некачественно-сделанных DjVu-книг. СТ на подобное в общем случае не способен.
ИМХО выравнивание освещённости в СТ ещё пока что неудовлетворительно - по крайней мере, по сравнению с Book Restorer 4.1. Кстати, в СК та же проблема (о чём я когда-то писал в топике по СК). После конечной бинаризации остаются "пересвеченные" (более бледные) пятнообразные участки текста (а после Book Restorer 4.1 - никогда).
Может, Ваши друзья на DYI-форуме возьмутся ещё как-нибудь сделать крутой алгоритм выравнивания освещённости?
Вот если бы в СТ существовала штатная возможность в течение всего цикла сканобработки передать сканы в Book Restorer 4.1 и назад в СТ (как это позволяет сделать СК, потому что сохраняет на диск промежуточно-обработанные сканы) - тогда проблемы бы не было.
Может, тоже сделаете (в отдалённом будущем) промежуточное сохранение сканов на диск (на каких-то этапах сканобработки) - как в СК (чтобы эти сканы можно было обрабатывать попутно в Book Restorer 4.1)? Почему бы и нет?
Единственная альтернатива - реализовать в СТ алгоритмы выравнивания освещённости и выпрямления искривленных строк не хуже, чем в Book Restorer 4.1. Реально ли это? ИМХО пока что сомнительно.
Меня вот, кстати, именно эти недостатки отвращают от СТ в сторону СК - ну не могу я никак смириться ни с кривыми строками, ни с пересвеченными пятнами текста.
СК ведь не так "тоталитарен", как СТ. Даже если ожидаемый алгоритм выпрямления искривленных строк окажется идеальным на 100% (?) - всё равно останется недостаточно качественный алгоритм выравнивания освещённости (а значит, всё насмарку - идём от СТ к СК).
Кстати, я вот подумал: СК, в отличие от СТ, может быть использован не только для самостоятельного создания DjVu-книг, но также и для улучшающей переделки чужих некачественно-сделанных DjVu-книг. СТ на подобное в общем случае не способен.
Tulon
И ещё ИМХО неплохо бы как-то расширить возможности СТ в плане бинаризации. А то, когда подаёшь на СТ сканы, у которых была выровнена освещённость в Book Restorer 4.1, диапазона регулирования порога бинаризации СТ оказывается недостаточно.
Надо бы, думается, расширить диапазон порога бинаризации. Или что-то в этом роде.
И ещё ИМХО неплохо бы как-то расширить возможности СТ в плане бинаризации. А то, когда подаёшь на СТ сканы, у которых была выровнена освещённость в Book Restorer 4.1, диапазона регулирования порога бинаризации СТ оказывается недостаточно.
Надо бы, думается, расширить диапазон порога бинаризации. Или что-то в этом роде.
Цитата:
Надо бы, думается, расширить диапазон порога бинаризации. Или что-то в этом роде.
Поддерживаю. Мне тоже (иногда) кажеться, что диапазон недостаточной.
Tulon
И еще – как вы относитесь к просьбу добавить настройку для записи ч/б TIFF в CCITT4-формат? Выключена по дефолт, конечно…
Tulon
Цитата:
Получается какая-то странная ситуация: начиная обрабатывать произвольные сканы в СТ, никогда не знаешь - а будет ли достигнуто в итоге желаемое качество готовых сканов?
Ведь вполне может получиться так, что только когда уже полностью обработаешь сканы, вдруг обнаруживаешь, что тебе не нравится полученное качество - а сделать ничего нельзя, ни передать сканы в Book Restorer для промежуточной доработки, ни в самом СТ никак не исправить недостаточное качество.
Понимаете ли Вы, что это обстоятельство на 80-90% обессмысливает существование Вашей программы? По крайней мере, в том виде, в котором она есть сейчас.
Да, на мой взгляд, эргономичность и удобство использования СТ на порядок лучше, чем у СК - но толку? Практически все плюсы сводит на нет вышеуказанный недостаток.
А вот это Ваше добровольно взятое на себя самоограничение - что "алгоритмы должны быть потокобезопасными" - так ли уж это нужно? В СК этого нет - ну и что - он прекрасно без этого обходится. Вы добровольно взвалили на себя лишнюю сложность, которая совершенно некритична - ни для удобства использования СТ, ни для получаемого качества обработки. Это уже, так сказать, "понты".
Я предлагаю такое решение проблемы "сторонней доработки":
Во-первых, необходимо научить СТ делать т.н. пары субсканов - как описано тут: http://forum.ru-board.com/topic.cgi?forum=5&topic=27424&start=1720#18 .
Во-вторых, СТ следует научить сохранять эти пары субсканов на диск до финальной бинаризации - т.е. оба субскана в режиме greyscale (где-то на полдороге стадии "Вывод").
В-третьих, СТ следует научить открывать эти пары субсканов с диска - по-видимому, в той самой точке, где они были выгружены на диск.
Что это даёт? Это дало бы возможность, выгрузив на диск пары субсканов в режиме greyscale, далее сделать с ними всё, что хочешь. Скажем, сделать выравнивание освещённости + исправление искривленных строк переднего субскана в Book Restorer 4.1. Или любые, самые извращенческие обработки то ли отдельно над передними субсканами, то ли отдельно над задними - в любой сторонней программе.
В самом деле - ну не можете же Вы воплотить в СТ все мыслимые алгоритмы сканобработки? Это же невозможно. А кому-то всегда будет хотеться до-обработать сканы в некой сторонней программе - которая, быть может, с высоким совершенством делает некую одну операцию.
Сейчас же это (до-обработка в сторонней программе) возможна только в том случае, когда на сканах отсутствуют серые картинки (обрабатываемые СТ-зонами).
Цитата:
ИМХО выравнивание освещённости в СТ ещё пока что неудовлетворительно
Получается какая-то странная ситуация: начиная обрабатывать произвольные сканы в СТ, никогда не знаешь - а будет ли достигнуто в итоге желаемое качество готовых сканов?
Ведь вполне может получиться так, что только когда уже полностью обработаешь сканы, вдруг обнаруживаешь, что тебе не нравится полученное качество - а сделать ничего нельзя, ни передать сканы в Book Restorer для промежуточной доработки, ни в самом СТ никак не исправить недостаточное качество.
Понимаете ли Вы, что это обстоятельство на 80-90% обессмысливает существование Вашей программы? По крайней мере, в том виде, в котором она есть сейчас.
Да, на мой взгляд, эргономичность и удобство использования СТ на порядок лучше, чем у СК - но толку? Практически все плюсы сводит на нет вышеуказанный недостаток.
А вот это Ваше добровольно взятое на себя самоограничение - что "алгоритмы должны быть потокобезопасными" - так ли уж это нужно? В СК этого нет - ну и что - он прекрасно без этого обходится. Вы добровольно взвалили на себя лишнюю сложность, которая совершенно некритична - ни для удобства использования СТ, ни для получаемого качества обработки. Это уже, так сказать, "понты".
Я предлагаю такое решение проблемы "сторонней доработки":
Во-первых, необходимо научить СТ делать т.н. пары субсканов - как описано тут: http://forum.ru-board.com/topic.cgi?forum=5&topic=27424&start=1720#18 .
Во-вторых, СТ следует научить сохранять эти пары субсканов на диск до финальной бинаризации - т.е. оба субскана в режиме greyscale (где-то на полдороге стадии "Вывод").
В-третьих, СТ следует научить открывать эти пары субсканов с диска - по-видимому, в той самой точке, где они были выгружены на диск.
Что это даёт? Это дало бы возможность, выгрузив на диск пары субсканов в режиме greyscale, далее сделать с ними всё, что хочешь. Скажем, сделать выравнивание освещённости + исправление искривленных строк переднего субскана в Book Restorer 4.1. Или любые, самые извращенческие обработки то ли отдельно над передними субсканами, то ли отдельно над задними - в любой сторонней программе.
В самом деле - ну не можете же Вы воплотить в СТ все мыслимые алгоритмы сканобработки? Это же невозможно. А кому-то всегда будет хотеться до-обработать сканы в некой сторонней программе - которая, быть может, с высоким совершенством делает некую одну операцию.
Сейчас же это (до-обработка в сторонней программе) возможна только в том случае, когда на сканах отсутствуют серые картинки (обрабатываемые СТ-зонами).
monday2000
Цитата:
Нужны примеры.
Цитата:
Когда чего-то просите, всегда пишите зачем. Зачем я стану добавлять опцию, если не знаю, зачем она кому-либо может быть нужна.
monday2000
Цитата:
Что значит нельзя? А вывести в режиме Серый / Цветной?
Цитата:
И ещё ИМХО неплохо бы как-то расширить возможности СТ в плане бинаризации. А то, когда подаёшь на СТ сканы, у которых была выровнена освещённость в Book Restorer 4.1, диапазона регулирования порога бинаризации СТ оказывается недостаточно.
Нужны примеры.
Цитата:
И еще – как вы относитесь к просьбу добавить настройку для записи ч/б TIFF в CCITT4-формат? Выключена по дефолт, конечно…
Когда чего-то просите, всегда пишите зачем. Зачем я стану добавлять опцию, если не знаю, зачем она кому-либо может быть нужна.
monday2000
Цитата:
Ведь вполне может получиться так, что только когда уже полностью обработаешь сканы, вдруг обнаруживаешь, что тебе не нравится полученное качество - а сделать ничего нельзя, ни передать сканы в Book Restorer для промежуточной доработки, ни в самом СТ никак не исправить недостаточное качество.
Что значит нельзя? А вывести в режиме Серый / Цветной?
Tulon
Цитата:
Я ведь выкладывал выше по треду образец скана, который как раз и демонстрирует недостаточность доступного диапазона значений для порога бинаризации.
Цитата:
Нужны примеры.
Я ведь выкладывал выше по треду образец скана, который как раз и демонстрирует недостаточность доступного диапазона значений для порога бинаризации.
Tulon
Цитата:
Так можно вывести сканы только целиком - а не в виде пар серых субсканов. Некое решение предлагал патч от anagnost96 - но точно не помню, такое же ли.
Цитата:
Что значит нельзя? А вывести в режиме Серый / Цветной?
Так можно вывести сканы только целиком - а не в виде пар серых субсканов. Некое решение предлагал патч от anagnost96 - но точно не помню, такое же ли.
Цитата:
Я ведь выкладывал выше по треду образец скана, который как раз и демонстрирует недостаточность доступного диапазона значений для порога бинаризации.
Вы же вроде написали патч для расширения диапазона? Или не вы? Если вы, то надо было выложить три скана: оригинал, результат без расширения диапазона и с расширением.
Цитата:
Так можно вывести сканы только целиком - а не в виде пар серых субсканов. Некое решение предлагал патч от anagnost96 - но точно не помню, такое же ли.
Если вы хотите делать такие операции как выравнивание освещения в BR, то для этого вывод в режиме Серый / Цветной как раз подходит. А раздельный вывод текста / картинок - это уже отдельный вопрос.
Tulon
Цитата:
Нет, не подходит - картинки портятся. Выравнивание освещённости в BR нужно делать только над текстом - не трогая картинки на том же скане.
Добавлено:
Tulon
Цитата:
Я сделал доп.программку - для склеивания/разделения сканов по чёрной трафаретке. Но всё это крайне неудобно и непрактично.
Цитата:
Постараюсь сделать на днях. Это непросто - надо перерыть кучу сканов, обработать, и найти нужный пример. Но могу сказать точно: то, что у меня там получилось в СТ - да, можно пользоваться, но можно бы получше - и в СК это можно достичь (только СК неудобен отсутствием авто-распознавания зон).
Цитата:
то для этого вывод в режиме Серый / Цветной как раз подходит.
Нет, не подходит - картинки портятся. Выравнивание освещённости в BR нужно делать только над текстом - не трогая картинки на том же скане.
Добавлено:
Tulon
Цитата:
Вы же вроде написали патч для расширения диапазона?
Я сделал доп.программку - для склеивания/разделения сканов по чёрной трафаретке. Но всё это крайне неудобно и непрактично.
Цитата:
Если вы, то надо было выложить три скана: оригинал, результат без расширения диапазона и с расширением.
Постараюсь сделать на днях. Это непросто - надо перерыть кучу сканов, обработать, и найти нужный пример. Но могу сказать точно: то, что у меня там получилось в СТ - да, можно пользоваться, но можно бы получше - и в СК это можно достичь (только СК неудобен отсутствием авто-распознавания зон).
Страницы: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172
Предыдущая тема: Невозможно установить Acronis True Image Home v10.0.4940
Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.