Андрей Боровский об YAGF, программистской ноосфере и интеллектуальном распознавании

Термин OCR мы вспоминаем, когда требуется конвертировать внушительных размеров фолиант в неприметный текстовый файл или сделать электронную версию документа на бумаге. Так или иначе, проблему надо решать. И среди свободных решений самым популярным по праву считается YAGF — оболочка для систем распознавания текстов Cuneiform и Tesseract.

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

Представьтесь, пожалуйста. Расскажите, чем занимаетесь по долгу службы и каким образом примкнули к лагерю open source?
Меня зовут Андрей Боровский. На работе я программист, занимаюсь в основном разработкой экспертных систем. Дома я, помимо прочего, тоже иногда программист, а еще любитель возиться со всякими электронными штуками.

С Линуксом познакомился в конце 97-го года. Мне тогда очень надоела Винда (даже эстетически) и я попросил знакомого найти что-нибудь свеженькое. Он принес мне компакт-диск с дистрибутивом Линукс. Кажется, это была Калдера. На диске были записаны образы дискет по 1.44 мегабайта, двадцать с чем-то дискет. Их надо было переписать на настоящие дискеты и устанавливать систему, что уже тогда было некоторым анахронизмом. В те времена в процессе установки инсталлятору нужно было сообщать много низкоуровневых параметров своего оборудования. Мне даже корпус компа пришлось открыть. Но я прошел эту процедуру и познакомился с Линуксом. :)

Как программист я столкнулся с Линуксом в 2001 году. Там был такой момент, мне нужно было посмотреть, как на практике работала какая-то вещь в тогдашней Qt, я взял диск с исходниками дистрибутива Линукс (это был Linux-Mandrake Russian Edition) и быстро нашел то, что мне было нужно. С тех пор я проникся уважением к открытому ПО. Для меня это своего рода «облако знаний», программистская ноосфера, где можно многому научиться. Так получилось, что многие редкие и интересные алгоритмы я прочел сначала в коде, а потом уже находил их описания в книгах или статьях. Для меня понятия «открытое ПО» и «Линукс» не тождественны. Например, существуют драйверы для Windows с открытыми исходными текстами. Всем, кому нужно писать свои драйверы, я рекомендую познакомиться с открытыми драйверами. Это хорошие наглядные учебные пособия. Разумеется, специальную литературу они не отменяют.

То есть, после первого знакомства забыли о линуксе на четыре года? Что помешало переходу?
Нет, не забыл, но и убежденным линуксоидом сразу не стал. Тогда были и другие интересные системы для десктопов: OS/2 еще не умерла и BeOS. BeOS выглядела очень интересно и перспективно. Ее убили не технические проблемы, а чисто маркетинговые ходы. Мне даже сейчас жаль, что так получилось. С интересом слежу за проектом Haiku, может что-нибудь сделаю для него.

Думал, задавать или не задавать вопрос о выборе Qt в качестве фреймворка для YAGF. Теперь же он потерял всякую актуальность — десять лет опыта не шутка. В развитии иных проектов на Qt не участвуете? Как оцениваете эволюцию «Кьюта» за прошедшую декаду лет?
Эволюция огромна. Сейчас некоторые подсистемы Qt сложнее, чем вся библиотека 10 лет назад. Возможно, библиотека стала слишком большой и пытается охватить слишком многое. Но это уже отдельная тема.

Извиняюсь, но не могу не задать вопрос после прочтения страницы вашего профиля в Google+. Там сказано: «В 15 лет своей программой убил школьную ЛВС. Так уж она была устроена. В смысле — ЛВС». Расскажите, пожалуйста, как примерили рубашку хакера :-)
«Рубашку черного хакера» я примерил случайно. Я не хотел никому навредить. Я писал программу, которая должна была передавать данные по этой самой ЛВС, и что-то там не так сделал. А в классе информатики использовалась централизованная архитектура, где всей передачей данных по сетке управляла программа на центральной станции. Эта программа получила мои данные и умерла. И при этом еще умудрилась запортить диск, а диск был системный. Я не считаю, что это моя вина. Программа, управляющая сетью, не должна падать от того, что кто-то передал «неправильные» данные. И тем более не должна портить файловую систему. Но учитель информатики был в ярости и две недели не подпускал меня к компьютерам вообще. :)

Со стороны кажется, что у YAGF поставлена амбициозная задача — убедить пользователей отказаться от виртуальных машин с FineReader. Так ли это на самом деле? Как вы оцениваете ситуацию с OCR в Linux? Какой системе отдаёте предпочтение: tesseract или cuneiform?
Нет, цель YAGF немного другая. Давайте будем реалистами. cuneiform, и tesseract разрабатывались как коммерческие проекты (и первый дошел до стадии стабильной коммерческой разработки). Потом разработчики открыли коды этих программ. Мы все понимаем, конечно, что если бы эти программы могли конкурировать с лидерами рынка, мы бы сейчас вряд ли имели на руках их исходники. Так что мы едва ли догоним и перегоним Readiris или FineReader. Но это не значит, что открытые проекты распознавания текста не нужны. Их преимущество — более высокая адаптируемость. Например, сейчас возрастает интерес к процессорам ARM. Когда появятся коммерческие системы распознавания текста для этих процессоров? Я думаю, этого никто точно не знает. А вот tesseract уже портировали на ARM. Что касается, собственно, YAGF, то в будущем эта программа могла бы поддерживать импорт из DjVu или, например, распознавание текста, зафиксированного видеокамерой. Причем не обязательно, что это сделаю именно я. Любой может подключиться к проекту и адаптировать его для своих нужд.

Сравнивать tesseract и cuneiform можно очень долго, потому что у этих программ много разных особенностей и параметров. Если быть кратким, то мое мнение такое: в будущем tesseract превзойдет cuneiform по всем пунктам (если, конечно, разработчики будут прилагать усилия, как сейчас). А пока-что лучше установить в системе оба инструмента и опытным путем выяснить, какой из них подходит лучше для конкретных задач. Поэтому я и добавил поддержку обоих инструментов в YAGF 0.8.7.

Касательно интереса к процессорам ARM. Смартфоны с Android'ом берут всё новые высоты по завоеванию рынка. Но Google не спешит внедрять Tesseract в прошивку. Их программа Googles отправляет снимок с камеры в облако, а потом присылает результат распознавания. Это говорит о моде облачных решений или сырости вышеназванной OCR?
Неудивительно, что tesseract нет в Android. Там вообще-то много чего нет, и я бы очень удивился, если бы там сейчас появился именно tesseract. Говоря о портировании на ARM, я, все-таки, имел в виду системы, к которым можно подключить сканер. При распознавании текста с фотографий tesseract показывает скромные результаты, в чем каждый может самостоятельно убедиться.

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

Перед интервью я попросил читателей задать свои вопросы «о наболевшем». Один комментатор интересовался преимуществом графических оболочек над CLI. Чтобы не уходить в дебри философии, придётся переформулировать и сузить вопрос: по-вашему, можно ли эффективно распознавать текст в консоли?
Ну давайте посмотрим, что для этого нужно. Сначала нужно запустить XSane, отсканировать страницы. Затем в графическом редакторе все это подправить. Затем, собственно, инструмент распознавания, потом текстовый редактор, чтобы посмотреть, что же получилось. Промежуточные данные нужно передавать в файлах, а затем удалять их. Некоторые этапы этого цикла придется пройти несколько раз. Если кому-то нравится работать таким образом, это его право. Но я думаю, что все это удобнее делать из одной программы, которая управляет всем циклом и показывает пользователю результаты. И многие пользователи YAGF согласны со мной. :)

Спрашиваю, потому что предпринимал попытки обойтись одним cuneiform. Результат был плачевным.
Мне при таком подходе не нравится, что я не вижу, что именно распознается. Приходится держать открытыми несколько программ и все время перезагружать файлы. YAGF избавляет от этой необходимости.

На сайте написано, что вы развиваете собственную ветку Cuneiform главным образом для распознавания текстов на смешанных языках (русский-французский, русский-немецкий, русский-испанский). Ваши патчи попадают в основную ветку? Какие наработки наиболее значимы, на ваш взгляд?
Тут надо учесть, что cuneiform не полностью открытая программа. Не углубляясь в технические подробности, скажу, что cuneiform нельзя обучить новым языкам. Он будет распознавать только то, что в него было когда-то заложено. Соответственно, мои попытки расширить возможности распознавания носили характер «хака». Текст распознавался на двух языках, а потом «склеивался». В процессе этого хакинга я узнал много интересного о внутреннем устройстве cuneiform, и иногда мои хаки неплохо работали, но в конечном итоге я понял — это неверный путь. Сейчас я не работаю над этим, а если снова начну, то уже на базе tesseract, который полностью открыт и обучаем.

В версии 0.8.7 появился импорт страниц из PDF. Стоит ли ожидать поддержки формата DjVu? Появится ли возможность наложить текстовый слой вместо изображения в PDF/DjVu?
При импорте PDF возникла одна интересная проблема. Во многих документах PDF, где текст хранится как картинка, разрешение этой картинки слишком низкое для уверенного распознавания. Я сейчас размышляю над алгоритмами реконструкции текста из картинки с низким разрешением в картинку с более высоким разрешением. Обычные алгоритмы масштабирования, такие, которые использует GIMP, например, тут не годятся. У меня уже есть идеи, но они будут хорошо работать (если будут) только для PDF, но не для DjVu. Для DjVu придется придумать что-то другое. Если получится, то импорт будет.

Для пост-обработки сканированных страниц существует Scan Tailor. Не планируете ли вы интегрировать этот инструмент в YAGF?
Я обсуждал эту возможность с разработчиками Scan Tailor (правда, это было давно) и мы пришли тогда к выводу, что пока каждый пойдет своим путем. Я сейчас хочу направить основные усилия на добавление в YAGF алгоритмов обработки текста, необходимых именно при распознавании текста (распознавание таблиц, распознавание типов блоков «текст/картинка». Когда это будет сделано, к вопросу об объединении со Scan Tailor можно будет вернуться, если вторая сторона, конечно, этого захочет. С другой стороны, один открытый проект, как правило, может заимствовать код из другого открытого проекта, что бы об этом не думал автор кода. Так что на многие вещи можно посмотреть и проще.

Каким вы видите первый финальный релиз (1.0)? У проекта есть roadmap или функции внедряются в зависимости от запросов пользователей и ваших личных предпочтений?
Более интеллектуальным (с большим числом алгоритмов, повышающих распознаваемость текста). Да и графический интерфейс надо доработать. Будет возможность сохранять проекты, которые состоят из многих страниц, для дальнейшей работы с проектом как с единым целым. Возможно, еще кое что будет добавлено. Но я осторожен в обещаниях. Лучше пообещать меньше, а сделать больше, чем наоборот. :)

Пожелания пользователей принимаются (принимаются и патчи с исправлениями и дополнениями), если новые фичи соответствуют моему представлению об облике программы. Я точно могу сказать, чем она не должна быть. Она не должна стать «комбайном». Слишком много функций редактирования изображения или текста, вызываемых пользователем, могут помешать. YAGF — это не графический редактор и не текстовый. Говоря о том, что не должно быть слишком много функций, я имею в виду именно команды пользователя. Функции, которые автоматически улучшают распознаваемость текста или исправляют ошибки, будут добавляться и добавляться.

Спасибо за беседу. Успехов вам и проекту!
Спасибо и Вам.

Tweet