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:

Mudanças de hardware

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

Fabricante adicional

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

Métodos de fabricação unificados

O gabinete de teste ITS-in-a-box rev1 de campo de visão regular (RFoV) foi reprojetado para usar os métodos de fabricação usados ​​pelos gabinetes de teste de caixa de campo de visão amplo (WFoV) e caixa de fusão de sensores . A funcionalidade é idêntica e, para simplificar, o design é denominado rev1a . O redesenho permite que os fabricantes armazenem um único tipo de plástico para fabricar todos os gabinetes de teste. Além disso, o suporte para tablet e os suportes de luz foram reprojetados para lidar com maior variação em 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) .

Mais opções de tablets

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 possua 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 altura da abertura do tablet foi ligeiramente reduzida 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 esses desenhos, consulte caixa RFoV (rev1a) e caixa WFoV (rev2.9) .

Novo controlador de fusão de sensores

O hardware do controlador de fusão de sensores foi reprojetado para melhorar a capacidade de fabricação. O novo controlador é baseado em Arduino , com uma placa de roteamento personalizada que é montada 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.

Vista superior do Arduino

Figura 1. Vista superior do escudo Arduino

Projeto do gabinete

Figura 2. Projeto do gabinete

O Android 11 é compatível com versões anteriores dos controladores existentes. Para invocar testes 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 de API

No Android 10, os testes ITS são designados como MANDATED e NOT_YET_MANDATED . Para lançar 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. Este requisito para que dispositivos atualizados passassem em todos os testes MANDATED fez com que os testes demorassem a se tornar testes MANDATED porque os dispositivos mais antigos também devem passar nos testes.

No Android 11, os testes MANDATED são controlados pela primeira sinalização de nível de API nas propriedades do telefone. Para dispositivos atualizados 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 superior a 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 do teste. Se algum teste na cena 1 falhar, toda a cena deverá ser executada novamente. Por definição, a repetição de toda a cena reduz a aprovação em testes marginais. No Android 11, os tempos de repetição são reduzidos dividindo a cena 1 em duas cenas, cena1_1 e cena1_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 equalizar o tempo do teste, não para equalizar 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 mesmos testes: *_a,b,c
Cena Número de testes Tempo de execução do Pixel 4 (min:seg)
0 11 1:12
1_1 22 5:12
1_2 13 5:20
2_a 5 3:22
2_b 1 0:24
2_c 1 0:24
3 6 2:04
4 2 2:46

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 a primeira sinalização de nível de API. Todos esses testes usam um primeiro nível de API 29, exceto o teste test_tonemap_curve , que usa um primeiro nível de API 30.

Cena Nome de teste Primeiro nível de API Descrição
0 test_tonemap_curve 30 Certifique-se de que o pipeline tenha saídas de cores adequadas com mapa de tons linear e entrada de imagem ideal (depende de test_test_patterns ).
1 test_ae_precapture_trigger 29 Teste a máquina de estado AE ao usar o gatilho de pré-captura. Certifique-se de que com o AE desativado o gatilho de pré-captura não tenha efeito.
test_channel_saturation 29 Certifique-se de que os canais RGB saturam com valores semelhantes para eliminar a tonalidade nas regiões saturadas.
2_a/b/c test_num_faces 29 Aumente a diversidade etária em cenas faciais.

Testes com alterações

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

Cena Nome de teste Primeiro nível de API Descrição das mudanças
1 test_burst_sameness_manual 30 Reduzir a tolerância para 2%.
4 test_aspect_ratio_and_crop 30 Mude para rodar em dispositivos LIMITADOS.
test_multi_camera_alignment 30 Percorra as câmeras individualmente se a captura de várias câmeras não for compatível. Retrabalhe a lógica de seleção de câmeras para dar conta de sistemas de três e quatro câmeras e pule câmeras mono, somente profundidade e IR.

Novos testes

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

Cena Nome de teste Primeiro nível de API Descrição
0 test_vibration_restrictions 30 Certifique-se de que alertas e vibrações não sejam ativados durante a captura de imagens.
2_a test_jpeg_quality 30 Teste se as tabelas de quantização diminuem a compactação para aumentar a qualidade JPEG.
2_d/2_e test_num_faces 30 Aumentar a diversidade etária dos rostos.
2_e test_continuous_picture 30 Certifique-se de que 3A se estabeleça em android.control.afAvailableModes = CONTINUOUS_PICTURE.
mudar test_scene_change 31 android.control.afSceneChange afirmado na mudança de cena.
6 test_zoom 30 Teste android.control.zoomRatioRange .

cena0/test_vibration_restriction

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

Afirmações

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

cena2_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.webp .

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 têm o formato: [255, 219, 0, 132, 0 (marcador luma), matriz luma 8x8, 1 (marcador croma), matriz croma 8x8].

O 0 para o marcador de matriz 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 Luma tendem a ter uma variedade maior de valores em comparação com as matrizes cromáticas, pois o olho humano é mais sensível ao luma do que o croma e as imagens JPEG levam isso em consideração.

Amostras de matrizes de luma e croma extraídas são mostradas abaixo para fatores de qualidade de 85 e 25 para a câmera traseira do Pixel 4 capturando cena2_a com o equipamento de teste ITS. Os valores da matriz aumentam (denotando maior compressão) substancialmente para a configuração de qualidade inferior. 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 luma em comparação com as matrizes 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 em comparação com a qualidade JPEG. À medida que a qualidade JPEG aumenta, o nível de compactação (média da matriz DQT de luma/croma) diminui.

Valores médios da matriz do Pixel 4

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

Afirmações

  • Para [25, 45, 65, 86], +20 em qualidade tem redução de 20% 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 telefone que falhou 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.

Exemplo de teste com falha

Figura 4. Exemplo de teste com falha

cena2_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 diversas câmeras, espera-se que o rosto mais desafiador seja o rosto mais à esquerda na cena2_d. Em particular, a modelo tem chapéu e barba, algo novo nas cenas de rosto. As novas cenas são mostradas nas figuras 5 e 6.

cena2_d

Figura 5. cena2_d

cena2_e

Figura 6. cena2_e

Afirmações

  • num_faces == 3

cena2_e/teste_imagem_contínua

Método

O teste test_continuous_picture faz uso de scene2_e mas pode ser habilitado 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 estabilizado ao final de uma captura de 50 quadros.

Afirmações

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

mudança de cena/teste_scene_change

Método

Um novo teste é ativado para testar se o sinalizador android.control.afSceneChange é ativado com uma mudança de cena. A mudança de cena faz com que o tablet exiba uma cena de rosto e depois ligue e desligue 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 temporização do teste. O tempo entre o desligamento da tela e a captura é ajustado com base nos resultados dos eventos de capturas anteriores.

Diagrama de tempo para test_scene_change

Figura 7. Diagrama de tempo para test_scene_change

Condições de turno:

  • 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 afirmada.
  • 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 mudará 30 quadros antes para obter a mudança de cena na captura.

Afirmações

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

cena6/test_zoom

Método

Uma nova cena é necessária para testar android.control.zoomRatioRange , pois as cenas estabelecidas não possuem um recurso pequeno o suficiente para serem ampliadas (cenas [1, 2, 4]) ou a cena possui 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 uma disposição 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, uma série 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 possuem um recurso com uma área de cerca de 7.500 pixels ( radius=50pixels ) para um sensor de 4.000 x 3.000 capturado com um campo de visão (FoV) de cerca de 80 graus.

cena test_zoom

Figura 8. cena test_zoom

Pixel 4 encontrou círculo

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

A Figura 9 mostra imagens capturadas pela câmera traseira de um Pixel 4 conforme o zoom aumenta de 1 a 8x em quatro etapas. Este conjunto de imagens é capturado sem nenhum cuidado específico na centralização, exceto para usar a 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 o tablet do gráfico está ligeiramente à esquerda do centro. Além disso, o gráfico parece suficiente para testar 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 está próxima da á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).

Afirmações

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

Aumento de testes de câmera LIMITADOS

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 foi atualizado para permitir o teste de dispositivos LIMITED com um primeiro nível de API 30 ou superior.

Cena Nome de teste
0 test_vibration_restrictions
2_a test_jpeg_quality
2_d/2_e test_num_faces
4 test_aspect_ratio_and_crop
6 test_zoom

A Figura 10 mostra o anel decodificador secreto ITS do Android 11. O anel decodificador secreto mostra quais configurações de teste os testes individuais são controlados. O portão é codificado por cores para simplificar a visualização. Os principais itens de gate 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 controlam a maioria dos testes. Além disso, os testes habilitados para dispositivos LIMITED são destacados em verde claro.

anel decodificador secreto

Figura 10. Anel decodificador secreto do Android 11