» Scan Tailor

Цитата:

Это добавит сложности в реализацию. ... Кстати под Linux у кого-нибудь падало?

Понятно. Жаль, что это будет сложно. Забыл написать -- у меня WinXP SP2.
Кстати, последняя сборка очень сильно тормозит на "Применить ко всем". Я даже подумал сначала, что появилось автосохранение...

Цитата:

Вот здесь есть нормальный ChangeLog, но он всегда идет с опозданием.

Спасибо!

Цитата:

Пожалуй это можно было бы вот так реализовать:
На первой стадии сделать галку "Только вывод". ...

Было бы здОрово, если бы такое было реализовано.

Цитата:

Можно будет попробовать как-нибудь. Свободного времени очень мало - в рабочие дни практически совсем нет.

Это понятно... Я могу только говорить и говорить Вам спасибо. Спасибо!!!!!!!

Цитата:

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

OK

Цитата:

30% - очень много. У меня такое тоже бывает, но только на сильно неполных страницах, где этот номер очень далеко от остального текста.

Да, у меня именно такой случай.

Цитата:

Посмотреть, правильно ли определился текст, можно через режим отладки - Инструменты -> режим отладки, потом переключится в ручной режим и обратно (все это на стадии определения рамки). Потом ищите вкладку text_mask.

OK, попробую.

Цитата:

Впрочем это навело меня на мысль добавить опцию "применить ко всем последующим".

Отлично! Это уже некоторая замена возможной опции "применить к выбранным".

Цитата:

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

Хорошо. Я всегда все стираю, когда готово (старая привычка), но если будет опять -- выложу.

Цитата:

Сделать такое пожалуй можно, но с большой вероятностью все равно вывод придется переделывать - достаточно одной страницы с мусором, попавшем в рамку контента, чтобы распухли все файлы на выводе.

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

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

А теперь вопросы. Прежде всего, могу подтвердить исчезновение лидеров в оглавлении (почему-то за исключением последней строчки на странице), а также многоточий в основном тексте. Возможность отключить/ослабить despeckle в подобных случаях очень помогла бы.

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

И еще одно пожелание: нельзя ли сделать настраиваемые имена файлов на выходе, подобно тому, как это реализовано в СК? Просто в файлах легче ориентироваться, если их нумерация соответствует номерам страниц книги. Можно, конечно, потом переименовать скриптом, но... Честно говоря, меня удивляет, что такая очевидная вещь до сих пор не попала в список TODO.


Добавлено:
Oops, лажанулся я -- вот же он, флажок "Удалять пятна". Но всё равно непонятно, почему с последней строкой оглавления всё в порядке, а остальные -- без отточий.

Цитата:

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

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


Цитата:

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

Выложите пример - скажу точно, в чем проблема.


Цитата:

И еще одно пожелание: нельзя ли сделать настраиваемые имена файлов на выходе, подобно тому, как это реализовано в СК? Просто в файлах легче ориентироваться, если их нумерация соответствует номерам страниц книги. Можно, конечно, потом переименовать скриптом, но... Честно говоря, меня удивляет, что такая очевидная вещь до сих пор не попала в список TODO.

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


Цитата:

Oops, лажанулся я -- вот же он, флажок "Удалять пятна". Но всё равно непонятно, почему с последней строкой оглавления всё в порядке, а остальные -- без отточий.

Давайте пример - скажу точно. Не исключено что и баг.

Цитата:

Выложите пример - скажу точно, в чем проблема.

Выложил подборку проблемных файлов по адресу http://www.thessalonica.org.ru/downloads/st-issues.zip . Это не сканы, а фотографии, но тем не менее прошу их не отвергать, т. к. за исключением описанных недочетов СТ с данной книгой справился вполне прилично, за что еще раз спасибо. Для DPI я выставлял несколько заниженное значение (200). Кстати, обнаружил, что despeckle может съедать не только точки, но и длинные тире, отбитые пробелами от окружающего текста (см. файл dashes.jpg в архиве по приведенной ссылке).

P.S. Столкнулся со случаями падения СТ под Линуксом (Suse 11.1 x86_64). Такое происходит, если в течение некоторого (достаточно долгого) времени вручную переключаться между страницами на этапе вывода. Stacktrace, боюсь, не особенно информативен, но тем не менее на всякий случай приложил и его тоже.

anagnost96
За stack trace спасибо - проблему еще не нашел, но по крайней мере теперь знаю, где искать.
Попробуйте еще вот что сделать:
В файле ThumbnailPixmapCache.cpp после #include'ов добавте строку:
#undef NDEBUG
Это активирует assert'ы в данном файле. Есть вероятность, что в следующий раз упадет как раз на assert'е - и будет уже понятнее, что именно пошло не так.

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

Проблемы с удалением полезного контента связаны с плохой контрастностью букв - к тому же там еще и jpeg. После бинаризации буквы распадаются на сегменты. По отдельности такие сегменты - кандидаты на удаление. Если например в слове не оказалось ни одной нераспавшейся буквы, то все слово может быть удалено, поскольку до других слов расстояние значительное, а сегменты малы. Задирание порога бинаризации улучшит ситуацию, но на таком исходном материале лучше совсем отключать despeckle.

Баг с падением вроде исправил. Ждите билда от U235 (в шапке). Ревизия 356.
То, что я исправил, могло произойти только после вывода хотябы одного файла. Не обязательно на стадии вывод - возможно по возвращении на другую стадию.
У всех при падениях такой сценарий соблюдался?

В понедельник собираюсь выпустить релиз 0.9.5. Пока это единственное изменение. Может за выходные что-то еще реализую.

я скормил 7 файлов 10500*10040 pix
и прога упала. Почему ?

Цитата:

я скормил 7 файлов 10500*10040 pix
и прога упала. Почему ?

Скорее всего там неправильное DPI прописано. Такой пиксельный размер соответствует разрешению 1200 DPI. Один человек тут работал с таким разрешением, и все было OK, если не считать потребления памяти под два гига. А если DPI меньше правильного, потребление памяти возрастает в квадрат отношения правильного к неправильному. То есть если в файлах указано 600 вместо 1200, потребление памяти возрастет в 4 раза. В 32х битных операционных системах теоретический предел - 4 гига, практический - от 2 до 3, и никакой файл подкачки тут не поможет.

Изменил дпи на 1200
теперь пишет

"Некоторые файлы не загрузились. Либо программа не поддерживает их формат, либо они повреждены. "

dma200899
Выложите один такой файл - посмотрю что с ним.

Цитата:

Баг с падением вроде исправил. Ждите билда от U235 (в шапке). Ревизия 356.

Спасибо! Поглядим.

Цитата:

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

У меня -- да.

Цитата:

Вообще-то предполагается, что на вывод вы пойдете только когда довольны рамкой.

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

Цитата:

Если дойдут руки до предупреждения, то возможно заодно сделаю и замораживание как вариант.

Спасибо!

Цитата:

Есть у меня мысль вообще оставлять имена как есть, только суффикс прибавлять для левой или правой половинки. Это по крайней мере просто сделать.

О, как это было бы здОрово! Тогда мои проблемы с расширением тоже исчезнут.
Обнаружилась, кстати, совершенно эзотерическая проблема -- цветные файлы TIFF после СТ не редактируются в 7-ом фотошопе, но если поменять canvas хотя бы чуть-чуть, то все нормально. Причем ситуация сохраняется даже после конвертации в BMP и обратно. Вы, случаем, не знаете, в чем тут может быть дело? Ни с какими другими тифами проблем никогда не было...


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

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

32 Mb
http://rapidshare.com/files/228500560/001_Panorama.rar.html

Я имел в виду не оригинальный файл, а такой, на котором вот это сообщение выскакивает:
"Некоторые файлы не загрузились. Либо программа не поддерживает их формат, либо они повреждены. "
Тот, что вы дали, грузится нормально, после исправления DPI в Gimp'е. Кстати говоря DPI там таки правильный. Вот если бы всю область картинки занимала страница или разворот, тогда пиксельные размеры в районе 10000 дают 1200 DPI. А у вас большая часть картинки прозрачная, а по середине маленькое изображение страницы. Не знаю, как вы такое умудрились получить, но тут конечно нужно делать crop, и при этом следить чтобы не побилось DPI.

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

Цитата:

после исправления DPI в Gimp'е

А я правил дпи в СК. Может поэтому.... ?

Цитата:

Так это и есть файл, на котором у меня СТ слетает. Никто и не говорил, что он "хороший".

На этом файле понятно почему падает - нехватка памяти. А вот почему после исправления DPI в СК не грузится - непонятно.


Цитата:

Может вы опцию для батч кропа в СТ сделаете ?

Слишком нетипичная задача, и к тому же не вписывается в интерфейс СТ.

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

Кстати хорошие новости для линуксоидов - Scan Tailor сейчас проходит процедуру включения в Ubuntu и Debian.

Поздравляю Убунтоидов. Жду в репах Мандривы

Теперь релизы как пирожки пекутся ?

Tulon

Цитата:

Слишком нетипичная задача, и к тому же не вписывается в интерфейс СТ.

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

Поэтому кроп, как и подгонку масштабирования можно рассматривать как один из этапов предобработки наряду с изменением дпи ?

У меня проблемы с компилированием последней версии. Можете что-то посоветовать?
[more=дальше..]

Код:
term@rapanui:~/Documents/incoming/scantailor-0.9.5> cmake .
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Boost version: 1.37.0
-- Found the following Boost libraries:
-- Checking to see if CXX compiler accepts flag -ffunction-sections -fdata-sections -Wl,--gc-sections
-- Checking to see if CXX compiler accepts flag -ffunction-sections -fdata-sections -Wl,--gc-sections - yes
-- Checking to see if CXX compiler accepts flag -fvisibility=hidden
-- Checking to see if CXX compiler accepts flag -fvisibility=hidden - yes
-- Looking for Q_WS_X11
-- Looking for Q_WS_X11 - found
-- Looking for Q_WS_WIN
-- Looking for Q_WS_WIN - not found.
-- Looking for Q_WS_QWS
-- Looking for Q_WS_QWS - not found.
-- Looking for Q_WS_MAC
-- Looking for Q_WS_MAC - not found.
-- Found Qt-Version 4.3.1
-- Found OpenSSL: /usr/lib64/libssl.so
-- Looking for _POSIX_TIMERS
-- Looking for _POSIX_TIMERS - found
-- Boost version: 1.37.0
-- Found the following Boost libraries:
-- unit_test_framework
-- prg_exec_monitor
-- Checking pthreads with CFLAGS="-pthread" and LIBS="-pthread" -- yes
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Configuring done
-- Generating done
-- Build files have been written to: /home/term/Documents/incoming/scantailor-0.9.5
term@rapanui:~/Documents/incoming/scantailor-0.9.5> make
Scanning dependencies of target compile_translations
[ 0%] Generating ru.qm
Updating '/home/term/Documents/incoming/scantailor-0.9.5/ru.qm'...
Generated 199 translations (199 finished and 0 unfinished)
[ 0%] Built target compile_translations
[ 1%] Generating ui_OutputOptionsWidget.h
[ 1%] Generating ApplyColorsDialog.h.moc
[ 1%] Generating ChangeDpiDialog.h.moc
[ 2%] Generating ImageView.h.moc
[ 2%] Generating OptionsWidget.h.moc
[ 3%] Generating ui_OutputChangeDpiDialog.h
[ 3%] Generating ui_OutputApplyColorsDialog.h
Scanning dependencies of target output
[ 4%] Building CXX object filters/output/CMakeFiles/output.dir/ApplyColorsDialog.cpp.o
[ 4%] Building CXX object filters/output/CMakeFiles/output.dir/ChangeDpiDialog.cpp.o
[ 5%] Building CXX object filters/output/CMakeFiles/output.dir/ImageView.cpp.o
[ 5%] Building CXX object filters/output/CMakeFiles/output.dir/Filter.cpp.o
In file included from /home/term/Documents/incoming/scantailor-0.9.5/./AbstractFilter.h:22,
from /home/term/Documents/incoming/scantailor-0.9.5/filters/output/Filter.h:23,
from /home/term/Documents/incoming/scantailor-0.9.5/filters/output/Filter.cpp:19:
/home/term/Documents/incoming/scantailor-0.9.5/foundation/RefCountable.h:26:22: error: QAtomicInt: No such file or directory
In file included from /home/term/Documents/incoming/scantailor-0.9.5/./AbstractFilter.h:22,
from /home/term/Documents/incoming/scantailor-0.9.5/filters/output/Filter.h:23,
from /home/term/Documents/incoming/scantailor-0.9.5/filters/output/Filter.cpp:19:
/home/term/Documents/incoming/scantailor-0.9.5/foundation/RefCountable.h:51: error: ‘QAtomicInt’ does not name a type
/home/term/Documents/incoming/scantailor-0.9.5/foundation/RefCountable.h: In constructor ‘RefCountable::RefCountable()’:
/home/term/Documents/incoming/scantailor-0.9.5/foundation/RefCountable.h:31: error: class ‘RefCountable’ does not have any field named ‘m_refCounter’
/home/term/Documents/incoming/scantailor-0.9.5/foundation/RefCountable.h: In member function ‘void RefCountable::ref() const’:
/home/term/Documents/incoming/scantailor-0.9.5/foundation/RefCountable.h:43: error: ‘m_refCounter’ was not declared in this scope
/home/term/Documents/incoming/scantailor-0.9.5/foundation/RefCountable.h: In member function ‘void RefCountable::unref() const’:
/home/term/Documents/incoming/scantailor-0.9.5/foundation/RefCountable.h:46: error: ‘m_refCounter’ was not declared in this scope
make[2]: *** [filters/output/CMakeFiles/output.dir/Filter.cpp.o] Error 1
make[1]: *** [filters/output/CMakeFiles/output.dir/all] Error 2
make: *** [all] Error 2

Цитата:

Теперь релизы как пирожки пекутся ?

Не заставлять же пользователей еще месяц-два терпеть падения, когда они уже исправлены.

terminat0r

Цитата:

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

Это все стандартные ситуации, для работы с которыми и был создан СТ. Я говорил о конкретном нетипичном случае - скан огромных размеров с небольшой зоной контента посередине. Если его не от-crop'ить заранее, просто не хватит памяти на его обработку. Такой скан я вижу впервые, и даже не могу предположить, откуда он такой получился.


Цитата:

У меня проблемы с компилированием последней версии. Можете что-то посоветовать?

У вас Qt версии 4.3.1, а нужна минимум 4.4.0.

В общем, новая книга -- новые проблемы.
а) Если страница отсканирована косо, и в полезную область попадает пустое место -- там образуется черная полоса.
б) Если на краю страницы присутствует белая полоса -- там при бинаризации тоже образуется черное пространство, причем оно съедает даже рядом стоящий текст.
в) Отточия съедаются "удалением пятен".
Архив (там в папке out уже сохраненный проект) -- http://dump.ru/file/2572611
Обратите внимание на 2 и 4 страницы. 2 страница -- пример (а), 4-ая -- пример сразу (б) и (в).
Я решил проблему (б) тем, что вручную заливал белое пространство цветом основного фона, и замазывал кисточкой неровности, но как постоянное решение это, я думаю, не годится.
Происхождение файлов: получил в виде PDF, собранного из необработанных сканов. Очень типичный случай.

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

iit512

Цитата:

хочется иметь возможность, щелкая на превью, не вызывать нового вывода, а просто просматривать картинку в увеличенном виде

И как ты себе это представляешь ?
С трудом представляю гонки на трамваях.

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

Занимаюсь вот какой проблемой, после завершения обработки изображений увеличились размеры файлов. У меня были файлы Gray tif многостраничные возможно это из-за color\gray
для выходных файлов. С black\white проблем нет. Разбираюсь пока. Напишу потом.

Цитата:

а) Если страница отсканирована косо, и в полезную область попадает пустое место -- там образуется черная полоса.
б) Если на краю страницы присутствует белая полоса -- там при бинаризации тоже образуется черное пространство, причем оно съедает даже рядом стоящий текст.

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


Цитата:

в) Отточия съедаются "удалением пятен".

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

MDunleavy
возможно у Вас изначальные тифы были с LZW или ZIP компрессией, а на выходе без, в этом случае размер файлов увеличивается примерно в 1,5-2 раза.

Цитата:

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

Не делать повторный вывод, если никакие параметры не изменились - такое есть в планах.

Добавлено:

Цитата:

возможно у Вас изначальные тифы были с LZW или ZIP компрессией, а на выходе без, в этом случае размер файлов увеличивается примерно в 1,5-2 раза.

На выходе как раз LZW. ZIP (он же Deflate) жмет чуть лучше, но не всеми программами читается. А еще бывают TIFFы с jpeg компрессией. Вот тут разница существенная будет. Но в нашем деле jpeg'ов надо всячески избегать.

Цитата:

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

Прошу прощения, я, наверное, не понял, что Вы имеете в виду.
Представляю я себе это очень просто: в меню вверху слева появляется дополнительный пункт, под названием, например, "Результат вывода". Там можно будет просматривать результат, а если разработчик захочет, то впоследствии добавить и обработку изображений, например, желанный ластик. В СК все эти вещи давно есть.

Добавлено:

Цитата:

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

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

Цитата:

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

Я так и делаю. Но проблема в том, что среди тех книг, которыми я занимаюсь, 2/3 имеют более половины таких страниц. Это -- тысячи страниц. Не думаю, что это "не много". К тому же, очень многие "обычные" книги имеют оглавление с отточиями. Если специально не отслеживать этот эффект, то соответствующие страницы будут испорчены.

iit512

Цитата:

Представляю я себе это очень просто: в меню вверху слева появляется дополнительный пункт, под названием, например, "Результат вывода". Там можно будет просматривать результат, а если разработчик захочет, то впоследствии добавить и обработку изображений, например, желанный ластик. В СК все эти вещи давно есть.

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


Цитата:

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

Ага, действительно там есть белые поля искусственного происхождения, причем очень близко к контенту. Это на самом деле еще хуже, чем просто края скана. Плохая обработка таких сканов не баг, а известное с самого начала ограничение алгоритма выравнивания освещения. Вот комментарии прямо из исходников (EstimateBackground.h):

Код:
This implementation can deal with very complex cases, like a page with
a picture covering most of it, but in return, it expects some conditions
to be met:
1. The orientation must be correct. To be precise, it can deal with
a more or less vertical folding line, but not a horizontal one.
2. The page must have some blank margins. The margins must be of
a natural origin, or to be precise, there must not be a noticeable
transition between the page background and the margins.
3. It's better to provide a single page to this function, not a
two page scan. When cutting off one of the pages, feel free
to fill areas near the the edges with black.
4. This implementation can handle dark surroundings around the page,
provided they touch the edges, but it performs better without them.