Esta página foi traduzida pela API Cloud Translation.

Suporte a várias câmeras

O Android 9 introduziu o suporte à API para dispositivos com várias câmeras por meio de um novo dispositivo de câmera lógica composto por dois ou mais dispositivos de câmera física apontando na mesma direção. O dispositivo de câmera lógica é exposto como um único CameraDevice/CaptureSession a um aplicativo que permite a interação com recursos de várias câmeras integrados ao HAL. Os aplicativos podem opcionalmente acessar e controlar fluxos, metadados e controles de câmeras físicas subjacentes.

Suporte para várias câmeras

Figura 1 . Suporte para várias câmeras

Neste diagrama, diferentes IDs de câmera são codificados por cores. O aplicativo pode transmitir buffers brutos de cada câmera física ao mesmo tempo. Também é possível definir controles separados e receber metadados separados de diferentes câmeras físicas.

Exemplos e fontes

Os dispositivos multicâmera devem ser anunciados com o recurso lógico multicâmera .

Os clientes de câmera podem consultar o ID da câmera dos dispositivos físicos dos quais uma câmera lógica específica é feita chamando getPhysicalCameraIds() . Os IDs retornados como parte do resultado são usados para controlar dispositivos físicos individualmente por meio de setPhysicalCameraId() . Os resultados de tais solicitações individuais podem ser consultados a partir do resultado completo invocando getPhysicalCameraResults() .

As solicitações de câmeras físicas individuais podem oferecer suporte apenas a um subconjunto limitado de parâmetros. Para receber uma lista dos parâmetros suportados, os desenvolvedores podem chamar getAvailablePhysicalCameraRequestKeys() .

Os fluxos de câmera física são suportados apenas para solicitações sem reprocessamento e apenas para sensores monocromáticos e bayer.

Implementação

Lista de verificação de suporte

Para adicionar dispositivos lógicos de várias câmeras no lado HAL:

Adicione um recurso ANDROID_REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA para qualquer dispositivo de câmera lógica suportado por duas ou mais câmeras físicas que também são expostas a um aplicativo.
Preencha o campo de metadados estático ANDROID_LOGICAL_MULTI_CAMERA_PHYSICAL_IDS com uma lista de IDs de câmera física.
Preencha os metadados estáticos relacionados à profundidade necessários para correlacionar os pixels dos fluxos de câmera física: ANDROID_LENS_POSE_ROTATION , ANDROID_LENS_POSE_TRANSLATION , ANDROID_LENS_INTRINSIC_CALIBRATION , ANDROID_LENS_DISTORTION , ANDROID_LENS_POSE_REFERENCE .
Defina o campo de metadados estático ANDROID_LOGICAL_MULTI_CAMERA_SENSOR_SYNC_TYPE como:
- ANDROID_LOGICAL_MULTI_CAMERA_SENSOR_SYNC_TYPE_APPROXIMATE : Para sensores no modo mestre-mestre, sem sincronização de obturador/exposição de hardware.
- ANDROID_LOGICAL_MULTI_CAMERA_SENSOR_SYNC_TYPE_CALIBRATED : Para sensores no modo mestre-escravo, sincronização de obturador/exposição de hardware.
Preencha ANDROID_REQUEST_AVAILABLE_PHYSICAL_CAMERA_REQUEST_KEYS com uma lista de parâmetros suportados para câmeras físicas individuais. A lista pode ficar vazia se o dispositivo lógico não oferecer suporte a solicitações individuais.
Se houver suporte para solicitações individuais, processe e aplique as physicalCameraSettings individuais que podem chegar como parte das solicitações de captura e anexe o physicalCameraMetadata individual de acordo.
Para o dispositivo Camera HAL versões 3.5 (introduzido no Android 10) ou superior, preencha a chave de resultado ANDROID_LOGICAL_MULTI_CAMERA_ACTIVE_PHYSICAL_ID usando o ID da câmera física ativa atual que suporta a câmera lógica.

Para dispositivos que executam o Android 9, os dispositivos de câmera devem oferecer suporte à substituição de um fluxo YUV/RAW lógico por fluxos físicos do mesmo tamanho (não se aplica a fluxos RAW) e o mesmo formato de duas câmeras físicas. Isso não se aplica a dispositivos que executam o Android 10.

Para dispositivos que executam o Android 10 em que a versão do dispositivo HAL da câmera é 3.5 ou superior, o dispositivo da câmera deve ser compatível com isStreamCombinationSupported para que os aplicativos consultem se uma determinada combinação de fluxo contendo fluxos físicos é compatível.

Mapa de configuração de stream

Para uma câmera lógica, as combinações de fluxo obrigatórias para o dispositivo de câmera de um determinado nível de hardware são as mesmas exigidas em CameraDevice.createCaptureSession . Todos os fluxos no mapa de configuração de fluxo devem ser fluxos lógicos.

Para um dispositivo de câmera lógica compatível com capacidade RAW com subcâmeras físicas de tamanhos diferentes, se um aplicativo configurar um fluxo RAW lógico, o dispositivo de câmera lógica não deve alternar para subcâmeras físicas com tamanhos de sensor diferentes. Isso garante que os aplicativos de captura RAW existentes não sejam interrompidos.

Para aproveitar o zoom óptico implementado por HAL, alternando entre subcâmeras físicas durante a captura RAW, os aplicativos devem configurar fluxos de subcâmera física em vez de um fluxo RAW lógico.

Combinação de stream garantida

Tanto a câmera lógica quanto suas câmeras físicas subjacentes devem garantir as combinações de fluxo obrigatórias necessárias para seus níveis de dispositivo.

Um dispositivo de câmera lógica deve operar da mesma maneira que um dispositivo de câmera física com base em seu nível de hardware e recursos. É recomendável que seu conjunto de recursos seja um superconjunto do conjunto de câmeras físicas individuais.

Em dispositivos que executam o Android 9, para cada combinação de transmissão garantida, a câmera lógica deve ser compatível com:

Substituir um fluxo lógico YUV_420_888 ou raw por dois fluxos físicos do mesmo tamanho e formato, cada um de uma câmera física separada, desde que o tamanho e o formato sejam suportados pelas câmeras físicas.
Adicionando dois fluxos brutos, um de cada câmera física, se a câmera lógica não anunciar a capacidade RAW, mas as câmeras físicas subjacentes sim. Isso geralmente ocorre quando as câmeras físicas têm tamanhos de sensor diferentes.
Usando fluxos físicos no lugar de um fluxo lógico do mesmo tamanho e formato. Isso não deve diminuir a taxa de quadros da captura quando a duração mínima do quadro dos fluxos físicos e lógicos for a mesma.

Considerações de desempenho e energia

Atuação:
- Configurar e transmitir fluxos físicos pode diminuir a taxa de captura da câmera lógica devido a restrições de recursos.
- A aplicação de configurações físicas da câmera pode diminuir a taxa de captura se as câmeras subjacentes forem colocadas em diferentes taxas de quadros.
Poder:
- A otimização de energia do HAL continua funcionando no caso padrão.
- A configuração ou solicitação de fluxos físicos pode anular a otimização de energia interna do HAL e incorrer em mais uso de energia.

Costumizaçã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 inteiramente da implementação HAL. A decisão sobre como os fluxos lógicos fundidos são derivados das câmeras físicas é transparente para o aplicativo e a estrutura da câmera Android.
Solicitações físicas individuais e resultados podem ser opcionalmente suportados. O conjunto de parâmetros disponíveis em tais solicitações também depende inteiramente da implementação específica do HAL.
A partir do Android 10, o 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 . Chamar getPhysicalCameraCharacteristics deve retornar as características da câmera física.

Validação

Os dispositivos lógicos de várias câmeras devem passar pelo CTS da câmera como qualquer outra câmera comum. Os casos de teste que visam esse tipo de dispositivo podem ser encontrados no módulo LogicalCameraDeviceTest .

Esses três testes ITS visam sistemas multicâmera para facilitar a fusão adequada de imagens:

Os testes de cena 1 e cena 4 são executados com o equipamento de teste ITS-in-a-box . O teste test_multi_camera_match afirma que o brilho do centro das imagens corresponde quando as duas câmeras estão habilitadas. O teste test_multi_camera_alignment afirma que os espaçamentos, orientações e parâmetros de distorção da câmera estão carregados corretamente. Se o sistema multicâmera incluir uma câmera Wide FoV (>90o), é necessária a versão rev2 da caixa ITS.

Sensor_fusion é um segundo equipamento de teste que permite movimentos repetidos e prescritos do telefone e afirma que os carimbos de data e hora do giroscópio e do sensor de imagem correspondem e que os quadros de várias câmeras estão sincronizados.

Todas as caixas estão disponíveis através da AcuSpec, Inc. ( www.acuspecinc.com , fred@acuspecinc.com) e MYWAY Manufacturing ( www.myway.tw , sales@myway.tw). Além disso, a caixa rev1 ITS pode ser adquirida através da West-Mark ( www.west-mark.com , dgoodman@west-mark.com).

Melhores Práticas

Para aproveitar ao máximo os recursos habilitados por várias câmeras, mantendo a compatibilidade do aplicativo, siga estas práticas recomendadas ao implementar um dispositivo lógico com várias câmeras:

(Android 10 ou superior) Oculte as subcâmeras físicas de getCameraIdList . Isso reduz o número de câmeras que podem ser abertas diretamente pelos aplicativos, eliminando a necessidade de os aplicativos terem lógica de seleção de câmera complexa.
(Android 11 ou superior) Para um dispositivo multicâmera lógico compatível com zoom óptico, implemente a API ANDROID_CONTROL_ZOOM_RATIO e use ANDROID_SCALER_CROP_REGION apenas para corte de proporção. ANDROID_CONTROL_ZOOM_RATIO permite que o dispositivo diminua o zoom e mantenha melhor precisão. Nesse caso, o HAL deve ajustar o sistema de coordenadas de ANDROID_SCALER_CROP_REGION , ANDROID_CONTROL_AE_REGIONS , ANDROID_CONTROL_AWB_REGIONS , ANDROID_CONTROL_AF_REGIONS , ANDROID_STATISTICS_FACE_RECTANGLES e ANDROID_STATISTICS_FACE_LANDMARKS para tratar o campo de visão pós-zoom como a matriz ativa do sensor. Para obter mais informações sobre como ANDROID_SCALER_CROP_REGION funciona em conjunto com ANDROID_CONTROL_ZOOM_RATIO , consulte camera3_crop_reprocess#cropping .
Para dispositivos com várias câmeras com câmeras físicas que possuem recursos diferentes, certifique-se de que o dispositivo anuncie suporte para um determinado valor ou intervalo para um controle somente se todo o intervalo de zoom for compatível com o valor ou intervalo. Por exemplo, se a câmera lógica for composta por uma câmera ultralarga, ampla e telefoto, faça o seguinte:
- Se os tamanhos das matrizes ativas das câmeras físicas forem diferentes, o HAL da câmera deve fazer o mapeamento das matrizes ativas das câmeras físicas para a matriz ativa da câmera lógica para ANDROID_SCALER_CROP_REGION , ANDROID_CONTROL_AE_REGIONS , ANDROID_CONTROL_AWB_REGIONS , ANDROID_CONTROL_AF_REGIONS , ANDROID_STATISTICS_FACE_RECTANGLES e ANDROID_STATISTICS_FACE_LANDMARKS perspectiva, o 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 câmera ultralarga for o foco fixo, certifique-se de que a câmera lógica anuncie o suporte ao foco automático. O HAL deve simular uma máquina de estado de foco automático para a câmera ultralarga para que, quando o aplicativo diminuir o zoom para a lente ultralarga, o fato de a câmera física subjacente ter foco fixo seja transparente para o aplicativo e as máquinas de estado de foco automático para os modos AF suportados trabalhar como esperado.
- Se as câmeras grande e teleobjetiva suportarem 4K a 60 fps e a câmera ultrawide suportar apenas 4K a 30 fps ou 1080p a 60 fps, mas não 4K a 60 fps, certifique-se de que a câmera lógica não anuncie 4k a 60 fps em suas configurações de fluxo suportadas. Isso garante a integridade dos recursos lógicos da câmera, garantindo que o aplicativo não tenha o problema de não atingir 4k @ 60 fps em um valor ANDROID_CONTROL_ZOOM_RATIO menor que 1.
A partir do Android 10, uma multicâmera lógica não é necessária para dar suporte a combinações de fluxo que incluem fluxos físicos. Se o HAL suportar uma combinação com fluxos físicos:
- (Android 11 ou superior) Para lidar melhor com casos de uso, como profundidade do estéreo e rastreamento de movimento, torne o campo de visão das saídas de fluxo físico o maior possível pelo hardware. No entanto, se um fluxo físico e um fluxo lógico se originarem da mesma câmera física, as limitações de hardware podem forçar o campo de visão do fluxo físico a ser igual ao fluxo lógico.
- Para lidar com a pressão de memória causada por vários fluxos físicos, certifique-se de que os aplicativos usem discardFreeBuffers para desalocar os buffers livres (buffers que são liberados pelo consumidor, mas ainda não enfileirados pelo produtor) se um fluxo físico estiver ocioso por um período de tempo.
- Se os fluxos físicos de câmeras físicas diferentes normalmente não estiverem anexados à mesma solicitação, certifique-se de que os aplicativos usem surface group para que uma fila de buffer seja usada para fazer backup de duas superfícies voltadas para o aplicativo, reduzindo o consumo de memória.