Подсистема HAL

Запросы

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

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

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

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

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

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

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

• Выходные данные RAW Bayer не подвергаются обработке внутри интернет-провайдера.
• Статистика генерируется на основе необработанных данных датчиков.
• Различные блоки обработки, преобразующие необработанные данные датчиков в 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() для этого захвата.
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 .

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

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

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

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

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

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