Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Soporte multicámara

Android 9 introdujo la 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ógica se expone como un único dispositivo de cámara / sesión de captura a una aplicación que permite la interacción con las funciones de varias cámaras integradas en 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, los diferentes ID de cámara están codificados por colores. La aplicación puede transmitir búferes sin procesar desde cada cámara física al mismo tiempo. También es posible establecer controles separados y recibir metadatos separados de diferentes cámaras físicas.

Ejemplos y fuentes

Dispositivos con varias cámaras deben ser objeto de publicidad con la capacidad de multi-cámara lógica .

Cámara clientes pueden consultar la ID de la cámara de los dispositivos físicos de una cámara lógica particular, está hecho de llamando getPhysicalCameraIds() . Los ID devueltos como parte del resultado se utilizan entonces para controlar dispositivos físicos individualmente a través de setPhysicalCameraId() . Los resultados de tales peticiones 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 getAvailablePhysicalCameraRequestKeys() .

Las transmisiones físicas de la cámara 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 multicámara en el lado HAL:

Para los dispositivos que ejecutan Android 9, los dispositivos con cámara deben admitir la sustitución de una secuencia lógica YUV / RAW con secuencias físicas del mismo tamaño (no se aplica a las secuencias 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 con Android 10, donde la versión del dispositivo HAL cámara es 3.5 o superior, el dispositivo debe ser compatible con la cámara isStreamCombinationSupported de aplicaciones para consultar si se admite una combinación particular corriente que contiene los flujos físicos.

Mapa de configuración de transmisión

Para una cámara lógica, las combinaciones corriente obligatorias para el dispositivo de cámara de un cierto nivel de hardware es lo mismo que lo que se requiere en CameraDevice.createCaptureSession . Todas las secuencias en el mapa de configuración de rutas deben ser secuencias lógicas.

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 asegura que las aplicaciones de captura RAW existentes no se rompan.

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

Combinación de flujo garantizada

Tanto la cámara lógica y sus cámaras físicas subyacentes deben garantizar las combinaciones corriente obligatorios requeridos por sus niveles de dispositivos.

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 que ejecutan Android 9, para cada combinación de transmisión garantizada, la cámara lógica debe admitir:

  • Reemplazo de un YUV_420_888 lógico o flujo en bruto 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 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 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 potencia y rendimiento

  • Rendimiento:

    • La configuración y la transmisión de secuencias físicas pueden ralentizar la velocidad de captura de la cámara lógica debido a 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.
  • Poder:

    • La optimización de energía de HAL continúa funcionando en el caso predeterminado.
    • La configuración o solicitud de 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.
  • Opcionalmente, se pueden admitir solicitudes y resultados físicos individuales. El conjunto de parámetros disponibles en tales solicitudes también depende completamente de la implementación de HAL específica.
  • De androide 10, el HAL puede reducir el número de cámaras que se pueden abrir directamente por una aplicación mediante la elección de no hacer publicidad de algunos o todos los PHYSICAL_IDs en getCameraIdList . Llamar getPhysicalCameraCharacteristics deben volver las características de la cámara física.

Validación

Los dispositivos lógicos de varias cámaras deben pasar 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 la LogicalCameraDeviceTest módulo.

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

Las pruebas de escena 1 y 4 escena ejecutan con el SU-in-a-box banco de pruebas. El test_multi_camera_match prueba afirma que el brillo del centro de las imágenes coincide cuando las dos cámaras están habilitados. El test_multi_camera_alignment prueba afirma que espaciados cámara, orientaciones y parámetros de distorsión se cargan 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 banco de pruebas que permite repetida, el movimiento del teléfono prescrito y afirma que las marcas de tiempo giroscopio y sensor de imagen coinciden y que los marcos de varias cámaras están sincronizadas.

Todas las cajas están disponibles a través AcuSpec, Inc. ( www.acuspecinc.com , fred@acuspecinc.com) y MYWAY Manufactura ( www.myway.tw , sales@myway.tw). Además, el Rev1 su caja puede adquirirse a través del oeste-Mark ( www.west-mark.com , dgoodman@west-mark.com).

Mejores prácticas

Para aprovechar al máximo las funciones habilitadas por multicámara y al mismo tiempo mantener la compatibilidad de la aplicación, siga estas prácticas recomendadas al implementar un dispositivo lógico multicámara:

  • (Android 10 o superior) Ocultar físicas sub-cámaras de getCameraIdList . Esto reduce la cantidad de cámaras que las aplicaciones pueden abrir directamente, lo que elimina la necesidad de que las aplicaciones tengan una lógica de selección de cámara compleja.
  • (Android 11 o superior) para un dispositivo multi-cámara lógica apoyo del zoom óptico, implementan el ANDROID_CONTROL_ZOOM_RATIO API, y el uso ANDROID_SCALER_CROP_REGION para la relación de aspecto de cultivos solamente. ANDROID_CONTROL_ZOOM_RATIO permite que el dispositivo para alejar y mantener 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 post-zoom de vista como la matriz activa sensor. Para obtener más información sobre cómo ANDROID_SCALER_CROP_REGION trabaja en conjunto con ANDROID_CONTROL_ZOOM_RATIO , ver camera3_crop_reprocess#cropping .
  • Para dispositivos multicámara con cámaras físicas que tienen diferentes capacidades, asegúrese de que el dispositivo anuncie soporte para un cierto 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 ancha, una ancha y una teleobjetivo, haga lo siguiente:
    • Si los tamaños de matriz activa de las cámaras físicas son diferentes, el HAL cámara tiene que hacer el mapeo de las matrices activas las cámaras físicas a la cámara de red activa 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 por lo que a partir de la década de aplicaciones perspectiva, el sistema de coordenadas es el tamaño de la 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 admita el enfoque automático. El 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 aleja de la lente ultraancha, el hecho de que la cámara física subyacente sea un enfoque fijo sea transparente para la aplicación y las máquinas de estado de enfoque automático para los modos AF compatibles. trabajar 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 compatibles. Esto garantiza la integridad de las capacidades de la cámara lógicos, asegurando que la aplicación no se ejecutará en el tema de no alcanzar 4k @ 60 fps con una ANDROID_CONTROL_ZOOM_RATIO valor inferior a 1.
  • A partir de Android 10, no se requiere una multicámara lógica para admitir combinaciones de transmisión que incluyen 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 transmisión física sea lo más grande que pueda lograr el hardware. Sin embargo, si un flujo físico y un flujo lógico se originan en la misma cámara física, las limitaciones del hardware pueden forzar que el campo de visión del flujo físico sea el mismo que el del flujo lógico.
    • Para hacer frente a la presión de memoria causada por múltiples flujos físicos, asegúrese de que las aplicaciones utilizan discardFreeBuffers desasignar los buffers libres (buffers que son liberadas por el consumidor, pero aún no se quita de la cola por el productor) si se espera un flujo físico para estar inactivo durante un período de tiempo.
    • Si los flujos físicos de diferentes cámaras físicas no están normalmente asociadas a la misma solicitud, asegúrese de que las aplicaciones usen el surface group de manera que un búfer de cola se utiliza para respaldar dos superficies de aplicación a la marcha, reducir el consumo de memoria.