O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Suporte para multi-câmeras

O Android 9 introduziu o suporte API para dispositivos com várias câmeras por meio de um novo dispositivo lógico de câmera composto por dois ou mais dispositivos físicos de câmera apontando na mesma direção. O dispositivo lógico de câmera é exposto como um único CameraDevice / CaptureSession para um aplicativo, permitindo a interação com recursos de várias câmeras integradas a HAL. Os aplicativos podem, opcionalmente, acessar e controlar streams de câmeras físicas subjacentes, metadados e controles.

Suporte multi-câmera

Figura 1. Suporte multi-câmera

Neste diagrama, diferentes IDs de câmera são codificados por cores. O aplicativo pode transmitir buffers raw 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

Dispositivos multi-câmara deve ser anunciado com a capacidade de multi-câmera lógica .

Clientes da câmara podem consultar o ID da câmera dos dispositivos físicos uma câmera lógica especial é feita de chamando getPhysicalCameraIds() . Os IDs retornados como parte do resultado são então usados para controlar dispositivos físicos individualmente através setPhysicalCameraId() . Os resultados de tais pedidos individuais podem ser consultados a partir do resultado completo invocando getPhysicalCameraResults() .

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

Os streams de câmeras físicas são suportados 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 HAL:

Para dispositivos que executam o Android 9, os dispositivos de câmera devem suportar a substituição de um fluxo YUV / RAW lógico por fluxos físicos do mesmo tamanho (não se aplica a fluxos RAW) e o mesmo formato de duas câmeras físicas. Isso não se aplica a dispositivos com Android 10.

Para os dispositivos que executam o Android 10 onde a câmara de HAL versão do dispositivo é 3,5 ou superior, o dispositivo de câmara tem de suportar isStreamCombinationSupported para aplicações a consulta se uma combinação corrente particular contendo fluxos físicas é suportado.

Mapa de configuração de fluxo

Para uma câmera lógico, as combinações de fluxo obrigatórios para o dispositivo da câmera de um certo nível de hardware é o mesmo que o que é necessário em CameraDevice.createCaptureSession . Todos os fluxos no mapa de configuração de fluxo devem ser fluxos lógicos.

Para um dispositivo lógico de câmera compatível com capacidade RAW com subcâmeras físicas de diferentes tamanhos, se um aplicativo configurar um fluxo RAW lógico, o dispositivo lógico de câmera não deve alternar para subcâmeras físicas com diferentes tamanhos de sensores. Isso garante que os aplicativos de captura RAW existentes não quebrem.

Para aproveitar as vantagens do zoom óptico implementado por HAL, alternando entre subcâmeras físicas durante a captura RAW, os aplicativos devem configurar streams de subcâmeras físicas em vez de um stream RAW lógico.

Combinação de fluxo garantida

Tanto a câmera lógico e suas câmeras físicas subjacentes devem garantir as combinações de fluxo obrigatórios exigidos para os seus níveis de dispositivo.

Um dispositivo lógico de câmera deve operar da mesma maneira que um dispositivo físico de câmera com base em seu nível de hardware e recursos. Recomenda-se que seu conjunto de recursos seja um superconjunto de câmeras físicas individuais.

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

  • Substituir um YUV_420_888 lógico ou stream bruto por dois streams 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 streams raw, um de cada câmera física, se a câmera lógica não anunciar capacidade RAW, mas as câmeras físicas subjacentes sim. Isso geralmente ocorre quando as câmeras físicas têm sensores de tamanhos diferentes.

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

Considerações de desempenho e energia

  • Atuação:

    • Configurar e transmitir fluxos físicos pode diminuir a taxa de captura da câmera lógica devido a restrições de recursos.
    • Aplicar as 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 a funcionar no caso padrão.
    • Configurar ou solicitar fluxos físicos pode substituir a otimização de energia interna do HAL e incorrer em mais uso de energia.

Costumização

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

  • A saída fundida do dispositivo lógico de 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 de câmera do Android.
  • Solicitações físicas individuais e resultados podem ser opcionalmente suportados. O conjunto de parâmetros disponíveis em tais solicitações também depende inteiramente da implementação HAL específica.
  • A partir do Android 10, o HAL pode reduzir o número de câmeras que podem ser diretamente abertas por um aplicativo por meio da eleição não anunciar algumas ou todas as PHYSICAL_IDs em getCameraIdList . Chamando getPhysicalCameraCharacteristics deve então retornar as características da câmera física.

Validação

Os dispositivos lógicos com várias câmeras devem passar pelo CTS da câmera como qualquer outra câmera normal. Os casos de teste que têm como alvo este tipo de dispositivo pode ser encontrado na LogicalCameraDeviceTest módulo.

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

Os testes 1 e cena cena 4 correr com o STI-em-um-caixa de equipamento de teste. O test_multi_camera_match teste afirma que o brilho do centro das imagens correspondem quando as duas câmeras são ambos habilitado. O test_multi_camera_alignment teste afirma que espaçamentos câmera, orientações e parâmetros de distorção estão devidamente carregado. Se o sistema multicâmera incluir uma câmera Wide FoV (> 90o), a versão rev2 da caixa ITS é necessária.

Sensor_fusion é um segundo equipamento de teste que permite repetido, movimento telefone prescrito e afirma que a data e hora giroscópio e sensores de imagem corresponder e que os quadros de multi-câmera estão em sincronia.

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

Melhores Práticas

Para aproveitar ao máximo os recursos habilitados por várias câmeras enquanto mantém a compatibilidade do aplicativo, siga estas práticas recomendadas ao implementar um dispositivo lógico de várias câmeras:

  • (Android 10 ou superior) Esconder sub-câmaras físicas de getCameraIdList . Isso reduz o número de câmeras que podem ser abertas diretamente por aplicativos, eliminando a necessidade de aplicativos com lógica de seleção de câmera complexa.
  • (Android 11 ou superior) para um dispositivo multi-câmara lógico apoio zoom óptico, implementar o ANDROID_CONTROL_ZOOM_RATIO API, e uso ANDROID_SCALER_CROP_REGION da razão de aspecto de cultivo única. ANDROID_CONTROL_ZOOM_RATIO permite que o dispositivo para reduzir e manter a melhor precisão. Neste 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 pós-zoom de vista como a matriz activa do sensor. Para mais informações sobre como ANDROID_SCALER_CROP_REGION trabalha em conjunto com ANDROID_CONTROL_ZOOM_RATIO , consulte camera3_crop_reprocess#cropping .
  • Para dispositivos multicâmera com câmeras físicas que possuem recursos diferentes, certifique-se de que o dispositivo anuncia suporte para um determinado valor ou intervalo para um controle apenas se todo o intervalo de zoom suportar o valor ou intervalo. Por exemplo, se a câmera lógica for composta por uma ultra grande, uma ampla e uma teleobjetiva, faça o seguinte:
    • Se os tamanhos de matriz ativa das câmeras físicas são diferentes, o HAL câmera deve fazer o mapeamento de matrizes ativas das câmeras físicas para a câmera lógica conjunto ativo 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 modo 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 teleobjetiva suportam foco automático, mas a câmera ultralarga tem foco fixo, certifique-se de que a câmera lógica anuncie o suporte ao foco automático. O HAL deve simular uma máquina de estado de autofoco para a câmera ultralarga para que, quando o aplicativo se afasta 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 autofoco para os modos AF suportados trabalhar conforme o esperado.
    • Se as câmeras grande e teleobjetiva suportarem 4K @ 60 fps e a câmera ultralarga suportar apenas 4K @ 30 fps ou 1080p @ 60 fps, mas não 4K @ 60 fps, certifique-se de que a câmera lógica não anuncie 4k @ 60 fps em suas configurações de fluxo com suporte. Isso garante a integridade dos recursos de câmera lógicas, garantindo que o aplicativo não vai correr para o problema de não conseguir 4k @ 60 fps em um ANDROID_CONTROL_ZOOM_RATIO valor inferior a 1.
  • A partir do Android 10, uma multicâmera lógica não é necessária para oferecer suporte a combinações de fluxo que incluem fluxos físicos. Se o HAL suporta 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 se originam da mesma câmera física, as limitações de hardware podem forçar o campo de visão do fluxo físico a ser o mesmo que o fluxo lógico.
    • Para lidar com a pressão de memória causada por múltiplos fluxos físicos, certifique-se de aplicativos usar discardFreeBuffers para desalocar os buffers livres (buffers que são liberados pelo consumidor, mas ainda não removidas da fila pelo produtor) se um fluxo físico é esperado para estar inactivo durante um período de tempo.
    • Se fluxos físicos de diferentes câmaras físicas não são tipicamente ligados ao mesmo pedido, certificar-se de aplicações utilizar surface group de modo a que uma fila de tampão é usado para fazer duas superfícies de frente para aplicação, redução do consumo de memória.