Вы когда-нибудь собирали театральные программки? Если да, то, наверное, в вашей коллекции их десятки, а может, наберется и сотня. А теперь представьте, что в вашем распоряжении 120 тысяч программок, 48 тысяч афиш и 100 тысяч исторических фотографий. Столько бумажных документов сохранил с середины XIX века Большой театр. Самые древние и ценные из них уже пожелтели и стали ветхими, а на поиск информации в театральном архиве уходили часы. Чтобы сохранить эти сокровища, сотрудники театрального музея начали вручную переводить документы в электронный вид, но оказалось, что на это могут уйти годы.

Поэтому в сентябре 2016 года вместе с Большим театром и при активной поддержке Феклы Толстой, праправнучки Льва Николаевича Толстого, мы запустили краудсорсинговый проект по оцифровке истории главного театра страны. В этом посте мы расскажем о подробностях первого этапа проекта и о его технических деталях: как мы оцифровывали уникальные документы с помощью ABBYY FineReader и как волонтеры помогали проверять результаты распознавания.

Ученые Национального института метеорологии Бразилии с 1909 года записывают всю информацию о погодных условиях и изменениях климата в стране. Исследователи анализируют эти данные и строят на их основе прогнозы. За сто лет специалисты собрали более 3 миллионов страниц записей о погоде в знойном Рио-де-Жанейро, на грохочущих водопадах Игуасу, в сумрачных лесах Амазонки и в туманном Сан-Паулу. Но вся информация хранилась в бумажном виде. С каждым годом ее копилось все больше, а старые записи приходили в негодность. Исследователям становилось все сложнее работать с документами.

Сегодня мы расскажем о том, как с помощью нашей технологии ABBYY FlexiCapture Engine Национальный институт метеорологии Бразилии оцифровал архив наблюдений за погодой, который ученые собирали более 100 лет.

Мы уже говорили о распознавании текста из видеопотока, его преимуществах по сравнению с обработкой фотографии и сценариях, где это особенно полезно.

Сегодня мы запускаем ABBYY Real-Time Recognition SDK для мобильных платформ Android и iOS. Поэтому хотим поговорить об особенностях распознавания данных на мобильном устройстве, а именно, об извлечении информации в видеопотоке на примере одного из самых сложных документов – гражданского паспорта.

Всем нам часто приходится использовать свои паспортные данные. Паспорт нужен для регистрации в мобильном банке или платёжной системе, покупки билетов, аренды машины. Сейчас многие используют для этих задач смартфон. Набирать информацию на маленькой клавиатуре мобильного устройства очень неудобно. Особенно неприятное поле для ввода – это данные о месте выдачи паспорта: обычно они занимают пару-тройку строк и содержат множество аббревиатур.

В предыдущем посте мы начали рассказывать, как OCR-технологии «переезжали» с настольных компьютеров в смартфоны – а началось всё с приложения для сканирования визиток Business Card Reader. Но сканирование визиток – это только один сценарий, где нужно мобильное распознавание. О том, как решались другие задачи хотелки пользователей, – читайте ниже.

Как мы уже говорили, перенос технологии распознавания на смартфоны связан с кучей ограничений и сложностей. Главной была и остаётся ресурсоёмкость технологии – невозможно перенести ее в мобильное устройство как есть. Но у нас уже с 2007 года был готовый инструментарий разработчика ABBYY Mobile OCR Engine, который позволял на мобильном оцифровать изображение и выдать результат в формате TXT без сохранения форматирования. И для начала в 2011 году мы решили воплотить в жизнь небольшие пользовательские сценарии, в которых такое «элементарное» распознавание вполне подходило.

Думаем, читателям нашего блога не нужно рассказывать подробно, что такое словарь ABBYY Lingvo. C этого продукта началась компания ABBYY 27 лет назад. Сначала словарь можно было использовать только на компьютерах, потом появились мобильные приложения и онлайн-сервисы. Недавно мы открыли доступ к словарям Lingvo для сторонних разработчиков на сайте https://developers.lingvolive.com – пока в бесплатном бета режиме.

Под катом мы подробнее расскажем о том, как мы работали над этим сервисом и как его можно использовать.

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

Кстати, сейчас мы расширяем команду, занимающуюся созданием продукта для распознавания текста из видеопотока на смартфонах. Если вы Android или iOS-разработчик с опытом написания высоконагруженных приложений и у вас есть желание разрабатывать новые технологии вместе с нами, спешите откликнуться на вакансию.

О видеопотоке и распознавании

Для начала скажем, с каким именно видеопотоком мы работаем.

Перенос OCR-технологий (технологий оптического распознавания) с ПК на мобильные устройства обсуждался, пожалуй, с момента их появления. Ещё в конце 90-х, когда «умные» устройства можно было пересчитать по пальцам, мы задумывались о создании программы, извлекающей данные из визитной карточки, – Business Card Reader, или сокращённо BCR. Эта идея, что называется, витала в воздухе, но ни возможности камер, ни вычислительная мощность устройств не позволяли тогда реализовать её. Выбирать особо не приходилось: либо обычный телефон с хорошей камерой «для обычных людей», либо продвинутый бизнес-наладонник «для профессионалов» (а зачем вообще бизнесменам нужны камеры на устройстве — себя, что ли, фотографировать?)

Но время шло, запросы людей росли, и худо-бедно приличные камеры начали появляться во всех устройствах. Как только возможности устройств «подтянулись», разработчики портировали нашу технологию распознавания, учитывая массу ограничений, свойственных мобильным операционным системам: размер библиотек (попробуй впихнуть OCR с базой изображений в 500 килобайт на носителе), скорость работы на малопроизводительных процессорах. Ещё пришлось учитывать, что распознавать предстояло не идеальные изображения со сканера, а фотографии, сделанные зачастую с перекосами, в условиях плохого освещения и т. п.

В этой статье мы бы хотели обратить внимание разработчиков приложений на такой неоднозначный механизм продвижения, как фичеринг в магазинах мобильных приложений (AppStore и Google Play). Да, нашему редактору тоже не нравится слово «фичеринг» (featuring), но адекватного русского аналога нет, поэтому будем использовать кальку с английского.

Apple или Google featuring – это методика, когда сам Apple или Google выбирает приложения, соответствующие текущим маркетинговым приоритетам этих компаний. Такие приложения выделяются на определенный период с помощью внутренних маркетинговых инструментов App Store/Google Play (прежде всего, это размещение баннера на главной странице App Store/Google Play, или размещение в тематичиской подборке на «видном месте»).

Количество программ — мобильных клиентов, привязанных к различным системам автоматизации деятельности предприятий, постоянно растёт. Согласно исследованию компании IDC, к 2016 году оно увеличится в 4 раза (по сравнению с 2014 годом). Конечно, ABBYY не могла остаться в стороне от этих тенденций, и у нас есть мобильные продукты, ориентированные на корпоративных пользователей. Об одном из них – ABBYY Mobile Imaging SDK (MI SDK) – мы ещё ни разу не рассказывали в блоге, исправляемся.

Наши пользователи привыкли, что мобильные продукты ABBYY – это либо про словари, либо про распознавание. Сразу оговоримся – в ABBYY Mobile Imaging SDK нет ни того, ни другого. Спрашивается, почему нам понадобилось выпускать такое приложение? Ответ – конечно, чтобы продать OCR ещё большему числу клиентов :). Ведь ABBYY Mobile Imaging SDK обычно используется в связке с нашими «корпоративными» решениями для распознавания данных (например, ABBYY Recognition Server) или извлечения данных (например, ABBYY FlexiCapture). Этот небольшой продукт призван помочь нашим «большим» решениям работать лучше, распознавать точнее.

Жизнь изменилась, и если раньше основным устройством, с которого мы получали изображение для распознавания, был сканер, то теперь его всё чаще заменяет мобильный телефон. Чем он отличается от сканера? Конечно, тем, что получить с него изображение хорошего качества гораздо сложнее (разумеется, в данном случае хорошее качество = достаточное для того, чтобы наши OCR-технологии могли распознать текст на фото).

Привет! В прошлый раз мы рассказали о том, как устроена технология понимания и анализа текстов на естественных языках ABBYY Compreno. Многие спрашивают нас – сколько уже можно разрабатывать технологию и где уже, наконец, продукты на базе Compreno. Как и обещали, сегодняшний материал посвящен продуктам и тому, какие именно задачи бизнеса они решают уже сегодня.

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

Сразу отметим, что решения на базе технологии Compreno – это аппликационные или технологические модули, которые встраиваются в любые решения, добавляя им возможности.

Как вы знаете, ABBYY занимается разработкой технологии анализа естественных языков Compreno. Сейчас система работает на английском и русском языках, и активно используется во многих проектах. Однако изначально сама технология была задумана как многоязычная, поэтому мы много внимания уделяем и «обучению» другим иностранным языкам. И тут можно провести некоторую аналогию с человеком: после изучения одного иностранного языка другие даются легче. В частности, сейчас мы добавляем в технологию немецкий язык и параллельно исследуем возможности рынка – есть ли интерес к этому направлению. Сразу оговоримся – пока речь о продуктах, поддерживающих немецкий, не идёт, мы в самом начале пути.

Сегодня мы расскажем вам, как помогали оцифровывать Сахалинскую областную универсальную научную библиотеку. Переводить библиотеки в электронный вид мы начали довольно давно. Постоянные читатели блога наверняка помнят обзорный пост по нашим библиотечным проектам, а также топики, посвященные оцифровке библиотеки Хартли и созданию каталога Королевского ботанического сада Эдинбурга. Итак, поехали.

Сахалинская областная универсальная научная библиотека существует уже 67 лет и остается одним из основных информационных, культурных и научно-исследовательских центров Дальнего Востока. Сегодня в библиотеке хранится около 617 тысяч различных изданий.

Современный мир требует от бизнеса быстрого взаимодействия с клиентами. Чтобы обслужить как можно больше пользователей, компании стараются снимать нагрузку с фронт-офисов, перенося обработку документов в бэк-офисы. Для этого бизнес создает центры – shared services centers или общие центры обслуживания, где происходит обработка и проверка документов и данных, которые пришли из офисов, взаимодействующих с клиентами.

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

Простой макрос

Все началось с простого макроса: (приблизительный код)

#define ADD_BYTE(C) do {            \
  if (offset == capa) {             \
    if (capa < 16) {                \
      capa = 16;                    \
    } else {                        \
      capa <<= 1;                   \
    }                               \
    buffer = realloc(buffer, capa); \
    assert(buffer != NULL);         \
  }                                 \
  buffer[offset++] = (C);           \
} while(0)

Для тех, кто не знаком с языком программирования C, поясню: этот простой макрос добавляет байт «C» в динамически выделяемый буфер (buffer), размер которого (в байтах) равен capa. Следующая позиция для записи определяется при помощи параметра offset. При каждом заполнении буфера происходит двукратное увеличение его объема (начиная с минимального размера в 16 байт).

Мы добавляем байты в динамический буфер — это одна из наиболее распространенных операций практически в любой программе (для работы со строками, массивами и т. п.).

Но как понять, насколько эффективна стратегия перераспределения?

Как отличить программиста от музыканта? Спросите у них, что такое C#.

С начала 1950-х годов, когда человечеству наконец-то удалось научить электронную машину петь, компьютеры постепенно превратились в полезный и универсальный инструмент звукопроизводства. Сегодня благодаря цифровым синтезаторам, VST-плагинам и цифровым звуковым рабочим станциям можно забыть о бесконечных катушках с магнитной лентой и заниматься звукозаписью дома, причем качество будет почти как в студии (при условии, что вы достаточно целеустремленны).

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

Для примера рассмотрим, что происходит при нажатии и отпускании средней клавиши до (в латинской транскрипции — С) на MIDI-клавиатуре (предположим, используется MIDI-канал № 1):

Статус-байт	Байт данных 1	Байт данных 2
144 = взять ноту	60 = нота до 3-й октавы	127 = скорость (0..127): резкий удар по клавише
128 = снять ноту	60 = нота до 3-й октавы	10 = скорость (0..127): плавное отпускание клавиши

Знакомо, правда?

О продукте FlexiCapture, как показывает опыт, обычные пользователи за пределами компании знают совсем мало («Уж не этим ли ЕГЭ распознают?»), несмотря на то, что он используется во многих крупных организациях. Можно с этим мириться, считая, что продукт не для конечного пользователя, а корпоративный. А можно периодически рассказывать про него всякое, что будет не только полезно тем, кто с ним уже знаком, но и намекнёт далёким от продукта людям, что Flex — это не просто 4 буквы в названии.

Наши партнеры из новосибирской компании АТАПИ Софтвер поделились своим приемами обработки разных сложных случаев. Это набор конкретных практических советов, которые, мы надеемся, будут вам полезны. Кроме того, каждая из этих историй подобна дзенскому коану — помогает раскрыть истинную природу FlexiCapture во всем ее многообразии.

Сегодня в рамках наших уроков английского мы расскажем об английских идиомах с именами.

John

John – одно из самых распространённых английских имён. Наверное, именно поэтому оно породило так много интересных идиом, а вымышленные и вполне себе реальные Джоны превратились в нарицательных персонажей:

John Q. Public или John Q. Citizen (товарищ или гражданин Джон Кью) – американизм, обозначающий среднестатистического гражданина, обычного человека. К слову, среднестатистическую гражданку называют Jane Q. Public.

John Hancock (Джон Хэнкок) – имя этого американского государственного деятеля, чья размашистая подпись под Декларацией независимости США приобрела всеобщую известность, стало нарицательным и используется для обозначения вообще всякой подписи. У нас шутливо говорят «поставить закорючку», а американцы просят «поставить своего джона хэнкока», тоже в шутку, разумеется.

Спешим сообщить, что сейчас проходит шестой онлайн-чемпионат по переводу — «Кубок Lingvo 2014». Как и раньше, в соревновании могут принять участие школьники старше 16 лет, студенты всех учебных заведений и форм обучения, а также аспиранты, получившие диплом об окончании вуза не ранее 2012 года. Участники поборются за звание лучшего переводчика, а также за призы и подарки, среди которых поездка в страну изучаемого языка.

В этом году задания Кубка составлены на основе лекций Coursera, а лучшие переводы наших участников станут доступны всем слушателям этого образовательного онлайн-проекта.

Мы продолжаем серию постов про искусственный интеллект, написанных по мотивам выступления в «Технопарке» Mail.ru Константина Анисимовича — директора департамента разработки технологий ABBYY. Вторая статья будет посвящена алгоритмам поиска.


В зависимости от того, какой способ представления знаний мы выбрали — декларативный или продукционный — мы определяем способ применения знаний. С продукционной системой все достаточно просто: мы непосредственно интерпретируем продукции.

Если же мы выбрали декларативное представление знаний, то все происходит несколько сложнее. Для этого нам нужно реализовать поиск в пространстве состояний. Дело в том, что структурированное представлений знаний организовано иерархически. А если мы пытаемся применить иерархическое описание к входным данным, то мы на каждом его уровне получим возможные варианты интерпретации данных — гипотезы.

Как случилось, что искусственный интеллект успешно развивается, а «правильного» определения для него до сих пор нет? Почему не оправдались надежды, возлагавшиеся на нейрокомпьютеры, и в чем заключаются три главные задачи, стоящие перед создателем искусственного интеллекта?

На эти и другие вопросы вы найдете ответ в статье под катом, написанной на основе выступления Константина Анисимовича, директора департамента разработки технологий ABBYY, одного из ведущих экспертов страны в сфере искусственного интеллекта.
При его личном участии были созданы технологии распознавания документов, которые применяются в продуктах ABBYY FineReader и ABBYY FormReader. Константин рассказал об истории и основах разработки AI на одном из мастер-классов для студентов Технопарка Mail.Ru. Материал мастер-класса и стал базой для цикла статей.

Всего в цикле будет три поста:
• Искусственный интеллект для программистов
• Применение знаний: алгоритмы поиска в пространстве состояний
• Получение знаний: инженерия знаний и машинное обучение