Поддержка нескольких камер

В Android 9 появилась поддержка API для многокамерных устройств посредством нового логического устройства камеры, состоящего из двух или более физических устройств камеры, направленных в одном направлении. Логическое устройство камеры предоставляется как один CameraDevice/CaptureSession для приложения, позволяющего взаимодействовать с интегрированными в HAL функциями многокамерной работы. Приложения могут дополнительно получать доступ к основным потокам физической камеры, метаданным и элементам управления и управлять ими.

Поддержка нескольких камер

Рисунок 1 . Поддержка нескольких камер

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

Примеры и источники

Многокамерные устройства должны рекламироваться с возможностью логической многокамерной работы .

Клиенты камеры могут запросить идентификатор камеры физических устройств, из которых состоит конкретная логическая камера, вызвав getPhysicalCameraIds() . Идентификаторы, возвращаемые как часть результата, затем используются для индивидуального управления физическими устройствами с помощью setPhysicalCameraId() . Результаты таких отдельных запросов можно запросить из полного результата, вызвав getPhysicalCameraResults() .

Отдельные запросы физической камеры могут поддерживать только ограниченный набор параметров. Чтобы получить список поддерживаемых параметров, разработчики могут вызвать getAvailablePhysicalCameraRequestKeys() .

Потоки физических камер поддерживаются только для запросов без повторной обработки и только для монохромных датчиков и датчиков Байера.

Выполнение

Контрольный список поддержки

Чтобы добавить логические многокамерные устройства на стороне HAL:

На устройствах под управлением Android 9 устройства камеры должны поддерживать замену одного логического потока YUV/RAW физическими потоками того же размера (не относится к потокам RAW) и того же формата с двух физических камер. Это не относится к устройствам под управлением Android 10.

Для устройств под управлением Android 10, где версия устройства HAL камеры – 3,5 или выше, устройство камеры должно поддерживать isStreamCombinationSupported чтобы приложения могли запрашивать, поддерживается ли конкретная комбинация потоков, содержащая физические потоки.

Карта конфигурации потока

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

Для устройства логической камеры, поддерживающего возможности RAW с физическими дополнительными камерами разных размеров, если приложение настраивает логический поток RAW, устройство логической камеры не должно переключаться на физические дополнительные камеры с датчиками разных размеров. Это гарантирует, что существующие приложения для захвата RAW не сломаются.

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

Гарантированное сочетание потоков

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

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

На устройствах под управлением Android 9 для каждой гарантированной комбинации потоков логическая камера должна поддерживать:

  • Замена одного логического YUV_420_888 или необработанного потока двумя физическими потоками одинакового размера и формата, каждый с отдельной физической камеры, при условии, что размер и формат поддерживаются физическими камерами.

  • Добавление двух необработанных потоков, по одному от каждой физической камеры, если логическая камера не объявляет о возможности RAW, но базовые физические камеры это делают. Обычно это происходит, когда физические камеры имеют разные размеры сенсоров.

  • Использование физических потоков вместо логического потока того же размера и формата. Это не должно снижать частоту кадров захвата, если минимальная длительность кадров физического и логического потоков одинакова.

Вопросы производительности и мощности

  • Производительность:

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

    • Оптимизация энергопотребления HAL продолжает работать в случае по умолчанию.
    • Настройка или запрос физических потоков может переопределить внутреннюю оптимизацию энергопотребления HAL и привести к увеличению энергопотребления.

Кастомизация

Вы можете настроить реализацию своего устройства следующими способами.

  • Объединенный вывод устройства логической камеры полностью зависит от реализации HAL. Решение о том, как объединенные логические потоки получаются от физических камер, прозрачно для приложения и платформы камер Android.
  • Индивидуальные физические запросы и результаты могут поддерживаться опционально. Набор доступных параметров в таких запросах также полностью зависит от конкретной реализации HAL.
  • Начиная с Android 10, HAL может уменьшить количество камер, которые могут быть напрямую открыты приложением, если отказаться от объявления некоторых или всех PHYSICAL_ID в getCameraIdList . Вызов getPhysicalCameraCharacteristics должен затем вернуть характеристики физической камеры.

Проверка

Логические многокамерные устройства должны проходить CTS камеры, как и любая другая обычная камера. Тестовые случаи, предназначенные для этого типа устройств, можно найти в модуле LogicalCameraDeviceTest .

Эти три теста ITS предназначены для многокамерных систем, чтобы облегчить правильное объединение изображений:

Испытания сцены 1 и сцены 4 проводятся на тестовом стенде ITS-in-a-box . Тест test_multi_camera_match утверждает, что яркость центра изображений совпадает, когда обе камеры включены. Тест test_multi_camera_alignment подтверждает, что параметры расстояния, ориентации и искажения камер загружены правильно. Если многокамерная система включает в себя камеру с широким полем обзора (>90°), требуется версия модуля ITS версии 2.

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

Все коробки можно приобрести в компаниях AcuSpec, Inc. ( www.acusspecinc.com , fred@acusspecinc.com) и MYWAY Manufacturing ( www.myway.tw , sales@myway.tw). Кроме того, коробку ITS rev1 можно приобрести через West-Mark ( www.west-mark.com , dgoodman@west-mark.com).

Лучшие практики

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

  • (Android 10 или выше) Скрыть физические дополнительные камеры из getCameraIdList . Это уменьшает количество камер, которые могут быть напрямую открыты приложениями, что устраняет необходимость в приложениях иметь сложную логику выбора камеры.
  • (Android 11 или более поздней версии) Для логического многокамерного устройства, поддерживающего оптический зум, реализуйте API ANDROID_CONTROL_ZOOM_RATIO и используйте ANDROID_SCALER_CROP_REGION только для обрезки соотношения сторон. ANDROID_CONTROL_ZOOM_RATIO позволяет устройству уменьшать масштаб и сохранять более высокую точность. В этом случае HAL должен настроить систему координат ANDROID_SCALER_CROP_REGION , ANDROID_CONTROL_AE_REGIONS , ANDROID_CONTROL_AWB_REGIONS , ANDROID_CONTROL_AF_REGIONS , ANDROID_STATISTICS_FACE_RECTANGLES и ANDROID_STATISTICS_FACE_LANDMARKS для обработки поля после масштабирования. рассматривать как активный массив датчиков. Для получения дополнительной информации о том, как ANDROID_SCALER_CROP_REGION работает вместе с ANDROID_CONTROL_ZOOM_RATIO , см. camera3_crop_reprocess#cropping .
  • Для многокамерных устройств с физическими камерами, имеющими разные возможности, убедитесь, что устройство объявляет поддержку определенного значения или диапазона для элемента управления, только если весь диапазон масштабирования поддерживает это значение или диапазон. Например, если логическая камера состоит из сверхширокоугольной, широкоугольной и телеобъективной камеры, выполните следующие действия:
    • Если размеры активного массива физических камер различаются, HAL камеры должен выполнить сопоставление активных массивов физических камер с активным массивом логической камеры для ANDROID_SCALER_CROP_REGION , ANDROID_CONTROL_AE_REGIONS , ANDROID_CONTROL_AWB_REGIONS , ANDROID_CONTROL_AF_REGIONS , ANDROID_STATISTICS_FACE_RECTANGLES и ANDROID_STATISTICS_FACE_LANDMARKS , чтобы из приложения В перспективе система координат представляет собой размер активного массива логической камеры.
    • Если широкоугольная камера и телеобъектив поддерживают автофокусировку, а сверхширокоугольная камера имеет фиксированный фокус, убедитесь, что логическая камера поддерживает автофокусировку. HAL должен моделировать конечный автомат автофокусировки для сверхширокоугольной камеры, чтобы, когда приложение приближается к сверхширокоугольному объективу, тот факт, что базовая физическая камера имеет фиксированный фокус, был прозрачен для приложения, а конечные автоматы автофокусировки для поддерживаемых режимов автофокусировки работать как положено.
    • Если широкоугольная и телеобъективная камеры поддерживают 4K при 60 кадрах в секунду, а сверхширокоугольная камера поддерживает только 4K при 30 кадрах в секунду или 1080p при 60 кадрах в секунду, но не 4K при 60 кадрах в секунду, убедитесь, что логическая камера не рекламирует 4K при 60 кадрах в секунду в поддерживаемые конфигурации потока. Это гарантирует целостность логических возможностей камеры, гарантируя, что приложение не столкнется с проблемой невозможности достижения 4K при 60 кадрах в секунду при значении ANDROID_CONTROL_ZOOM_RATIO менее 1.
  • Начиная с Android 10, логическая многокамерная камера не требуется для поддержки комбинаций потоков, включающих физические потоки. Если HAL поддерживает комбинацию с физическими потоками:
    • (Android 11 или более поздней версии) Чтобы лучше обрабатывать такие варианты использования, как глубина стерео и отслеживание движения, сделайте поле обзора выходных физических потоков настолько большим, насколько это возможно с помощью аппаратного обеспечения. Однако если физический поток и логический поток исходят от одной и той же физической камеры, аппаратные ограничения могут привести к тому, что поле зрения физического потока будет таким же, как и у логического потока.
    • Чтобы устранить нехватку памяти, вызванную несколькими физическими потоками, убедитесь, что приложения используют discardFreeBuffers для освобождения свободных буферов (буферов, которые освобождаются потребителем, но еще не исключены из очереди производителем), если ожидается, что физический поток будет простаивать в течение определенного периода. времени.
    • Если физические потоки от разных физических камер обычно не прикрепляются к одному и тому же запросу, убедитесь, что приложения используют surface group , чтобы одна буферная очередь использовалась для поддержки двух поверхностей, обращенных к приложению, что снижает потребление памяти.