Subsistema HAL

Solicitações

O framework do app envia solicitações de resultados capturados ao subsistema da câmera. Uma solicitação corresponde a um conjunto de resultados. Uma solicitação encapsula 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 de RAW para YUV e geração de estatísticas. Isso permite muito mais controle sobre os resultados saída e processamento. Várias solicitações podem estar em andamento ao mesmo tempo, e o envio de solicitações não bloqueia. E as solicitações são sempre processadas a ordem em que são recebidas.

Figura 1. Modelo da câmera

HAL e subsistema da câmera

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

O pipeline da câmera também oferece suporte a gatilhos que o framework do app pode iniciar para ativar recursos como o autofoco. Ele também envia notificações de volta para framework do app, notificando os apps sobre eventos, como um bloqueio de foco automático ou erros.

Figura 2. Pipeline da câmera

Alguns blocos de processamento de imagem mostrados no diagrama acima não são bem definida na versão inicial. O pipeline da câmera faz com que o seguinte ou suposições:

• A saída RAW Bayer não passa por 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 dados brutos do sensor para YUV estão em um ordem arbitrária.
• Embora várias unidades de balança e corte sejam exibidas, todas as unidades do escalonador compartilham o controles de região de saída (zoom digital). No entanto, cada unidade pode ter um resolução de saída e formato de pixel.

Resumo do uso de APIs
Este é um breve resumo das etapas para usar a API Android da câmera. Consulte a Seção de sequência de operações esperada e inicialização para um detalhamento sobre os etapas, incluindo chamadas de API.

1. Detecta e enumera dispositivos de câmera.
2. Abra o dispositivo e conecte os listeners.
3. Configurar saídas para o caso de uso (como capturar, gravar, etc.).
4. Crie solicitações para o caso de uso de destino.
5. Capturar/repetir solicitações e bursts.
6. Recebe metadados de resultados e dados de imagem.
7. Ao trocar de casos de uso, volte à etapa 3.

Resumo da operação de HAL

• As solicitações assíncronas para capturas vêm do framework.
• O dispositivo HAL precisa processar as solicitações nessa ordem. E, para cada solicitação, produza metadados do resultado 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/hora precisam ser idênticos para todas as saídas de uma determinada solicitação, e como usá-los, o framework pode combiná-los se necessário.
• Todas as configurações e estados de captura (exceto as rotinas 3A) são encapsuladas nas solicitações e nos resultados.

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

Inicialização e sequência da 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 a interface HIDL e definições.

Enumerar, abrir dispositivos de câmera e criar uma sessão ativa

1. Após a inicialização, o framework começa a detectar qualquer presente provedores de câmeras que implementam interface ICameraProvider. Se o provedor ou provedores estiverem presentes, o framework tentará estabelecer uma conexão.
2. O framework enumera os dispositivos de câmera usando ICameraProvider::getCameraIdList():
3. O framework instancia um novo ICameraDevice chamando os respectivos ICameraProvider::getCameraDeviceInterface_VX_X().
4. O framework chama ICameraDevice::open() para criar um novo sessão de captura ativa ICameraDeviceSession.

Usar uma sessão de câmera ativa

1. O framework chama ICameraDeviceSession::configureStreams() com uma lista de streams de entrada/saída para o dispositivo HAL.
2. O framework solicita configurações padrão para alguns casos de uso com chamadas para ICameraDeviceSession::constructDefaultRequestSettings(). Isso pode ocorrer a qualquer momento depois que ICameraDeviceSession for criado por ICameraDevice::open.
3. O framework constrói e envia a primeira solicitação de captura à HAL com com base em um dos conjuntos de configurações padrão e com pelo menos um de saída que foi registrado anteriormente pelo framework. Isto é enviado à HAL com ICameraDeviceSession::processCaptureRequest(). A HAL precisa bloquear o retorno dessa chamada até que esteja pronta para a próxima solicitação seja enviada.
4. O framework continua a enviar solicitações e chamadas. ICameraDeviceSession::constructDefaultRequestSettings() para receber de configuração 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 o captura), a HAL chama ICameraDeviceCallback::notify() com a mensagem do SHUTTER, incluindo o número do frame e o carimbo de data/hora do início de exposição. Esse callback de notificação não precisa acontecer antes da primeira chamada processCaptureResult() para uma solicitação, mas nenhum resultado foi entregue a um aplicativo para uma captura até depois O notify() para essa captura é chamado.
6. Após algum atraso no pipeline, a HAL começa a retornar capturas concluídas para o framework com ICameraDeviceCallback::processCaptureResult(). Eles são retornados na mesma ordem em que as solicitações foram enviadas. Vários status podem estar em trânsito de uma só vez, dependendo da profundidade do pipeline do dispositivo HAL da câmera.

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

• O framework pode parar de enviar novas solicitações, aguardar as capturas existentes para serem concluídas (todos os buffers preenchidos, todos os resultados retornado) e, em seguida, chame ICameraDeviceSession::configureStreams() de novo. Isso redefine o hardware e o pipeline da câmera para um novo conjunto de streams de entrada/saída. Alguns streams podem ser reutilizados da transmissão anterior, configuração do Terraform. Em seguida, o framework continua da primeira solicitação de captura à HAL, se pelo menos um o stream de saída registrado permanece. Caso contrário, ICameraDeviceSession::configureStreams() é obrigatório primeiro.
• O framework pode chamar ICameraDeviceSession::close() para encerrar a sessão da câmera. Ele pode ser chamado a qualquer momento da estrutura estão ativos, embora a chamada possa ser bloqueada até que as capturas em trânsito foram concluídas (todos os resultados foram retornados, todos os buffers preenchida). Depois que a chamada close() é retornada, não há mais chamadas para ICameraDeviceCallback são permitidas a partir da HAL. Quando o close() está em andamento, o framework não pode chamar nenhuma outra Funções do dispositivo HAL.
• No caso de um erro ou outro evento assíncrono, a HAL deve chamar ICameraDeviceCallback::notify() com os parâmetros apropriados mensagem de erro/evento. Depois de retornar de uma notificação de erro fatal em todo o dispositivo, a HAL precisa agir como se close() tivesse sido chamado. No entanto, a HAL precisa cancelar ou conclua todas as capturas pendentes antes de chamar notify(), para que, uma vez notify() for chamado com um erro fatal, o framework não e receber mais callbacks do dispositivo. Outros métodos close() vai retornar -ENODEV ou NULL depois que o método notify() retorna de um erro fatal mensagem de erro.

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 do recursos. Para mais informações, consulte nível de hardware com suporte.

Interação entre a solicitação de captura do app, 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 pelas rotinas de controle dos 3A. Por exemplo, quando a exposição automática é ativo, o tempo de exposição, a duração do frame e os parâmetros de sensibilidade do são controlados pelo algoritmo 3A da plataforma e todos os valores especificados são ignorados. Os valores escolhidos para o frame pelas rotinas 3A precisam ser informados nos metadados de saída. A tabela a seguir descreve os diferentes modos 3Um bloco de controle e as propriedades controladas por esses modos. Consulte o platform/system/media/camera/docs/docs.html para definições dessas propriedades.

Todos os controles no bloco "Processamento de imagem" na Figura 2 operam em uma e geralmente cada bloco tem três modos:

• DESATIVADO: o bloco de processamento está desativado. Os desmossaicos, correção de cor e os blocos de ajuste de curva de tom não podem ser desativados.
• RÁPIDO: nesse modo, o bloco de processamento pode não desacelerar o frame de saída em comparação com o modo DESATIVADO, mas, caso contrário, deverá produzir a melhor saída, é possível devido a essa restrição. Normalmente, isso é usado para modos de visualização ou gravação de vídeo, ou a captura em sequência para imagens estáticas. Em alguns dispositivos, isso pode ser equivalente ao modo DESATIVADO (nenhum processamento pode ser feito sem desacelerando o frame rate). Em alguns dispositivos, isso pode ser equivalente a Modo HIGH_QUALITY (a melhor qualidade ainda não diminui o frame rate).
• HIGH_QUALITY: neste modo, o bloco de processamento deve produzir a melhor melhor resultado de qualidade possível, diminuindo a taxa de quadros conforme necessário. Normalmente, isso é usado para capturas estáticas de alta qualidade. Alguns blocos incluir um controle manual que pode ser selecionado em vez de FAST ou ALTA_QUALIDADE. Por exemplo, o bloco de correção de cor oferece suporte a uma matriz de transformação, enquanto o ajuste da curva de tom oferece suporte a uma ou curva de mapeamento de tons.

O frame rate máximo que pode ser suportado por um subsistema de câmera é uma função de muitos fatores:

• Resoluções solicitadas de streams de imagem de saída
• Disponibilidade de modos de agrupamento por classes/ignorando no gerador de imagens
• A largura de banda da interface do imager
• A largura de banda dos vários blocos de processamento de ISP

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

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