Compatibilidad con varias cámaras

Android 9 introdujo la compatibilidad de la API para dispositivos con varias cámaras a través de un nuevo dispositivo de cámara lógico 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 app, lo que permite la interacción con las funciones multicámara integradas en la HAL. De manera opcional, las apps pueden acceder a los flujos, 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 los dispositivos físicos que componen una cámara lógica en particular llamando a getPhysicalCameraIds(). Luego, los IDs que se devuelven como parte del resultado se usan para controlar dispositivos físicos de forma individual a través de setPhysicalCameraId(). Los resultados de estas solicitudes individuales se pueden consultar desde el resultado completo invocando getPhysicalCameraResults().

Las solicitudes de cámara física 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 son de reprocesamiento y solo para sensores monocromáticos y Bayer.

Implementación

Lista de tareas de asistencia

Para agregar dispositivos multicámara lógicos 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/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 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

En el caso de 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 se requieren en CameraDevice.createCaptureSession. Todos los flujos del mapa de configuración de flujos deben ser lógicos.

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 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 apps de captura RAW existentes no se interrumpan.

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

Combinación de transmisiones 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 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.

  • Se agregan 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 los 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 limitaciones de recursos.
    • Aplicar la configuración de la cámara física puede ralentizar la velocidad de captura si las cámaras subyacentes se configuran 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 del HAL y generar un mayor consumo de energía.

Personalización

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

  • El resultado fusionado del dispositivo de cámara lógica depende por completo de la implementación del HAL. La decisión sobre cómo se derivan los flujos lógicos fusionados de las cámaras físicas es transparente para la app y el framework de la cámara de Android.
  • Se pueden admitir de forma opcional las solicitudes y los 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. Luego, la llamada a getPhysicalCameraCharacteristics debe devolver las características de la cámara física.

Validación

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

Estas tres pruebas del ITS se enfocan en los sistemas de varias cámaras para facilitar la fusión adecuada de las imágenes:

Las pruebas de la escena 1 y la 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 ambas cámaras están habilitadas. La prueba test_multi_camera_alignment afirma que los parámetros de distorsión, orientación y espaciado de la cámara se cargan correctamente. Si el sistema de varias cámaras incluye una cámara con un campo visual amplio (mayor a 90°), se requiere la versión rev2 de la caja del ITS.

Sensor_fusion es un segundo soporte 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).

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 cámaras secundarias 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 con varias cámaras que admita el zoom óptico, implementa la API de ANDROID_CONTROL_ZOOM_RATIO 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, 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 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 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 se compone de una cámara ultra gran angular, una gran angular y una teleobjetivo, haz lo siguiente:
    • Si los tamaños de los arrays activos de las cámaras físicas son diferentes, la HAL de 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 del 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 estados de enfoque automático para la cámara ultra gran angular, de modo que, cuando la app aleje el zoom hasta 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 estados de enfoque automático para los modos de AF admitidos funcionen según lo esperado.
    • 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 asegura que la app no tendrá problemas para alcanzar los 4K a 60 FPS con un valor de ANDROID_CONTROL_ZOOM_RATIO inferior a 1.
  • A partir de Android 10, no es necesario que una cámara múltiple lógica admita combinaciones de transmisiones 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 a partir de la visión estéreo y el seguimiento de movimiento, haz que el campo de visión de las salidas de transmisión físicas sea lo más grande posible según lo permita el hardware. Sin embargo, si una transmisión física y una lógica provienen de la misma cámara física, es posible que las limitaciones de hardware obliguen 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 varios flujos físicos, 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 un flujo físico esté inactivo durante un período.
    • Si los flujos físicos 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.