2. Программные средства для ввода и обработки зрительных данных
Программные средства для ввода и обработки зрительных данных можно разделить на три группы: инструментальные средства для обращения к аппаратным средствам из приложений (SDK); библиотеки с реализацией алгоритмов обработки изображений и программные пакеты для ввода и обработки зрительных данных в интерактивном режиме. В случае, если функции SDK перенаправляют вызовы приложений операционной системе, можно говорить об интерфейсе прикладного программирования (API), предоставляемом конкретной операционной системой.
2.1 SDK для ввода зрительных данных
Инструментальные средства разработки (SDK) для ввода зрительных данных – это программные средства, предоставляющие приложениям доступ к устройствам ввода зрительных данных (фреймграбберам) и источникам зрительных данных (камерам). Во многих случаях (преимущественно при работе с источниками видеосигнала телевизионного стандарта) непосредственного доступа к камерам не предусмотрено, и управление свойствами получаемых в ПК зрительных данных осуществляется только с помощью фреймграббера.
Приложения, выполняющие ввод и обработку зрительных данных, составляют относительно небольшую долю приложений, разрабатываемых для современных ОС. По этой причине до последнего времени в ОС массового распространения для персональных компьютеров не было общепринятого стандарта на интерфейс прикладного программирования для ввода зрительных данных.
Для ОС Windows в 1992 г. был разработан интерфейс прикладного программирования (API) Video for Windows (VFW). В основном он был предназначен для захвата и сохранения видеоданных на диске (типичная задача в приложениях нелинейного видеомонтажа [3]). VFW успешно обеспечивает захват больших объемов данных (сейчас скорость захвата может превышать 20 Мб/с), и этот API используется в большом количестве приложений [22]. Однако у архитектуры VFW есть ряд недостатков, затрудняющих использование этого интерфейса в системах технического зрения: невозможность программного управления аппаратным обеспечением, отсутствие доступа к отдельным полукадрам, избыточное копирование буферов изображений.
По этим причинам производители промышленных фреймграбберов были вынуждены разрабатывать собственные специфические драйверы для своих плат, вследствие чего оказалось:
промышленные фреймграбберы нельзя использовать в мультимедиа-приложениях общего назначения;
приложения технического зрения жестко привязаны к конкретной модели фреймграббера;
платы различных производителей не взаимозаменяемы – это становится серьезной проблемой, когда фреймграбберы определенной марки перестают выпускаться.
Перечисленные недостатки интерфейса VFW оказались также существенными для приложений видеоконференций и технологий интеграции персонального компьютера с телевидением. Поэтому для ОС Windows была разработана новая программная технология ввода зрительных данных (видеозахвата – video capture) на базе 32-разрядной архитектуры драйверов для ОС Windows – WDM (Windows Driver Model) [23, 21].
В результате в настоящее время можно выделить 6 разновидностей SDK для ввода зрительных данных [6].
1. SDK на основе DLL
SDK на базе DLL поставляются с документированным API и примерами приложений, обычно на языке Си или Си++. Для ОС, отличных от Windows, аналогом описываемых SDK являются статические библиотеки и драйверы, управляемые из приложений (например, через механизм DeviceIoCtl). Подобные SDK обычно рассчитаны на взаимодействие с фреймграбберами определенных моделей.
Преимущества: возможность полного контроля над аппаратными ресурсами, предоставляемого разработчиками драйверов, входящих в комплект SDK. Нет ограничений, налагаемых стандартными общесистемными механизмами.
Недостатки: у разработчиков ПрО необходимы навыки программирования на Си, приложения получаются непереносимыми на другую аппаратную базу, привязанными к данной модели фреймграббера и SDK.
2. SDK на основе объектов ActiveX
Элементы управления (объекты) ActiveX являются средством обеспечения модульности программных компонент на уровне исполняемых файлов в среде Windows [26]. Достаточно легко могут быть встроены в прикладную программу с помощью современных сред программирования Visual Studio, Borland Delphi, C++ Builder и т.п.
Преимущества: легко использовать в средах быстрой разработки приложений Visual Basic, Borland Delphi и т.п. Для написания достаточно сложных приложений требуется небольшое количество исходного текста.
Недостатки: большие накладные расходы на вызовы методов, связанные с использованием variant-совместимых типов данных в рамках технологии Windows COM.
3. Драйверы VFW
С помощью API Video for Windows приложения могут использовать для получения изображений драйвер VFW.
Преимущества: широкое использование в существующих мультимедиа-приложениях и недорогих устройствах ввода (например, в Web-камерах).
Недостатки: ограниченные возможности управления аппаратурой, прекращение развития интерфейса VFW компанией Microsoft.
4. Драйверы WDM
Современная модель драйверов для 32-битных PCI-устройств, устройств FireWire вроде цифровых видеокамер, устройств USB и др. Модель видеозахвата WDM была разработана для преодоления проблем, изначально присущих VFW. Главными преимуществами видеозахвата с использованием WDM являются:
обеспечивается поддержка 32-разрядных драйверов для устройств с 32-разрядной архитектурой, таких, как платы PCI, устройства USB, камеры FireWire (IEEE 1394) и др;
интеграция с DirectShow API (интерфейс программирования и макетирования ввода и программной обработки изображений);
предусмотрена поддержка Plug and Play, управление питанием и высокопроизводительный потоковый видеозахват;
допускается несколько потоков данных (аудио, видео и др.);
обеспечивается ввод и отображение полукадров и отслеживание интервала обратного хода луча кадровой развертки;
выполняется прямое взаимодействие с драйверами WDM режима ядра ОС;
предусмотрена работа с коммутатором входных потоков данных.
Преимущества: 32-битный интерфейс для мультимедиа-приложений, естественная интеграция с концепцией графа фильтров Microsoft, доступность из приложений распространенных сред программирования семейства MS Visual Studio.
Недостатки: пока не для всех фреймграбберов есть соответствующие драйверы. Аппаратная независимость в данной модели драйверов означает сильную зависимость от архитектуры ОС Windows, что затрудняет перенос ПрО на другие программные платформы.
5. Фильтры видеозахвата
Фильтры видеозахвата используются, например, вместе с редактором графа фильтров фирмы Microsoft для получения изображений с помощью WDM-драйверов.
Преимущества: быстрое макетирование процесса ввода и, возможно, обработки изображений с помощью редактора графа фильтров, доступность из Visual Basic и Visual C++.
Недостатки: необходимость разработки приложений в терминах потоков данных. Это не слишком удобно для СТЗ со сложной логикой обработки зрительных данных и взаимодействием.
6. Кодеки потоковых видеоданных
Видеокодеки являются программными компрессорами/декомпрессорами реального времени для обработки потока видеоданных. Предназначены для преобразования видеопотока в AVI-формат или данных из AVI-формата в видеопоток. Кодеки регистрируются в системном реестре MS Windows и могут быть использованы в любом приложении, которое написано для DirectShow или VFW.
Преимущества: кодеки совместимы с приложениями наподобие Media Player, Media Studio и т.д., с редактором графа фильтров. К ним можно обращаться из Visual Basic и Visual C.
Недостатки: в СТЗ не всегда удается обойтись воспроизведением видеоданных без программной обработки: кроме вывода видеоданных, на них приходится накладывать образы различных объектов, представляющих результаты обработки изображений.
Рассматривая перечисленные варианты реализации SDK применительно к задаче разработки СТЗ реального времени, в качестве наиболее подходящего варианта можно выбрать "SDK на основе DLL (или статической библиотеки)". В данном SDK должны быть функции настройки параметров фреймграббера (например, яркость, контрастность, номер входного канала, четность снимаемого полукадра) и функции для запуска фреймграббера на ввод изображения. После завершения ввода изображения фреймграббер должен сгенерировать прерывание, которое с помощью какого-либо объекта синхронизации потоков в базовой ОС должно быть передано на уровень приложения. В данной модели, несмотря на использование аппаратно-зависимых компонент ПрО, возможно обеспечение относительной аппаратной независимости СТЗ за счет реализации собственного уровня абстракции аппаратного обеспечения для ввода зрительных данных.
|
