Подсистема 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 камеры. Определения интерфейсов 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_ALWAYS_FLASH	То же, что и 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	ВЫКЛЮЧЕННЫЙ	Никто
	FOCUS_MODE_*	android.lens.focusDistance
android.control.videoСтабилизация	ВЫКЛЮЧЕННЫЙ	Никто
	НА	Можно настроить android.scaler.cropRegion для реализации стабилизации видео.
режим управления Android	ВЫКЛЮЧЕННЫЙ	AE, AWB и AF отключены
	АВТО	Используются индивидуальные настройки AE, AWB и AF.
	SCENE_MODE_*	Можно переопределить все перечисленные выше параметры. Отдельные элементы управления 3A отключены.

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

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

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

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

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

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