Вернуться к разделу "СканКромсатор v5.6A. Пособие по программе".
Создание электронных версий бумажных книг в форматах DjVu и Pdf - это технология, включающая в себя несколько простых этапов:
1). Сканирование (оцифровка) бумажных книг.
2). Обработка (облагораживание) полученных "сырых" сканов.
3). Кодирование обработанных сканов в формат DjVu (Pdf).
На сегодняшний день, этапы №1 и №3 довольно хорошо проработаны и технологически развиты - сканирование книг - операция крайне простая и не требующая квалификации, кодирование в DjVu - сводится к применению простых, удобных и доступных программ.
Наиболее узким местом во всей технологии является п. №2 - обработка сырых сканов. Не считая варианта полностью ручной обработки, существует лишь один приемлемый способ автоматизации этой процедуры - использование программы СканКромсатор (автор - bolega).
СканКромсатор (или просто "Кромсатор") - это программа с визуальным графическим интерфейсом под Windows, основная задача которой - обрезка и выравнивание сырых сканов таким образом, чтобы получились ровные (отсканированные) страницы книжного текста, с равномерными полями по бокам. Кроме того, программа умеет обрезать "мусор" (неизбежно образующийся при сканировании), устранять перекос страниц, и делать многие другие аналогичные задачи.
СканКромсатор - программа уникальная и исключительно полезная. При этом её размер не превышает 2,5 МБ, что делает её доступной практически каждому (путём скачивания из Интернета). Использование СканКромсатора радикально упрощает и облегчает процесс создания электронной DjVu-версии бумажной книги.
Однако, при этом программа обладает рядом существенных недостатков. Самый основной из них - повышенная трудность освоения. Сложный интерфейс, обилие опций, отсутствие авторской документации, полная непохожесть на все известные программы - всё это отталкивает рядового и массового пользователя от использования СканКромсатора и, тем самым, сдерживает процесс распространения идеологии "DjVu-книгоделания" в широких массах.
В процессе составления "Пособия по Кромсатору" у меня сложились определённые представления о недостатках программы и возможностях их исправления. Идеальный СканКромсатор, на мой взгляд, мог бы базироваться на следующих "краеугольных камнях":
1. Модульность.
2. Многопроходность.
3. Адекватность.
4. Лаконичность.
5. Эргономичность.
Современный же СканКромсатор, насколько я могу судить, базируется на полностью противоположных принципах - полярных на 180 градусов этим. Думаю, отсюда и многие его проблемы.
Давайте немного пофантазируем и представим -
что бы мы с вами сделали, чтобы кардинально
улучшить существующий СканКромсатор. Для этого
рассмотрим подробнее предлагаемые принципы:
1. Модульность. Это не раз предложенная мною
идея о разбиении СканКромсатора на несколько
узкоспециализированных программ со следующими
условными названиями:
a. Kromsator Lite.
b. Gray Enhancer.
c. Pdf Creator.
d. Profile Editor (Для визуального редактирования ini -
файла).
Нынешний же Кромсатор похож на MS Office,
объединённый в одну программу.
Такое разбиение сразу же радикально облегчило бы интерфейс каждой новой программы и упростило бы пользователям овладевание этими программами, а также так мы учли бы тот факт, что кромсаторные задачи имеют разную степень нужности - кромсание нужно всем, "вытягивание" серых сканов (улучшение фона) - половине пользователям, а работа с Pdf - вообще единицам (к тому же, для работы с Pdf есть множество других программ).
Кроме того, это позволило бы отказаться от резаков и заменить их прямоугольниками - если никаких зон нет, то и проблема "где какая зона" ушла бы. Думаю, многим ясно, что резаки - изначально неправильная концепция, и избавившись от них, мы одновременно избавились бы от множества прочих загромождающих интерфейс элементов управления - панели управления резаками, резаковых рельсов, и т.д. Конечно, тут не всё ясно пока, но все возможные проблемы можно решить. Например, Automargins - можно будет сделать по 4 бокам окна скана соответствующие кнопки; есть и другие варианты.
Обычно в оправдание присутствия резаков
указывают тот факт, что из-за несовершенства
алгоритмов Draft Kromsate нередко приходится
"распространять позицию резака на все
последующие сканы" и "как это делать, если не
будет резаков". На это можно ответить, что в
программировании всегда можно одну и ту же
задачу решить разными приемлемыми способами -
достаточно лишь проявить некоторую смекалку и
сообразительность.
2. Многопроходность. Я предлагал - пусть в
Kromsator Lite не будет предусмотрена однопроходная
обработка сырых сканов. Только многопроходная!
Смысл обязательной многопроходности в том, чтобы
сначала тем или иным путём унифицировать
разнобойные сырые сканы, получить некий
полуфабрикат и уже лишь его подавать на само
кромсание. Предподготовка - это в основном
разрезание разворотов или отпиливание
"ошмётков" (полосы соседней страницы у
одиночных сканов), но может быть и что-то ещё.
Обязательная многопроходность - это борьба с излишним и вредным универсализмом. Как известно, сырые сканы крайне разнообразны по своим характеристикам - кто-то сканирует в чёрно-белом режиме, кто-то - в сером, кто-то делает сдвоенные сканы, а кто-то одиночные - и т.д.
На мой взгляд, бессмысленно делать "гибрид мясорубки с печкой и стиральной машиной в одном флаконе" - такая программа получится непомерно сложной до такой степени, что выйдет из-под контроля своего создателя - именно такую ситуацию мы и наблюдаем сейчас со СканКромсатором.
При предлагаемом мною подходе можно было бы,
например, выкинуть подопции для "левой" и
"правой" страницы, ликвидировать понятия
"чётные" и "нечётные" страницы. Причём
для предподготовки можно было бы использовать и
другие программы - FineReader, Irfan View, BookRestorer.
"Экономически" немыслимо обрабатывать
разнобойные сканы за один проход. Пусть Kromsator Lite
принимал бы на входе только (может быть, даже и
исключительно) 3 типа файлов (все TIFF):
а. CCIT FAX G4.
b. Grey LZW.
c. Color LZW.
(Работу с DjVu - также следовало бы выкинуть, на то
есть свои программы).
При этом следовало бы одновременно сделать
ставку на отличную программу Irfan View - пусть Kromsator
Lite работал бы в связке с Irfan View и не дублировал те
возможности, которые уже есть в Irfan View (кстати, там
они, на мой взгляд, лучше реализованы, чем в
Кромсаторе). Да, использование унифицированных
сканов-полуфабрикатов заодно сильно упростило
бы работу с профилями Task options settings, а то и вовсе
Kromsator Lite смог бы автоматом запоминать в ini-файл
изменённые пользователем опции (как Irfan View) - эта
было бы крайне удобно!
3. Адекватность. Здесь речь идёт о том, чтобы
"подтянуть" Кромсатор по некоторым базовым
показателям до уровня популярных графических
программ. Кстати, в настоящее время это по-моему
самая важная, серьёзная и актуальная задача для
Кромсатора. Конкретно имеется в виду следующее:
а. Научить Кромсатор листать большие файлы с
приемлемой задержкой. И тогда сразу же отпадёт
нужда в идее подсовывать под Draft kromsate BW-файлы, а
кромсать потом уже такие же GREY-файлы. Всё-таки,
это, пожалуй, неправильное решение. Правильное
решение - научить Кромсатор листать большие
файлы быстрее - судите по Файнридеру - он же с
серыми изображениями работает, а не с BW, а в
ABBYY наверняка не глупые люди сидят.
b. Подправить кромсаторное deskew - практически
любая большая картинка сбивает его с толку, и
Кромсатор поворачивает лист под диким углом
каким-то. В то же время Файнридер - без проблем
справляется.
с. Не исключено, что и dithering-алгоритм в Кромсаторе
реализован не лучшим образом. По сравнению с Irfan
View, который (как я понял) все серые сканы целиком
конвертит в Ч/Б по dithering-алгоритму, и при этом
мусор не вылезает - так, как в Кромсаторе. Если так
сделать и в Кромсаторе, то отпадёт нужда в зонах
"convert to bitonal", "convert to b/w".
Пока все эти вещи не налажены в Кромсаторе,
постоянно борешься сам с собою: "а не сделать
ли данную задачу частично в другой программе?
Ведь тут всё так неудобно".
4. Лаконичность. Тут я имею в виду, что не надо
было бы в Kromsator Lite реализовывать такие
возможности, которые есть, например, в том же Irfan
View. Пусть сохранилась бы простота использования
программы. Также следовало бы ориентироваться
исключительно на среднестатистические
потребности пользователей (вычисляя их
умозрительно), а не на пожелания отдельных
"уважаемых книгосканировщиков" (сколь бы
заслуженны ни были эти люди). Это необходимая
жертва - иначе толку не будет. В конце концов, если
будет нынешний Кромсатор и Kromsator Lite, то обе
стороны окажутся удовлетворены. Посмотрите,
например, на WinDjView - вот образец высокой
эргономичности и продуманности интерфейса. Всё
удобно, но ничего лишнего. Реализовываются лишь действительно
нужные возможностьи. А у СканКромсатора даже
иконки на кнопочках и те - какие-то пёстрые,
крикливо-разнобойные, совершенно случайные. В
иконках кнопочек не наблюдается никакой хорошей
строгости, системности, общего стиля - то, что
есть практически в любой нормальной программе.
5. Эргономичность. Здесь подразумевается создание интуитивно-ясного интерфейса программы. Необходимо сделать так, чтобы вообще почти исчезла нужда в любой документации по Кромсатору - чтобы любой "чайник" мог открыть Кромсатор и за 10-15 минут самостоятельно понять принцип его работы. Исходя из этой цели, следует выкинуть из интерфейса Кромсатора всё неинтуитивно-ясное, функционально заменив выкидываемое интуитивно-ясным.
Важно отметить: тут не идёт речь о "радикальном улучшении" алгоритмов программы, что само по себе позволило бы сильно упростить интерфейс. Предлагается всего лишь "упаковать" уже имеющиеся алгоритмы в новую оболочку - более удобную для пользователя. Очевидно, что в этом направлении можно сделать очень многое. Лично я уже придумал несколько совершенно конкретных рекомендаций, в дальнейшем их могут дать и другие люди.
Приведу некоторые цитаты из форумов, иллюстрирующие мнение bolega:
user: Я бы хотел в идеале, чтобы были продукты, альтернативные Кромсатору.
bolega: Хорошо, что Вы об этом сказали.
Меня уже давно мучает вопрос, почему при таком
повальном увлечении сканированием всего и вся, и
немалом спросе на инструменты обработки, до сих
пор не появляется ничего альтернативного
кромсатору (под windows), во всяком случае в той же
ценовой категории? :)
Для меня это просто загадка. Обычно рынок всегда
живо реагирует на спрос. А тут непонятно. Или все
так зачарованы FR, что и пытаться боятся. Или
боятся наших "законодателей", которые
завтра примут "закон" о том, что инструменты
обработки копирайтных материалов будут
приравниваться к самому копированию таких
материалов?
Взять например вьюеры - их полным полно, какие
хочешь, и платные, и бесплатные. И OCR-программ
предостаточно. А по специализированной
обработке книг - ничего. Один BR, да и тот
изначально делался как дорогое дополнение к их
собственным таким же дорогим сканерам.
user: На мой взгляд, интерфейс программы сложен, перегружен, и не интуитивен.
bolega: Возможно, интерфейс и
неинтуитивен.
Но представьте на минуту, если я попрошу вас по
вечерам каждый день заниматься вышиванием
крестиком. Для меня программирование интерфейса
- такое же скучное и ничего не дающее ни уму ни
сердцу занятие. Там, где дело касается
алгоритмов, где надо подумать и покопаться в
литературе и журналах, там мне интересно, да
думаю и любому другому, делающему бесплатные
программы.
В сети можно найти много готовых исходников
всяких отдельно взятых полезных алгоритмов,
связанных с обработкой изображений. Но никто за
просто так не хочет связываться с созданием
полнофункциональной программы, объединяющей все
это в единое целое, да и еще под управлением
нормального графич. интерфейса, а не командной
строки. Потому что, повторюсь, дело это - трудное,
муторное, неинтересное, и главное, неблагодарное.
(Только не приводите мне как контраргумент
всякие ImageMagic,Gimp и прочие. Эти программы - просто
набор классических фильтров, описанных в любой
книжке по ImPr. Ничего полезного для нашего дела
там нет и быть не может, такого, чего бы уже не
было в любом другом обычном графическом
редакторе).
user: А нельзя ли отказаться от концепции резаков?
bolega: Резаки - это в своем роде паспорт,
особая примета Кромсатора. Почему-то все
предлагают мне сделать Кромсатор похожим хоть на
какую-то, но совершенно другую программу. Я уже
писал почему резаки, а не зоны. Обычно когда
говорят о необходимости зон в Кромсаторе, то
приводят пример FR, программ сканирования и т.д. Но
совсем забывают, что там зоны - это "последняя
инстанция", внутри их уже ничего
конкретизироваться не будет, т.е. есть зона - и к
ней применяется то-то и то-то, как к целому. В
Кромсаторе же нужно внутри отрезаемых областей
ставить всякие exclude-зоны, а также работать с
выделениями, чистить, редактировать и т.п. Ни одна
другая программа это не позволяет! И правильно
делает. Т.к. неоднозначность в обработке нажатий
мыши. Как интерпретировать щелчок на зоне,
лежащей внутри другой зоны (под щелчком
понимается не просто нажал-отпустил, но также и
начало процесса выделения).
Кроме того, у меня в графическом движке нет
возможности работать с непрямоугольными зонами.
В принципе его можно переписать, но вы просто не
представляете, что такое графич. движок - это
десятки мегабайт кода! На это я точно уже не буду
время тратить.
Так же нужно учитывать, что показать
окончательный контур после кромсания на
_исходном_ скане - большая проблема. Ведь если на
выходе он прямоугольный, то на исх. скане - увы, в
большинстве случаев нет.
user: А почему Вы не используете OCR для распознавания контура голого текста?
bolega: Я и сам уже несколько раз писал, что в определенных местах ( и только в них) мне не хватает OCR, но на 95% он не нужен. Если Вы почитаете современные (и не очень) зарубежные журналы, то там тема распознавания контента без привлечения OCR существует очень давно и с большим успехом развивается. Этим занимаются многие ученые и вряд ли они считают это тупиковым занятием.
user: Можно ли как-то упростить использование программы?
bolega: Многие советы по упрощению работы
SK, котрые мне дают, дают люди, которые основывают
свои мысли исключительно исходя из своих
собственных сканов (оно и понятно). Но я провожу
эксперименты на сотнях разных сканах, сделанных
разными людьми, на разных сканерах. И вы не
представляете как варьируется качество, от
идеального, до откровенно ужасного. На некоторых
сканах даже можно разобрать склонившееся лицо
сканировщика :) , до такой степени небрежно
выбирается зона сканирования, точнее, она никак
не выбирается. В таких условиях говорить о
каком-то едином, упрощенном, подходе к обработке
не приходиться. Тут и AI не поможет.
Взять типичный случай - сканируется одна
страница разворота, но в область сканирования
зачем-то попадает половина (!!) другой половины
разворота. Как программа обработки должна
интерпретировать (на автомате) еще кучу текста на
скане? Так что тут без ручного вмешательства
никак не обойтись.
user: Что, если бы Вы вынесли весь текст в какой-то *.lng файл - наверняка нашлось бы несколько человек и перевели бы все на несколько языков.
bolega: Я этого до сих пор не сделал по одной причине - мне нравится английский язык своей компактностью. Например, русские надписи во многих случаях просто бы не влезли в теперешние размеры элементов управления.
user: А можно сделать иконки на кнопочках получше?
bolega: Видимо придется на пару месяцев все бросить и заняться иконо-писью, либо нанимать дизайнера-художника за деньги, который сумеет на холсте 24х24 (16х16) пикселя передать глубокий смысл команды. Кстати, это очень не просто оказалось. Вообще я считаю все новое сразу не воспринимается. Со временем привыкаешь и уже становится безразлично, нарисована ли в иконке простая линия или bitonal-изображение Дали.
Рассмотрев программу СканКромсатор, мы подходим к основной задаче, ради которой и написана данная статья:
Необходимо всем вместе (и каждому отдельно) задуматься о создании программы, альтернативной СканКромсатору.
К тому же, следует помнить, что это слишком тяжёлая задача чисто физически - одному человеку (т.е. bolega) отвечать за обеспечение такой важной проблемы, как обработка сырых сканов. Ведь достойной альтернативы СканКромсатору нет пока ни одной!
Что может представлять из себя программа, аналогичная СканКромсатору? Кто мог бы её создать и развивать? Давайте попытаемся найти ответы на эти вопросы.
Зная СканКромсатор и опыт его существования, можно сформулировать достаточно конкретное и даже детальное "проектное задание" для возможной будущей программы. Давайте назовём её условно и по аналогии, например, "ScanProcessor".
Прежде всего, ScanProcessor должен быть обязательно с открытыми исходниками, и желательно, в рамках GPL-лицензии. Открытость кода даст возможность коллективно-поэтапной разработки программы ("Принцип Linux").
Во-вторых, ScanProcessor обязательно должен быть наипростейшим в использовании, т.е. доступным большинству пользователей. Не секрет, что подавляющее число потенциальных книгосканировщиков - это люди, вообще бесконечно далёкие от "сложного" использования компьютера. В лучшем случае, это люди, которых наскоро научили на компьютерных курсах выполнять какую-то свою примитивную и однообразную задачу на компьютере, и они боятся на шаг отступить в сторону, чтобы сделать на компьютере нечто отличающееся от их повседневной деятельности. Таковы жесткие реалии, и с этим нельзя не считаться.
Если мы хотим, чтобы электронных версий бумажных книг стало больше, то мы должны предоставить этим людям продукт, доступный их уровню восприятия, и предоставляющий функциональность на уровне СканКромсатора.
Но как это сделать? Как совместить простоту использования и разнообразие сложностей скан-обработки? Я об этом уже говорил выше, когда описывал недостатки Кромсатора. На мой взгляд, эту задачу можно решить при помощи вышеописанных глобальных принципов:
1. Модульность: Пусть ScanProcessor занимается
исключительно лишь обрезкой сырых сканов.
Остальные задачи (очистка фона, групповое
переименование файлов, и т.п.) должны выполняться
другими программами - ScanKromsator, BookRestorer, Adobe Photoshop,
RasterID и т.д. Следует включить в ScanProcessor лишь
"наиболее неотъемлемые" операции,
сопутствующие обрезке: despeckle, deskew, возможно,
изменение DPI.
2. Многопроходность: Как было сказано выше,
предлагается сделать обработку сырых сканов
обязательно 2-х-этапной: на первом этапе мы
унифицируем сканы, делаем их соответствующими
некоторым минимальным требованиям (разрезаем
развороты, отпиливаем ошмётки, делаем deskew и
despeckle), и только потом, на втором этапе, производим
их финишную обрезку. Такой подход позволит
сделать интерфейс программы максимально
простым, т.к. уже не будет "особых" и
"исключительных" сканов, требующих
специальной обработки и особых элементов
управления в интерфейсе для этого.
3. Адекватность: ScanProcessor не должен быть по
базовым показателям значительно хуже, чем другие
распространённые графические программы.
Например, он должен будет листать сканы со
скоростью, не худшей, чем у ACDSee, определять угол
deskew не хуже, чем ABBYY FineReader, иметь достаточно
отлаженный интерфейс, чтобы не выдавать
постоянно ошибки "нестыковки параметров".
Это, пожалуй, одна из самых трудных задач. Она
предполагает, с одной стороны, правильный выбор
хороших базовых чужих исходников, и с другой
стороны, немалое количество времени, потраченное
на тестирование и "вылизывание" интерфейса.
4. Лаконичность: Я предлагаю ориентировать
ScanProcessor исключительно на среднестатистические
задачи, вычисляя их умозрительно, а не на
реализацию запросов рядовых пользователей
(которые норовят просить "добавьте то,
добавьте это", но при этом никто не скажет -
"уберите то, уберите это"). Например,
программа может ограничиться исключительно
обработкой только чёрно-белых сканов (не серых и
не цветных), и только в формате Tif, к примеру. Не
стоит, например, предусматривать в программе
Exclude-зоны, как в Кромсаторе -
среднестатистическая бумажная книга не содержит
серых рисунков-фотографий (которые нужно в эти
зоны заключать при обработке), deskew и despeckle можно
улучшить или, в крайнем случае, просто
"загрубить" так, чтобы и они перестали
нуждаться в Exclude-зонах.
Думаю, нужно крайне избирательно воплощать в программе разные возможности - только такие, которые действительно нужны всем, и без которых ну никак не обойтись. То, что умеют делать и другие программы, воплощать не стоит - ради сохранения наибольшей простоты использования программы. Думаю, это необходимая жертва. Так, например, в Кромсаторе есть опция "резаки не режут, а только чистят". Как выяснилось, эта возможность была нужна одному-единственному человеку, а сотни других людей получили в результате излишнее загромождение интерфейса данной деталью.
5. Эргономичность: Конечно, интерфейс ScanProcessor должен быть интуитивно-ясным. Врочем, при выполнении всех предыдущих принципов, эту задачу можно решить относительно просто. В числе общих рекомендаций можно назвать следующие: не дублировать элементы управления, чётко разделить странично-ориентированные и глобальные опции и "прятять" глобальные, вызывая их только по необходимости, и держать "на виду" только странично-ориентированные (а не вместе с глобальными), логически группировать сходные элементы управления, сделать программу "похожей" на распространённые программы (с целью придания интуитивно-ясности), продумать цветовое-пиктограммное оформление.
Но кто же может сделать такую программу? И как именно - с чего, например, начать?
Вопросы непростые. Начнём со второго.
Поскольку наш гипотетический ScanProcessor задумывается с открытыми исходниками, то делать его может не один человек, а несколько. Конечно, должен быть некий один человек - главный координатор проекта - привлекающий тем или иным способом добровольных помощников, которые делали бы хотя бы каждый по одному тщательно отлаженному модулю, которые координатор потом собирал бы воедино и контролировал бы при этом общую работоспособность системы.
Из каких модулей может состоять подобный ScanProcessor? Начать можно, прежде всего, с изготовления простого "каркасного графического приложения" - аналога известного "Hello, world!" в языках программирования. Такое каркасное приложение должно будет:
- Способно полноценно работать не только под Windows XP/2000, но и обязательно (!) под Windows 98.
- Иметь размер в пределах 2-3 Мегабайт (максимум 5) - чтобы кто угодно мог скачать будущую программу из Интернета по модему.
- Иметь визуальный графический интерфейс.
- Уметь загружать, отображать на экране, листать, и сохранять группу графических файлов (достаточно ограничиться чёрно-белыми файлами в формате Tif).
- Предоставлять функции для работы со сканом как просто с прямоугольной матрицей чёрных и белых (серых) пикселей.
Такое каркасное приложение и будет фундаментом для будущего ScanProcessor. Однако, для этого, оно должно удовлетворять следующим условиям:
- Исходные коды должны быть написаны в хорошем стиле, снабжены комментариями, свободны от излишних "программистских трюков".
- Высокоуровневые функции каркасного приложения должны быть задокументированы - чтобы их потом могли использовать даже программисты, не знакомые именно с программированием растровой графики.
Создание полноценного каркасного приложения - это только первый этап. Второй, и самый сложный этап - это создание модуля распознавания образов - т.е. "ядра" программы, определяющего, где на скане текст, где поля, а где "мусор".
Я не знаю, на каком принципе сделано распознавание образов в Кромсаторе. В нашем случае это могут быть какие-то методы искусственного интеллекта - например, самообучающиеся нейросети (как в Файнридере), либо, может быть, достаточно будет обойтись просто обычными статистическо-алгоритмическими методами.
Такой модуль распознавания образов может сделать программист-"алгоритмист" (какой-нибудь выпускник мехмата), и ему даже не обязательно хорошо знать визуальное программирование: ему достаточно представить наши чёрно-белые сканы просто как прямоугольные матрицы чёрных и белых пикселей, а на выходе он должен выдать нам всего лишь восемь чисел - координаты углов прямоугольника, очерчивающего голый текст на скане.
В случае удачной реализации двух предыдущих этапов останется проделать лишь заключительный этап - сборку 2 модулей в единое целое с добавлением необходимых визуальных элементов управления. Это довольно реальная задача, при условии, что функции всех собираемых модулей задокументированы.
В итоге мы получим крайне простенькую и примитивную программу - ScanProcessor, которая только и будет уметь, что загружать (очень сильно подготовленные) сканы и выдавать "голые тексты". Конечно, такой программой будет малореально пользоваться, но со временем можно будет привлекать людей с тем, чтобы они доработали её - скажем, добавили deskew, despeckle, навешивание полей, и т.п. - то есть те опции, которые не вошли в первоначальное "ядро системы", но без которых не обойтись. При таком подходе мы получим со временем совершенно полноценную, удобную и функциональную программу.
Конечно, этот путь непрост, но есть ли более лучший? Достоинство такой схемы в том, что она позволяет разбить всю задачу на мелкие подзадачи, которые более реально выполнить, чем всё сразу.
Наконец, самый интересный вопрос: кто всё это будет делать?
На мой взгляд, эта проблема сводится к задаче "где найти главного координатора проекта". Если будет координатор, то он найдёт способ привлечь добровольцев для помощи. Это должен быть человек, имеющий компьютер, сканер, доступ в Интернет, и владеющий визуальным программированием. Например, он может написать вышеуказанное каркасное приложение (задача несложная даже для рядового программиста), а потом начать искать на форумах, связанных с вопросами искусственного интеллекта, человека, способного взяться за создание описанного модуля распознавания образов. А в конце скомпоновать оба модуля воедино.
Найти главного координатора проекта можно обычными путями - вывешивать в разных местах Интернета соответствующие объявления (например, со ссылкой на данную статью), спрашивать своих друзей и знакомых. При всей кажущейся нереальности это не столь уж невыполнимая задача.
В заключение я хотел бы обратиться с простой просьбой к читающим эти строки: рассказывайте об этой статье на разных форумах, давайте ссылку на неё, пишите соответствующие объявления на своих персональных сайтах (типа "Ищем главного координатора для проекта "Альтернатива Кромсатору"). При грамотном подходе и толковой организации дела можно решить любую сложную задачу - даже такую, как эта, как бы сложно поначалу это ни выглядело.
В разделе "Материалы по сканированию и оцифровке бумажных книг" в пункте "Материалы для разработчика" есть небольшая подборка ссылок на исходники, которые теоретически можно использовать при создании ScanProcessor.
Впрочем, не исключено, что все необходимые исходники для создания программы, альтернативной СканКромсатору, уже существуют, и нужно просто суметь их найти и скомпоновать нужным образом.
Если у Вас есть какие-то соображения по теме этой статьи - сообщите мне по электронной почте (см. внизу страницы).
Автор: monday2000.
25 августа 2006 г.
E-Mail (monday2000 [at] yandex.ru)