Подсистема HAL

Запросы

Платформа приложения отправляет запросы на захваченные результаты в подсистему камеры. Один запрос соответствует одному набору результатов. Запрос инкапсулирует всю информацию о конфигурации для сбора и обработки этих результатов. Сюда входят такие вещи, как разрешение и формат пикселей; ручной датчик, объектив и управление вспышкой; 3А режимы работы; Управление обработкой RAW в YUV; и формирование статистики. Это позволяет лучше контролировать вывод и обработку результатов. Несколько запросов могут выполняться одновременно, и отправка запросов не блокируется. И запросы всегда обрабатываются в порядке их поступления.

Рисунок 1. Модель камеры

HAL и подсистема камеры

Подсистема камеры включает в себя реализации компонентов конвейера камеры, таких как алгоритм 3A и элементы управления обработкой. Камера HAL предоставляет интерфейсы для реализации ваших версий этих компонентов. Для обеспечения кросс-платформенной совместимости между несколькими производителями устройств и поставщиками процессоров сигналов изображения (ISP или датчиков камеры) модель конвейера камеры является виртуальной и не соответствует напрямую какому-либо реальному ISP. Однако он достаточно похож на настоящие конвейеры обработки, поэтому вы можете эффективно сопоставить его с вашим оборудованием. Кроме того, он достаточно абстрактен, чтобы использовать несколько различных алгоритмов и порядков работы без ущерба для качества, эффективности или совместимости между устройствами.

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

Рисунок 2. Конвейер камеры

Обратите внимание, что некоторые блоки обработки изображений, показанные на диаграмме выше, не были четко определены в исходной версии. Конвейер камеры делает следующие предположения:

• Выходной файл RAW Bayer не обрабатывается внутри ISP.
• Статистика генерируется на основе необработанных данных датчиков.
• Различные блоки обработки, преобразующие необработанные данные датчика в формат YUV, расположены в произвольном порядке.
• Несмотря на то, что отображаются несколько единиц масштабирования и кадрирования, все единицы масштабирования совместно используют элементы управления областью вывода (цифровое масштабирование). Однако каждое устройство может иметь разное выходное разрешение и формат пикселей.

Сводка по использованию API
Это краткое изложение шагов по использованию API камеры Android. Подробное описание этих шагов, включая вызовы API, см. в разделе «Запуск и ожидаемая последовательность операций».

1. Слушайте и перечисляйте камеры.
2. Откройте устройство и подключите слушателей.
3. Настройте выходные данные для целевого варианта использования (например, захват неподвижных изображений, запись и т. д.).
4. Создайте запрос(ы) для целевого варианта использования.
5. Захват/повторение запросов и пакетов.
6. Получите метаданные результата и данные изображения.
7. При переключении вариантов использования вернитесь к шагу 3.

Сводка операций HAL

• Асинхронные запросы на захваты исходят от фреймворка.
• Устройство HAL должно обрабатывать запросы по порядку. И для каждого запроса создайте метаданные выходных результатов и один или несколько буферов выходных изображений.
• «Первым пришел — первым обслужен» для запросов и результатов, а также для потоков, на которые ссылаются последующие запросы.
• Временные метки должны быть одинаковыми для всех выходных данных данного запроса, чтобы платформа могла при необходимости сопоставить их вместе.
• Вся конфигурация захвата и состояние (за исключением подпрограмм 3A) инкапсулируются в запросах и результатах.

Рисунок 3. Обзор камеры HAL

Запуск и ожидаемая последовательность операций

В этом разделе содержится подробное объяснение шагов, ожидаемых при использовании API камеры. См. раздел « Платформа/аппаратное обеспечение/интерфейсы/камера/» для определения интерфейса HIDL.

Перечисление, открытие камер и создание активной сессии

1. После инициализации платформа начинает прослушивать всех существующих поставщиков камер, которые реализуют интерфейс ICameraProvider . Если такой провайдер или провайдеры присутствуют, платформа попытается установить соединение.
2. Фреймворк перечисляет камеры с помощью ICameraProvider::getCameraIdList() .
3. Фреймворк создает экземпляр нового ICameraDevice , вызывая соответствующий ICameraProvider::getCameraDeviceInterface_VX_X() .
4. Платформа вызывает ICameraDevice::open() для создания нового активного сеанса захвата ICameraDeviceSession.

Использование активного сеанса камеры

1. Фреймворк вызывает ICameraDeviceSession::configureStreams() со списком потоков ввода/вывода на устройство HAL.
2. Платформа запрашивает настройки по умолчанию для некоторых случаев использования с вызовами ICameraDeviceSession::constructDefaultRequestSettings() . Это может произойти в любой момент после того, как ICameraDeviceSession будет создан с помощью ICameraDevice::open .
3. Платформа создает и отправляет первый запрос на захват в HAL с настройками, основанными на одном из наборов настроек по умолчанию, и по крайней мере с одним потоком вывода, который ранее был зарегистрирован платформой. Это отправляется в HAL с помощью ICameraDeviceSession::processCaptureRequest() . HAL должен заблокировать возврат этого вызова, пока он не будет готов к отправке следующего запроса.
4. Платформа продолжает отправлять запросы и вызывает ICameraDeviceSession::constructDefaultRequestSettings() для получения буферов настроек по умолчанию для других вариантов использования по мере необходимости.
5. Когда начинается захват запроса (сенсор начинает выставляться для захвата), HAL вызывает ICameraDeviceCallback::notify() с сообщением SHUTTER, включая номер кадра и временную метку для начала выдержки. Этот обратный вызов с уведомлением не должен происходить до первого processCaptureResult() для запроса, но никакие результаты не будут доставлены в приложение для захвата до тех пор, пока не будет вызвано notify( notify() для этого захвата.
6. После некоторой задержки конвейера HAL начинает возвращать завершенные захваты в фреймворк с помощью ICameraDeviceCallback::processCaptureResult() . Они возвращаются в том же порядке, в котором были отправлены запросы. Несколько запросов могут выполняться одновременно, в зависимости от глубины конвейера устройства HAL камеры.

Через некоторое время произойдет одно из следующего:

• Платформа может прекратить отправку новых запросов, дождаться завершения существующих захватов (все буферы заполнены, все результаты возвращены), а затем снова вызвать ICameraDeviceSession::configureStreams() . Это сбрасывает аппаратное обеспечение камеры и конвейер для нового набора потоков ввода/вывода. Некоторые потоки могут быть повторно использованы из предыдущей конфигурации. Затем платформа переходит от первого запроса захвата к HAL, если остается хотя бы один зарегистрированный выходной поток. (В противном случае сначала требуется ICameraDeviceSession::configureStreams() .)
• Фреймворк может вызвать ICameraDeviceSession::close() для завершения сеанса камеры. Это может быть вызвано в любое время, когда никакие другие вызовы из фреймворка не активны, хотя вызов может блокироваться до тех пор, пока не будут завершены все текущие захваты (все результаты возвращены, все буферы заполнены). После возврата вызова close() больше не разрешены вызовы ICameraDeviceCallback из HAL. После выполнения вызова close() платформа не может вызывать какие-либо другие функции устройства HAL.
• В случае ошибки или другого асинхронного события HAL должен вызвать ICameraDeviceCallback::notify() с соответствующим сообщением об ошибке/событии. После возврата из уведомления о фатальной ошибке для всего устройства HAL должен действовать так, как если бы для него была вызвана функция close() . Однако HAL должен либо отменить, либо завершить все незавершенные захваты перед вызовом notify() , чтобы после вызова notify( notify() с фатальной ошибкой инфраструктура не получала дальнейших обратных вызовов от устройства. Методы, кроме close() , должны возвращать -ENODEV или NULL после возврата метода notify notify() из сообщения о фатальной ошибке.

Рисунок 4. Рабочий процесс камеры

Аппаратные уровни

Устройства камеры могут реализовывать несколько аппаратных уровней в зависимости от их возможностей. Дополнительные сведения см. в разделе поддерживаемый аппаратный уровень .

Взаимодействие между запросом захвата приложения, управлением 3A и конвейером обработки

В зависимости от настроек в блоке управления 3A конвейер камеры игнорирует некоторые параметры в запросе захвата приложения и вместо этого использует значения, предоставляемые подпрограммами управления 3A. Например, когда активна автоматическая экспозиция, время экспозиции, продолжительность кадра и параметры чувствительности датчика контролируются алгоритмом платформы 3A, а любые значения, указанные приложением, игнорируются. Значения, выбранные для кадра подпрограммами 3A, должны быть указаны в выходных метаданных. В следующей таблице описаны различные режимы блока управления 3A и свойства, которыми управляют эти режимы. См. в файле platform/system/media/camera/docs/docs.html определения этих свойств.

Элементы управления в блоке обработки изображений на рис. 2 работают по одному и тому же принципу, и обычно каждый блок имеет три режима:

• OFF: Этот блок обработки отключен. Блоки настройки демозаики, цветокоррекции и кривой тона нельзя отключить.
• БЫСТРЫЙ: в этом режиме блок обработки может не замедлять частоту кадров вывода по сравнению с режимом OFF, но в остальном он должен производить вывод наилучшего качества, который он может с учетом этого ограничения. Как правило, это используется для предварительного просмотра или режимов записи видео, а также для серийного захвата неподвижных изображений. На некоторых устройствах это может быть эквивалентно режиму OFF (никакая обработка не может выполняться без замедления частоты кадров), а на некоторых устройствах это может быть эквивалентно режиму HIGH_QUALITY (наилучшее качество по-прежнему не снижает частоту кадров).
• HIGH_QUALITY: в этом режиме блок обработки должен производить результат наилучшего возможного качества, снижая частоту выходных кадров по мере необходимости. Как правило, это используется для высококачественной фотосъемки. Некоторые блоки включают ручное управление, которое можно выбрать вместо FAST или HIGH_QUALITY. Например, блок коррекции цвета поддерживает матрицу преобразования цвета, а корректировка кривой тона поддерживает произвольную глобальную кривую преобразования тона.

Максимальная частота кадров, которую может поддерживать подсистема камеры, зависит от многих факторов:

• Запрошенные разрешения выходных потоков изображений
• Наличие режимов биннинга/пропуска на тепловизоре
• Полоса пропускания интерфейса имидж-сканера
• Пропускная способность различных блоков обработки ISP

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

• Датчик изображения всегда настраивается для вывода наименьшего возможного разрешения с учетом запрошенных приложением размеров выходного потока. Наименьшее разрешение определяется как не меньше максимального запрошенного размера выходного потока.
• Поскольку любой запрос может использовать любой или все сконфигурированные в данный момент выходные потоки, датчик и интернет-провайдер должны быть настроены для поддержки масштабирования одного захвата на все потоки одновременно.
• Потоки JPEG действуют как обработанные потоки YUV для запросов, для которых они не включены; в запросах, в которых на них прямо ссылаются, они действуют как потоки JPEG.
• Процессор JPEG может работать одновременно с остальной частью конвейера камеры, но не может обрабатывать более одного снимка за раз.