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 diferentes câmeras 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 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 pelo 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 fluxos de câmera física são compatíveis apenas com solicitações sem reprocessamento e somente com sensores monocromos 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 é compatível.

Mapa de configuração de streaming

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

Para um dispositivo de câmera lógica com suporte a 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 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 do 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 fluxo bruto ou YUV_420_888 lógico por dois fluxos físicos do mesmo tamanho e formato, cada um de uma câmera física separada, considerando que o tamanho e o formato têm suporte das câmeras físicas.

  • Adição de 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 o fizerem. 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 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 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 do 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. Chamar 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, as orientações e os 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) Ocultar subcâmeras físicas do 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 for compatível com o valor ou intervalo. Por exemplo, se a câmera lógica for composta por uma câmera ultra-ampla, uma câmera ampla e uma câmera 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 ser de 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 qpm e a câmera ultra-wide tiver suporte apenas a 4K a 30 qpm ou 1080p a 60 qpm, mas não 4K a 60 qpm, verifique se a câmera lógica não anuncia 4K a 60 qpm nas configurações de streaming 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 câmera lógica não é necessária para oferecer suporte a combinações de streaming que incluem streamings físicos. Se o HAL oferecer suporte a uma combinação com fluxos físicos:
    • (Android 11 ou mais recente) Para lidar melhor com casos de uso como profundidade de rastreamento estéreo e de movimento, faça com que o campo de visão das saídas de transmissão física seja o maior possível para o 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 que são liberados pelo consumidor, mas ainda não foram 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.