O Android 9 introduziu suporte à API para várias câmeras com um novo dispositivo de câmera lógica composto por dois ou mais dispositivos físicos e dispositivos de câmera apontando para a mesma direção. A câmera lógica exposto como um único CameraDevice/CaptureSession a um app, permitindo com recursos de várias câmeras integrados à HAL. Os aplicativos podem, opcionalmente, acessar e controlar streams de câmera física subjacentes, metadados e controles.
Figura 1. Compatibilidade com várias câmeras
Neste diagrama, diferentes IDs de câmera são codificados por cores. O app pode fazer streaming de buffers brutos de cada câmera física ao mesmo tempo. Também é definir controles separados e receber metadados separados de diferentes câmeras físicas.
Exemplos e origens
Dispositivos com várias câmeras devem ser anunciados com o recurso lógico de várias câmeras.
Os clientes de câmera podem consultar o ID da câmera dos dispositivos físicos que uma determinada
de que a câmera lógica é composta ao chamar
getPhysicalCameraIds()
Os IDs retornados como parte do resultado são usados para controlar dispositivos físicos
individualmente por meio de
setPhysicalCameraId()
Os resultados dessas solicitações individuais podem ser consultados no
resultado invocando
getPhysicalCameraResults()
Solicitações de câmera física individuais podem suportar apenas um subconjunto limitado de
parâmetros. Para receber uma lista dos parâmetros compatíveis, os desenvolvedores podem chamar
getAvailablePhysicalCameraRequestKeys()
Os streams de câmeras físicas são compatíveis apenas com solicitações que não são de reprocessamento e apenas para sensores monocromáticos e bayer.
Implementação
Lista de verificação de suporte
Para adicionar dispositivos lógicos com várias câmeras no lado da HAL:
- Adicione um
ANDROID_REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
para qualquer dispositivo de câmera lógica apoiado por dois ou mais que também estão expostas a um app. - Preencher o
ANDROID_LOGICAL_MULTI_CAMERA_PHYSICAL_IDS
metadados com uma lista de IDs de câmeras físicas. - Preencher os metadados estáticos relacionados à profundidade necessários para a correlação entre
streams de câmera física pixels:
ANDROID_LENS_POSE_ROTATION
,ANDROID_LENS_POSE_TRANSLATION
,ANDROID_LENS_INTRINSIC_CALIBRATION
,ANDROID_LENS_DISTORTION
,ANDROID_LENS_POSE_REFERENCE
. Defina o
ANDROID_LOGICAL_MULTI_CAMERA_SENSOR_SYNC_TYPE
metadados para:ANDROID_LOGICAL_MULTI_CAMERA_SENSOR_SYNC_TYPE_APPROXIMATE
: Para sensores no modo principal principal, sem sincronização de obturador/exposição no hardware.ANDROID_LOGICAL_MULTI_CAMERA_SENSOR_SYNC_TYPE_CALIBRATED
: Para sensores no modo secundário principal, sincronização do obturador/exposição do hardware.
Preencher
ANDROID_REQUEST_AVAILABLE_PHYSICAL_CAMERA_REQUEST_KEYS
com uma lista de parâmetros compatíveis com câmeras físicas individuais. A A lista pode ficar vazia se o dispositivo lógico não aceitar solicitações individuais.Se houver suporte para solicitações individuais, processe e aplique as
physicalCameraSettings
que podem chegar como parte das solicitações de captura e anexam os registros individuaisphysicalCameraMetadata
de maneira adequada.Para as versões 3.5 de dispositivos HAL da câmera (introduzidos no Android 10) ou versões mais recentes, preencha
ANDROID_LOGICAL_MULTI_CAMERA_ACTIVE_PHYSICAL_ID
chave de resultado usando o ID da câmera física ativa atual em suporte ao câmera lógica.
Para dispositivos com o Android 9, as câmeras precisam suporte a substituição de um fluxo lógico YUV/RAW por fluxos físicos do mesmo tamanho (não se aplica a streams RAW) e o mesmo formato de duas câmeras. Isso não se aplica a dispositivos com o Android 10.
Para dispositivos com o Android 10, em que
versão do dispositivo HAL da câmera é
3,50
ou superior, a câmera precisa oferecer suporte
isStreamCombinationSupported
para que os aplicativos consultem se determinada combinação de streams contendo
streams físicos são suportados.
Mapa de configuração do stream
Para uma câmera lógica, as combinações de stream obrigatórias para o dispositivo de câmera de
um determinado nível de hardware é igual ao necessário
CameraDevice.createCaptureSession
Todos os streams no mapa de configuração de stream precisam ser lógicos.
Para um dispositivo de câmera lógico compatível com capacidade RAW com subcâmeras físicas de tamanhos diferentes, se um app configurar um stream RAW lógico, o dispositivo de câmera lógica não deve alternar para subcâmeras físicas com diferentes tamanhos de sensores. Isso garante que os apps de captura RAW existentes não sejam corrompidos.
Para aproveitar o zoom óptico implementado pela HAL alternando entre em subcâmeras físicas durante a captura RAW, os aplicativos devem configurar streams físicos de subcâmera, em vez de um fluxo lógico RAW.
Combinação de transmissão garantida
Tanto a câmera lógica quanto as câmeras físicas subjacentes devem garantir a combinações obrigatórias de stream necessárias para cada dispositivo.
Um dispositivo de câmera lógico precisa funcionar da mesma forma que uma câmera física com base no nível de hardware e nos recursos dele. Recomenda-se que o é um superconjunto do conjunto de câmeras físicas individuais.
Em dispositivos com o Android 9, para cada item combinação de stream, a câmera lógica precisa oferecer suporte a:
Substituir um YUV_420_888 lógico ou fluxo bruto por dois fluxos físicos de do mesmo tamanho e formato, cada um para uma câmera física separada, já que o tamanho e o formato compatíveis com as câmeras físicas.
Adicionar dois streams brutos, um de cada câmera física, se a câmera lógica não anuncia capacidade RAW, mas sim as câmeras físicas subjacentes. Isso geralmente ocorre quando as câmeras físicas têm sensores de tamanhos diferentes.
Usar streams físicos em vez de streams lógicos do mesmo tamanho e . Isso não deve retardar o frame rate da captura quando a duração mínima de frame dos streams físicos e lógicos é a mesma.
Considerações sobre desempenho e eficiência
Desempenho:
- Configurar e transmitir streams físicos pode atrasar a a taxa de captura lógica da câmera devido a restrições de recursos.
- Aplicar as configurações da câmera física pode diminuir a taxa de captura se o são colocados em diferentes frame rates.
Alimentação:
- A otimização de energia da HAL continua funcionando no caso padrão.
- Configurar ou solicitar streams físicos pode substituir e aumenta o consumo de energia.
Personalização
Você pode personalizar a implementação do seu dispositivo das seguintes maneiras.
- A saída fundida do dispositivo de câmera lógica depende totalmente da HAL. implementação. A decisão sobre como os streams lógicos combinados são derivados As câmeras físicas são transparentes para o app e a câmera do Android de análise de dados em nuvem.
- Solicitações físicas individuais e resultados podem ser suportados opcionalmente. A de parâmetros disponíveis nessas solicitações também depende totalmente a implementação específica da HAL.
- A partir do Android 10, a HAL pode reduzir o número de
câmeras que podem ser abertas diretamente por um aplicativo optando por não
anunciar alguns ou todos os PHYSICAL_IDs em
getCameraIdList
Ligando paragetPhysicalCameraCharacteristics
deve retornar as características da câmera física.
Validação
Os dispositivos lógicos com várias câmeras precisam passar no CTS da câmera como qualquer outra câmera normal.
Os casos de teste voltados para esse tipo de dispositivo podem ser encontrados no
LogicalCameraDeviceTest
mais tarde neste módulo.
Esses três testes ITS têm como alvo sistemas com várias câmeras para facilitar o fusão de imagens:
scene1/test_multi_camera_match.py
scene4/test_multi_camera_alignment.py
sensor_fusion/test_multi_camera_frame_sync.py
Os testes das cenas 1 e 4 são executados com o
Teste ITS-in-a-box
equipamento O teste test_multi_camera_match
declara que o brilho do
e o centro das imagens coincidem quando as duas câmeras estão ativadas. A
O teste test_multi_camera_alignment
declara que o espaçamento, as orientações da câmera
e os parâmetros de distorção
foram carregados corretamente. Se o sistema com várias câmeras
incluir uma câmera com amplo campo de visão (>90o) e a versão rev2 da caixa ITS.
O Sensor_fusion
é um segundo equipamento de teste que permite apps repetidos e prescritos de uso
movimento e declara que os carimbos de data/hora do giroscópio e do sensor de imagem correspondem e que
que os frames de várias câmeras estejam sincronizados.
Todas as caixas estão disponíveis por meio da AcuSpec, Inc. (www.acuspecinc.com, fred@acuspecinc.com) e MYWAY Manufatura (www.myway.tw, sales@myway.tw). Além disso, o box ITS rev1 pode ser comprado na West-Mark (www.west-mark.com, dgoodman@west-mark.com).
Práticas recomendadas
Para aproveitar ao máximo os recursos habilitados por várias câmeras, mantendo apps do Google, siga estas práticas recomendadas ao implementar uma lógica dispositivo com várias câmeras:
- (Android 10 ou versões mais recentes) Ocultar subcâmeras físicas
getCameraIdList
Isso reduz o número de câmeras que podem ser abertas diretamente sem que eles precisem ter uma lógica complexa de seleção de câmera. - (Android 11 ou versões mais recentes) Para uma lógica com várias câmeras
dispositivo compatível com zoom óptico, implemente o
ANDROID_CONTROL_ZOOM_RATIO
API e usarANDROID_SCALER_CROP_REGION
apenas para corte de proporção.ANDROID_CONTROL_ZOOM_RATIO
permite que o dispositivo diminua o zoom e mantenha uma precisão melhor. Nesse caso, a HAL precisa ajustar o sistema de coordenadas deANDROID_SCALER_CROP_REGION
,ANDROID_CONTROL_AE_REGIONS
,ANDROID_CONTROL_AWB_REGIONS
,ANDROID_CONTROL_AF_REGIONS
,ANDROID_STATISTICS_FACE_RECTANGLES
, eANDROID_STATISTICS_FACE_LANDMARKS
para tratar o método de campo de visão como a matriz ativa do sensor. Para mais informações sobre comoANDROID_SCALER_CROP_REGION
trabalha comANDROID_CONTROL_ZOOM_RATIO
, vercamera3_crop_reprocess#cropping
. - Para dispositivos com várias câmeras com câmeras físicas de diferentes
verifique se o dispositivo anuncia suporte para um determinado valor
ou intervalo para um controle somente se todo o intervalo de zoom oferecer suporte ao valor
ou intervalo de endereços. Por exemplo, se a câmera lógica for composta por uma lente ultra grande angular,
uma câmera ampla e uma telefoto, faça o seguinte:
- Se os tamanhos de matriz ativa das câmeras físicas forem diferentes, o
a HAL da câmera precisa fazer o mapeamento das matrizes ativas das câmeras físicas para
a matriz lógica ativa de câmera para
ANDROID_SCALER_CROP_REGION
;ANDROID_CONTROL_AE_REGIONS
,ANDROID_CONTROL_AWB_REGIONS
,ANDROID_CONTROL_AF_REGIONS
,ANDROID_STATISTICS_FACE_RECTANGLES
, eANDROID_STATISTICS_FACE_LANDMARKS
para que, do ponto de vista do aplicativo, sistema de coordenadas é o tamanho da matriz ativa da câmera lógica. - Se as câmeras grande angular e telefoto oferecerem suporte ao foco automático, mas a ultra grande angular a câmera está com foco fixo, verifique se a câmera lógica anuncia o foco automático suporte. A HAL precisa simular uma máquina de estado de foco automático para o modelo para que, quando o app diminuir o zoom para a lente ultra grande angular, o fato de a câmera física subjacente tem foco fixo e é transparente para o app; e as máquinas de estado de foco automático para os modos de AF compatíveis funcionam da forma o esperado.
- Se as câmeras grande angular e telefoto forem compatíveis com 4K a 60 fps, e a
a câmera ultra grande angular só é compatível com 4K a 30 fps ou 1080p a 60 fps, mas
não a 4K a 60 fps, verifique se a câmera lógica não anuncia em 4K @
60 QPS nas configurações de transmissão compatíveis. Isso garante que
integridade dos recursos lógicos da câmera, garantindo que o app não
se depare com o problema de não atingir 4K a 60 fps a um
ANDROID_CONTROL_ZOOM_RATIO
menor que 1.
- Se os tamanhos de matriz ativa das câmeras físicas forem diferentes, o
a HAL da câmera precisa fazer o mapeamento das matrizes ativas das câmeras físicas para
a matriz lógica ativa de câmera para
- Com foco no Android 10, uma lógica com várias câmeras
não precisa oferecer suporte a combinações de streams que incluem streams físicos.
Se a HAL oferecer suporte a uma combinação com streams físicos:
- (Android 11 ou versões mais recentes) Para gerenciar melhor o uso como profundidade de estéreo e rastreamento de movimento, tornam o campo de visão das saídas de stream físico as mais amplas possíveis pelo hardware. No entanto, se um stream físico e um stream lógico se originarem do mesmo câmera física, as limitações de hardware podem forçar o campo de visão do fluxo físico seja igual ao fluxo lógico.
- Para lidar com a pressão de memória causada por vários streams físicos,
verificar se os apps usam
discardFreeBuffers
para desalocar os buffers livres (que são liberados pelo consumidor, mas ainda não foram retirados da fila pelo produtor) se for esperado que um stream físico seja ficam ociosos por um período. - Se as transmissões físicas de diferentes câmeras físicas não costumam ser
anexadas à mesma solicitação, verifique se os apps usam
surface group
para que uma fila do buffer seja usada para apoiar duas superfícies voltadas para o aplicativo, reduzir o consumo de memória.