Se usó la API de Cloud Translation para traducir esta página.

Soporte multicámara

Android 9 introdujo la compatibilidad con API para dispositivos con varias cámaras a través de un nuevo dispositivo de cámara lógica compuesto por dos o más dispositivos de cámara físicos que apuntan en la misma dirección. El dispositivo de cámara lógica se expone como un solo CameraDevice/CaptureSession a una aplicación que permite la interacción con funciones de múltiples cámaras integradas con HAL. Las aplicaciones pueden acceder y controlar opcionalmente las transmisiones, los metadatos y los controles de la cámara física subyacente.

Soporte multicámara

Figura 1 . Soporte multicámara

En este diagrama, las diferentes ID de cámara están codificadas por colores. La aplicación puede transmitir búfer sin procesar desde cada cámara física al mismo tiempo. También es posible configurar controles separados y recibir metadatos separados de diferentes cámaras físicas.

Ejemplos y fuentes

Los dispositivos multicámara deben anunciarse con la capacidad lógica multicámara .

Los clientes de cámara pueden consultar la ID de cámara de los dispositivos físicos de los que está hecha una cámara lógica en particular llamando a getPhysicalCameraIds() . Los ID devueltos como parte del resultado se usan para controlar los dispositivos físicos individualmente a través setPhysicalCameraId() . Los resultados de tales solicitudes individuales se pueden consultar desde el resultado completo invocando getPhysicalCameraResults() .

Las solicitudes de cámaras físicas individuales pueden admitir solo un subconjunto limitado de parámetros. Para recibir una lista de los parámetros admitidos, los desarrolladores pueden llamar a getAvailablePhysicalCameraRequestKeys() .

Las transmisiones de cámaras físicas solo se admiten para solicitudes que no sean de reprocesamiento y solo para sensores monocromáticos y bayer.

Implementación

Lista de verificación de soporte

Para agregar dispositivos lógicos de varias cámaras en el lado HAL:

Agregue una capacidad ANDROID_REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA para cualquier dispositivo de cámara lógica respaldado por dos o más cámaras físicas que también estén expuestas a una aplicación.
Rellene el campo de metadatos estático ANDROID_LOGICAL_MULTI_CAMERA_PHYSICAL_IDS con una lista de ID de cámaras físicas.
Rellene los metadatos estáticos relacionados con la profundidad necesarios para correlacionar los píxeles de las transmisiones de la cámara física: ANDROID_LENS_POSE_ROTATION , ANDROID_LENS_POSE_TRANSLATION , ANDROID_LENS_INTRINSIC_CALIBRATION , ANDROID_LENS_DISTORTION , ANDROID_LENS_POSE_REFERENCE .
Establezca el campo de metadatos estático ANDROID_LOGICAL_MULTI_CAMERA_SENSOR_SYNC_TYPE en:
- ANDROID_LOGICAL_MULTI_CAMERA_SENSOR_SYNC_TYPE_APPROXIMATE : para sensores en modo maestro-maestro, sin obturador de hardware/sincronización de exposición.
- ANDROID_LOGICAL_MULTI_CAMERA_SENSOR_SYNC_TYPE_CALIBRATED : para sensores en modo maestro-esclavo, obturador de hardware/sincronización de exposición.
Complete ANDROID_REQUEST_AVAILABLE_PHYSICAL_CAMERA_REQUEST_KEYS con una lista de parámetros admitidos para cámaras físicas individuales. La lista puede estar vacía si el dispositivo lógico no admite solicitudes individuales.
Si se admiten solicitudes individuales, procese y aplique los ajustes de cámara physicalCameraSettings individuales que pueden llegar como parte de las solicitudes de captura y agregue los metadatos de cámara physicalCameraMetadata individuales en consecuencia.
Para las versiones 3.5 o posteriores del dispositivo Camera HAL (introducido en Android 10), complete la clave de resultado ANDROID_LOGICAL_MULTI_CAMERA_ACTIVE_PHYSICAL_ID con el ID de la cámara física activa actual que respalda la cámara lógica.

Para los dispositivos que ejecutan Android 9, los dispositivos con cámara deben admitir la sustitución de una transmisión YUV/RAW lógica por transmisiones físicas del mismo tamaño (no se aplica a las transmisiones RAW) y el mismo formato de dos cámaras físicas. Esto no se aplica a los dispositivos que ejecutan Android 10.

Para los dispositivos que ejecutan Android 10 donde la versión del dispositivo HAL de la cámara es 3.5 o superior, el dispositivo de la cámara debe ser compatible con isStreamCombinationSupported para que las aplicaciones consulten si se admite una combinación de transmisión en particular que contiene transmisiones físicas.

Mapa de configuración de flujo

Para una cámara lógica, las combinaciones de transmisión obligatorias para el dispositivo de cámara de un cierto nivel de hardware son las mismas que se requieren en CameraDevice.createCaptureSession . Todos los flujos en el mapa de configuración de flujo deben ser flujos lógicos.

Para un dispositivo de cámara lógica que admita la capacidad RAW con subcámaras físicas de diferentes tamaños, si una aplicación configura un flujo RAW lógico, el dispositivo de cámara lógica no debe cambiar a subcámaras físicas con diferentes tamaños de sensor. Esto garantiza que las aplicaciones de captura RAW existentes no se rompan.

Para aprovechar el zoom óptico implementado por HAL al cambiar entre subcámaras físicas durante la captura RAW, las aplicaciones deben configurar transmisiones de subcámaras físicas en lugar de una transmisión RAW lógica.

Combinación de transmisión garantizada

Tanto la cámara lógica como sus cámaras físicas subyacentes deben garantizar las combinaciones de transmisión obligatorias requeridas para sus niveles de dispositivo.

Un dispositivo de cámara lógica debe funcionar de la misma manera que un dispositivo de cámara física en función de su nivel de hardware y capacidades. Se recomienda que su conjunto de funciones sea un superconjunto del de las cámaras físicas individuales.

En los dispositivos que ejecutan Android 9, para cada combinación de transmisión garantizada, la cámara lógica debe ser compatible con:

Reemplazar un YUV_420_888 lógico o flujo sin procesar con dos flujos físicos del mismo tamaño y formato, cada uno de una cámara física separada, dado que el tamaño y el formato son compatibles con las cámaras físicas.
Agregar dos flujos sin formato, uno de cada cámara física, si la cámara lógica no anuncia la capacidad RAW, pero las cámaras físicas subyacentes sí lo hacen. Esto suele ocurrir cuando las cámaras físicas tienen diferentes tamaños de sensor.
Usar flujos físicos en lugar de un flujo lógico del mismo tamaño y formato. Esto no debe ralentizar la velocidad de fotogramas de la captura cuando la duración mínima de fotogramas de los flujos físicos y lógicos es la misma.

Consideraciones de rendimiento y potencia

Actuación:
- La configuración y transmisión de secuencias físicas puede ralentizar la velocidad de captura de la cámara lógica debido a las limitaciones de recursos.
- La aplicación de la configuración de la cámara física puede ralentizar la velocidad de captura si las cámaras subyacentes se colocan en diferentes velocidades de fotogramas.
Energía:
- La optimización de energía de HAL sigue funcionando en el caso predeterminado.
- Configurar o solicitar flujos físicos puede anular la optimización de energía interna de HAL e incurrir en un mayor uso de energía.

personalización

Puede personalizar la implementación de su dispositivo de las siguientes maneras.

La salida fusionada del dispositivo de cámara lógica depende completamente de la implementación de HAL. La decisión sobre cómo se derivan los flujos lógicos fusionados de las cámaras físicas es transparente para la aplicación y el marco de la cámara de Android.
Las solicitudes físicas individuales y los resultados se pueden admitir opcionalmente. El conjunto de parámetros disponibles en tales solicitudes también depende completamente de la implementación HAL específica.
A partir de Android 10, HAL puede reducir la cantidad de cámaras que una aplicación puede abrir directamente al elegir no anunciar algunos o todos los PHYSICAL_ID en getCameraIdList . Llamar getPhysicalCameraCharacteristics debe devolver las características de la cámara física.

Validación

Los dispositivos lógicos de varias cámaras deben pasar la cámara CTS como cualquier otra cámara normal. Los casos de prueba que apuntan a este tipo de dispositivo se pueden encontrar en el módulo LogicalCameraDeviceTest .

Estas tres pruebas ITS están dirigidas a sistemas multicámara para facilitar la fusión adecuada de imágenes:

Las pruebas de escena 1 y escena 4 se ejecutan con el equipo de prueba ITS-in-a-box . La prueba test_multi_camera_match afirma que el brillo del centro de las imágenes coincide cuando las dos cámaras están habilitadas. La prueba test_multi_camera_alignment afirma que los parámetros de separación, orientación y distorsión de la cámara están correctamente cargados. Si el sistema multicámara incluye una cámara Wide FoV (>90o), se requiere la versión rev2 de la caja ITS.

Sensor_fusion es una segunda plataforma de prueba que permite el movimiento repetido y prescrito del teléfono y afirma que las marcas de tiempo del giroscopio y del sensor de imagen coinciden y que los fotogramas de varias cámaras están sincronizados.

Todas las cajas están disponibles a través de AcuSpec, Inc. ( www.acuspecinc.com , fred@acuspecinc.com) y MYWAY Manufacturing ( www.myway.tw , sales@myway.tw). Además, la caja ITS rev1 se puede comprar a través de West-Mark ( www.west-mark.com , dgoodman@west-mark.com).

Mejores prácticas

Para aprovechar al máximo las funciones habilitadas por varias cámaras y mantener la compatibilidad de las aplicaciones, siga estas prácticas recomendadas cuando implemente un dispositivo lógico de varias cámaras:

(Android 10 o superior) Oculte las subcámaras físicas de getCameraIdList . Esto reduce la cantidad de cámaras que las aplicaciones pueden abrir directamente, eliminando la necesidad de que las aplicaciones tengan una lógica de selección de cámara compleja.
(Android 11 o superior) Para un dispositivo lógico multicámara compatible con zoom óptico, implemente la API ANDROID_CONTROL_ZOOM_RATIO y use ANDROID_SCALER_CROP_REGION para recortar la relación de aspecto. ANDROID_CONTROL_ZOOM_RATIO permite que el dispositivo se aleje y mantenga una mejor precisión. En este caso, el HAL debe ajustar el sistema de coordenadas de ANDROID_SCALER_CROP_REGION , ANDROID_CONTROL_AE_REGIONS , ANDROID_CONTROL_AWB_REGIONS , ANDROID_CONTROL_AF_REGIONS , ANDROID_STATISTICS_FACE_RECTANGLES y ANDROID_STATISTICS_FACE_LANDMARKS para tratar el campo de visión posterior al zoom como matriz activa del sensor. Para obtener más información sobre cómo funciona ANDROID_SCALER_CROP_REGION junto con ANDROID_CONTROL_ZOOM_RATIO , consulte camera3_crop_reprocess#cropping .
Para dispositivos de varias cámaras con cámaras físicas que tienen diferentes capacidades, asegúrese de que el dispositivo anuncie soporte para un valor o rango determinado para un control solo si todo el rango de zoom admite el valor o rango. Por ejemplo, si la cámara lógica se compone de una cámara ultra gran angular, una gran angular y un teleobjetivo, haga lo siguiente:
- Si los tamaños de matriz activa de las cámaras físicas son diferentes, la HAL de la cámara debe realizar la asignación de las matrices activas de las cámaras físicas a la matriz activa de la cámara lógica para ANDROID_SCALER_CROP_REGION , ANDROID_CONTROL_AE_REGIONS , ANDROID_CONTROL_AWB_REGIONS , ANDROID_CONTROL_AF_REGIONS , ANDROID_STATISTICS_FACE_RECTANGLES y ANDROID_STATISTICS_FACE_LANDMARKS para que desde la aplicación LAND_STATISTICS_FACE. perspectiva, el sistema de coordenadas es el tamaño de matriz activa de la cámara lógica.
- Si las cámaras gran angular y de teleobjetivo admiten el enfoque automático, pero la cámara ultraancha tiene un enfoque fijo, asegúrese de que la cámara lógica anuncie la compatibilidad con el enfoque automático. La HAL debe simular una máquina de estado de enfoque automático para la cámara ultraancha, de modo que cuando la aplicación se aleje a la lente ultraancha, el hecho de que la cámara física subyacente tenga un enfoque fijo sea transparente para la aplicación, y las máquinas de estado de enfoque automático para los modos AF admitidos trabajar como se esperaba.
- Si las cámaras de gran angular y teleobjetivo admiten 4K a 60 fps y la cámara ultraancha solo admite 4K a 30 fps, o 1080p a 60 fps, pero no 4K a 60 fps, asegúrese de que la cámara lógica no anuncie 4k a 60 fps en sus configuraciones de transmisión admitidas. Esto garantiza la integridad de las capacidades de la cámara lógica, lo que garantiza que la aplicación no tendrá el problema de no lograr 4k a 60 fps con un valor ANDROID_CONTROL_ZOOM_RATIO inferior a 1.
A partir de Android 10, no se requiere una cámara múltiple lógica para admitir combinaciones de transmisión que incluyan transmisiones físicas. Si HAL admite una combinación con flujos físicos:
- (Android 11 o superior) Para manejar mejor los casos de uso, como la profundidad del estéreo y el seguimiento de movimiento, haga que el campo de visión de las salidas de flujo físico sea lo más grande que pueda lograr el hardware. Sin embargo, si una transmisión física y una transmisión lógica se originan en la misma cámara física, las limitaciones del hardware pueden forzar que el campo de visión de la transmisión física sea el mismo que el de la transmisión lógica.
- Para abordar la presión de la memoria causada por múltiples flujos físicos, asegúrese de que las aplicaciones usen discardFreeBuffers para desasignar los búferes libres (búferes que libera el consumidor, pero que el productor aún no elimina de la cola) si se espera que un flujo físico esté inactivo durante un período. de tiempo.
- Si las transmisiones físicas de diferentes cámaras físicas normalmente no se adjuntan a la misma solicitud, asegúrese de que las aplicaciones usen un surface group para que una cola de búfer se use para respaldar dos superficies orientadas a la aplicación, lo que reduce el consumo de memoria.