» Scan Tailor

Tulon

Цитата:

Чем выводить по две версии каждого файла, проще выводить в черно-белом файлы где нет картинок, и в сером / цветном - где есть.

Нет, Вы не поняли - не надо выводить по 2 версии каждого файла, я предлагаю именно вариант
Цитата:

выводить в черно-белом файлы где нет картинок, и в сером / цветном - где есть.

- т.е. просто выводить их в разные папки на выходе - чтобы в каждой папке оказались TIF-файлы одинаковой глубины цвета.

Цитата:

После чего научить DjVu Small или какой другой кодировщик выставлять оптимальный режим для каждого типа файлов.

"На-лету" они этого не умеют (т.е. не умеют "в лоб" кодировать разнородную смесь - видимо, из-за возможных сложностей со словарями). Я же предлагаю "задним числом" автоматически вставлять одиночные серые DjVu в нужные места многостраничного ЧБ DjVu - например, ориентируясь по названиям одиночных серых DjVu в виде номеров страниц.

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

Tulon
Это пока слишком круто для нас. То есть смысл это делать появится лишь в том случае, если miniDjVu научиться кодировать не хуже коммерческого кодировщика. А в имеющийся коммерческий кодировщик documenttodjvu.exe такое изменение не внесёшь (насколько я знаю).

Добавлено:
Топик по CuneiForm: http://forum.ru-board.com/topic.cgi?&forum=5&topic=25677&glp

Добавлено:
P.S. Вышел Irfan View 4.20

шапка включена

Раз уж шапку зачем-то включили - то я добавил туда пару полезных линков.

У меня возникла идея по поводу кодирования смеси тифов разной глубины цвета: это можно делать ещё и посредством исключительно msepdjvu - т.е. без участия documenttodjvu. (Рассматривается случай не-цветной книги - чёрно-белый текст с редкими полутоновыми рисунками-фотографиями).

Алгоритм такой:

На входе - набор свежеотсканированных grayscale-тифов.

1. Обычные страницы с чёрно-белым текстом просто переводим в ЧБ-тифы - порогово-адаптивной (вроде бы есть такая ) бинаризацией (просто пороговая слишком грубовата - по словам bolega).

2. Страницы, содержащие полутоновые рисунки, обрабатываем по методу разделённых сканов:

Делим grayscale-скан на 2 файла: отдельно - ЧБ-текст (ЧБ-тиф) и отдельно - полутоновая фотография (grayscale-tif) (так, чтобы при совмещении получился опять исходный скан). Как я понимаю, сейчас это делается путём проставления Picture-зон в СК. Обрабатываем эти 2 "полускана" так, чтобы получить из них единый sep-файл. Эта методика уже известна, для неё есть утилита FSD by Manfred.

Теперь пошло кое-что новое:

3. Обычные ЧБ сканы из п.1 также конвертируем в sep-файлы - по такому алгоритму:

Цитата:

tifftopnm bw1.tif | pnmtodjvurle > bw1.sep
tifftopnm bw2.tif | pnmtodjvurle > bw2.sep
tifftopnm bw3.tif | pnmtodjvurle > bw3.sep
...
tifftopnm bw100.tif | pnmtodjvurle > bw100.sep

4. Теперь мы имеем смесь sep-файлов, которую просто собираем в готовый многостраничный DjVu-файл при помощи либо msepdjvu, либо csepdjvu:

Цитата:

msepdjvu bw1.sep bw2.sep gray1.sep bw3.sep bw4.sep gray2.sep bw5.sep demo.djvu

Ещё можно попробовать профиль кодирования подсунуть (и размер словаря также). Я попробовал закодировать такую разнородную (по глубине цвета) смесь sep-файлов - всё нормально получилось.

Небольшая новизна в том, что documenttodjvu тут вообще не используется. Тогда как в методе разделённых сканов (насколько я понимаю) по методу делаются вручную отдельно сканы с картинками, затем вся оставшаяся книга кодируется посредством documenttodjvu, а потом DjVu-картинки вручную вставляются в нужные места ЧБ-DjVu-книги.

Практическая полезность такого метода "Разнородное sep-кодирование" будет зависеть ИМХО от того, можно ли к нему применить профиль кодирования, или нет (т.е. насколько выигрышен получится размер DjVu).

Я тут немного поэкспериментировал с DjVu Small 0.3.1. Выяснил интересные для себя вещи:

1. Оказывается, documenttodjvu.exe всё-таки умеет правильно кодировать "на-лету" разнородную смесь, состоящую из ЧБ, серых и цветных тифов. Если, например, поставить в DjVu Small профиль "user B/W (300 dpi)" и выбрать опцию "Документ -> DjVu" (т.е. использование documenttodjvu.exe) - то при закодировании всё нормально получается - ЧБ-тифы кодируются, по-видимому, с выбранным профилем "user B/W (300 dpi)", а серые и цветные - по-видимому, с профилем "Scanned". Я раньше ошибочно считал, что при кодировании такой смеси возникнет ошибка - нет, не возникает.

2. Профили семейства "Photo" не работают с phototodjvu.exe - возникает ошибка "Illegal profile". И это не глюк DjVu Small 0.3.1 - при проверке через командную строку получается то же самое.

3. phototodjvu.exe (т.е. Фото -> DjVu) работает исключительно с профилем Default (т.е. это профиль "documenttodjvu").

4. И самое интересное: documenttodjvu.exe с профилем семейства "Photo" даёт при кодировании результат, идентичный использованию phototodjvu.exe с профилем Default (!).

Отсюда делаем интереснейший вывод: phototodjvu.exe - это всего лишь один из режимов работы documenttodjvu.exe, выделенный разработчиками (для удобства, наверное) в отдельную программу.

Значит, phototodjvu.exe можно смело выкидывать из DjVu Small 0.3.1 как излишество.

Добавлено:
Правда, phototodjvu.exe не умеет кодировать разнородную смесь, состоящую из ЧБ, серых и цветных тифов. ЧБ-тифы он просто пропускает при кодировании. А потребность в том, чтобы phototodjvu.exe умел это делать, быть может, есть - т.к. порой documenttodjvu ни с одним профилем (кроме Photo) не в состоянии удовлетворительно закодировать серые/цветные фотографии - вылезают артефакты слоя маски.

monday2000

Цитата:

Я тут немного поэкспериментировал с DjVu Small 0.3.1.

Вам название топика "Scan Tailor" не о чём не говорит?

trigliff
Все эти особенные виды кодирования не мыслимы без подготовки сканов какой-либо сканобрабатывающей программой. Я подразумеваю, что для этого можно приспособить Scan Tailor - в связке с (возможно, видоизменённой) DjVu Small - только надо разобраться в деталях.

Tulon
ИМХО имело бы смысл сделать отдельную программу, которая разрезала бы сдвоенные развороты пополам и/или отпиливала ошмётки от одиночных сканов. Я это называю "унификация".

Такой программе хорошо бы иметь всего 2 функции: split-page и deskew. Программе не следует менять DPI и глубину цвета. Если на входе серое - то и на выходе тоже, если на входе ЧБ - и на выходе ЧБ и т.д.

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

1. Отключение сглаживающего фильтра.
2. Подгрузка в память фоновым тредом 5-10 впереди- и послестоящих за данным сканов. (кстати, я так и не знаю - есть ли это в СК? В WinDjView есть.)
3. Отображение сканов в половинном масштабе - по сравнению с Fit Window как сейчас.

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

Именно в подобной программе можно пойти на такие жертвы, как пп. 1 и 3 - т.к. в общем случае тут точность не важна, а вот скорость листания - очень даже.

Сразу после загрузки сканов в такую программу надо бы как-то выбирать один из 2 вариантов:

а. Сдвоенные развороты.
б. Одиночные сканы.

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

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

В отличие от СК, split-резак должен автозапоминать свою последнюю выставленную позицию - а в СК нужно, всякий раз подвинув резак, кликать на нём Copy current position to -> all down - это лишний гемор.

Да, лента с thumbnails ИМХО не нужна в такой программе - будет лишь фактором, тормозящим производительность.

Добавлено:
Процедура унификации ИМХО должна быть самой первой в цепочке обработки сырых сканов. До унификации имеет смысл делать только выравнивание освещённости (если есть нужда) (как это делает Book Restorer 4.1) - потому что, возможно (я не знаю) алгоритм выравнивания освещённости "смотрит" в каждой обрабатываемой точке на близлежащие пространства.

Унификация ИМХО совершенно необходима - она сильно упрощает всю последующую скан-обработку.

Кстати, попросите у U235 исходники 5 алгоритмов выравнивания освещённости, которые он в прошлом году передал bolega, после чего bolega воплотил их в последнем СК.

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

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

Включать/отслючать сглаживание на отдельных этапах мне никто не мешает уже сейчас.

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


Цитата:

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

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


Цитата:

В отличие от СК, split-резак должен автозапоминать свою последнюю выставленную позицию - а в СК нужно, всякий раз подвинув резак, кликать на нём Copy current position to -> all down - это лишний гемор.

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


Цитата:

Да, лента с thumbnails ИМХО не нужна в такой программе - будет лишь фактором, тормозящим производительность.

Да нет - весьма полезная вещь. Особенно в пакетном режиме.

Насчет выравнивания освещенности - до этого еще руки не дошли.

Tulon

Цитата:

Лучше бы конечно без этого обойтись.

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

Цитата:

Вы, наверное, ещё не видели те препоганейшие в этом отношении сканы, которые мне попадались.

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

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

Tulon

Цитата:

Выпустил новую версию.

1. Вывод в PNG? Коллективный разум давно выявил, что самое лучшее - TIF - см. http://www.djvu-soft.narod.ru/scan/scan_likbez.htm .

2.
Цитата:

так что попридержите пока претензии на эту тему.

Всё же ждём решения этого вопроса.

3. Хотелось бы увидеть исходники единым зипом на http://scantailor.sf.net .

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

В Qt паршивая поддержка TIFF'а, в частности туда не пишутся DPI. Да и вообще этот формат - настоящий франкенштейн. Я с ним уже намучился когда делал поддержку чтения.

Исходники в tar.gz выложу на днях.
Улучшений по usability у меня уже много в TODO накопилось - буду постепенно ими заниматься.

Хэлп? Ну, я думал там все понятно, хотя пару моментов можно было бы прояснить. Ести какие-то конкретные вопросы?

Работать предлагаю так:
Создаем проект, добавляем файлы, если попросят - исправляем DPI.
Если нужно, правим ориентацию страниц.
Переходим сразу на Select Content. Предыдущие этапы пускай работают на автомате. Запускаем пакетную обработку (batch processing). Следим за лентой предпросмотра. Если видим что не так, кликаем на ту страницу (это останавливает пакетную обработку), правим. Если проблема не в выделении контента, а скажем в разрезке страниц - переходим на соответствующий фильтр и исправляем проблему там. Затем возвращаемя на Select Content и опять запускаем пакетную обработку. Тут есть одно неудобство - пакетная обработка начнется опять сначала, но все-таки пойдет быстрее, чем в первый раз, поскольку результаты операций запоминаются.
Закончив Select Content, идем на Page Layout и правим поля, центровку, и подобные вещи.
Теперь идем на output, выставляем нужные параметры, и опять запускаем пакетную обработку.

Tulon
А Вы, в свою очередь, попробуйте мою "альтернативу Кромсатору", написанную за один вечер "Альтернатива" представляет собой тот же Кромсатор, сопровожденный краткой инструкцией из трех (3-х!) пунктов. Единственный параметр, который, возможно, придется покрутить - порог бинаризации.
Таким образом, снимается проблема указанная здесь:
Цитата:

По сравнению со СканКромсатором планируется большее удобство использования, большая интерактивность, но при этом не меньшая автоматизация процесса.

Т.е. практически полная автоматизация, удобство, отсутствие необходимости разбираться в настройках и т.п.
Сможет ли в такой "конфигурации" СК тягаться со Scan Tailor'ом в плане юзабилити?

Некоторого результата удалось добиться. Загрузил довольно сложную книгу (1935 года). На выходе получил обработанные сканы - обрезанные, выровненные. Как при обрезке, так и при выравнивании пока много ошибок.
О качестве обработки растра, понятное дело, говорить не приходится. bolega был прав, что никакие алгоритмы адаптивной бинаризации не заменят бинаризации с предварительной обработкой полутоновых изображений (с возможностью контроля со стороны пользователя).
Т.е. концепция действительно оригинальная, но пока СТ представляет собой некую раму, на которую предстоит навесить двигатель, трансмиссию, колеса и т.д., и т.п. Искренне желаю удачи и терпения в этом нелегком деле. Готов тестировать время от времени новые версии.

Tulon
А PNG поддерживает 24-битный режим? Я попробовал - вроде бы да. Это, значит, только GIF не поддерживает ни запись о разрешении, ни больше 256 цветов?

Цитата:

Ести какие-то конкретные вопросы?

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

Попробовал я пред-настроенный Кромсатор от ghosty. Это конечно шаг вперед по сравнению с оригиналом. Все-же у СТ гораздо больший потенциал.

Несколько страниц где СТ ошибается, выложите куда-нибудь, а ссылку сюда.


Цитата:

А PNG поддерживает 24-битный режим? Я попробовал - вроде бы да.

Поддерживает.

Просили исходники в одном архиве - получите:
http://downloads.sourceforge.net/scantailor/scantailor-src-20080804.tar.gz?use_mirror=osdn

Tulon
Спасибо!

Добавлено:
Посмотрите, пожалуйста, на досуге методичку от Arcand:

http://abab.front.ru/CorelScan.RAR (CHM, 831 КБ)

Это инструкция по улучшающей обработке grey-сканов с использованием Corel PHOTO-PAINT. Подозреваю, что это - самая продвинутая технология из ныне известных (превосходящая даже возможности СК в части улучшающей обработки grey-сканов).

Есть ли шанс когда-нибудь в далёком будущем реализовать такие же обработки в ScanTailor? Дело в том, что использовать Corel PHOTO-PAINT - явно удел избранных, а нужен аналогичный, доступный и удобный для чайников инструмент. Насколько я понимаю, СканКромсатор такие обработки делать (вроде бы) не умеет (или об этом малоизвестно/неизвестно).

У того CHM файла кодировка не прописана. Он у меня в Линуксе не читается. Картинки впрочем дают понять, о чем речь. Тут имеет смысл говорить о том или ином фильтре в отдельности. Например выборочное размывание - дело хорошее и реализуется не слишком сложно. Думаю со временем оно появится в СТ. Начсет других фильтров, можете высказывать пожелания, но только поконкретнее, а не просто "фильтры как в Corel Photo Paint".

Цитата:

У того CHM файла кодировка не прописана

Вот я в Pdf на скорую руку напечатал:

http://rapidshare.com/files/135727861/CorelScan.rar.html

Tulon
В формате HTM:

http://www.djvu-soft.narod.ru/scan/corel_scan.htm

Там на самом деле читать было и не обязательно, все видно по скриншотам. Ответ все тот же. Есть там пара вещей, которые хотелось бы видеть в СТ, но разговор стоит вести по каждой конкретной фичи в отдельности.

Да это дело не срочное - это на весьма далёкую перспективу.

Выпустил новую версию. Брать как обычно на http://scantailor.sf.net

Изменения были такие:
* Новый алгоритм разделения страниц. Ищет именно линию сгиба, а не белое пространство между страницами. Если ничего не находит, используется старый алгоритм.
* Улучшена бинаризация Sauvola. Теперь не такие тонкие буквы выдает. Возможно теперь стоит совсем убрать бинарицацию Wolf, потому как она всегда выдает слишком жирные результаты.
* Немного улучшено (надеюсь) нахождение рамки контента.
* Немного улучшена usability, там где это было легко сделать.
* Пофиксен баг (был только под Windows) из-за которого глючила лента предпросмотра на этапе вывода.

В общем софт вполне готов к реальному использованию. Хотелось бы услышать, чего именно вам лично (обращаюсь ко всем) не хватает, чтобы перейти с СК / БР / что-то еще на СТ.

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

Tulon
Спасибо, будем пробовать.

Хотелось бы сразу предложить выкласть To-Do на хомяке с раставленной приоритезацией.

И народ будет знать в каком направлении ведется работа и Вас будут меньше дергать с одними и теми же предложениями.

Правильно я понимаю, что страницы с картинками пока нельзя обработать (текст -> b/w, картинки -> grey или color)?

Tulon

Цитата:

В общем софт вполне готов к реальному использованию. Хотелось бы услышать, чего именно вам лично (обращаюсь ко всем) не хватает, чтобы перейти с СК / БР / что-то еще на СТ.

К сожалению, в прошлой версии не нашел никаких параметров бинаризации.
Не хватает, в первую очередь, различных видов сглаживаний (Blur)/увеличения резкости (Sharpen), коррекции освещенности...