Suporte a várias câmeras

O Android 9 introduziu 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 apontados para a mesma direção. O dispositivo de câmera lógica é exposto como um único CameraDevice/CaptureSession para um app, permitindo a interação com recursos de várias câmeras integrados à HAL. Os apps podem acessar e controlar fluxos de câmera física, 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 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 origens

Os dispositivos com várias câmeras precisam ser anunciados com o recurso lógico de várias câmeras.

Os clientes de câmera podem consultar o ID dos dispositivos físicos que compõem uma determinada câmera lógica chamando getPhysicalCameraIds(). Os IDs retornados como parte do resultado são usados para controlar dispositivos físicos individualmente por setPhysicalCameraId(). Os resultados dessas solicitações individuais podem ser consultados no resultado completo invocando getPhysicalCameraResults().

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

Os fluxos de câmera física são compatíveis apenas com solicitações sem reprocessamento e 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 que executam o Android 9, os dispositivos de câmera precisam oferecer suporte à substituição de um streaming lógico YUV/RAW por streamings físicos do mesmo tamanho (não se aplica a streamings RAW) e do mesmo formato de duas câmeras físicas. Isso não se aplica a dispositivos com Android 10.

Em dispositivos com Android 10 em que a versão do dispositivo HAL de câmera é 3.5 ou mais recente, o dispositivo de câmera precisa ser compatível com isStreamCombinationSupported para que os apps consultem se uma combinação de streaming específica que contém streamings físicos é compatível.

Mapa de configuração de streaming

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 são as mesmas exigidas em CameraDevice.createCaptureSession. Todos os fluxos no mapa de configuração de fluxo precisam ser lógicos.

Para um dispositivo de câmera lógica que oferece suporte à capacidade RAW com subcâmeras físicas de tamanhos diferentes, se um app configurar um fluxo RAW lógico, o dispositivo de câmera lógica não poderá mudar para subcâmeras físicas com tamanhos de sensor diferentes. Isso garante que os apps de captura RAW atuais não sejam interrompidos.

Para aproveitar o zoom óptico implementado pelo HAL trocando entre subcâmeras físicas durante a captura RAW, os apps precisam configurar streams de subcâmeras físicas em vez de um stream RAW lógico.

Combinação garantida de streams

A câmera lógica e as câmeras físicas subjacentes precisam garantir as combinações de stream obrigatórias necessárias para os níveis de dispositivo.

Um dispositivo de câmera lógica deve operar da mesma forma que um dispositivo de câmera física com base no nível e nas capacidades de hardware. Recomendamos que o conjunto de recursos seja um superconjunto das câmeras físicas individuais.

Em dispositivos com o Android 9, para cada combinação de streaming garantida, a câmera lógica precisa oferecer suporte a:

  • Substituir um stream lógico YUV_420_888 ou bruto por dois streams físicos do mesmo tamanho e formato, cada um de uma câmera física separada, desde que o tamanho e o formato sejam 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 anunciar a capacidade RAW, mas as câmeras físicas subjacentes sim. Isso geralmente acontece quando as câmeras físicas têm tamanhos de sensor diferentes.

  • Usar fluxos físicos em vez de um fluxo lógico do mesmo tamanho e formato. Isso não pode diminuir a taxa de frames da captura quando a duração mínima de frames dos fluxos físico e lógico for a mesma.

Considerações sobre desempenho e bateria

  • 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 forem colocadas em diferentes taxas de frames.

  • Alimentação:

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

Personalização

É possível personalizar a implementação do dispositivo das seguintes maneiras.

  • A saída combinada do dispositivo de câmera lógica depende totalmente da implementação da HAL. A decisão sobre como os fluxos lógicos combinados são derivados das câmeras físicas é transparente para o app e a estrutura de câmera do Android.
  • Pedidos e resultados físicos individuais podem ser aceitos opcionalmente. O conjunto de parâmetros disponíveis nessas solicitações também depende totalmente da implementação específica da HAL.
  • No Android 10, a HAL pode reduzir o número de câmeras que podem ser abertas diretamente por um app ao optar por não anunciar alguns ou todos os PHYSICAL_IDs em getCameraIdList. Chamar getPhysicalCameraCharacteristics precisa retornar as características da câmera física.

Validação

Os dispositivos lógicos com várias câmeras precisam passar no CTS de câmera como qualquer outra câmera comum. Os casos de teste que têm como destino esse tipo de dispositivo podem ser encontrados no módulo LogicalCameraDeviceTest.

Estes três testes do ITS têm como alvo sistemas com várias câmeras 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 ativadas. O teste test_multi_camera_alignment afirma que os espaçamentos, as orientações e os parâmetros de distorção da câmera são carregados corretamente. Se o sistema de várias câmeras incluir uma câmera de campo de visão amplo (>90o), será necessária a versão rev2 da caixa ITS.

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

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

Práticas recomendadas

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

  • (Android 10 ou mais recente) Oculte as subcâmeras físicas de getCameraIdList. Isso reduz o número de câmeras que podem ser abertas diretamente por apps, eliminando a necessidade de que eles tenham uma lógica complexa de seleção de câmera.
  • (Android 11 ou mais recente) Para um dispositivo lógico com várias câmeras que ofereça suporte a zoom óptico, implemente a API ANDROID_CONTROL_ZOOM_RATIO e use ANDROID_SCALER_CROP_REGION somente 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 campo de visão pós-zoom como a matriz ativa do sensor. Para mais informações sobre como o ANDROID_SCALER_CROP_REGION funciona com o ANDROID_CONTROL_ZOOM_RATIO, consulte camera3_crop_reprocess#cropping.
  • Para dispositivos com várias câmeras físicas que têm recursos diferentes, verifique se o dispositivo anuncia suporte a um determinado valor ou intervalo para um controle somente se toda a faixa de zoom for compatível com o valor ou intervalo. Por exemplo, se a câmera lógica for composta por uma câmera ultra-wide, uma wide e uma telefoto, faça o seguinte:
    • Se os tamanhos de matriz ativa das câmeras físicas forem diferentes, a HAL da câmera precisará fazer o mapeamento das matrizes ativas das câmeras físicas para a matriz ativa da câmera lógica em 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. Assim, do ponto de vista do app, o sistema de coordenadas é o tamanho da matriz ativa da câmera lógica.
    • Se as câmeras ampla e telefoto forem compatíveis com foco automático, mas a ultra-ampla tiver foco fixo, verifique se a câmera lógica anuncia a compatibilidade com foco automático. A HAL precisa simular uma máquina de estado de foco automático para a câmera ultra grande angular. Assim, quando o app reduzir o zoom para a lente ultra grande angular, o fato de a câmera física subjacente ter foco fixo será transparente para o app, e as máquinas de estado de foco automático para os modos de AF compatíveis funcionarão como esperado.
    • Se as câmeras grande-angular e teleobjetiva forem compatíveis com 4K a 60 fps, e a câmera ultrawide for compatível apenas com 4K a 30 fps ou 1080p a 60 fps, mas não 4K a 60 fps, verifique se a câmera lógica não anuncia 4K a 60 fps nas configurações de stream compatíveis. Isso garante a integridade dos recursos da câmera lógica, evitando que o app não alcance 4K a 60 fps em um valor de ANDROID_CONTROL_ZOOM_RATIO menor que 1.
  • A partir do Android 10, uma multicâmera lógica não precisa oferecer suporte a combinações de streaming que incluem streamings físicos. Se o HAL for compatível com uma combinação de streamings físicos:
    • (Android 11 ou mais recente) Para lidar melhor com casos de uso, como profundidade de estéreo e rastreamento de movimento, faça com que o campo de visão das saídas de stream físicas seja o maior possível para o hardware. No entanto, se um stream físico e um stream lógico forem originados da mesma câmera física, as limitações de hardware poderão forçar o campo de visão do stream físico a ser igual ao do stream lógico.
    • Para resolver a pressão de memória causada por vários fluxos físicos, verifique se os apps usam discardFreeBuffers para desalocar os buffers livres (buffers liberados pelo consumidor, mas ainda não removidos da fila pelo produtor) se um fluxo físico ficar inativo por um período.
    • Se os fluxos físicos de diferentes câmeras físicas não forem normalmente anexados à mesma solicitação, verifique se os apps usam surface group para que uma fila de buffers seja usada para apoiar duas superfícies voltadas para o app, reduzindo o consumo de memória.