Подсистема HAL

Запросы

Каркас приложения отправляет запросы на захваченные результаты в подсистему камеры. Один запрос соответствует одному набору результатов. Запрос инкапсулирует всю информацию о конфигурации захвата и обработки этих результатов. Сюда входят такие вещи, как разрешение и формат пикселей; ручное управление датчиком, объективом и вспышкой; режимы работы 3A; управление обработкой 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 камеры. Пожалуйста, смотрите platform/hardware/interfaces/camera/ для определений интерфейса 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() для этого захвата.
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 (если поддерживается)
	ВКЛ_АВТО_ВСПЫШКА	Все включено, плюс android.flash.firingPower, android.flash.firingTime и android.flash.mode
	ВСЕГДА_МИГАЕТ	То же, что и ON_AUTO_FLASH
	ВКЛ_АВТО_ВСПЫШКА_КРАСНЫХ_ГЛАЗ	То же, что и ON_AUTO_FLASH
android.control.awbMode	ВЫКЛЮЧЕННЫЙ	Никто
	БАЛАНС_БЕЛОГО_*	android.colorCorrection.transform. Корректировки, зависящие от платформы, если android.colorCorrection.mode имеет значение FAST или HIGH_QUALITY.
android.control.afMode	ВЫКЛЮЧЕННЫЙ	Никто
	РЕЖИМ_ФОКУСА_*	android.lens.focusРасстояние
android.control.videoСтабилизация	ВЫКЛЮЧЕННЫЙ	Никто
	НА	Можно настроить android.scaler.cropRegion для реализации стабилизации видео
режим.управления.андроидом	ВЫКЛЮЧЕННЫЙ	AE, AWB и AF отключены
	АВТО	Используются индивидуальные настройки AE, AWB и AF
	РЕЖИМ_СЦЕНЫ_*	Может переопределять все параметры, перечисленные выше. Отдельные элементы управления 3A отключены.

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

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

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

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

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

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