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 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 streams, metadados e controles de câmeras físicas subjacentes.

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 de várias câmeras lógicas.

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

As solicitações de câmeras físicas 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 aceitos apenas para solicitações de não 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 que executam o Android 9, os dispositivos de câmera precisam oferecer suporte à substituição de um stream YUV ou RAW lógico por streams físicos do mesmo tamanho (não se aplica a streams RAW) e do mesmo formato de duas câmeras físicas. Isso não se aplica a dispositivos que executam o Android 10.

Para dispositivos que executam o Android 10 em que a versão do dispositivo HAL da 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 stream específica que contém streams físicos é aceita.

Mapa de configuração de 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 são as mesmas necessárias em CameraDevice.createCaptureSession. Todos os streams no mapa de configuração de stream precisam ser lógicos.

Para um dispositivo de câmera lógica que oferece suporte ao recurso 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 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 pela HAL alternando 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 de stream garantida

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 precisa operar da mesma forma que um dispositivo de câmera física com base no nível e nos recursos de hardware. Recomendamos que o conjunto de recursos seja um superconjunto das câmeras físicas individuais.

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

  • Substituir um stream YUV_420_888 ou bruto lógico 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 aceitos pelas câmeras físicas.

  • 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 streams físicos no lugar de um stream lógico do mesmo tamanho e formato. Isso não pode diminuir a taxa de quadros da captura quando a duração mínima do quadro dos streams físicos e lógicos for a mesma.

Considerações sobre desempenho e energia

  • Desempenho:

    • A configuração e o streaming 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âmeras físicas pode diminuir a taxa de captura se as câmeras subjacentes forem colocadas em taxas de quadros diferentes.

  • Energia:

    • A otimização de energia da HAL continua funcionando no caso padrão.
    • A configuração ou solicitação de streams físicos pode substituir a otimização de energia interna da 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 inteiramente da implementação da HAL. A decisão sobre como os streams lógicos combinados são derivados das câmeras físicas é transparente para o app e o framework de câmera do Android.
  • As solicitações e os resultados físicos individuais podem ser aceitos opcionalmente. O conjunto de parâmetros disponíveis nessas solicitações também depende inteiramente da 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 app, optando por não anunciar alguns ou todos os PHYSICAL_IDs em getCameraIdList. A chamada de 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 da câmera como qualquer outra câmera normal. Os casos de teste destinados a esse tipo de dispositivo podem ser encontrados no LogicalCameraDeviceTest módulo.

Esses três testes ITS são destinados a sistemas com várias câmeras para facilitar a combinaçã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 com várias câmeras incluir uma câmera com 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 o movimento repetido e prescrito do smartphone e afirma que os carimbos de data/hora do giroscópio e do sensor de imagem correspondem e que os quadros 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 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 os apps tenham uma lógica complexa de seleção de câmeras.
  • (Android 11 ou mais recente) Para um dispositivo lógico com várias câmeras que oferece suporte ao zoom óptico, implemente a ANDROID_CONTROL_ZOOM_RATIO API e use ANDROID_SCALER_CROP_REGION apenas para o corte da 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 ANDROID_SCALER_CROP_REGION funciona com 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 para um determinado valor ou intervalo de um controle somente se todo o intervalo de zoom oferecer 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 teleobjetiva, faça o seguinte:
    • Se os tamanhos da 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 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 . 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 grande angular e teleobjetiva oferecem suporte ao foco automático, mas a câmera ultra grande angular tem foco fixo, verifique se a câmera lógica anuncia suporte ao 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 diminui o zoom para a lente ultra grande angular, 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 foco automático aceitos funcionam conforme o esperado.
    • Se as câmeras grande angular e teleobjetiva oferecem suporte a 4K a 60 fps e a câmera ultra grande angular oferece suporte apenas a 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 aceitas. Isso garante a integridade dos recursos da câmera lógica, garantindo que o app não encontre o problema de não atingir 4K a 60 fps em um ANDROID_CONTROL_ZOOM_RATIO valor menor que 1.
  • No Android 10 e mais recente, uma câmera lógica com várias câmeras não precisa oferecer suporte a combinações de stream que incluem streams físicos. Se a HAL oferece suporte a uma combinação com streams físicos:
    • (Android 11 ou mais recente) Para processar melhor 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ísico 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 o mesmo que o stream lógico.
    • Para resolver a pressão de memória causada por vários streams físicos, verifique se os apps usam discardFreeBuffers para desalocar os buffers livres (buffers liberados pelo consumidor, mas ainda não enfileirados pelo produtor) se um stream físico ficar inativo por um período.
    • Se os streams físicos de câmeras físicas diferentes não forem normalmente anexados à mesma solicitação, verifique se os apps usam surface group para que uma fila do buffer seja usada para oferecer suporte a duas superfícies voltadas para o app, reduzindo o consumo de memória.