Подсистема HAL

На этой странице описывается подсистема HAL, включая запросы, подсистему камеры, последовательность запуска и работы, аппаратные уровни и взаимодействия.

Запросы

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

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

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

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

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

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

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

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

Краткое описание использования API

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

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

Краткое описание работы HAL

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

Рисунок 3. Общий вид HAL-модуля камеры.

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

В этом разделе приведено подробное описание шагов, ожидаемых при использовании API камеры. Определения интерфейсов HIDL см. в platform/hardware/interfaces/camera/ .

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

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, включающим номер кадра и метку времени начала экспозиции. Этот обратный вызов notify не обязательно должен происходить до первого вызова processCaptureResult для запроса, но результаты захвата не передаются приложению до тех пор, пока не будет вызван 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 с фатальной ошибкой платформа не получала дальнейших обратных вызовов от устройства. Методы, кроме close , должны возвращать -ENODEV или NULL после возврата метода notify из сообщения о фатальной ошибке.

Рисунок 4. Схема работы камеры.

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

В зависимости от возможностей камер, устройства могут реализовывать несколько уровней аппаратной поддержки. Для получения дополнительной информации см. раздел «Поддерживаемые уровни аппаратной поддержки» .

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

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

Параметр	Состояние	контролируемые свойства
android.control.aeMode	OFF	Никто.
	ON	android.sensor.exposureTime , android.sensor.frameDuration , android.sensor.sensitivity , android.lens.aperture (если поддерживается) и android.lens.filterDensity (если поддерживается).
	ON_AUTO_FLASH	Всё ON , плюс android.flash.firingPower , android.flash.firingTime и android.flash.mode .
	ON_ALWAYS_FLASH	Аналогично ON_AUTO_FLASH .
	ON_AUTO_FLASH_RED_EYE	Аналогично ON_AUTO_FLASH .
android.control.awbMode	OFF	Никто.
	WHITE_BALANCE_*	android.colorCorrection.transform . Корректировки, специфичные для платформы, если android.colorCorrection.mode имеет значение FAST или HIGH_QUALITY .
android.control.afMode	OFF	Никто
	FOCUS_MODE_*	android.lens.focusDistance
android.control.videoStabilization	OFF	Никто.
	ON	Можно изменить параметр android.scaler.cropRegion для реализации стабилизации видео.
android.control.mode	OFF	Функции AE, AWB и AF отключены.
	AUTO	Используются индивидуальные настройки AE, AWB и AF.
	SCENE_MODE_*	Можно переопределить все перечисленные выше параметры. Отдельные элементы управления 3A отключены.

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

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

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

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

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

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