Soporte multicámara

Android 9 introdujo compatibilidad con API para dispositivos multicámara 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ógico se expone como un único CameraDevice/CaptureSession a una aplicación que permite la interacción con funciones multicámara integradas en HAL. Opcionalmente, las aplicaciones pueden acceder y controlar las transmisiones, los metadatos y los controles de las cámaras físicas subyacentes.

Soporte multicámara

Figura 1 . Soporte multicámara

En este diagrama, las diferentes ID de cámaras están codificadas por colores. La aplicación puede transmitir buffers 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 el ID de la cámara de los dispositivos físicos que componen una cámara lógica particular llamando getPhysicalCameraIds() . Los ID devueltos como parte del resultado se utilizan luego para controlar los dispositivos físicos individualmente a través de setPhysicalCameraId() . Los resultados de dichas solicitudes individuales se pueden consultar a partir del 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 getAvailablePhysicalCameraRequestKeys() .

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

Implementación

Lista de verificación de soporte

Para agregar dispositivos lógicos multicámara en el lado HAL:

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

Para 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 admitir isStreamCombinationSupported para que las aplicaciones consulten si se admite una combinación de transmisión particular que contiene transmisiones físicas.

Mapa de configuración de flujo

Para una cámara lógica, las combinaciones de secuencias obligatorias para el dispositivo de cámara de un determinado nivel de hardware son las mismas que se requieren en CameraDevice.createCaptureSession . Todas las secuencias en el mapa de configuración de secuencias deben ser secuencias lógicas.

Para un dispositivo de cámara lógica que admite capacidad RAW con subcámaras físicas de diferentes tamaños, si una aplicación configura una transmisión RAW lógica, el dispositivo de cámara lógica no debe cambiar a subcámaras físicas con diferentes tamaños de sensores. 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 físicas de subcámaras en lugar de una transmisión RAW lógica.

Combinación de flujo garantizada

Tanto la cámara lógica como sus cámaras físicas subyacentes deben garantizar las combinaciones de flujo 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 según su nivel de hardware y sus capacidades. Se recomienda que su conjunto de funciones sea un superconjunto del de las cámaras físicas individuales.

En dispositivos con Android 9, para cada combinación de transmisión garantizada, la cámara lógica debe admitir:

  • Reemplazar una secuencia lógica YUV_420_888 o sin procesar por dos secuencias físicas del mismo tamaño y formato, cada una de una cámara física independiente, dado que el tamaño y el formato son compatibles con las cámaras físicas.

  • Agregar dos transmisiones sin formato, una 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 sensores.

  • 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 sea la misma.

Consideraciones de rendimiento y potencia.

  • Actuación:

    • La configuración y transmisión de transmisiones físicas puede ralentizar la velocidad de captura de la cámara lógica debido a limitaciones de recursos.
    • La aplicación de configuraciones físicas de la cámara puede reducir la velocidad de captura si las cámaras subyacentes se colocan en velocidades de fotogramas diferentes.

  • Fuerza:

    • La optimización de energía de HAL continúa funcionando en el caso predeterminado.
    • Configurar o solicitar transmisiones físicas 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.
  • Opcionalmente se pueden admitir solicitudes y resultados físicos individuales. El conjunto de parámetros disponibles en dichas 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 optar por no anunciar algunos o todos los PHYSICAL_ID en getCameraIdList . Luego, llamar getPhysicalCameraCharacteristics debe devolver las características de la cámara física.

Validación

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

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

Las pruebas de las escenas 1 y 4 se ejecutan con el banco de pruebas 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 espacios, orientaciones y parámetros de distorsión de las cámaras están cargados correctamente. 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 un segundo equipo de prueba que permite movimientos repetidos y prescritos 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 la multicámara y al mismo tiempo mantener la compatibilidad de las aplicaciones, siga estas mejores prácticas al implementar un dispositivo multicámara lógico:

  • (Android 10 o superior) Ocultar 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 que admita zoom óptico, implemente la API ANDROID_CONTROL_ZOOM_RATIO y use ANDROID_SCALER_CROP_REGION solo 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, 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 multicámara con cámaras físicas que tienen diferentes capacidades, asegúrese de que el dispositivo anuncie compatibilidad con un determinado valor o rango para un control solo si todo el rango de zoom admite el valor o rango. Por ejemplo, si la cámara lógica está compuesta por una cámara ultra gran angular, una gran angular y una teleobjetivo, haga lo siguiente:
    • Si los tamaños de la matriz activa de las cámaras físicas son diferentes, la cámara HAL 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 En 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 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. El HAL debe simular una máquina de estado de enfoque automático para la cámara ultra ancha, de modo que cuando la aplicación se aleja hacia la lente ultra ancha, 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. Funciona como se esperaba.
    • Si las cámaras 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 lógicas de la cámara, asegurando que la aplicación no tendrá el problema de no alcanzar 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 transmisiones que incluyan transmisiones físicas. Si HAL admite una combinación con transmisiones físicas:
    • (Android 11 o superior) Para manejar mejor 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 transmisión física sea lo más grande que pueda lograr el hardware. Sin embargo, si una secuencia física y una secuencia lógica se originan en la misma cámara física, las limitaciones del hardware pueden obligar a que el campo de visión de la secuencia física sea el mismo que el de la secuencia 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 son liberados por el consumidor, pero que el productor aún no los retira 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 surface group para que se use una cola de búfer para respaldar dos superficies orientadas a la aplicación, lo que reduce el consumo de memoria.