Подсистема 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, включающим номер кадра и метку времени начала экспозиции. Этот обратный вызов уведомления не обязательно должен происходить до первого вызова 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	ВЫКЛЮЧЕННЫЙ	Никто
	НА	android.sensor.exposureTime android.sensor.frameDuration android.sensor.sensitivity android.lens.aperture (если поддерживается) android.lens.filterDensity (если поддерживается)
	ON_AUTO_FLASH	Всё включено, плюс android.flash.firingPower, android.flash.firingTime и android.flash.mode.
	ВСЕГДА ВКЛЮЧЕНО_ВКЛЮЧЕНО_ВКЛЮЧЕНО	Аналогично ON_AUTO_FLASH
	ON_AUTO_FLASH_RED_EYE	Аналогично ON_AUTO_FLASH
android.control.awbMode	ВЫКЛЮЧЕННЫЙ	Никто
	БАЛАНС БЕЛОГО*	android.colorCorrection.transform. Корректировки, специфичные для платформы, если android.colorCorrection.mode имеет значение FAST или HIGH_QUALITY.
android.control.afMode	ВЫКЛЮЧЕННЫЙ	Никто
	РЕЖИМ ФОКУСА*	android.lens.focusDistance
android.control.videoStabilization	ВЫКЛЮЧЕННЫЙ	Никто
	НА	Можно настроить параметр android.scaler.cropRegion для реализации стабилизации видео.
android.control.mode	ВЫКЛЮЧЕННЫЙ	AE, AWB и AF отключены.
	АВТО	Используются индивидуальные настройки AE, AWB и AF.
	РЕЖИМ_СЦЕНЫ_*	Можно переопределить все перечисленные выше параметры. Отдельные элементы управления 3A отключены.

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

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

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

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

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

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