Subsistema HAL

solicitações de

A estrutura do aplicativo emite solicitações de resultados capturados para o subsistema da câmera. Uma solicitação corresponde a um conjunto de resultados. Uma solicitação encapsula todas as informações de configuração sobre a captura e o processamento desses resultados. Isso inclui coisas como resolução e formato de pixel; sensor manual, lente e controle de flash; Modos de operação 3A; Controle de processamento RAW para YUV; e geração de estatísticas. Isso permite muito mais controle sobre a saída e o processamento dos resultados. Várias solicitações podem estar em andamento ao mesmo tempo e o envio de solicitações não é bloqueador. E as solicitações são sempre processadas na ordem em que são recebidas.

Figura 1. Modelo de câmera

O HAL e o subsistema de câmera

O subsistema de câmera inclui implementações de componentes no pipeline da câmera, como o algoritmo 3A e controles de processamento. A câmera HAL fornece interfaces para você implementar suas versões desses componentes. Para manter a compatibilidade entre plataformas entre vários fabricantes de dispositivos e fornecedores de processadores de sinal de imagem (ISP ou sensor de câmera), o modelo de pipeline de câmera é virtual e não corresponde diretamente a nenhum ISP real. No entanto, é semelhante o suficiente aos pipelines de processamento reais para que você possa mapeá-los para o seu hardware com eficiência. Além disso, é abstrato o suficiente para permitir vários algoritmos e ordens de operação diferentes sem comprometer a qualidade, a eficiência ou a compatibilidade entre dispositivos.

O pipeline da câmera também oferece suporte a gatilhos que a estrutura do aplicativo pode iniciar para ativar coisas como o foco automático. Ele também envia notificações de volta à estrutura do aplicativo, notificando os aplicativos sobre eventos como bloqueio de foco automático ou erros.

Figura 2. Pipeline da câmera

Observe que alguns blocos de processamento de imagem mostrados no diagrama acima não estão bem definidos na versão inicial. O pipeline da câmera faz as seguintes suposições:

• A saída RAW Bayer não sofre processamento dentro do ISP.
• As estatísticas são geradas com base nos dados brutos do sensor.
• Os vários blocos de processamento que convertem os dados brutos do sensor em YUV estão em ordem arbitrária.
• Embora múltiplas unidades de escala e corte sejam mostradas, todas as unidades do escalador compartilham os controles da região de saída (zoom digital). No entanto, cada unidade pode ter uma resolução de saída e formato de pixel diferentes.

Resumo do uso da API
Este é um breve resumo das etapas para usar a API da câmera Android. Consulte a seção Sequência de inicialização e operação esperada para obter uma análise detalhada dessas etapas, incluindo chamadas de API.

1. Ouça e enumere dispositivos de câmera.
2. Abra o dispositivo e conecte os ouvintes.
3. Configure saídas para o caso de uso de destino (como captura de imagens estáticas, gravação, etc.).
4. Crie solicitações para o caso de uso de destino.
5. Capturar/repetir solicitações e rajadas.
6. Receba metadados de resultados e dados de imagem.
7. Ao mudar de caso de uso, retorne à etapa 3.

Resumo da operação HAL

• As solicitações assíncronas de capturas vêm da estrutura.
• O dispositivo HAL deve processar as solicitações em ordem. E para cada solicitação, produza metadados de resultados de saída e um ou mais buffers de imagem de saída.
• Primeiro a entrar, primeiro a sair para solicitações e resultados e para fluxos referenciados por solicitações subsequentes.
• Os carimbos de data e hora devem ser idênticos para todas as saídas de uma determinada solicitação, para que a estrutura possa combiná-las, se necessário.
• Toda configuração e estado de captura (exceto as rotinas 3A) são encapsulados nas solicitações e resultados.

Figura 3. Visão geral do HAL da câmera

Sequência de inicialização e operação esperada

Esta seção contém uma explicação detalhada das etapas esperadas ao usar a API da câmera. Consulte platform/hardware/interfaces/camera/ para definições de interface HIDL.

Enumerando, abrindo dispositivos de câmera e criando uma sessão ativa

1. Após a inicialização, a estrutura começa a escutar quaisquer provedores de câmera presentes que implementem a interface ICameraProvider . Se tal provedor ou provedores estiverem presentes, a estrutura tentará estabelecer uma conexão.
2. A estrutura enumera os dispositivos de câmera por meio de ICameraProvider::getCameraIdList() .
3. A estrutura instancia um novo ICameraDevice chamando o respectivo ICameraProvider::getCameraDeviceInterface_VX_X() .
4. A estrutura chama ICameraDevice::open() para criar uma nova sessão de captura ativa ICameraDeviceSession.

Usando uma sessão de câmera ativa

1. A estrutura chama ICameraDeviceSession::configureStreams() com uma lista de fluxos de entrada/saída para o dispositivo HAL.
2. A estrutura solicita configurações padrão para alguns casos de uso com chamadas para ICameraDeviceSession::constructDefaultRequestSettings() . Isso pode ocorrer a qualquer momento após a criação de ICameraDeviceSession por ICameraDevice::open .
3. A estrutura constrói e envia a primeira solicitação de captura para o HAL com configurações baseadas em um dos conjuntos de configurações padrão e com pelo menos um fluxo de saída que foi registrado anteriormente pela estrutura. Isso é enviado para o HAL com ICameraDeviceSession::processCaptureRequest() . O HAL deve bloquear o retorno desta chamada até que esteja pronto para o envio da próxima solicitação.
4. A estrutura continua a enviar solicitações e chamadas ICameraDeviceSession::constructDefaultRequestSettings() para obter buffers de configurações padrão para outros casos de uso, conforme necessário.
5. Quando a captura de uma solicitação começa (o sensor começa a expor para a captura), o HAL chama ICameraDeviceCallback::notify() com a mensagem SHUTTER, incluindo o número do quadro e o timestamp para início da exposição. Esse retorno de chamada de notificação não precisa acontecer antes da primeira chamada processCaptureResult() para uma solicitação, mas nenhum resultado é entregue a um aplicativo para uma captura até que notify() para essa captura seja chamada.
6. Após algum atraso no pipeline, o HAL começa a retornar capturas concluídas para a estrutura com ICameraDeviceCallback::processCaptureResult() . Eles são retornados na mesma ordem em que as solicitações foram enviadas. Várias solicitações podem estar em andamento ao mesmo tempo, dependendo da profundidade do pipeline do dispositivo HAL da câmera.

Depois de algum tempo, ocorrerá uma das seguintes situações:

• A estrutura pode parar de enviar novas solicitações, aguardar a conclusão das capturas existentes (todos os buffers preenchidos, todos os resultados retornados) e, em seguida, chamar ICameraDeviceSession::configureStreams() novamente. Isso redefine o hardware e o pipeline da câmera para um novo conjunto de fluxos de entrada/saída. Alguns fluxos podem ser reutilizados da configuração anterior. A estrutura então continua desde a primeira solicitação de captura até o HAL, se pelo menos um fluxo de saída registrado permanecer. (Caso contrário, ICameraDeviceSession::configureStreams() será necessário primeiro.)
• A estrutura pode chamar ICameraDeviceSession::close() para encerrar a sessão da câmera. Isso pode ser chamado a qualquer momento quando nenhuma outra chamada da estrutura estiver ativa, embora a chamada possa ser bloqueada até que todas as capturas em andamento sejam concluídas (todos os resultados retornados, todos os buffers preenchidos). Após o retorno da chamada close() , nenhuma outra chamada para ICameraDeviceCallback será permitida no HAL. Depois que a chamada close() estiver em andamento, a estrutura não poderá chamar nenhuma outra função do dispositivo HAL.
• No caso de um erro ou outro evento assíncrono, o HAL deve chamar ICameraDeviceCallback::notify() com a mensagem de erro/evento apropriada. Depois de retornar de uma notificação de erro fatal em todo o dispositivo, o HAL deve agir como se close() tivesse sido chamado. No entanto, o HAL deve cancelar ou concluir todas as capturas pendentes antes de chamar notify() , de modo que, quando notify() for chamado com um erro fatal, a estrutura não receberá mais retornos de chamada do dispositivo. Métodos além de close() devem retornar -ENODEV ou NULL após o método notify() retornar de uma mensagem de erro fatal.

Figura 4. Fluxo operacional da câmera

Níveis de hardware

Os dispositivos de câmera podem implementar vários níveis de hardware dependendo de suas capacidades. Para obter mais informações, consulte nível de hardware compatível .

Interação entre a solicitação de captura do aplicativo, o controle 3A e o pipeline de processamento

Dependendo das configurações no bloco de controle 3A, o pipeline da câmera ignora alguns dos parâmetros na solicitação de captura do aplicativo e usa os valores fornecidos pelas rotinas de controle 3A. Por exemplo, quando a exposição automática está ativa, o tempo de exposição, a duração do quadro e os parâmetros de sensibilidade do sensor são controlados pelo algoritmo da plataforma 3A e quaisquer valores especificados pelo aplicativo são ignorados. Os valores escolhidos para o quadro pelas rotinas 3A devem ser informados nos metadados de saída. A tabela a seguir descreve os diferentes modos do bloco de controle 3A e as propriedades controladas por esses modos. Consulte o arquivo platform/system/media/camera/docs/docs.html para obter definições dessas propriedades.

Todos os controles no bloco de processamento de imagem na Figura 2 operam com um princípio semelhante e, geralmente, cada bloco possui três modos:

• OFF: Este bloco de processamento está desabilitado. Os blocos de demonstração, correção de cores e ajuste da curva de tons não podem ser desativados.
• RÁPIDO: Neste modo, o bloco de processamento pode não diminuir a taxa de quadros de saída em comparação com o modo OFF, mas deve produzir a saída da melhor qualidade possível, dada essa restrição. Normalmente, isso seria usado para modos de visualização ou gravação de vídeo, ou captura contínua para imagens estáticas. Em alguns dispositivos, isso pode ser equivalente ao modo OFF (nenhum processamento pode ser feito sem diminuir a taxa de quadros) e, em alguns dispositivos, pode ser equivalente ao modo HIGH_QUALITY (a melhor qualidade ainda não diminui a taxa de quadros).
• HIGH_QUALITY: Neste modo, o bloco de processamento deve produzir o resultado da melhor qualidade possível, diminuindo a taxa de quadros de saída conforme necessário. Normalmente, isso seria usado para captura de imagens estáticas de alta qualidade. Alguns blocos incluem um controle manual que pode ser selecionado opcionalmente em vez de FAST ou HIGH_QUALITY. Por exemplo, o bloco de correção de cores suporta uma matriz de transformação de cores, enquanto o ajuste da curva de tons suporta uma curva de mapeamento de tons global arbitrária.

A taxa máxima de quadros que pode ser suportada por um subsistema de câmera é função de vários fatores:

• Resoluções solicitadas de fluxos de imagens de saída
• Disponibilidade de modos binning/skipping no gerador de imagens
• A largura de banda da interface do gerador de imagens
• A largura de banda dos vários blocos de processamento do ISP

Como esses fatores podem variar muito entre diferentes ISPs e sensores, a interface HAL da câmera tenta abstrair as restrições de largura de banda em um modelo o mais simples possível. O modelo apresentado possui as seguintes características:

• O sensor de imagem é sempre configurado para gerar a menor resolução possível, considerando os tamanhos de fluxo de saída solicitados pelo aplicativo. A menor resolução é definida como sendo pelo menos tão grande quanto o maior tamanho do fluxo de saída solicitado.
• Como qualquer solicitação pode usar qualquer um ou todos os fluxos de saída atualmente configurados, o sensor e o ISP devem ser configurados para suportar o escalonamento de uma única captura para todos os fluxos ao mesmo tempo.
• Os fluxos JPEG agem como fluxos YUV processados ​​para solicitações nas quais não estão incluídos; em solicitações nas quais são referenciados diretamente, eles atuam como fluxos JPEG.
• O processador JPEG pode ser executado simultaneamente com o restante do pipeline da câmera, mas não pode processar mais de uma captura por vez.