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 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 os fluxos, metadados e controles da câmera física.

Compatibilidade com várias câmeras

Figura 1. Compatibilidade com várias câmeras

Neste diagrama, os IDs de câmeras diferentes 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

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 da câmera dos dispositivos físicos de que 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 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 com suporte, 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 com sensores monocromáticos e bayer.

Implementação

Lista de verificação de suporte

Para adicionar dispositivos com várias câmeras lógicas no lado da HAL:

Para dispositivos que executam o Android 9, os dispositivos de câmera precisam 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 o Android 10.

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

Mapa de configuração de streaming

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

Para um dispositivo de câmera lógica que ofereça suporte ao formato 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á alternar para subcâmeras físicas com diferentes tamanhos de sensor. Isso garante que os apps de captura RAW atuais não sejam corrompidos.

Para aproveitar o zoom óptico implementado pela HAL alternando entre subcâmeras físicas durante a captura RAW, os apps precisam 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 precisam garantir as combinações de stream obrigatórias necessárias para os níveis de dispositivo.

Um dispositivo de câmera lógica precisa funcionar da mesma forma que um dispositivo de câmera física com base no nível de hardware e nos recursos. É recomendável que o conjunto de recursos seja um superconjunto do de 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 YUV_420_888 lógico ou bruto por dois streams físicos de o mesmo tamanho e formato, cada um de uma câmera física separada, já que as câmeras físicas oferecem suporte de tamanho e formato.

  • Adicionar dois streams 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 sim. Isso geralmente ocorre quando as câmeras físicas têm tamanhos de sensor diferentes.

  • Usar fluxos físicos no lugar 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 do frame dos fluxos físicos e lógicos é a mesma.

Considerações sobre desempenho e energia

  • Desempenho:

    • A configuração e a transmissão de streams 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 de câmera física pode diminuir a taxa de captura se as câmeras subjacentes forem colocadas em frame rates diferentes.

  • Alimentação:

    • A otimização de energia da HAL continua funcionando no caso padrão.
    • Configurar ou solicitar fluxos físicos pode substituir a otimização de energia interna do HAL e gerar mais uso 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 do HAL. A decisão sobre como os fluxos lógicos fundidos são derivados das câmeras físicas é transparente para o app e o framework da câmera do Android.
  • É possível oferecer suporte a solicitações e resultados físicos individuais. O conjunto de parâmetros disponíveis nessas solicitações também depende totalmente da implementação específica da HAL.
  • No Android 10 e versões mais recentes, a HAL pode reduzir o número de câmeras que podem ser abertas diretamente por um app ao escolher não anunciar alguns ou todos os PHYSICAL_IDs em getCameraIdList. A chamada getPhysicalCameraCharacteristics precisa retornar as características da câmera física.

Validação

Dispositivos lógicos com várias câmeras precisam passar pelo CTS da câmera, como qualquer outra câmera normal. Os casos de teste destinados a esse tipo de dispositivo podem ser encontrados no módulo LogicalCameraDeviceTest.

Esses três testes do ITS são destinados a sistemas de várias câmeras para facilitar a fusão adequada de imagens:

Os testes da cena 1 e da cena 4 são executados com a plataforma 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 garante que os espaçamentos, orientações e parâmetros de distorção da câmera sejam carregados corretamente. Se o sistema de várias câmeras incluir uma câmera de campo de visão amplo (>90o), a versão rev2 da caixa ITS será necessária.

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 na 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 versões mais recentes) Oculte 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 os apps tenham uma lógica de seleção de câmera complexa.
  • (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 apenas para recorte de proporção. ANDROID_CONTROL_ZOOM_RATIO permite que o dispositivo diminua o zoom e mantenha uma precisão melhor. Nesse caso, o 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 ANDROID_SCALER_CROP_REGION funciona com ANDROID_CONTROL_ZOOM_RATIO, consulte camera3_crop_reprocess#cropping.
  • Para dispositivos com várias câmeras com câmeras físicas com recursos diferentes, verifique se o dispositivo anuncia suporte a um determinado valor ou intervalo para um controle somente se todo o intervalo de zoom tiver suporte ao valor ou intervalo. Por exemplo, se a câmera lógica for composta por uma câmera ultra grande angular, uma grande angular 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 precisa 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, do ponto de vista do app, o sistema de coordenadas seja o tamanho da matriz ativa da câmera lógica.
    • Se as câmeras grande angular e telefoto tiverem suporte ao foco automático, mas a câmera ultra-ampla tiver foco fixo, verifique se a câmera lógica oferece suporte ao foco automático. A HAL precisa simular uma máquina de estado de foco automático para a câmera ultrawide. Assim, quando o app diminui o zoom para a lente ultrawide, o fato de a câmera física subjacente ter foco fixo é transparente para o app, e as máquinas de estado de foco automático para os modos de AF aceitos funcionam como esperado.
    • Se as câmeras grande-angular e telefoto tiverem suporte a 4K a 60 qps e a câmera ultra-wide tiver suporte apenas a 4K a 30 qps ou 1080p a 60 qps, mas não 4K a 60 qps, verifique se a câmera lógica não anuncia 4K a 60 qps nas configurações de transmissão com suporte. Isso garante a integridade dos recursos lógicos da câmera, garantindo que o app não tenha o problema de não atingir 4K a 60 qps com um valor de ANDROID_CONTROL_ZOOM_RATIO menor que 1.
  • A partir do Android 10, uma lógica lógica com várias câmeras não é necessária para oferecer suporte a combinações de streaming que incluem streams físicos. Se o HAL oferecer suporte a uma combinação com fluxos físicos:
    • (Android 11 ou versões mais recentes) 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 stream físico o maior possível que possa ser alcançado pelo hardware. No entanto, se um stream físico e um stream lógico tiverem origem na 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 o mesmo que o stream lógico.
    • Para lidar com 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 estiver inativo por um período.
    • Se os fluxos de diferentes câmeras físicas não estiverem normalmente anexados à mesma solicitação, verifique se os apps usam surface group para que uma fila de buffer seja usada para fazer backup de duas plataformas voltadas a apps, reduzindo o consumo de memória.