Автор Тема: Высокоуровневая схема работы идеальной программы скан-обработки  (Прочитано 12446 раз)

kontiky

  • Новичок
  • *
  • Сообщений: 20
    • Просмотр профиля
Недавно перетряхивая свой жесткий диск, обнаружил свои старые наброски по программе-альтернативе Scan Kromsator

Запустил, повертел... потом скачал текущий Scan Kromsator, посмотрел, скачал Scan Tailor, тоже посмотрел и призадумался...

Какой процесс обработки сканов в Scan Kromsator? Обработка стоится по следующей схеме
  • загрузить изображения в программу (в виде отдельных страниц или разворотов - не важно)
  • запустить Draft Kromsate (происходит расстановка т.е. резаков, выделающих полезную информацию на одной странице или развороте)
  • пользователь просматривает результаты расстановки резаков, подправляет другие параметры обработки
  • запускт Process! (здесь программа разрезает развороты, делает поворот, чистку и пр.)
  • пользователь в отдельном окне может просмотреть результаты работы и если надо вернуться на пару шагов назад, подправить настройки и снова запустить Process! для всех изображений, или только для части. здесь же доступен графический редактор, для ручной доводки результатов работы программы
Чем мне не нравится Scan Kromsator? Непрозрачностью и запутанностью интерфейса, особенно в случае работы с разворотами (хотя свое дело он делает).

Как работает Scan Tailor (кстати, хорошее название)? Примерно так (сильно много не разбирался, возможны ошибки)
  • загрузить в программу изображения
  • выполнить разрезание разворотов (если нужно)
  • выполнить ручную правку параметров (если нужно)
  • выполнить другие виды обработки (если нужно)
Чем мне не понравилось в Scan Tailor? Довольно жесткая последовательность действий. Отсутствие полного контроля над изображениями в любой точке процесса (нет ручного редактирования).

Я хотел бы обсудить как должна выглядеть высокоуровневая схема работы (workflow) над сканами в идеальной программе скан-обработки.
Мне видется что-то типа того, как происходит работа в FineReader
  • создание нового пакета работы (batch)
  • загрузка в batch изображений (из файлов, со сканера etc.). в любой момент работы для любого скана доступен ручной графический редактор
  • выполнить функцию Analyze (анализ структуры сканов), с выделением прямоугольными областями (не резаками, боже упаси) текста, изображений и пр.
  • здесь можно просмотреть результаты анализа и подправить их
  • задание других параметров обработки
  • получение готових обработанных изображений
  • здесь можно еще раз пройтись по изображениям пакета, сравнить исходное изображени с полученным, что-то подправить в редакторе, задать другие параметры автоматичекской обработки и пересоздать выходной файл изображения (для отдельного скана или группы сканов в пакете)
В принципе, схема напоминает то, что уже есть в Кромсаторе. Проблема на мой взгляд в разрезании разворотов. Если помещать в пакет развороты без разрезки (как сделано в том же Кромсаторе), дальше сложно работать с таким сканом - сложно задавать параметры обработки отдельно для левой и правой страницы, сложно сравнивать с результатом. Если вынести собственно разрезание в отдельную операцию при загрузке изображений (как сделано в FineReader) - непонятно, как контролировать (и, возможно, подправлять) результаты определения разворота (а это может потребоваться до собственно разрезки), ну и нарушается вся стройная схема работы с пакетом - одна операция становиться какой-то особенной.

Словом, пока я не вижу идеальной схемы обработки сканов. Может быть, ее видите вы?
« Последнее редактирование: 29 ёоЫм 2010, 17:06:50 от kontiky »

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
Здраствуйте, kontiky! Рад Вас видеть на этом форуме.

Спасибо за интерес к этой теме. У меня тоже к этой теме огромный интерес.

У меня есть кое-какие соображения по этой теме.
Сразу условимся: "СТ" - это Скан Тейлор, "СК" - это СканКромсатор, "Tulon" - это автор СТ, "bolega" - это автор СК.
Цитировать
Проблема на мой взгляд в разрезании разворотов.
Да. Тут Вы попали прямо в точку. В настоящее время это проблема № 1.
Цитировать
Если вынести собственно разрезание в отдельную операцию при загрузке изображений (как сделано в FineReader)
На мой взгляд, необходимо именно "вынести собственно разрезание в отдельную операцию". Точнее, необходимо сделать отдельную независимую программу, которая будет осуществлять разрезку разворотов (+ отрезание ошмётка смежной страницы - для случая одиночных сканов) - и больше ничего (этой программе не следует делать).
Цитировать
- непонятно, как контролировать (и, возможно, подправлять) результаты определения разворота (а это может потребоваться до собственно разрезки),
Я бы сделал операцию визуального составления задания на пакетную разрезку чисто ручной. Т.е. пользователь вручную пробегает по всем сканам и вручную на каждом развороте позиционирует резак (тем самым постранично формируя задание на пакетную разрезку). Так сейчас можно в СК делать.

И только опционально можно (при желании, но отнюдь не необходимо) сделать автоматическое распознавание линии будущего разреза (как в СТ).

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

Кроме того - отдельная программа для порезки разворотов вообще нужна сама по себе. Не все, кому она нужна, сканируют в DjVu-PDF. Пример: Те, кто делают OCR в CuneiForm, очень нуждаются в программе для порезки разворотов. Могут быть и иные примеры.

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

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

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

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

После разрезки разворотов дальнейшая последовательность сканобработки достаточно неплохо реализована в СТ (но эту тему мы ещё обсудим подробнее).

На первое время вырисовывается такая схема работы.

1. Сканер - создание сырых сканов.
2. Предлагаемая мною простейшая программа по разрезке разворотов.
3. СТ.

Поэтому - нет ли у Вас интереса создать предлагаемаю мною простейшую программу по разрезке разворотов?
« Последнее редактирование: 30 ёоЫм 2010, 10:34:38 от monday2000 »

kontiky

  • Новичок
  • *
  • Сообщений: 20
    • Просмотр профиля
Цитировать
Я бы сделал операцию визуального составления задания на пакетную разрезку чисто ручной. Т.е. пользователь вручную пробегает по всем сканам и вручную на каждом развороте позиционирует резак (тем самым постранично формируя задание на пакетную разрезку). Так сейчас можно в СК делать.

И только опционально можно (при желании, но отнюдь не необходимо) сделать автоматическое распознавание линии будущего разреза (как в СТ).
Думаю, подход СТ более правильный - сначала автоматическое определение линии разреза - потом возможность ручной правки. Собственно и в СК сделано примерно так же - сначала Draft Krimsate - потом окончательный Process!

Цитировать
Делать чисто ручную разрезку - не особо напряжно. В СК это занимает от силы 5 минут. Ничего, юзер не переломится - чтобы потратить 5 минут на выставление резака разрезки (на всех разворотах).
Это сильно зависит от объема книги. Лучше что бы часть работы приняла на себя машина.

Цитировать
Зато ручной подход даёт неоценимое преимущество - он даёт железную гарантию, что всё будет порезано именно так, как надо. Никакая автоматика дать подобную гарантию не в силах (в общем случае).
С таким подходом полностью согласен.

kontiky

  • Новичок
  • *
  • Сообщений: 20
    • Просмотр профиля
Цитировать
Вы видели множество DjVu-файлов, сделанных в виде сдвоенных разворотов?
И не раз. Это просто беда  :'(

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
Цитировать
Думаю, подход СТ более правильный - сначала автоматическое определение линии разреза - потом возможность ручной правки.
Это уже частности. Можно и так, конечно.

PS Пока я редактировал свой 1 пост в этом топике, Вы уже успели новые написать - гляньте в конец моего 1 поста в этом топике.  ;)

kontiky

  • Новичок
  • *
  • Сообщений: 20
    • Просмотр профиля
Цитировать
После разрезки разворотов дальнейшая последовательность сканобработки достаточно неплохо реализована в СТ (но эту тему мы ещё обсудим подробнее).
Давайте обсудим. Я вчера подробнее поигрался с СТ и несколько под впечатлением того, что вы называете ПВО.
Цитировать
Поэтому - нет ли у Вас интереса создать предлагаемаю мною простейшую программу по разрезке разворотов?
Можно попробовать. Задача не выглядит слишком уж большой.
Какие, навскидку, сейчас есть готовые алгоритмы автоопределения линии разреза?

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

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
kontiky
Цитировать
Какие, навскидку, сейчас есть готовые алгоритмы автоопределения линии разреза?
Я не знаю. Разве что внутри СТ. Спросите у Tulon - на форуме http://diybookscanner.org/forum/viewforum.php?f=8 Да для начала сделайте хоть чисто ручную разрезку - а потом уж добавьте автоматику. Это будет нормально.
Цитировать
И еще, мне было бы чертовки удобно разрабатывать все на Java. Это, как я понимаю, идет в разрез с вашей концепцией идеальной программы сканобработки.
Ну что делать - давайте пока хоть так.  :-\ А это не будет ли сильно глючить из-за Java? Сколько я видел таких Java-зависимых программ - часто они почему-то, в сущности, не работают - или сильно тормозят. А это будет кроссплатформенным? А как насчёт Qt?
Цитировать
Давайте обсудим.
В СТ, думаю, плох такой принцип, когда на всех стадиях реальная обработка не делается, а только отображается. А реально обработка происходит лишь в конце. Это Вы это называете "ПВО"?

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

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

Вообще-то, пока нет простой программы по разрезке разворотов, трудно говорить о том, что должно быть "после разрезки". Вот если кто-то сделает простую программу по разрезке разворотов - и все начнут ею пользоваться - тогда будет гораздо понятнее, что должно быть "после разрезки".
« Последнее редактирование: 30 ёоЫм 2010, 11:05:00 от monday2000 »

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
В общем, грубо и вкратце схема выглядит пока так:

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

По большому счёту - это пока всё.

kontiky

  • Новичок
  • *
  • Сообщений: 20
    • Просмотр профиля
Цитировать
kontiky
Цитировать
Какие, навскидку, сейчас есть готовые алгоритмы автоопределения линии разреза?
Я не знаю. Разве что внутри СТ. Спросите у Tulon - на форуме http://diybookscanner.org/forum/viewforum.php?f=8
Спасибо, спрошу. Тулон вообще контактен? А как на счет алгоритма в СК? Или он неотделим от общего процесса расстановки резаков?
Цитировать
Цитировать
И еще, мне было бы чертовки удобно разрабатывать все на Java. Это, как я понимаю, идет в разрез с вашей концепцией идеальной программы сканобработки.
Ну что делать - давайте пока хоть так.  :-\ А это не будет ли сильно глючить из-за Java? Сколько я видел таких Java-зависимых программ - часто они почему-то, в сущности, не работают - или сильно тормозят. А это будет кроссплатформенным? А как насчёт Qt?
Да. Программа будет кроссплатформенной без перекомпиляции. И глючить точно не будет ;) Посмотрите, для примера, на IntelliJ IDEA - программа полностью написана на Java.

Что касается скорости обработки (больших) изображений - нужно пробовать. Qt - это С++, на котором я не писал лет 10 уже. Если скорость обработки на Java окажеться неудовлетворительной, ну тогда придется думать о написании на С++. Кстати, почему в ваших программах (DjVu Small) вы не используете Qt?

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

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

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
Цитировать
Тулон вообще контактен?
В принципе, да. Хотя сейчас, после ухода с Руборда - кто его знает. :D
Цитировать
А как на счет алгоритма в СК?
Тут уж я ничего не могу сказать, что Вы, bolega не знаете? :)
Цитировать
Кстати, почему в ваших программах (DjVu Small) вы не используете Qt?
Привычка. Но, если возникнет острая нужда - буду хоть на Java, хоть на Qt. К тому же - за исключением не-кроссплатформенности, мой вариант идеален - малый размер, не требуется никаких SDK (типа Java), работа под Windows 98.
Цитировать
Да. Программа будет кроссплатформенной без перекомпиляции.
Что ж, давайте пока на Java.

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

57an

  • Постоялец
  • ***
  • Сообщений: 201
    • Просмотр профиля
    • Djvu Bookmarker on SF.net
Извините, вклинюсь.
Сколько видел книг с неразрезанными разворотами - раздражает не само отсутствие разрезки разворота на страницы, а сопутствующее ему отсутствие компенсации наклона страниц перед бинаризацией (что ведет к сильным искажениям при попытке доделки таких книг).
Насчет возможности удаления мусора на промежуточном этапе - сомневаюсь в целесообразности, т.к. оно должно производиться уже над бинаризованными сканами, т.е. в самый последний момент, после СТ.

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

kontiky

  • Новичок
  • *
  • Сообщений: 20
    • Просмотр профиля
Цитировать
Предлагаю начать с чего-то конкретного - а именно, с создания простой программы по порезке разворотов. Согласны? А уже, сделав её, двинем дальше.
Согласен. Начну с ручной порезки, а там посмотрим.

kontiky

  • Новичок
  • *
  • Сообщений: 20
    • Просмотр профиля
Сколько видел книг с неразрезанными разворотами - раздражает не само отсутствие разрезки разворота на страницы, а сопутствующее ему отсутствие компенсации наклона страниц перед бинаризацией (что ведет к сильным искажениям при попытке доделки таких книг).
Что вы подразумеваете под "отсутствием компенсации наклона"?

Цитировать
2) сохранение проекта, его пропатчивание - задание полезной области по границам резака, нулевых полей, если не было этапа компенсации наклона, то нулевых углов.
"Ну это уже какой-то волюнтаризм" (с)  ;D

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
57an
Цитировать
Сколько видел книг с неразрезанными разворотами - раздражает не само отсутствие разрезки разворота на страницы, а сопутствующее ему отсутствие компенсации наклона страниц
То есть, Вы предлагаете встроить в предлагаемую мною простейшую программу по разрезке разворотов также ещё и операцию Deskew?

Я бы отнёсся к такой идее осторожно. Может быть, и да - как вариант. А может - вообще - сделать отдельную программу, которая будет делать только одно лишь пакетное Deskew - с возможностью ручной визуальной правки. Т.е., грубо говоря, вырезать кусок с Deskew из СТ в отдельную программу. Думаю, и такая независимая программа также была бы нелишней.

Хотя в вопросе "включать или не включать Deskew в состав простейшей программы по разрезке разворотов" у меня нет чёткой убеждённости - да или нет. Заманчиво, конечно - но минусы такие, что замедляется/усложняется процесс, и ещё момент: всегда ли Deskew срабатывает верно? Вот в СК Deskew нередко лажает, в СТ - пока ни разу не видел. От ответа на вопрос, "лажает или нет", зависит ответ на вопрос "включать или нет". Если не лажает - включать, и наоборот. Конечно, "включить"-очень заманчиво, что там и говорить. Но тогда уж непременно как опцию, а не как обязательный этап.

57an

  • Постоялец
  • ***
  • Сообщений: 201
    • Просмотр профиля
    • Djvu Bookmarker on SF.net
Цитировать
волюнтаризм
Для меня это лишь способ минимумом усилий сделать максимум функционала.

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