» ScanKromsator СканКромсатор (Часть 2)

monday2000

Цитата:

избирающую в отдельную папку все сканы, подлежащие распознаванию

Тут мне вообще непонятна проблема. Я уже распознавал сотни книг из-под SK, и никаких неудобств не имел. Как раз именно потому, что файлы, из которых вырезаны зоны, имеют обычную сквозную нумерацию и посему стоят в списке там, где им и положено. (Для себя я сделал вообще проще: я вызываю распознавание FR непосредственно из SK, напрямую обращаясь к FR dll, т.е. без загрузки его GUI).
Кстати, в новой версии SK есть поддержка drag'drop файлов из проводника. Есть она и в FR

bolega

Цитата:

я вызываю распознавание FR непосредственно из SK, напрямую обращаясь к FR dll, т.е. без загрузки его GUI

Да что же Вы молчите-то! Расскажите, как это Вы делаете? Это же как здорово! Просто мечта. Какая версия FR?

Цитата:

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

Но ведь мешают "XXXX.sep.tif" и "pic.XXXX.tif" - они же сидят в той же папке, и их надо как-либо отсеивать в сторону (а оcтавшееся скармливать FR).

monday2000

Цитата:

как это Вы делаете?

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


Цитата:

Просто мечта.

Да, это позволяет выполнять распознавание без участия пользователя, с помощью батника или скриптов. Результат распознавания - frf-файлы, т.е. как обычно. На них, в свою очередь, можно, опять же, без участия пользователя, напускать утилиту gencho. Смысл всего этого - получить готовый распознанный djvu без какого-либо итерактива.

Добавлено:

Цитата:

Но ведь мешают "XXXX.sep.tif" и "pic.XXXX.tif"

pic.XXXX не мешают, они стоят в конце списка.
XXXX.sep мешают, но они никак не подвязаны к заданию SK, поэтому в принципе их можно и в отдельную папку генерировать, тут я согласен

Добавлено:

Цитата:

Какая версия FR?

8. Про другие не знаю

bolega

Цитата:

Поэтому я просто пошлю Вам его координаты в ПМ

Давайте, а ещё лучше - ключевые слова, по которым можно найти эту утилитку в Сети.

Цитата:

pic.XXXX не мешают, они стоят в конце списка.

Ну, не совсем. Всё равно при открытии в FR надо следить, чтобы pic.XXXX не попали в селекцию. Может быть, это с чьей-то точки зрения - мелкое неудобство, но всё же - неудобство.

Было бы здорово вообще "совершенно бездумно" открывать в FR файлы из СК-папки out, не задумываясь о наличии там pic.XXXX.

К тому же, в том же BR файлы открываются по Automated Import - т.е. всё содержимое папки.

Идеально было бы "генерировать в отдельную папку pic.XXXX (наряду с XXXX.sep)".

Добавлено:
Нельзя ли настроить FR так, чтобы он автоматом отсеивал pic.XXXX? Может, как-то через его встроенную систему скриптов?

Цитата:

Было бы здорово вообще "совершенно бездумно" открывать в FR файлы

Вы как всегда печетесь о полнейших маргиналах. А вот я от них ничего хорошего не жду. Будут ли они на 5 сек дольше грузить файлы в FR, мне абсолютно безразлично. Слабое место все равно не в этом, а в программе обработке и конечно, в яйцах (помните поговорку про танцора?).



Добавлено:

Цитата:

найти эту утилитку в Сети

Это не утилитка вовсе, а метод использования служб FR

bolega
Сделайте ещё, пожалуйста, генерацию ini-файла со списком и координатами pic.XXXX на XXXX.tif. И чтобы этот ini-файл создавался, скажем, в папке out.
Тогда не потребуется генерировать XXXX.sep.tif в СК - это будет автоматически делать DjVu Sep во время своей работы.

Добавлено:

Цитата:

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

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

Добавлено:

Цитата:

Слабое место все равно не в этом, а в программе обработке

Да уж действительно. Я тут интересовался - оказывается, нет и не существует даже достаточно приличного open-source вьювера. Основа основ любой программы сканобработки (70-80%) - это достаточно качественный графический движок (на уровне СК). И вот - нет такого пока. Если и есть что-то приличное (вьювер) - так с закрытыми исходниками.

Видимо, это и есть та самая причина, что Вы удивлялись как-то, почему никто не делает ещё одну программу по сканобработке - не могут никто сделать нормальный графический движок. Даже AndyZ не может в WinDjView. Вот и в Scan Tailor этому не уделено должного внимания. И вообще тема "графический движок" даже как-то и не звучит на программистских сайтах/форумах.

Будь такой движок (обязательно документированный более-менее) - давно народ понаделал бы хотя бы самых простейших софтов по сканобработке (типа "обрезка по фиксированной рамке" - для сканов журналов удобно - ни СК, ни Ирфан тут не "заточены").

Вот если бы исходники СК были открыты, то можно было бы там подсмотреть архитектуру графического движка и воссоздать его (движок СК) уже на C++, а также максимально задокументировать. ИМХО тут проблема именно в архитектурных решениях (графического движка).

monday2000

Цитата:

Сделайте ещё, пожалуйста, генерацию ini-файла со списком и координатами

Сделаю.


Цитата:

Тогда не потребуется генерировать XXXX.sep.tif в СК - это будет автоматически делать DjVu Sep во время своей работы.

Только не забудьте, что просто слить картинку с белой страницей зачастую мало, требуется предварительно Upsample ее до dpi текстовой части, чтобы dpi XXXX.sep.tif и XXXX.tif были одинаковыми. У меня, например, они всегда разные: текст 600dpi, а зоны - 300, и только при слиянии зон их dpi тоже доводится до 600. Хранить зоны в 600dpi, при том, что они сосканированы в 300, считаю только лишней тратой места, т.е. предпочитаю апсэмплить их уже в последний момент, на этапе merge

Добавлено:

Цитата:

то можно было бы там подсмотреть архитектуру графического движка и воссоздать его (движок СК) уже на C++,

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

bolega

Цитата:

требуется предварительно Upsample ее до dpi текстовой части,

В библиотеке FreeImage есть Bicubic resample - надеюсь, его качества будет достаточно. DPI и размеры хранятся в заголовке файла. Важно, чтобы значение DPI было истинным - а не 96 dpi.

Цитата:

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

Нужен не код - нужны общие идеи, архитектура. Код нужен только для написания быстрого ресемплинга - что, хоть и проблема, но худо-бедно решаемая.

bolega

Цитата:

Поэтому я просто пошлю Вам его координаты в ПМ

Что же не присылаете?

monday2000

Цитата:

Что же не присылаете?

Автор сказал, что сам опубликует. Что и сделал в топике по сканированию


Цитата:

Нужен не код - нужны общие идеи, архитектура

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

bolega

Цитата:

Что и сделал в топике по сканированию

Имеется в виду Melirius, выложивший нечто грандиозное? Передавайте ему привет - т.к. я в eBookz не вхож.

P.S. ИМХО надо поставить цель перейти в будущем с FR на CuneiForm, а от FR полностью отказаться. Качество распознавания CuneiForm весьма приличное. Глобальная цель -уйти по-максимуму от не-open-source софтов во всей цепочке сканобработки (в т.ч. от СК). Оставить только documenttodjvu и pdftodjvu - и всё, всё остальное должно быть open-source и под свободной лицензией. Замена documenttodjvu и pdftodjvu на соответствующие open-source аналоги - дело значительно более отдалённого будущего.

Добавлено:
bolega
Выложите, пожалуйста, эту систему "распознавание в FR без запуска его GUI" отдельно небольшим пакетом (можно в варезный топик по FR) - а то качать ~ 350 МБ от Melirius явно не вариант.

Цитата:

~ 350 МБ

Че-то Вы как-то легко округлили в большую сторону. Может все-таки ~200 без хэлпов? И почему самого Melirius, как автора пакета, не попросите?

monday2000
http://mihd.net/64brsaf

bolega
Спасибо, этот хелп я уже скачал, у меня же в eBookz доступ "только чтение" (я это имел в виду под "не вхож" - не совсем точно выразился). Надо будет попросить Генчо интегрировать эту фичу в DjvuOCR (и довести её до ума сколь возможно).
DmitryKz

Цитата:

Че-то Вы как-то легко округлили в большую сторону. Может все-таки ~200 без хэлпов?

Даже 200 слишком много. Сравнить с http://www.djvu-soft.narod.ru/basic.htm - так там и 30 метров не наберётся.

Цитата:

И почему самого Melirius, как автора пакета, не попросите?

Так Melirius может сюда и не заглядывает особо часто.

А вообще - Melirius совершает очередную попытку подогнать в одну систему готовые разнородные софты. Это, скорее всего, тупиковый путь. Лучше самостоятельно писать сканобрабатывающие open-source программы. Или хотя бы сканобрабатывающие алгоритмы - в виде консольных экзешников (например, на базе FreeImage - ИМХО самое лёгкое) - которые передавать Tulon для интеграции в СТ. ИМХО самое актуальное на данный момент - суметь реализовать технологию CorelScan от Arcand в СТ (вроде бы в СК этого нет, но точно не знаю).
Но всё равно спасибо Melirius за такую большую работу. Оттуда можно выбрать немало полезных моментов.

Добавлено:
Выложил ссылки от Melirius:

http://www.djvu-soft.narod.ru/hi_fi_djvu.htm

monday2000

Цитата:

Лучше самостоятельно писать сканобрабатывающие open-source программы. Или хотя бы сканобрабатывающие алгоритмы - в виде консольных экзешников (например, на базе FreeImage - ИМХО самое лёгкое) - которые передавать Tulon для интеграции в СТ.

Пишите! Как только получится что-то хорошее, я с удовольствием включу в коллекцию.

Melirius
Я выложил отдельно Ваше описание распознавания в FR 8 без запуска его GUI:

http://www.djvu-soft.narod.ru/fr_auto.htm

Добавлено:
Именование файлов — «колхозный» стандарт

http://www.djvu-soft.narod.ru/kolxo3_ns.htm

Добавлено:
Melirius
Если можно, выложите, пожалуйста, исходный файл, из которого был создана Ваша Pdf-инструкция (который сконвертили в Pdf).

monday2000

Могу предложить, если Вы разбираетесь в LaTeX, отослать его Вам на мыло. Но без картинок Вы его не скомпилируете, а они весят в исходниках солидно. Чистый текст там пересыпан служебными словами, так что для копирования лучше не мудрствуйте лукаво, а выдирайте из PDF'а.

Melirius
Интересный раздел в Вашей доке - "4.2.1 Настройки picture-зон для цветного текста или line-art" (про СК). Пока ничего не пойму, о чём там. Очень сложно всё расписано - практически невозможно понять что-либо.

Понятна лишь общая идея - постеризация (уменьшение количества цветов - "цветовая монотонизация") будущего foreground-субскана (задача, о которой я говорил в http://www.djvu-soft.narod.ru/scan/low_color_djvu.htm , и которую Arcand успешно делает в Corel PHOTO-PAINT).

Я так представлял себе, что Picture-зоны используются только для выделения будущих объектов background-субскана (для МРС). А, оказывается, Picture-зоны могут, что ли, также и выделять и как-то обрабатывать и будущие объекты foreground-субскана для МРС? (Т.е. цветной текст или line-art объекты)?

Если да, то тогда лучше ввести в CK вместо Picture-зон какие-нибудь foreground-picture-зоны и background-picture-зоны - чтобы не путать их воедино.

Кстати, кодировать постеризованные объекты именно методом МРС не всегда разумно - размер DjVu получается очень большим.

monday2000

Любимый вопрос студентам: что именно не понятно в разделе 4.2.1? С какой фразы, где происходит отключение головного мозга? Выясню - попытаюсь помочь.

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


Цитата:

Кстати, кодировать постеризованные объекты именно методом МРС не всегда разумно - размер DjVu получается очень большим.

Гхкм - а что написано в примечании на странице 18? Причём это утверждение верно только для прямоугольников, если же все буквы разноцветные, но на одном фоне, то МРС прекрасно работает - размер маленький.

вопрос снят, см ниже
Удачи

Melirius
Выложил у себя эту главу из Вашего хелпа отдельно:

http://www.djvu-soft.narod.ru/kromsator/cla_melirius.htm

Слегка обкорнал в конце, правда - вырезал всё не относящееся напрямую к СК. Скриншоты слегка замылены - т.к. выдраны из PDF.

Добавил в sk в главное окно thumbnail-ы сканов (опция).
Два режима:
1) загрузка иконок по мере просмотра, с кэшированием загруженного и упреждающего кэширования. Как в FR и djvusolo.
2) полное упреждающее кэширование.
В обоих вариантах загрузка идет фоновыми потоками, параллельными основному

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

Melirius
Не хочется Вас расстраивать, но, как говорится, лучше горькая, да правда...

Вот этот Ваш набор - Hi-Fi DjVu - ясное дело, обречён по определению быть, мягко говоря, э-э-э..., не слишком востребованным книгосканировщиками. Причины этого, думаю, понятны - нет нужды повторять. Мне просто жаль Вашего времени и труда - на что же Вы их гасите?:

Цитата:

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

Я могу Вам предложить иной путь приложения Ваших труда и времени - ИМХО гораздо более эффективный. Как я понял, Вам не чуждо хотя бы простейшее программирование. Вы могли бы писать алгоритмы сканобработки - допустим, в виде консольных Делфи-программ на базе FreeImage. Подробнее см. тут: http://forum.ru-board.com/topic.cgi?forum=5&topic=27424&start=120#12

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

Да, собственно, чаще всего эти алгоритмы не требуется с нуля изобретать - нужные идеи есть в Интернете.

Полученные алгоритмы можно передавать для внедрения в Scan Tailor. А можно ещё сделать своеобразный "консольный СканКромсатор" - в качестве копилки-хранилища алгоритмов (на будущее) - тоже крайне полезно.

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

Добавлено:
Melirius
Не могли бы Вы сделать себе хотя бы простенький сайтик? Чтобы там выкладывать все Ваши ссылки и т.п. Мне сложно отслеживать Ваши обновления пакетов и менять ссылки - проще однажды поставить линк на сайт, и всё.

PS То же самое я думаю про конвейер от are.

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

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

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

При всем уважении к участникам, предлагаю перейти в более подходящий топик. Либо во флейм.

DmitryKz

Цитата:

А то от Вас только и слышно, надо сделать так, это неправильно, надо идти таким путем.

Всё довольно просто:

1. Рано или поздно - мною или кем-то ещё - будет реализована глобальная задача - "создание по-максимуму-open-source технологии книгосканирования". Думаю, смысл и преимущества таковой всем ясны - нет нужды обсуждать. Немаловажно также и то, что ИМХО осуществление таковой цели практически неотвратимо - это только вопрос времени.

2. Так зачем же тогда сейчас тратить своё время и силы абсолютно впустую (я имею в виду работу Melirius?) Жалко ведь "работать на унитаз". Я сейчас надёргал из хелпа Melirius всё ценное и отдельно на свой сайт выложил/выложу - остальное - нужно одному только Melirius и больше никому. Мне досадно, что эти слова обидны для Melirius - но надо же взглянуть правде в глаза. Заодно необходимо развеять возможные общественные иллюзии относительно продукта Melirius - здесь я просто вынужден не посчитаться с самолюбием Melirius - ради интересов дела.

Что, скажете, я не прав?

PS В этот топик я пишу не от хорошей жизни - а вынужденно. Но я стараюсь здесь всё же придерживаться темы СК.

Добавлено:
Вот поэтому-то я и предлагаю Arcand, U235 - а теперь уже и Melirius (и всем желающим заодно) - потихоньку начать осваивать консольное программирование на FreeImage. Не надо тут торопиться, не надо гнать лошадей. Присмотреться, начать с простейшего - а дальше оно само пойдёт. И польза от этого будет максимальной. Не нравится именно FreeImage - ради бога, возьмите, скажем, ImageMagic (но я бы не советовал ).

Например, можно перегнать Leptonica на FreeImage (хотя бы выборочно). Или что-то в этом роде. Все, что Arcand делает на Corel PHOTO-PAINT, а U235 на Матлабе, хорошо бы постараться реализовать на более низком уровне (FreeImage).

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

Возвращаясь к СканКромсатору:

Если почитать, скажем, последний ScanAndShare, то становится ясно, что в описанной там технологии самым уязвимым местом является sas-апсемплинг. В смысле, что 2х-кратный рост размера DjVu совсем нежелателен. Что же тогда делать? Как обрабатывать в СК "Grey 300 -> BW 600", чтобы DjVu распухал менее, чем в 2 раза?
bolega
Может быть, Вы исхитритесь реализовать в СК технологию http://www.djvu-soft.narod.ru/scan/corel_scan.htm ? Или она уже в СК реализована? Или это умеют делать СК-профиля от ghosty?

Нельзя же оставить вещи навсегда так, как они есть сейчас - т.е. "2х-кратный рост DjVu". Надо бы добиться (снизить до) хотя бы 30-40% распухания.

(Необходимость проделывания "Grey 300 -> BW 600" уже вроде бы ни у кого не вызывает сомнений).

monday2000

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

Затем меня попросили "эту удобную штуку", как говориться, "опубличить". Что я и сделал не без удовольствия. Хотите - берите, хотите - нет. Я лично сам им пользуюсь, как bolega Kromsator'ом. Буду счастлив, если кто-то тоже найдёт пакет полезным.

Относительно help'а: всё ценное - это как-то чересчур. Само описание пакета вероятно, тоже ценно - если им, конечно, пользоваться. Здесь мы подходим к другому вопросу: среди open-source софта я пока не вижу конструктивных альтернатив самым важным программам пакета - ScanKromsator'у и консольным exe-шникам из DEE. "Конструктивный" в данном случае обозначает "обладающий необходимым минимумом лично мне необходимых фич" и "сопоставимый по степени сжатия файлов", соответственно.


Цитата:

Melirius
Не могли бы Вы сделать себе хотя бы простенький сайтик? Чтобы там выкладывать все Ваши ссылки и т.п. Мне сложно отслеживать Ваши обновления пакетов и менять ссылки - проще однажды поставить линк на сайт, и всё.

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

Melirius

Цитата:

"Работа на унитаз",

Конкретно тут я имею в виду Вашу попытку увязать в одну систему разнородные софты - через Total Commander и "DjVu bar" - тот же ScanAndShare гораздо практичней.

А вот разделы про СК в Вашем хелпе - это очень ценно. Есть и другие ценные моменты.

Добавлено:
Melirius

Цитата:

не вижу конструктивных альтернатив самым важным программам пакета - ScanKromsator'у

Даже СК не умеет делать http://www.djvu-soft.narod.ru/scan/corel_scan.htm (а потребность велика). Если начать (хотя бы Вам) пробовать писать консольные алгоритмы под FreeImage - то есть шанс со временем придумать реализацию http://www.djvu-soft.narod.ru/scan/corel_scan.htm для СК (для СТ заодно). А может, Вы придумаете ещё один алгоритм выравнивания освещённости. Или deskew, не сбиваемый с толку картинками. Или какую-нибудь "крутую" бинаризацию. Да мало ли что из алгоритмов ещё нужно - чего нет даже в СК (не говоря уже об СТ).

Всё равно будет хоть какой-то толк - по сравнению с работами по скомпоновыванию разношёрстных комплексов.

Добавлено:
Мне на форуме ABBYY дали совет, как отсеивать в сторону pic.0001.tif, pic.0002.tif, pic.0003.tif при открытии сканов в FR:

Цитата:

Надо просто при открытии файла написать ????.??? и нажать Enter, после этого видимыми станут только файлы с именами, подходящими под нужный вам шаблон. Далее выделяете всё и открываете.

monday2000


Цитата:

Даже СК не умеет делать http://www.djvu-soft.narod.ru/scan/corel_scan.htm (а потребность велика).

Не разбрасывайтесь словами. Что именно из этого не умеет делать SK? Вы хоть раз в Grey enchance заглядывали?

P. S. Заметьте, я задаю конкретные вопросы, а Вы отделываетесь общими словами. Пока ни одного конкретного ответа. Мой Вам совет - измените стиль общения. По крайней мере отвечайте на прямо поставленные вопросы либо сообщайте, что отвечать не собираетесь.