» Scan Tailor: Часть 2

Сообщение "Бинаризация JPEG и TIFF, отсканированных с различным dpi" перенесено в топик Электронные книги: сканирование, обработка, сборка - IV.

StanFreeWare
Так в том то и дело, что делать какие-то выводы насчет бинаризации в ST по этим результатам совершенно невозможно:
Большинство символов в djvu на разных страницах одинаковые, в силу специфики кодирования со общим словарем.
По графику можно предположить, что 150jpeg70 просто сильнее отличается от других страниц (больше несловарных символов).

Tulon

Цитата:

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

Да.
И, по-видимому, это как-то связано с 16-битностью.
При этом интересно, что для файла IrfanView пишет: Original colors -> 65536, current colors -> 256.

Пересканировал с 8 битами, эффект пропал.

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

Вследствие используемых технологий утилитка работает только под .NET 3.5
ST Outliner 0.1

Выпустил версию 0.9.8. Брать на оффсайте.

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

Собирался после этого релиза вплотную заняться исправлением кривизны строк (деварпингом), но передумал, так как нашел задачу поважнее. Похоже, что Scan Tailor уже сделал пост-обработку достаточно простой для домохозяек*, и теперь осталось последнее для них препятствие - сборка страниц в DjVu или PDF. Вот этим и планирую заняться - сделаю простую GUIную прогу для сборки обработанных ST файлов в DjVu. Думаю за пару месяцев можно такую вещь сделать.

* Под домохозяйками в данном контексте я понимаю людей, которые не хотят заморачиваться. К таковым отнесу и себя.

Tulon

Цитата:

Вот этим и планирую заняться - сделаю простую GUIную прогу для сборки обработанных ST файлов в DjVu.

Это было бы замечательно, но как насчет того, чтобы встроить экспорт в djvu (pdf) в сам ST как еще один этап?
Я на днях изучал исходники djvulibre (cjb2), и понял, что многие функции уже есть в ST, например выделение связных компонент, очистка от мелкого мусора.
Если делать экспорт в tiff, а затем кодировать, то будет делаться двойная работа, сначала в ST, затем в кодировщике djvu. Что, на мой взгляд, не оптимально.

Цитата:

В последние дни правил мелкие проблемы

А что именно, если не секрет?
На первый взгляд -
1) поправлено управление наклоном резака при увеличенном масштабе.
2) по-умолчанию теперь маленький веник (за что отдельное спасибо - одну книжку средний веник сильно попортил - й заменил на и, а также переносы поудалял).
Жаль, что не прислушались к вращению по Ctrl+колесико.

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

U235

Цитата:

Это было бы замечательно, но как насчет того, чтобы встроить экспорт в djvu (pdf) в сам ST как еще один этап?
Я на днях изучал исходники djvulibre (cjb2), и понял, что многие функции уже есть в ST, например выделение связных компонент, очистка от мелкого мусора.

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

StanFreeWare

Цитата:

А что именно, если не секрет?

Смотрите ссылку "Последние изменения в дереве исходников" в шапке.


Цитата:

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

Наводит на мысль о неправильном DPI. Выкладывайте пример, если еще не выкладывали.

cnf

Цитата:

Мне очень не хватает вертикальной линейки, чтобы вручную точно регулировать высоту блока полезной области. Хоть и не часто, но попадаются книги, где линейка очень нужна.

Ну вы хотябы объясните зачем.

Цитата:

Ну вы хотябы объясните зачем.

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

cnf

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

cnf
ОК, понял. Буду иметь в ввиду, но естественно ничего не обещаю.

Цитата:

Выкладывайте пример, если еще не выкладывали.

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

Цитата:

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

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

StanFreeWare
Однако проблем с деспеклингом я там и не увидел. В области текста средний веник ничего не удалил.

cnf

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

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

Tulon

Цитата:

* Под домохозяйками в данном контексте я понимаю людей, которые не хотят заморачиваться. К таковым отнесу и себя.

Если под "нежеланием заморачиваться" понимать отказ от Dewarping (и BR-Lighting Correction) - то это плохо кончится - поскольку это просто де-факто пропаганда "делайте книги некачественно".

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

Цитата:

сделаю простую GUIную прогу для сборки обработанных ST файлов в DjVu.

Собираетесь захватить весь "рынок" DjVu-книгосканирования? Своей недостаточно качественной продукцией ("не-заморачивательной")? А не слишком ли грандиозно?
Только не забывайте, что фриварных качественных DjVu-кодировщиков не существует (DjVu Solo 3.1 не в счёт, т.к. он не консольный). miniDjVu - это игрушка и баловство - крайне сомнительно, что его можно рекомендовать как серьёзное средство для массового дежавючения. Адекватность miniDjVu ещё предстоит доказать многочисленными тестами и исследованиями.

P.S. СканКромсатор, при всех своих колоссальных недостатках, всё-таки гораздо более "честная" программа (без этой лживо-лицемерной "не-заморачивательности"), чем Ваш СТ.

P.P.S. В Вашей программе (СТ) нет даже ластика.

monday2000


Цитата:

miniDjVu - это игрушка и баловство - крайне сомнительно, что его можно рекомендовать как серьёзное средство для массового дежавючения.

Ну, лично я активно использую и полагаю, что усилия, затраченные на его доводку, для меня вполне окупились. Впрочем, здесь это оффтопик.

Tulon

Цитата:

Похоже, что Scan Tailor уже сделал пост-обработку достаточно простой для домохозяек*, и теперь осталось последнее для них препятствие - сборка страниц в DjVu или PDF.

А как же OCR? Распознавание текста никто не сможет сделать лучше FineReader. Из него же потом собирается PDF или Djvu. Зачем приделывать ST лишнюю функцию, которую он все равно не сможет делать качественно?

Цитата:

Распознавание текста никто не сможет сделать лучше FineReader

Не знаю, не знаю, я не стал бы так говорить
Например www.cuneiform.ru Если допилить, то будет ничем не хуже. Уже сейчас результаты достаточно хорошие.

C0USIN

Цитата:

А как же OCR? Распознавание текста никто не сможет сделать лучше FineReader. Из него же потом собирается PDF или Djvu. Зачем приделывать ST лишнюю функцию, которую он все равно не сможет делать качественно?

ОCR для сборки в DjVu не является необходимым, и прикручивать его к ST никто не собирается.

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

1) Некоторые свободные OCR-программы в качестве стандарта, де-факто, позволяют для вывода результата использовать формат hOCR в котором имеется информация о расположении символов в файле.

и ocropus и версия cuneiform для Linux (есть mingw порт для Win32) умеют выводить в hocr.

2) Есть программа hocr2djvused - которая как раз и занимается добавлением текстового слоя. (С помощью ещё и djvused)


Цитата:

HOCR2DJVUSED(1) hocr2djvused manual HOCR2DJVUSED(1)

NAME
hocr2djvused - hOCR to djvused script converter

SYNOPSIS
hocr2djvused [option...]

DESCRIPTION
hocr2djvused reads a hOCR[1] file (as produced by OCRopus[2] or Cuneiform[3]) from the standard input and converts
it to a djvused script.

....

djvused


Цитата:

DJVUSED(1) DjVuLibre-3.5 DJVUSED(1)

NAME
djvused - Multi-purpose DjVu document editor.

SYNOPSIS
djvused [options] djvufile

DESCRIPTION
Program djvused is a powerful command line tool for manipulating multi-page documents, creating or editing annota‐
tion chunks, creating or editing hidden text layers, pre-computing thumbnail images, and more. The program first
reads the DjVu document djvufile and executes a number of djvused commands.

Djvused commands can be read from a specific file (when option -f is specified), read from the command line (when
option -e is specified), or read from the standard input (the default).

В общем, можно обойтись и без этой функции в ST, потом отдельно обрабатывая djvu для добавления текстового слоя.

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

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

Выход на DJVU - это логическое развитие программы. Попутно автору придется решить ряд задач, которые уже отмечались ранее. Это и выравнивание текстовой области, и приведение ее размера к публичным форматам. Безусловно, все это очень нужно.
Уверяю Вас, пока не стоит думать об OCR - тут дел автору хватит... Одно потянет другое...
С наилучшими пожеланиями..
Успехов

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

Цитата:

это программа для сканобработки

повторюсь, потребительская ценность этой программы много выше

Добавлено:
добавлю, термин
Цитата:

для домохозяек

лучше бы исключить!
Это неуважительно к потенциальным пользователям...

Dashout
ну да, еще твейн прикрутить и пр.
а термин про домохозяек это цитата
извиняюсь за оффтоп

VadimirTT
А насчет твейна, кстати, неплохая мысль.
Очень многие "гуманитарии" не слезут с технологии FR->PDF именно из-за пакетного сканирования..

StanFreeWare

Цитата:

А насчет твейна, кстати, неплохая мысль.

А как тогда же кроссплатформенность?

Если учесть, что автоочистка сканов не может быть идеальна на все 100%, то реализация кодирования в djvu приемлема только при наличии в программе элементарного ластика для "доведения до ума" сканов вручную.

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