Compatibilidad con varias cámaras

Android 9 introdujo compatibilidad de API para varias cámaras mediante un nuevo dispositivo de cámara lógica compuesto por dos o más dispositivos dispositivos de cámara que apuntan en la misma dirección. El dispositivo de cámara lógica expuestos como un único CameraDevice/CaptureSession a una app, lo que permite Interacción con funciones de varias cámaras integradas en HAL. Opcionalmente, las apps pueden acceder y controlar transmisiones, metadatos y controles de cámaras físicas subyacentes.

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 hacer lo siguiente: transmitir búferes sin procesar desde cada cámara física al mismo tiempo. También se usa es posible establecer controles separados y recibir metadatos separados de diferentes cámaras físicas.

Ejemplos y fuentes

Los dispositivos con varias cámaras deben promocionarse con el 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 un determinado de la cámara lógica se compone de llamando getPhysicalCameraIds() Los IDs que se muestran como parte del resultado se usan para controlar los dispositivos físicos. individualmente a través de setPhysicalCameraId() Los resultados de esas solicitudes individuales se pueden consultar desde la resultado invocando getPhysicalCameraResults()

Las solicitudes individuales de cámaras físicas 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á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 lógicos de varias cámaras en el lado del HAL, haz lo siguiente:

En el caso de los dispositivos que ejecutan Android 9, los dispositivos con cámara deben es compatible con 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 tiendas físicas cámaras. 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 La versión del dispositivo de la HAL de la cámara es 3.5 o una superior, la cámara debe admitir isStreamCombinationSupported para que las apps consulten si una combinación de transmisión específica que contiene 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 cámara de un cierto nivel de hardware es el mismo que se requiere CameraDevice.createCaptureSession Todas las transmisiones del mapa de configuración de transmisiones deben ser transmisiones lógicas.

Para un dispositivo de cámara lógica que admite la capacidad de 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 de sensores. Esto garantiza que las apps de captura RAW existentes no se dañen.

Para aprovechar el zoom óptico implementado por HAL al cambiar entre subcámaras físicas durante la captura RAW, las apps deben configurar transmisiones físicas de subcámaras 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 la combinaciones obligatorias de novedades necesarios para los niveles de sus dispositivos.

Un dispositivo de cámara lógica debería funcionar de la misma manera que una cámara física según su nivel de hardware y sus capacidades. Se recomienda que sus conjunto de atributos es un superconjunto del de las cámaras físicas individuales.

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

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

  • Agregar dos transmisiones sin procesar, una para cada cámara física, si la cámara lógica no promociona la capacidad de RAW, pero las cámaras físicas subyacentes sí. Esto suele ocurrir cuando las cámaras físicas tienen sensores de diferentes tamaños.

  • Usar transmisiones físicas en lugar de una transmisión lógica del mismo tamaño y de un conjunto de datos tengan un formato común. Esto no debe disminuir la velocidad de fotogramas de la captura cuando la duración mínima de fotogramas de las transmisiones físicas y lógica es la misma.

Consideraciones de rendimiento y energía

  • Rendimiento:

    • Configurar y transmitir transmisiones físicas puede ralentizar la de captura lógica de la cámara debido a restricciones de recursos.
    • Aplicar la configuración física de la cámara puede disminuir la velocidad de captura si la las cámaras subyacentes se ubican en diferentes velocidades de fotogramas.

  • Alimentación:

    • La optimización de energía de la HAL seguirá funcionando en el caso predeterminado.
    • Configurar o solicitar transmisiones físicas puede anular la conexión interna del HAL la optimización de la energía e incurrirá en un mayor uso de la energía.

Personalización

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

  • La salida fusionada del dispositivo de cámara lógico depende por completo de la HAL para implementarlos. La decisión de cómo derivan las transmisiones lógicas fusionadas Las cámaras físicas son transparentes para la app y la cámara de Android. en un framework de aplicaciones.
  • Las solicitudes físicas individuales y los resultados pueden admitirse de manera opcional. El de parámetros disponibles en esas solicitudes también depende completamente de la implementación específica de HAL.
  • A partir de Android 10, la HAL puede reducir cámaras que una aplicación puede abrir directamente con la elección de no anunciar algunos o todos los PHYSICAL_ID en getCameraIdList Llamando a getPhysicalCameraCharacteristics debe mostrar las características de la cámara física.

Validación

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

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

Las pruebas de escena 1 y escena 4 se ejecutan con el Prueba de ITS integrado rig. La prueba test_multi_camera_match confirma que el brillo de la centro de las imágenes coincide cuando ambas cámaras están habilitadas. El La prueba de test_multi_camera_alignment afirma que el espaciado, las orientaciones y distorsión se cargan correctamente. Si el sistema de varias cámaras incluye una cámara con FoV amplio (>90o) y se requiere la versión rev2 de la caja del ITS.

Sensor_fusion es un segundo equipo de pruebas que permite usar teléfonos repetidos y recetados y declara que las marcas de tiempo del giroscopio y del sensor de imagen coinciden, y que los marcos 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 habilitadas cuando hay varias cámaras y mantener al mismo tiempo compatibilidad con apps, sigue estas prácticas recomendadas cuando implementes dispositivo multicámara:

  • (Android 10 o versiones posteriores) Ocultar subcámaras físicas de getCameraIdList Esto reduce la cantidad de cámaras que pueden abrirse directamente apps, 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 una multicámara lógica que admita el zoom óptico, implementa la ANDROID_CONTROL_ZOOM_RATIO API y usa ANDROID_SCALER_CROP_REGION solo para recortes de relación de aspecto. ANDROID_CONTROL_ZOOM_RATIO permite que el dispositivo se aleje y mantenga una mayor 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 enfoque posterior al zoom visual como el sensor activo del array. 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.
  • Para dispositivos multicámara con cámaras físicas que tengan diferentes asegúrate de que el dispositivo anuncie la compatibilidad con un valor determinado o rango de un control solo si todo el rango de zoom admite el valor o rango. Por ejemplo, si la cámara lógica consta de un lente ultra gran angular, una cámara con gran angular y una teleobjetivo, haz lo siguiente:
    • Si los tamaños de las matrices activas de las cámaras físicas son diferentes, el HAL de la cámara debe hacer la asignación de los grupos activos de las cámaras físicas a el 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 para que, desde la perspectiva de la app, de coordenadas es el tamaño del array activo de la cámara lógica.
    • Si las cámaras gran angular y teleobjetivo admiten enfoque automático, pero la cámara ultra gran angular cámara tiene un enfoque fijo, asegúrate de que la cámara lógica anuncie el enfoque automático y asistencia. La HAL debe simular una máquina de estado de enfoque automático para el lente ultra gran angular para que, cuando la app se acerque al lente ultra gran angular, el hecho de que la cámara física subyacente es que el enfoque fijo es transparente para la app, y las máquinas de estado de enfoque automático para los modos de AF compatibles funcionan como lo esperado.
    • Si las cámaras gran angular y la teleobjetivo admiten 4K a 60 fps y las la cámara ultra gran angular solo admite 4K a 30 FPS o 1080p a 60 FPS, pero no es 4K a 60 FPS, asegúrate de que la cámara lógica no anuncie 4K a 60 FPS. 60 FPS en las configuraciones de transmisión compatibles. Esto garantiza la la integridad de las capacidades lógicas de la cámara, lo que garantiza que la app tienes el problema de no lograr la calidad 4K a 60 fps a una ANDROID_CONTROL_ZOOM_RATIO es inferior a 1.
  • Desde Android 10, una cámara lógica multicámara no es necesario para admitir combinaciones de transmisión que incluyan transmisiones físicas. Si la HAL admite una combinación con transmisiones físicas:
    • (Android 11 o versiones posteriores) Para controlar mejor el uso como la profundidad a partir de sonido estéreo y el seguimiento de movimiento, hacen que el campo visual una salida de transmisión física tan grande como sea posible con el hardware. Sin embargo, si una transmisión física y una lógica se originan a partir de la misma una cámara física, las limitaciones de hardware podrían forzar el campo visual de la física para que sea la misma que 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 anular la asignación de los búferes libres (búferes que libera el consumidor, pero el productor no las sacó de la cola) si se espera que una transmisión física sin actividad durante un tiempo determinado.
    • Si las transmisiones físicas de distintas cámaras físicas no suelen adjunta a la misma solicitud, asegúrate de que las apps usen surface group de modo que una cola de búfer se use para respaldar dos superficies orientadas a la app lo que reduce el consumo de memoria.