Suporte a várias câmeras

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.

Compatibilidade com várias câmeras

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:

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 para getPhysicalCameraCharacteristics 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:

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 usar ANDROID_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 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 método de campo de visão como a matriz ativa do sensor. Para mais informações sobre como ANDROID_SCALER_CROP_REGION trabalha com ANDROID_CONTROL_ZOOM_RATIO, ver camera3_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, e ANDROID_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.
  • 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.