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 y controlar transmisiones, metadatos y controles de la cámara física subyacente.

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 independientes y recibir metadatos independientes de diferentes cámaras físicas.

Ejemplos y fuentes

Los dispositivos con varias cámaras deben promocionarse con la capacidad lógica de varias cámaras.

Los clientes de cámara pueden consultar el ID de la cámara de los dispositivos físicos de los dispositivos físicos de una cámara lógica en particular llamando a getPhysicalCameraIds(). Los IDs que se devuelven como parte del resultado se usan para controlar dispositivos físicos individualmente a través de setPhysicalCameraId(). Los resultados de esas 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ámara físicas solo son compatibles con 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 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 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.

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 una posterior, el dispositivo de la cámara debe admitir isStreamCombinationSupported para que las apps consulten si se admite una combinación de transmisiones en particular que contenga transmisiones físicas.

Mapa de configuración de la transmisión

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

En el caso de un dispositivo de cámara lógica que admita la capacidad de 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 no se dañen las apps de captura de RAW existentes.

Para aprovechar el zoom óptico implementado en HAL cambiando entre subcámaras físicas durante la captura de 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 transmisiones obligatorias requeridas para sus niveles de dispositivos.

Un dispositivo de cámara lógico 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 atributos 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:

  • Se reemplazó una transmisión YUV_420_888 lógica o sin procesar por dos transmisiones físicas del mismo tamaño y formato, cada una desde una cámara física independiente, dado que las cámaras físicas admiten 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 de 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 las transmisiones físicas y lógicas es la misma.

Consideraciones de rendimiento y energía

  • Rendimiento:

    • Configurar y transmitir transmisiones físicas puede ralentizar la tasa de captura de la cámara lógica debido a restricciones de recursos.
    • Aplicar la configuración física de la cámara puede disminuir 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 HAL sigue funcionando en el caso predeterminado.
    • La configuración o solicitud de transmisiones físicas puede anular la optimización de energía interna de HAL y generar un mayor consumo de energía.

Personalización

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

  • El resultado combinado del dispositivo de cámara lógico depende por completo 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 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 HAL.
  • A partir de Android 10, el HAL puede reducir la cantidad de cámaras que una app puede abrir directamente si elige no anunciar algunos o todos los PHYSICAL_IDs en getCameraIdList. Llamar a getPhysicalCameraCharacteristics debe mostrar las características de la cámara física.

Validación

Los dispositivos lógicos con 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 módulo LogicalCameraDeviceTest.

Estas tres pruebas de ITS se orientan a sistemas de varias cámaras para facilitar la fusión correcta de imágenes:

Las pruebas de las escenas 1 y 4 se ejecutan con la plataforma 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 confirma 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 de campo visual amplio (>90°), se requiere la versión rev2 de la caja del ITS.

Sensor_fusion es una segunda plataforma de prueba que permite el movimiento del teléfono repetido y prescrito y confirma 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 de 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 habilitadas cuando hay varias cámaras y mantener la compatibilidad con las apps, sigue estas prácticas recomendadas cuando implementes 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 compleja de selección de cámaras.
  • (Android 11 o versiones posteriores) Para un dispositivo lógico con varias cámaras que admita zoom óptico, implementa la API de ANDROID_CONTROL_ZOOM_RATIO y usa ANDROID_SCALER_CROP_REGION solo para el recorte de relación de aspecto. ANDROID_CONTROL_ZOOM_RATIO permite que el dispositivo se aleje 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 funciona ANDROID_SCALER_CROP_REGION 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, el HAL de la cámara debe asignar 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 enfoque fijo, asegúrate de que la cámara lógica anuncie la compatibilidad con el enfoque automático. El 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 aleja el zoom al lente ultra gran angular, el hecho de que la cámara física subyacente tenga enfoque fijo sea transparente para la app y las máquinas de estados de enfoque automático para los modos de AF admitidos funcionen como se espera.
    • Si las cámaras gran angular y telefoto 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 compatibles. 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 con un valor de 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 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 seguimiento de movimiento y estéreo, haz 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 lógica provienen de la misma cámara física, las limitaciones de hardware podrían forzar 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 múltiples transmisiones físicas, asegúrate de que las apps usen discardFreeBuffers para desasignar los búferes libres (los que libera el consumidor, pero que el productor aún no quita de la cola) si se espera que una transmisión física esté inactiva durante un período.
    • Si, por lo general, las transmisiones físicas de diferentes cámaras físicas no se adjuntan 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 plataformas orientadas a la app, lo que reduce el consumo de memoria.