Добрый день, уважаемые читатели.
Наверное, вы хотите услышать от нас бравурную success-story внедрения наших облачных технологий. Разочарую – сегодня речь пойдёт о делах более чем земных, но не становящихся от этого менее интересными. Я попробую рассказать вам об амбициозном проекте процессинга рунических документов, получаемых из разных источников. К примеру, вот таких:
В этом проекте мы столкнулись с необычными задачами не только для систем распознавания, синтеза текста и DA (document analysis – так у нас называют часть FineReader’а, отвечающую за выделение текстовых областей), но и для обработки изображений и экспорта.
Наша компания выступила в этом проекте не в совсем привычной для себя роли. Обычно наши технологии используются для потокового ввода документов, мы в этом поднаторели основательно и потому к таким задачам всегда готовы. На этот раз заказчики выбрали нас для решения скорее исследовательских задач, где требуется кропотливое восстановление каждого документа с максимальной точностью.
Как наши читатели, наверное, знают, руны предназначены для начертания не столько на бумагоподобных источниках, как береста, пергамент или папирус, сколько для высечения их на камнях и дощечках. На это указывает даже форма большинства рунических символов:
Так как руны наносились обычно режущим инструментом, то применение стандартной признаковой распознавалки, обученной для работы с печатными текстами, было неразумно – тем более, что в нашем распоряжении есть такой мощный инструмент как структурное распознавание, где каждый символ описывается на языке отрезков, дуг и их взаимного расположения (см. в документации к SDK).
Процесс оказался привычным, хоть и довольно трудоёмким – пришлось вручную описывать структуру каждой руны, а затем уже полуавтоматически подбирать соотношения между ними. Заметим, что в руническом письме элемент «дуга» не использовался (не каждый сможет выдолбить дугу или окружность на камне).
Как мы уже упоминали, большинство рун изображено на небумажных носителях. Поэтому для первоначальной оцифровки применять сканер весьма затруднительно. Пришлось обходиться фототехникой. Как следствие, мы при обработке часто не знали размер изображения. Поначалу этот вопрос решался довольно просто – при фотографировании мы ставили рядом с рунным камнем разработчика, чей рост был известен. Фотографии выглядели как-то так:
Но впоследствии, когда нам стало доступно больше источников, пришлось прекратить опираться на разрешение изображений в наших алгоритмах.
Особый интерес у наших заказчиков, да и у разработчиков, вызвали так называемые лунные руны. Как известно, эти руны можно прочитать только при свете луны, причём некоторые можно рассмотреть, только если луна находится в той же фазе, в которой она была в момент их нанесения. Для некоторых важен также и лунный месяц. Как выяснилось, никакой магии при этом не используется, просто спектр лунного свечения несколько меняется от фазы к фазе и от месяца к месяцу в течение года, и нужные компоненты могут проявляться не всегда, а только в определённый день лунного года. В этом легко убедиться, рассмотрев такие руны ровно через полгода после момента, когда их можно прочесть, но находясь примерно на той же широте южного полушария – руны будут видны столь же чётко.
Для ускорения процесса (чтобы не ждать по полгода для каждой записи) мы немного доработали стандартную камеру. Пришлось расширить диапазон принимаемых областей спектра, добавив наиболее характерное лунное измерение октарин – так что теперь наши изображения стали сохраняться в 32-битном цветовом пространстве RGBO. Для удобства мы стали записывать синюю и октариновую компоненты в старшие биты, так что наше цветовое пространство корректно было бы называть BORG (или GROB для систем с Big Endian).
Не обошлось и без казусов. Как вы, наверное, знаете, с помощью рун записано довольно много разнообразнейших заклятий. Причём некоторые из них защищены от переписывания: всё-таки копирайт – это изобретение не последних лет. Но мы неосторожно выгрузили пару таких защищённых заклятий в html – и в результате браузер, которым это просматривали, оказался проклятым, и при попытке открыть, скажем, Хабр стал выдавать примерно следующие сообщения:
Пришлось сохранять тексты с простым сжатием и распаковывать по частям, изучая их на предмет заклятий некопирования.
На наше счастье, на тестовой базе не нашлось достаточно мощных заклятий огня, с которыми часто имеют дело наши заказчики. Для них это давно решённая проблема: все их компьютеры оборудованы огнетушителями с автономной системой управления под BeOS. Всё дело в том что в BeOS реализована полезная функция is_computer_on_fire, которая к тому же довольно точно измеряет температуру горящей материнской платы (подробнее – здесь). Кстати, сисадмины заказчика угостили нас весьма недурным шашлыком – если температуру материнской платы поддерживать в районе 230-240 градусов Цельсия, то всего за сорок минут мясо получается нежным и очень сочным.
Все распознанные руны были аккуратно нанесены на свитки и переданы заказчику. Разумеется, мы не откажем себе в удовольствии разместить здесь групповое фото с заказчиками:
Дмитрий Дерягин,
департамент разработки технологий
Автор: 57DeD
