Compatibilidad con varias cámaras

Android 9 introdujo la compatibilidad con la API para dispositivos con varias cámaras a través de un nuevo dispositivo de cámara lógico formado 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 solo CameraDevice/CaptureSession a una app, lo que permite la interacción con las funciones de varias cámaras integradas en la HAL. De manera opcional, las apps pueden acceder a las transmisiones, los metadatos y los controles de la cámara física subyacente, y controlarlos.

Compatibilidad con varias cámaras

Figura 1. Compatibilidad con varias cámaras

En este diagrama, los diferentes IDs de cámara están codificados por color. La app puede transmitir búferes sin procesar de 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 con varias cámaras se deben anunciar con la capacidad lógica de varias cámaras.

Los clientes de la cámara pueden consultar el ID de la cámara de los dispositivos físicos que componen una cámara lógica en particular llamando a getPhysicalCameraIds(). Luego, los IDs que se muestran como parte del resultado se usan para controlar los dispositivos físicos de forma individual a través de setPhysicalCameraId(). Los resultados de esas solicitudes individuales se pueden consultar en el resultado completo invocando getPhysicalCameraResults().

Las solicitudes individuales de la cámara física 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 la cámara física solo se admiten para solicitudes que no se vuelven a procesar y solo para sensores monocromáticos y bayer.

Implementación

Lista de tareas de compatibilidad

Para agregar dispositivos lógicos de varias cámaras en el lado de la HAL, haz lo siguiente:

En el caso de los dispositivos que ejecutan Android 9, los dispositivos de cámara deben admitir el reemplazo de una transmisión lógica YUV o RAW 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.

En el caso de los dispositivos que ejecutan Android 10 en los que la versión del dispositivo de la HAL de la cámara es 3.5 o posterior, el dispositivo de la cámara debe admitir isStreamCombinationSupported para que las apps consulten si se admite una combinación de transmisión en particular que contenga transmisiones físicas.

Mapa de configuración de transmisión

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

En el caso de un dispositivo de cámara lógica que admita la capacidad RAW con subcámaras físicas de diferentes tamaños, si una app 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 sensor. Esto garantiza que las apps de captura RAW existentes no se interrumpan.

Para aprovechar el zoom óptico implementado en la HAL cambiando entre subcámaras físicas durante la captura RAW, las apps 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 necesarias 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 los dispositivos que ejecutan Android 9, para cada combinación de transmisión garantizada, la cámara lógica debe admitir lo siguiente:

  • Reemplazar una transmisión lógica YUV_420_888 o sin procesar por dos transmisiones físicas del mismo tamaño y formato, cada una de una cámara física independiente, siempre que las cámaras físicas admitan el tamaño y el formato.

  • Agregar dos transmisiones sin procesar, 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 sensor.

  • Usar transmisiones físicas en lugar de una transmisión lógica 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 las transmisiones físicas y lógicas sea la misma.

Consideraciones sobre el rendimiento y la energía

  • Rendimiento:

    • Configurar y transmitir transmisiones físicas puede ralentizar la velocidad de captura de la cámara lógica debido a las restricciones de recursos.
    • Aplicar 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.

  • Alimentación:

    • La optimización de energía de la HAL sigue funcionando en el caso predeterminado.
    • Configurar o solicitar transmisiones físicas puede anular la optimización de energía interna de la HAL y generar un mayor uso de energía.

Personalización

Puedes personalizar la implementación de tu dispositivo de las siguientes maneras.

  • El resultado fusionado del dispositivo de cámara lógica depende por completo de la implementación de la HAL. La decisión sobre cómo se derivan las transmisiones lógicas fusionadas de las cámaras físicas es transparente para la app y el framework de la cámara de Android.
  • De manera opcional, se pueden admitir solicitudes y resultados físicos individuales. El conjunto de parámetros disponibles en esas solicitudes también depende por completo de la implementación específica de la HAL.
  • A partir de Android 10, la HAL puede reducir la cantidad de cámaras que una app puede abrir directamente si decide no anunciar algunos o todos los PHYSICAL_IDs en getCameraIdList. Llamar a getPhysicalCameraCharacteristics luego debe mostrar las características de la cámara física.

Validación

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

Estas tres pruebas de ITS se orientan a sistemas de varias cámaras 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 espaciado, orientación y distorsión de la cámara se cargan correctamente. Si el sistema de varias cámaras incluye una cámara con un FoV amplio (>90o), se requiere la versión rev2 de la caja de ITS.

Sensor_fusion es un segundo equipo 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 de ITS rev1 se puede comprar a través de West-Mark (www.west-mark.com, dgoodman@west-mark.com).

Prácticas recomendadas

Para aprovechar al máximo las funciones disponibles cuando hay varias cámaras y mantener la compatibilidad con las apps, sigue estas prácticas recomendadas al implementar un dispositivo lógico de varias cámaras:

  • (Android 10 o versiones posteriores) Oculta las subcámaras físicas de getCameraIdList. Esto reduce la cantidad de cámaras que las apps pueden abrir directamente, lo que elimina la necesidad de que las apps tengan una lógica de selección de cámara compleja.
  • (Android 11 o versiones posteriores) Para un dispositivo lógico de varias cámaras que admita el zoom óptico, implementa la ANDROID_CONTROL_ZOOM_RATIO API y usa ANDROID_SCALER_CROP_REGION solo para el recorte de la relación de aspecto. ANDROID_CONTROL_ZOOM_RATIO permite que el dispositivo aleje la imagen y mantenga una mejor precisión. En este caso, la 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 visual posterior al zoom como el array activo del sensor. Para obtener más información sobre cómo ANDROID_SCALER_CROP_REGION funciona junto con ANDROID_CONTROL_ZOOM_RATIO, consulta camera3_crop_reprocess#cropping.
  • En el caso de los dispositivos con varias cámaras con cámaras físicas que tienen diferentes capacidades, asegúrate de que el dispositivo anuncie la compatibilidad con un valor o un rango determinado para un control solo si todo el rango de zoom admite el valor o el rango. Por ejemplo, si la cámara lógica está compuesta por una cámara ultra gran angular, una gran angular y un teleobjetivo, haz lo siguiente:
    • Si los tamaños de array activo de las cámaras físicas son diferentes, la HAL de la cámara debe realizar la asignación de los arrays activos de las cámaras físicas al array activo 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 , de modo que, desde la perspectiva de la app, el sistema de coordenadas sea el tamaño de array activo de la cámara lógica.
    • Si las cámaras gran angular y teleobjetivo admiten el enfoque automático, pero la cámara ultra gran angular tiene un enfoque fijo, asegúrate 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 ultra gran angular, de modo que, cuando la app aleje la imagen a la lente ultra gran angular, el hecho de que la cámara física subyacente tenga un enfoque fijo sea transparente para la app, y las máquinas de estado de enfoque automático para los modos de AF admitidos funcionen como se espera.
    • Si las cámaras gran angular y teleobjetivo admiten 4K a 60 fps, y la cámara ultra gran angular solo admite 4K a 30 fps o 1080p a 60 fps, pero no 4K a 60 fps, asegúrate 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 app no tenga el problema de no alcanzar 4k a 60 fps en un ANDROID_CONTROL_ZOOM_RATIO valor inferior a 1.
  • En Android 10 y versiones posteriores, no es necesario que una cámara lógica de varias cámaras admita combinaciones de transmisión que incluyan transmisiones físicas. Si la HAL admite una combinación con transmisiones físicas, haz lo siguiente:
    • (Android 11 o versiones posteriores) Para controlar mejor los casos de uso, como la profundidad del estéreo y el seguimiento de movimiento, haz que el campo visual de las salidas de transmisión física sea lo más grande posible para el hardware. Sin embargo, si una transmisión física y una transmisión lógica provienen de la misma cámara física, las limitaciones de hardware podrían forzar a que el campo visual de la transmisión física sea el mismo que el de la transmisión lógica.
    • Para abordar la presión de memoria causada por varias transmisiones físicas, asegúrate de que las apps usen discardFreeBuffers para liberar los búferes libres (búferes que libera el consumidor, pero que el productor aún no pone en cola) si se espera que una transmisión física esté inactiva durante un período.
    • Si las transmisiones físicas de diferentes cámaras físicas no suelen adjuntarse a la misma solicitud, asegúrate de que las apps usen surface group para que se use una cola de búfer para respaldar dos superficies orientadas a la app, lo que reduce el consumo de memoria.