Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Компьютеры » Программы » ScanKromsator СканКромсатор (Часть 2)

Модерирует : gyra, Maz

Widok (30-03-2009 18:08): Лимит страниц. Продолжаем здесь.  Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105

   

Widok



Moderator-Следопыт
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
ScanKromsator: Знаменитый Кромсатор для обрезки получаемых при сканировании изображений, а также для разделения страниц, очистки от мусора и т.п. (есть FAQ). Автор: bolega. http://bolega.hotmail.ru/
 
Начало обсуждения - здесь.
 
Текущая версия: ScanKromsator v5.92 (2 МБ)
Предыдущая версия: ScanKromsator v5.91 full (3,26 МБ) зеркало
 
Старые версии: Подробнее...
Изменения в новой версии (5.92) + описание нового порядка обработки (с "финализацией" файлов)

 
Самая краткая инструкция по работе с СК (включает "сборку" СК) от ghosty
 
ScanAndShare - инструкция в картинках от VadimirTT, + начальные установки SK.Использование ScanKromsator’а v5.91 от Melirius
 
Вопросы и ответы по работе со СканКромсатором:
http://abab.front.ru/QandA_SK.ZIP (80 КБ, от 20.06.06)
 
Хелп v1.0 для Кромсатора. Есть в PDF (368 КБ) и в HTM и DOC (537 КБ)
 
Пособие по Кромсатору от monday2000  
(Составлено на базе "Вопросов и ответов" + Хелп v1.0).  См. подробности. Обновлено 30.10.07

Всего записей: 24190 | Зарегистр. 07-04-2002 | Отправлено: 15:15 17-08-2007 | Исправлено: ghosty, 15:09 25-12-2008
ghosty



Gold Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
bolega
Не расстраивайтесь, это сезонное.  
 
To All:
Давайте уже закругляться с оффтопом, действительно?

Всего записей: 6808 | Зарегистр. 21-09-2002 | Отправлено: 19:55 15-09-2008
bolega

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
ghosty

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

Всего записей: 4435 | Зарегистр. 09-09-2002 | Отправлено: 10:06 16-09-2008
monday2000

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
bolega

Цитата:
Если Вы считаете, что и в BR возникнут (якобы) трудности с файлами после SK

Да.

Цитата:
Тот, кто пользуется BR, не пользуется SK.  

Но ещё остаётся FineReader.

Цитата:
Ваши пожелания я не принимаю.

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

Цитата:
Поскольку я совершенно запутался в последних спорах

Всё на самом деле очень просто:
 
1. Я предложил подстроить СК под FineReader (или BR) более оптимальным образом - для случая разделённых сканов.
 
2. В случае, если СК изменится в данном направлении, я берусь подстроить и DjVu Small и DjVu Sep под изменившийся выход из СК - как бы этот выход ни видоизменился бы.
 
Вот и всё.
 
Короче, "цена вопроса" - делать или нет утилитку для тасования файлов "после СК" под FR (избирающую в отдельную папку все сканы, подлежащие распознаванию). Делать это не хочется, т.к. это будет лишний шаг для юзеров.

Всего записей: 2841 | Зарегистр. 13-01-2005 | Отправлено: 12:11 16-09-2008
bolega

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
monday2000

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

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

Всего записей: 4435 | Зарегистр. 09-09-2002 | Отправлено: 15:16 16-09-2008 | Исправлено: bolega, 15:22 16-09-2008
monday2000

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
bolega

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

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

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

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

Всего записей: 2841 | Зарегистр. 13-01-2005 | Отправлено: 15:31 16-09-2008
bolega

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
monday2000

Цитата:
как это Вы делаете?

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

Цитата:
Просто мечта.

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

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

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

Цитата:
Какая версия FR?  

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

Всего записей: 4435 | Зарегистр. 09-09-2002 | Отправлено: 17:35 16-09-2008
monday2000

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
bolega

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

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

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

Ну, не совсем. Всё равно при открытии в FR надо следить, чтобы pic.XXXX не попали в селекцию. Может быть, это с чьей-то точки зрения - мелкое неудобство, но всё же - неудобство.
 
Было бы здорово вообще "совершенно бездумно" открывать в FR файлы из СК-папки out, не задумываясь о наличии там pic.XXXX.
 
К тому же, в том же BR файлы открываются по Automated Import - т.е. всё содержимое папки.
 
Идеально было бы "генерировать в отдельную папку pic.XXXX (наряду с XXXX.sep)".
 
Добавлено:
Нельзя ли настроить FR так, чтобы он автоматом отсеивал pic.XXXX? Может, как-то через его встроенную систему скриптов?

Всего записей: 2841 | Зарегистр. 13-01-2005 | Отправлено: 17:59 16-09-2008
bolega

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

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

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

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

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

Всего записей: 4435 | Зарегистр. 09-09-2002 | Отправлено: 18:26 16-09-2008
monday2000

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

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

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

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

Да уж действительно. Я тут интересовался - оказывается, нет и не существует даже достаточно приличного open-source вьювера. Основа основ любой программы сканобработки (70-80%) - это достаточно качественный графический движок (на уровне СК). И вот - нет такого пока. Если и есть что-то приличное (вьювер) - так с закрытыми исходниками.
 
Видимо, это и есть та самая причина, что Вы удивлялись как-то, почему никто не делает ещё одну программу по сканобработке - не могут никто сделать нормальный графический движок. Даже AndyZ не может в WinDjView. Вот и в Scan Tailor этому не уделено должного внимания. И вообще тема "графический движок" даже как-то и не звучит на программистских сайтах/форумах.
 
Будь такой движок (обязательно документированный более-менее) - давно народ понаделал бы хотя бы самых простейших софтов по сканобработке (типа "обрезка по фиксированной рамке" - для сканов журналов удобно - ни СК, ни Ирфан тут не "заточены").
 
Вот если бы исходники СК были открыты, то можно было бы там подсмотреть архитектуру графического движка и воссоздать его (движок СК) уже на C++, а также максимально задокументировать. ИМХО тут проблема именно в архитектурных решениях (графического движка).

Всего записей: 2841 | Зарегистр. 13-01-2005 | Отправлено: 20:40 16-09-2008 | Исправлено: monday2000, 21:10 16-09-2008
bolega

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
monday2000

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

Сделаю.
 

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

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

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

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

Всего записей: 4435 | Зарегистр. 09-09-2002 | Отправлено: 11:59 17-09-2008
monday2000

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
bolega

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

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

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

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

Всего записей: 2841 | Зарегистр. 13-01-2005 | Отправлено: 12:58 17-09-2008
monday2000

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
bolega

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

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

Всего записей: 2841 | Зарегистр. 13-01-2005 | Отправлено: 09:24 18-09-2008
bolega

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
monday2000

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

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

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

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

Всего записей: 4435 | Зарегистр. 09-09-2002 | Отправлено: 10:40 18-09-2008
monday2000

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
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 явно не вариант.

Всего записей: 2841 | Зарегистр. 13-01-2005 | Отправлено: 11:31 18-09-2008 | Исправлено: monday2000, 11:42 18-09-2008
DmitryKz

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
~ 350 МБ  

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

Всего записей: 3142 | Зарегистр. 29-09-2005 | Отправлено: 12:21 18-09-2008
bolega

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
monday2000
http://mihd.net/64brsaf

Всего записей: 4435 | Зарегистр. 09-09-2002 | Отправлено: 13:07 18-09-2008
monday2000

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
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

Всего записей: 2841 | Зарегистр. 13-01-2005 | Отправлено: 14:15 18-09-2008
Melirius



Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
monday2000

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

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

Всего записей: 318 | Зарегистр. 01-04-2005 | Отправлено: 22:29 18-09-2008
monday2000

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
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).

Всего записей: 2841 | Зарегистр. 13-01-2005 | Отправлено: 16:07 19-09-2008
Melirius



Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
monday2000
 
Могу предложить, если Вы разбираетесь в LaTeX, отослать его Вам на мыло. Но без картинок Вы его не скомпилируете, а они весят в исходниках солидно. Чистый текст там пересыпан служебными словами, так что для копирования лучше не мудрствуйте лукаво, а выдирайте из PDF'а.

Всего записей: 318 | Зарегистр. 01-04-2005 | Отправлено: 21:30 19-09-2008
   

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105

Компьютерный форум Ru.Board » Компьютеры » Программы » ScanKromsator СканКромсатор (Часть 2)
Widok (30-03-2009 18:08): Лимит страниц. Продолжаем здесь.


Реклама на форуме Ru.Board.

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.B0ard
© Ru.B0ard 2000-2024

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru