Notas de lançamento do conjunto de testes de imagem de câmera do Android 11

Esta página resume as alterações no Camera Image Test Suite (ITS) no Android 11. As alterações se enquadram nas seguintes categorias:

• Alterações de hardware
• Testes OBRIGATÓRIOS de primeiro nível de API
• Teste de iluminação validado
• Mudanças no nome da cena
• Teste alterações e adições
• Testes de câmera LIMITADOS aumentados

Alterações de hardware

O Android 11 apresenta várias alterações de hardware para reduzir custos e aumentar a disponibilidade. Essas mudanças se enquadram nas seguintes categorias:

• Fabricante adicional
• Métodos de fabricação unificados
• Maiores opções de tablet
• Abertura reduzida do tablet
• Novo controlador de fusão de sensores

Fabricante adicional

A Rahi Systems está qualificada para produzir gabinetes de teste ITS além do nosso fornecedor existente, o projeto MYWAY. As informações da empresa para fornecedores qualificados são as seguintes:

• Rahi Systems Inc.
  48303 Fremont Blvd, Fremont CA 94538, EUA
  rahisystems.com/products/android-device-testing-equipment/
  androidpartner@rahisystems.com
  +1-510-319-3802

• Projeto MYWAY
  4F., No. 163, Fu-Ying Road, XinZhuang District, New Taipei City, Taiwan
  twmyway. com
  vendas@myway.tw
  +886-2-29089060

Métodos de fabricação unificados

O gabinete de teste ITS-in-a-box de campo de visão regular rev1 (RFoV) foi reprojetado para usar os métodos de fabricação em uso pelos gabinetes de teste de caixa de campo de visão amplo (WFoV) e caixa de fusão de sensor . A funcionalidade é idêntica e, para simplificar, o design é chamado de rev1a . O redesenho permite que os fabricantes armazenem um único tipo de plástico para fabricar todos os gabinetes de teste. Além disso, a montagem do tablet e os suportes de luz foram redesenhados para lidar com uma maior variação de tablets e barras de luz LED.

Para baixar as descrições e desenhos mecânicos mais recentes, consulte caixa RFoV (rev1a) e caixa WFoV (rev2.9) .

Maiores opções de tablet

Tablets incluindo o Samsung Galaxy Tab A 10.1 e o Chuwi Hi9 Air 10.1 são adicionados à lista de tablets recomendados. É importante que o tablet não tenha modulação por largura de pulso (PWM) para ajustar o brilho da tela e eliminar faixas nas imagens capturadas.

Para obter as informações mais recentes sobre tablets recomendados, consulte Requisitos do tablet .

Abertura reduzida do tablet

Para permitir o uso do Galaxy Tab A 10.1, a abertura do tablet é ligeiramente reduzida em altura para os gabinetes de teste RFoV (rev1a) e WFoV (rev2). As revisões que refletem essas mudanças são rev1a.1 e rev2.9. Para estes desenhos, veja caixa RFoV (rev1a) e caixa WFoV (rev2.9) .

Novo controlador de fusão de sensores

O hardware do controlador de fusão do sensor foi redesenhado para melhorar a capacidade de fabricação. O novo controlador é baseado em Arduino , com um escudo de placa de roteamento personalizado que é montado na parte superior do Arduino. A Figura 1 mostra a blindagem e a figura 2 mostra o desenho mecânico do gabinete. O novo controlador é alimentado por uma única fonte de 5 V que alimenta o motor diretamente. A eletrônica é controlada completamente através do conector USB. A fonte de alimentação separada permite o isolamento completo entre a eletrônica de controle e o servo motor. Além disso, um único controlador pode controlar até seis servomotores.

Figura 1. Vista superior do shield Arduino

Figura 2. Projeto do gabinete

O Android 11 é compatível com os controladores existentes. Para invocar o teste com o controlador baseado em Arduino, use:

python tools/run_all_tests.py device=# camera=# rot_rig=arduino:1 scenes=sensor_fusion

Primeiro nível da API

No Android 10, os testes ITS são designados como MANDATED e NOT_YET_MANDATED . Para iniciar como um dispositivo Android 10, todos os testes MANDATED devem ser aprovados. Os testes NOT_YET_MANDATED podem falhar, mas são tabulados como PASS para relatórios do verificador CTS. O requisito de testes MANDATED também se aplica a dispositivos atualizados. Esse requisito para que os dispositivos atualizados sejam aprovados em todos os testes MANDATED fez com que os testes demorassem para se tornarem testes MANDATED porque os dispositivos mais antigos também devem passar nos testes.

No Android 11, os testes MANDATED são controlados pelo primeiro sinalizador de nível de API das propriedades do telefone. Para dispositivos que atualizam para o Android 11, os testes são executados como testes NOT_YET_MANDATED , o que significa que um teste pode falhar, mas ser tabulado como PASS em CtsVerifier.apk .

Por exemplo:

• No Android 11, o teste test_channel_saturation é MANDATED para dispositivos com um primeiro nível de API maior que 29.
• No Android 10, o teste test_channel_saturation é MANDATED para todos os dispositivos.

Validando a iluminação da cena

No Android 11, a iluminação da cena é validada analisando o brilho nos cantos da cena. Todas as cenas manuais são validadas para iluminação e as cenas baseadas em tablet são validadas para câmeras RFoV no equipamento de teste RFoV e câmeras WFoV no equipamento de teste WFoV. Se os níveis de iluminação forem inadequados, um erro será relatado e o teste falhará.

Mudanças no nome da cena

No Android 10, a cena 1 representa a maioria dos testes e uma grande porcentagem do tempo total de teste. Se algum teste na cena 1 falhar, a cena inteira deve ser executada novamente. Por design, executar novamente toda a cena reduz a passagem de testes marginais. No Android 11, os tempos de reexecução são reduzidos dividindo a cena 1 em duas cenas, scene1_1 e scene1_2.

A tabela a seguir mostra os tempos de teste tabulados para a câmera traseira do Pixel 4 para diferentes cenas. O número de testes é dividido para igualar o tempo de teste, não para igualar o número de testes.

Além disso, há uma limpeza de nome. A cena 2 é dividida com letras e a cena 1 é dividida com números. A nomenclatura para as diferentes extensões é:

• Cenas com o mesmo gráfico, mas testes diferentes: *_1,2,3
• Cenas com gráficos diferentes, mas os mesmos testes: *_a,b,c

Alterações de teste

Testes atualizados para usar o primeiro nível de API

No Android 11, os testes na tabela a seguir são atualizados para usar o primeiro sinalizador de nível de API. Todos esses testes usam um primeiro nível de API de 29, exceto o teste test_tonemap_curve , que usa um primeiro nível de API de 30.

Testes com alterações

Os testes na tabela a seguir são atualizados no Android 11. As alterações são descritas na coluna Descrição das alterações .

Novos testes

Os testes na tabela a seguir estão ativados no Android 11. Os testes são resumidos na tabela e as descrições detalhadas são fornecidas nas seções a seguir.

scene0/test_vibration_restriction

Este teste não requer uma cena específica, mas o dispositivo sob teste (DUT) deve ser colocado ou montado em uma superfície dura. Isso inclui a montagem nos gabinetes de teste ITS-in-a-box.

Declarações

• Sem vibrações durante o uso da câmera

scene2_a/test_jpeg_quality

Método

Diferentes partes do arquivo JPEG são definidas por marcadores de 2 bytes. Para obter mais informações, consulte JPEG .

O teste extrai as matrizes de quantização da captura JPEG. O marcador para as matrizes de quantização na captura JPEG é a sequência [255, 219]. Quando o marcador é encontrado, os próximos dois itens da lista são o tamanho. O marcador de tamanho JPEG DQT geralmente é [0, 132] = 256*0+132 = 132, que representa o tamanho dos dados DQT na captura JPEG. Os dados incorporados são da forma: [255, 219, 0, 132, 0 (marcador de luma), matriz de luma 8x8, 1 (marcador de croma), matriz de croma 8x8].

O 0 para o marcador de matriz de luma e 1 para o marcador de croma parecem consistentes para vários dispositivos, incluindo telefones que separam as duas matrizes em seções DQT separadas no arquivo JPEG. As matrizes de Luma tendem a ter uma variedade maior de valores em comparação com as matrizes de croma, pois o olho humano é mais sensível à luma do que às imagens de croma e JPEG levam isso em consideração.

As matrizes de luma e croma extraídas de amostra são mostradas abaixo para fatores de qualidade de 85 e 25 para a câmera traseira do Pixel 4 capturando a cena2_a com o equipamento de teste ITS. Os valores da matriz aumentam (indicando maior compressão) substancialmente para a configuração de qualidade mais baixa. Essas matrizes só são impressas com o script se o sinalizador debug=True for aplicado. Observe a maior variação nas entradas nas matrizes de luma em comparação com as matrizes de croma.

    luma matrix (quality = 85)    chroma matrix (quality = 85)

    [[ 5  3  4  4  4  3  5  4]    [[ 5  5  5  7  6  7 14  8]
     [ 4  4  5  5  5  6  7 12]     [ 8 14 30 20 17 20 30 30]
     [ 8  7  7  7  7 15 11 11]     [30 30 30 30 30 30 30 30]
     [ 9 12 17 15 18 18 17 15]     [30 30 30 30 30 30 30 30]
     [17 17 19 22 28 23 19 20]     [30 30 30 30 30 30 30 30]
     [26 21 17 17 24 33 24 26]     [30 30 30 30 30 30 30 30]
     [29 29 31 31 31 19 23 34]     [30 30 30 30 30 30 30 30]
     [36 34 30 36 28 30 31 30]]     [30 30 30 30 30 30 30 30]]

    luma matrix (quality = 25)            chroma matrix (quality = 25)

    [[ 32  22  24  28  24  20  32  28]    [[ 34  36  36  48  42  48  94  52]
     [ 26  28  36  34  32  38  48  80]     [ 52  94 198 132 112 132 198 198]
     [ 52  48  44  44  48  98  70  74]     [198 198 198 198 198 198 198 198]
     [ 58  80 116 102 122 120 114 102]     [198 198 198 198 198 198 198 198]
     [112 110 128 144 184 156 128 136]     [198 198 198 198 198 198 198 198]
     [174 138 110 112 160 218 162 174]     [198 198 198 198 198 198 198 198]
     [190 196 206 208 206 124 154 226]     [198 198 198 198 198 198 198 198]
     [242 224 200 240 184 202 206 198]]     [198 198 198 198 198 198 198 198]]

A Figura 3 mostra os valores médios da matriz para a câmera traseira do Pixel 4 versus a qualidade JPEG. À medida que a qualidade JPEG aumenta, o nível de compactação (média da matriz DQT de lumina/croma) diminui.

Figura 3. Médias da matriz luma/chroma DQT da câmera traseira do Pixel 4 versus qualidade JPEG

Declarações

• Para [25, 45, 65, 86], +20 em qualidade tem 20% de redução nas médias da matriz de quantização.
• As cargas úteis da matriz DQT são números quadrados.

A Figura 4 mostra um exemplo de um telefone que falha no teste. Observe que para imagens de qualidade muito baixa ( jpeg.quality < 50 ), não há aumento na compressão na matriz de quantização.

Figura 4. Exemplo de teste com falha

scene2_d/e test_num_faces

Duas novas cenas de detecção de rosto são adicionadas para aumentar a diversidade facial das verificações do algoritmo de detecção de rosto. Com testes repetidos de várias câmeras, espera-se que o rosto mais desafiador seja o rosto mais à esquerda na cena2_d. Em particular, há um chapéu e uma barba no modelo, algo novo nas cenas de rosto. As novas cenas são mostradas nas figuras 5 e 6.

Figura 5. cena2_d

Figura 6. cena2_e

Declarações

• num_faces == 3

scene2_e/test_continuous_picture

Método

O teste test_continuous_picture faz uso de scene2_e, mas pode ser ativado com qualquer uma das cenas de rostos. Neste teste, 50 quadros de resolução VGA são capturados com a solicitação de captura primeiro configurando android.control.afMode = 4 (CONTINUOUS_PICTURE) .

Espera-se que o sistema 3A tenha se estabelecido no final de uma captura de 50 quadros.

Declarações

• 3A está em estado convergente no final da captura.

scene_change/test_scene_change

Método

Um novo teste é habilitado para testar se o sinalizador android.control.afSceneChange é afirmado com uma mudança de cena. A mudança de cena faz uso do tablet exibindo uma cena de rosto e, em seguida, ligando e desligando o tablet para criar uma mudança de cena. A cena reutiliza scene2_e, mas está em uma cena separada devido ao controle de tablet necessário.

Além disso, para testes manuais, a mudança de cena pode ser realizada acenando com a mão na frente da câmera.

A Figura 7 mostra um diagrama de tempo do teste. O tempo entre o desligamento da tela e a captura é ajustado com base nos resultados de eventos de capturas anteriores.

Figura 7. Diagrama de tempo para test_scene_change

Condições de mudança:

• Se houver uma mudança de cena e afSceneChange == 1 , o teste retornará PASS .
• Se houver uma mudança de cena e afSceneChange == 0 , a mudança de cena mudará 5 quadros antes para dar mais tempo para afSceneChange ser afirmado.
• Se não houver mudança de cena e afSceneChange == 1 , o teste retornará FAIL .
• Se não houver mudança de cena e afSceneChange == 0 , a mudança de cena muda 30 quadros antes para obter a mudança de cena na captura.

Declarações

• A tela (cena) alterna.
• O sinalizador afSceneChange está em [0, 1].
• Se nenhuma mudança de cena, 3A converge (funcionalmente idêntico a test_continuous_picture ).
• Se afSceneChange == 1 , o brilho deve mudar na cena.
• PASS dentro de seis tentativas com tempo alterado com base em resultados anteriores.

scene6/test_zoom

Método

Uma nova cena é necessária para testar android.control.zoomRatioRange , pois as cenas estabelecidas não têm um recurso pequeno o suficiente para serem ampliadas (cenas [1, 2, 4]) ou a cena tem muitos objetos que não são facilmente identificados , complicando a extração de recursos (cena 3).

A Figura 8 mostra a nova cena com um arranjo regular de círculos. A matriz de círculos afrouxa os requisitos de centralização do DUT/gráfico e permite um círculo sempre próximo ao centro da imagem capturada. Nesta cena, um conjunto de círculos 9x5 com uma borda preta cobre todo o tablet. Um círculo é substituído por um quadrado no canto superior direito para mostrar a orientação. Os tamanhos dos círculos têm um recurso com uma área de cerca de 7500 pixels ( radius=50pixels ) para um sensor de 4000x3000 capturado com um campo de visão (FoV) de cerca de 80 graus.

Figura 8. cena test_zoom

Figura 9. Pixel 4 cam[0] zoom = [1, 3,33, 5,67, 8] imagens com círculo encontrado

A Figura 9 mostra as imagens capturadas para a câmera traseira de um Pixel 4 à medida que o zoom aumenta de 1 a 8x em quatro etapas. Esse conjunto de imagens é capturado sem nenhum cuidado específico na centralização, exceto pelo uso da abertura de teste do telefone com duas aberturas para permitir o teste das câmeras frontal e traseira. Um deslocamento do centro é esperado e é observado quando a mesa gráfica está ligeiramente à esquerda do centro. Além disso, o gráfico parece suficiente para testar com taxas de zoom superiores a 8x.

Encontrando círculos

O teste inclui um método find_circle() usando findContours que encontra todos os contornos e restringe a pesquisa de contornos aos círculos desejados testando o seguinte:

• Os contornos devem ter uma área maior que 10 pixels.
• Os contornos devem ter NUM_PTS >= 15 .
• Os contornos devem ter centros pretos.
• Os contornos devem se assemelhar a um círculo, ou seja, sua área é próxima à área pi*r2 do contorno.

Faixa de teste

android.control.zoomRatioRange é dividido em 10 etapas.

• [1, 7] testes [1, 1,67, 2,33, 3, 3,67, 4,33, 5, 5,67, 6,33, 7]

O zoom é interrompido se o círculo encontrado tocar os limites da imagem. Há uma verificação para garantir que um nível de zoom suficiente seja alcançado no teste (10x).

Declarações

• Pelo menos um círculo é encontrado em cada configuração de zoom.
• 10x ou máximo de android.control.zoomRatioRange é testado.
• O raio do círculo é dimensionado com zoom (RTOL 10% do esperado).
• Deslocamento do centro do círculo das escalas centrais com zoom (RTOL 10% do esperado).
• Nível de zoom suficiente é alcançado (2x).

Testes de câmera LIMITADOS aumentados

No Android 11, os testes na tabela a seguir testam câmeras LIMITED . Além dos novos testes , o teste scene4/test_aspect_ratio_and_crop é atualizado para permitir o teste de dispositivos LIMITED com um primeiro nível de API de 30 ou superior.

A Figura 10 mostra o anel decodificador secreto ITS do Android 11. O anel decodificador secreto mostra por quais configurações de teste os testes individuais são controlados. O gating é codificado por cores para simplificar a visualização. Os principais itens do portão são:

• MANUAL_SENSOR
• READ_3A *requer MANUAL SENSOR
• COMPUTE_TARGET_EXPOSURES *requer MANUAL SENSOR
• PER_FRAME_CONTROL
• RAW
• SENSORS * REALTIME
• MULTI_CAMERA

MANUAL SENSOR , READ_3A , COMPUTE_TARGET_EXPOSURES e PER_FRAME_CONTROL a maioria dos testes. Além disso, os testes habilitados para dispositivos LIMITED são destacados em verde claro.

Figura 10. Anel decodificador secreto do Android 11