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.
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:
- Agrega un
ANDROID_REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
para cualquier dispositivo de cámara lógica respaldado por dos o más dispositivos que también están expuestas a una app. - Propaga el objeto
ANDROID_LOGICAL_MULTI_CAMERA_PHYSICAL_IDS
de metadatos con una lista de IDs de cámaras físicas. - Propaga los metadatos estáticos relacionados con la profundidad que se requieren para correlacionar
transmisiones de cámaras físicas píxeles:
ANDROID_LENS_POSE_ROTATION
:ANDROID_LENS_POSE_TRANSLATION
,ANDROID_LENS_INTRINSIC_CALIBRATION
,ANDROID_LENS_DISTORTION
:ANDROID_LENS_POSE_REFERENCE
. Establece la estática
ANDROID_LOGICAL_MULTI_CAMERA_SENSOR_SYNC_TYPE
metadatos para:ANDROID_LOGICAL_MULTI_CAMERA_SENSOR_SYNC_TYPE_APPROXIMATE
: Para los sensores en el modo principal principal, no hay sincronización del obturador de hardware ni de la exposición.ANDROID_LOGICAL_MULTI_CAMERA_SENSOR_SYNC_TYPE_CALIBRATED
: Para los sensores en el modo secundario principal, se sincroniza el obturador y la exposición del hardware.
Propagar
ANDROID_REQUEST_AVAILABLE_PHYSICAL_CAMERA_REQUEST_KEYS
con una lista de los parámetros admitidos para cámaras físicas individuales. El La lista puede estar vacía si el dispositivo lógico no admite solicitudes individuales.Si se admiten solicitudes individuales, procesa y aplica las solicitudes individuales.
physicalCameraSettings
que pueden llegar como parte de las solicitudes de capturaphysicalCameraMetadata
según corresponda.Para las versiones 3.5 de dispositivos de la HAL de la cámara (presentado en Android 10) o versiones posteriores, completa el
ANDROID_LOGICAL_MULTI_CAMERA_ACTIVE_PHYSICAL_ID
clave de resultado con el ID de la cámara física activa que respalda la clave. lógica de la cámara.
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 agetPhysicalCameraCharacteristics
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:
scene1/test_multi_camera_match.py
scene4/test_multi_camera_alignment.py
sensor_fusion/test_multi_camera_frame_sync.py
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 usaANDROID_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 deANDROID_SCALER_CROP_REGION
.ANDROID_CONTROL_AE_REGIONS
,ANDROID_CONTROL_AWB_REGIONS
,ANDROID_CONTROL_AF_REGIONS
:ANDROID_STATISTICS_FACE_RECTANGLES
: yANDROID_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ómoANDROID_SCALER_CROP_REGION
funciona junto conANDROID_CONTROL_ZOOM_RATIO
, consultacamera3_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
: yANDROID_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.
- 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
- 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.