Suporte a várias câmeras

O Android 9 introduziu suporte de 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 para um aplicativo, permitindo a interação com recursos de múltiplas câmeras integrados ao HAL. Opcionalmente, os aplicativos podem acessar e controlar fluxos, metadados e controles de câmeras físicas subjacentes.

Suporte multicâmera

Figura 1 . Suporte multicâmera

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 com múltiplas câmeras devem ser anunciados com o recurso lógico de múltiplas câmeras .

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 é composta, chamando 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 a partir do resultado completo invocando getPhysicalCameraResults() .

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

Os fluxos de câmeras físicas 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 com múltiplas câmeras no lado HAL:

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 do mesmo formato de duas câmeras físicas. Isso não se aplica a dispositivos com 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 fluxo

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 deverá alternar para subcâmeras físicas com tamanhos de sensor diferentes. Isso garante que os aplicativos de captura RAW existentes não quebrem.

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âmeras físicas em vez de um fluxo RAW lógico.

Combinação de stream garantida

Tanto a câmera lógica quanto as câmeras físicas subjacentes devem garantir as combinações de fluxo obrigatórias exigidas 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 no nível e nas capacidades de hardware. É recomendado que seu conjunto de recursos seja um superconjunto das câmeras físicas individuais.

Em dispositivos com Android 9, para cada combinação de transmissão garantida, a câmera lógica deve suportar:

  • Substituir um fluxo lógico YUV_420_888 ou bruto por dois fluxos físicos do mesmo tamanho e formato, cada um de uma câmera física separada, visto que o tamanho e o formato são suportados pelas câmeras físicas.

  • Adicionar dois fluxos brutos, um de cada câmera física, se a câmera lógica não anunciar o recurso RAW, mas as câmeras físicas subjacentes o fizerem. Isso geralmente ocorre quando as câmeras físicas possuem tamanhos de sensores diferentes.

  • Usando fluxos físicos no lugar de um fluxo lógico do mesmo tamanho e formato. Isto não deve diminuir a taxa de quadros da captura quando a duração mínima dos quadros dos fluxos físicos e lógicos for a mesma.

Considerações de desempenho e potência

  • Desempenho:

    • A configuração e o streaming de fluxos físicos podem 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 taxas de quadros diferentes.

  • Poder:

    • A otimização de energia do HAL continua funcionando no caso padrão.
    • Configurar ou solicitar fluxos físicos pode substituir a otimização de energia interna do HAL e incorrer em mais consumo de energia.

Costumização

Você pode personalizar a implementação do seu dispositivo das seguintes maneiras.

  • A saída fundida do dispositivo lógico da câmera 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 e resultados físicos individuais 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 então retornar as características da câmera física.

Validação

Dispositivos lógicos com múltiplas câmeras devem passar pelo CTS da câmera como qualquer outra câmera normal. Os casos de teste direcionados a este tipo de dispositivo podem ser encontrados no módulo LogicalCameraDeviceTest .

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

Os testes da cena 1 e da 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), será 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 múltiplas 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 ITS rev1 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 múltiplas câmeras e, ao mesmo tempo, manter a compatibilidade do aplicativo, siga estas práticas recomendadas ao implementar um dispositivo lógico com múltiplas câmeras:

  • (Android 10 ou superior) Oculte 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 uma lógica complexa de seleção de câmeras.
  • (Android 11 ou superior) Para um dispositivo lógico com várias câmeras 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 junto com ANDROID_CONTROL_ZOOM_RATIO , consulte camera3_crop_reprocess#cropping .
  • Para dispositivos com várias câmeras com câmeras físicas que possuem capacidades 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 suportar o valor ou intervalo. Por exemplo, se a câmera lógica for composta por uma câmera ultralarga, grande angular e telefoto, faça o seguinte:
    • Se os tamanhos da matriz ativa das câmeras físicas forem diferentes, o HAL da câmera deverá 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 para que a partir do aplicativo perspectiva, o sistema de coordenadas é o tamanho da matriz ativa da câmera lógica.
    • Se as câmeras grande angular e telefoto suportarem foco automático, mas a câmera ultralarga tiver foco fixo, certifique-se de que a câmera lógica anuncie suporte para 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 funcionar conforme o esperado.
    • Se as câmeras grande angular e telefoto suportarem 4K a 60 fps, e a câmera ultralarga 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 terá o problema de não atingir 4k a 60 fps com um valor ANDROID_CONTROL_ZOOM_RATIO inferior a 1.
  • A partir do Android 10, não é necessária uma multicâmera lógica para oferecer suporte a combinações de stream que incluam streams 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 de estéreo e rastreamento de movimento, torne o campo de visão das saídas de fluxo físico o maior que puder ser alcançado pelo hardware. No entanto, se um fluxo físico e um fluxo lógico originarem-se da mesma câmera física, as limitações de hardware poderão forçar o campo de visão do fluxo físico a ser igual ao do 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 retirados da fila pelo produtor) se for esperado que um fluxo físico fique ocioso por um período de tempo.
    • Se os fluxos físicos de diferentes câmeras físicas 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 apoiar duas superfícies voltadas para o aplicativo, reduzindo o consumo de memória.