Главное > Общий
Высокоуровневая схема работы идеальной программы скан-обработки
kontiky:
Недавно перетряхивая свой жесткий диск, обнаружил свои старые наброски по программе-альтернативе 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) - непонятно, как контролировать (и, возможно, подправлять) результаты определения разворота (а это может потребоваться до собственно разрезки), ну и нарушается вся стройная схема работы с пакетом - одна операция становиться какой-то особенной.
Словом, пока я не вижу идеальной схемы обработки сканов. Может быть, ее видите вы?
monday2000:
Здраствуйте, kontiky! Рад Вас видеть на этом форуме.
Спасибо за интерес к этой теме. У меня тоже к этой теме огромный интерес.
У меня есть кое-какие соображения по этой теме.
Сразу условимся: "СТ" - это Скан Тейлор, "СК" - это СканКромсатор, "Tulon" - это автор СТ, "bolega" - это автор СК.
--- Цитировать ---Проблема на мой взгляд в разрезании разворотов.
--- Конец цитаты ---
Да. Тут Вы попали прямо в точку. В настоящее время это проблема № 1.
--- Цитировать ---Если вынести собственно разрезание в отдельную операцию при загрузке изображений (как сделано в FineReader)
--- Конец цитаты ---
На мой взгляд, необходимо именно "вынести собственно разрезание в отдельную операцию". Точнее, необходимо сделать отдельную независимую программу, которая будет осуществлять разрезку разворотов (+ отрезание ошмётка смежной страницы - для случая одиночных сканов) - и больше ничего (этой программе не следует делать).
--- Цитировать --- - непонятно, как контролировать (и, возможно, подправлять) результаты определения разворота (а это может потребоваться до собственно разрезки),
--- Конец цитаты ---
Я бы сделал операцию визуального составления задания на пакетную разрезку чисто ручной. Т.е. пользователь вручную пробегает по всем сканам и вручную на каждом развороте позиционирует резак (тем самым постранично формируя задание на пакетную разрезку). Так сейчас можно в СК делать.
И только опционально можно (при желании, но отнюдь не необходимо) сделать автоматическое распознавание линии будущего разреза (как в СТ).
Делать чисто ручную разрезку - не особо напряжно. В СК это занимает от силы 5 минут. Ничего, юзер не переломится - чтобы потратить 5 минут на выставление резака разрезки (на всех разворотах). Зато ручной подход даёт неоценимое преимущество - он даёт железную гарантию, что всё будет порезано именно так, как надо. Никакая автоматика дать подобную гарантию не в силах (в общем случае). Просто, к примеру, тот же Tulon этого не понимает - находясь в плену ошибочных стереотипов.
--- Цитировать ---ну и нарушается вся стройная схема работы с пакетом - одна операция становиться какой-то особенной.
--- Конец цитаты ---
Увы, это необходимое зло. Так наиболее разумно. Это называется "предварительная унификация". Это резко упрощает жизнь разработчикам тех программ, которые будут обрабатывать уже порезанный "полуфабрикат" - не нужно будет изобретать всякие сложные ухищрения ("левые"-"правые" страницы в СК, виртуальная разрезка в СТ - сложнейшее, излишнее ухищрения программиста, потребляющее уйму времени и сил).
Кроме того - отдельная программа для порезки разворотов вообще нужна сама по себе. Не все, кому она нужна, сканируют в DjVu-PDF. Пример: Те, кто делают OCR в CuneiForm, очень нуждаются в программе для порезки разворотов. Могут быть и иные примеры.
Кроме того, юзер непредсказуем. По самым необъяснимым причинам найдутся те, кто захочет ограничится исключительно одной разрезкой разворотов - и всё. Вы видели множество DjVu-файлов, сделанных в виде сдвоенных разворотов? А вот если бы была простейшая (для понимания чайника) программа разрезки сдвоенных разворотов - то такие сдвоенные DjVu резко пошли бы на убыль.
Также - найдётся немало юзверей, которым хоть кол на голове теши - а они не станут сколь-нибудь сложно обрабатывать сырые сканы. А вот хотя бы просто порезать развороты (обсуждаемой гипотетической программой) они ещё со скрипом согласятся - и сразу потом запхнут порезанное прямо в DjVu (а сейчас пхают даже в непорезанном виде).
Люди жаждут простоты - так нужно им её дать. Представьте, что Вы приходите, и говорите: "вот Вам программа для разрезки разворотов. Простая и удобная. Проще уже некуда (а они как раз такое и жаждут). Этой программой Вы можете порезать сдвоенные развороты - а дальше, что хотите, то и делайте, тут я Вашу свободу никак не ограничиваю (в отличие от Tulon). Можете передать порезанное на обработку в СТ - а кому лень - сразу запихивайте в DjVu (это неправильно, но повторюсь - всяким там женщинам Вы никогда не объясните, как правильно делать DjVu-книги)".
Вот именно так нам и нужно достичь вожделенной максимальной простоты сканобработки - которая и будет залогом и гарантией массового DjVu-книгосканирования. Сейчас такой простоты нет - тот же СТ гораздо сложнее для понимания чайника, чем предлагаемая мною простейшая программа по сканобработке.
После разрезки разворотов дальнейшая последовательность сканобработки достаточно неплохо реализована в СТ (но эту тему мы ещё обсудим подробнее).
На первое время вырисовывается такая схема работы.
1. Сканер - создание сырых сканов.
2. Предлагаемая мною простейшая программа по разрезке разворотов.
3. СТ.
Поэтому - нет ли у Вас интереса создать предлагаемаю мною простейшую программу по разрезке разворотов?
kontiky:
--- Цитировать ---Я бы сделал операцию визуального составления задания на пакетную разрезку чисто ручной. Т.е. пользователь вручную пробегает по всем сканам и вручную на каждом развороте позиционирует резак (тем самым постранично формируя задание на пакетную разрезку). Так сейчас можно в СК делать.
И только опционально можно (при желании, но отнюдь не необходимо) сделать автоматическое распознавание линии будущего разреза (как в СТ).
--- Конец цитаты ---
Думаю, подход СТ более правильный - сначала автоматическое определение линии разреза - потом возможность ручной правки. Собственно и в СК сделано примерно так же - сначала Draft Krimsate - потом окончательный Process!
--- Цитировать ---Делать чисто ручную разрезку - не особо напряжно. В СК это занимает от силы 5 минут. Ничего, юзер не переломится - чтобы потратить 5 минут на выставление резака разрезки (на всех разворотах).
--- Конец цитаты ---
Это сильно зависит от объема книги. Лучше что бы часть работы приняла на себя машина.
--- Цитировать ---Зато ручной подход даёт неоценимое преимущество - он даёт железную гарантию, что всё будет порезано именно так, как надо. Никакая автоматика дать подобную гарантию не в силах (в общем случае).
--- Конец цитаты ---
С таким подходом полностью согласен.
kontiky:
--- Цитировать ---Вы видели множество DjVu-файлов, сделанных в виде сдвоенных разворотов?
--- Конец цитаты ---
И не раз. Это просто беда :'(
monday2000:
--- Цитировать ---Думаю, подход СТ более правильный - сначала автоматическое определение линии разреза - потом возможность ручной правки.
--- Конец цитаты ---
Это уже частности. Можно и так, конечно.
PS Пока я редактировал свой 1 пост в этом топике, Вы уже успели новые написать - гляньте в конец моего 1 поста в этом топике. ;)
Навигация
Перейти к полной версии