Notas da versão do pacote de testes de imagens da câmera do Android 11

Esta página resume as mudanças no pacote de testes de imagens da câmera (ITS, na sigla em inglês) no Android 11. As mudanças se enquadram nas seguintes categorias:

• Mudanças de hardware
• Primeiros testes OBRIGATÓRIOS no nível da API
• Iluminação de teste validada
• Mudanças no nome do cenário
• Testar mudanças e adições
• Aumento dos testes de câmera LIMITED

Mudanças de hardware

O Android 11 introduz várias mudanças de hardware para reduzir o custo e aumentar a disponibilidade. Essas mudanças se enquadram nas seguintes categorias:

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

Fabricante adicional

A Rahi Systems é qualificada para produzir gabinetes de teste ITS, além do nosso fornecedor atual, o design da 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

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

Métodos de fabricação unificados

O invólucro de teste do ITS-in-a-box de campo de visão normal (RFoV) da rev1 foi redesenhado para usar os métodos de fabricação usados pelos invólucros de teste da caixa de campo de visão amplo (WFoV) e da caixa de fusão de sensores. A funcionalidade é idêntica e, para simplificar, o design é chamado de rev1a. O novo design permite que os fabricantes armazenem um único tipo de plástico para fabricar todos os invólucros de teste. Além disso, o suporte para tablet e os suportes de luz foram redesenhados para lidar com uma maior variação em tablets e barras de luz de LED.

Para fazer o download das descrições e desenhos mecânicos mais recentes, consulte Caixa de RFoV (rev1a) e Caixa de WFoV (rev2.9).

Mais opções para 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 tenha modulação de largura de pulso (PWM, na sigla em inglês) para ajustar o brilho da tela e eliminar as faixas nas imagens capturadas.

Para conferir as informações mais recentes sobre tablets recomendados, consulte Requisitos para tablets.

Abertura reduzida do tablet

Para permitir o uso do Galaxy Tab A 10.1, a abertura do tablet é reduzida um pouco na 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 esses desenhos, consulte Caixa de RFoV (rev1a) e Caixa de 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 no Arduino, com uma placa de roteamento personalizada que é montada sobre o Arduino. A Figura 1 mostra o escudo, 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. Os componentes eletrônicos são controlados totalmente pelo conector USB. A fonte de alimentação separada permite o isolamento completo entre a eletrônica de controle e o servomotor. Além disso, um único controlador pode controlar até seis servomotores.

Figura 1. Vista de cima do escudo do Arduino

Figura 2. Design da caixa

O Android 11 é compatível com os controles atualizados. 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 da API

No Android 10, os testes ITS são designados como MANDATED e NOT_YET_MANDATED. Para ser lançado como um dispositivo Android 10, todos os testes MANDATED precisam ser aprovados. Os testes NOT_YET_MANDATED podem falhar, mas são tabulados como PASS para relatórios do verificador do CTS. O requisito de testes MANDATED também se aplica a dispositivos atualizados. Esse requisito de que os dispositivos atualizados passassem em todos os testes de MANDATED causava atraso nos testes para que eles se tornassem testes MANDATED, porque dispositivos mais antigos também precisam passar nos testes.

No Android 11, os testes MANDATED são bloqueados pela primeira flag de nível da API das propriedades do smartphone. Para dispositivos que fazem upgrade 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.

Exemplo:

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

Como validar 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 tablets 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, toda a cena precisará ser executada novamente. Por design, a reexecução de 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 nomes. A cena 2 é dividida com letras, e a cena 1 é dividida com números. A nomenclatura das 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

Testar alterações

Testes atualizados para usar o primeiro nível da API

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

Testes com alterações

Os testes na tabela a seguir foram atualizados no Android 11. As mudanças são descritas na coluna Descrição das mudanças.

Novos testes

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

scene0/test_vibration_restriction

Esse teste não requer uma cena específica, mas o dispositivo em teste (DUT, na sigla em inglês) precisa ser colocado ou montado em uma superfície rígida. Isso inclui a montagem nos gabinetes de teste do ITS-in-a-box.

Afirmaçõ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 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 dois itens de lista seguintes são o tamanho. O marcador de tamanho DQT do JPEG 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 de luma 8x8, 1 (marcador cromático), matriz de chroma 8x8].

O 0 para o marcador de matriz de luma e 1 para o marcador cromado aparece consistente em vários dispositivos, incluindo smartphones 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 chroma, já que o olho humano é mais sensível à luma do que as imagens chroma e JPEG.

As amostras de matrizes de luminância e crominância extraídas são mostradas abaixo para fatores de qualidade de 85 e 25 para a câmera traseira do Pixel 4 que captura a cena2_a com o equipamento de teste ITS. Os valores da matriz aumentam (denotando maior compactação) substancialmente para a configuração de qualidade mais baixa. Essas matrizes só serão impressas com o script se a flag debug=True for aplicada. Observe a maior variação nas entradas nas matrizes de luminância em comparação com as matrizes de crominância.

    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 do JPEG aumenta, o nível de compactação (média da matriz DQT de luminância/crominância) diminui.

Figura 3. Médias da matriz DQT de luminância/cromia da câmera traseira do Pixel 4 em comparação com a qualidade JPEG

Afirmações

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

A Figura 4 mostra um exemplo de um smartphone que não passou no teste. Para imagens de baixa qualidade (jpeg.quality < 50), não há aumento na compactaçã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 facial foram adicionadas para aumentar a diversidade facial das verificações do algoritmo. Com testes repetidos de várias câmeras, o rosto mais desafiador é esperado para ser o mais à esquerda em scene2_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.scene2_d

Figura 6. scene2_e

Afirmações

• num_faces == 3

scene2_e/test_continuous_picture

Método

O teste test_continuous_picture usa cena2_e, mas pode ser ativado com qualquer uma das cenas de rosto. Nesse teste, 50 frames de resolução VGA são capturados com a solicitação de captura definindo primeiro android.control.afMode = 4 (CONTINUOUS_PICTURE).

O sistema 3A deve ter sido estabilizado no final de uma captura de 50 frames.

Afirmações

• A 3A está no estado de convergência no final da captura.

scene_change/test_scene_change

Método

Um novo teste foi ativado para testar se a flag android.control.afSceneChange é afirmada com uma mudança de cena. A mudança de cena usa o tablet exibindo uma cena de rosto e, em seguida, liga e desliga 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 feita acenando 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 de test_scene_change

Mudar as condições:

• 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 será deslocada cinco frames antes para dar mais tempo para que afSceneChange seja definido.
• 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 será deslocada 30 frames antes para conseguir a mudança de cena na captura.

Afirmações

• Alternar tela (cena).
• A flag afSceneChange está em [0, 1].
• Se não houver mudança de cena, a 3A converge (funcionalmente idêntica à test_continuous_picture).
• Se afSceneChange == 1, o brilho precisa mudar no cenário.
• PASS em seis tentativas com o tempo alterado com base em resultados anteriores.

scene6/test_zoom

Método

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

A Figura 8 mostra a nova cena com uma matriz regular de círculos. A matriz de círculos afrouxa os requisitos de centralização de DUT/gráfico e permite que um círculo esteja sempre próximo ao centro da imagem capturada. Nesta cena, uma matriz 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 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.

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 imagens capturadas pela câmera traseira de um Pixel 4 à medida que o zoom aumenta de 1 para 8x em quatro etapas. Esse conjunto de imagens é capturado sem cuidados específicos de centralização, exceto para usar a abertura de teste do smartphone com duas aberturas para permitir o teste das câmeras frontal e traseira. Um deslocamento do centro é esperado e é observado porque o tablet do gráfico está um pouco à esquerda do centro. Além disso, o gráfico parece suficiente para testar com proporções de zoom maiores que 8x.

Como encontrar 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 do que 10 pixels.
• Os contornos precisam ter NUM_PTS >= 15.
• Os contornos precisam ter centros pretos.
• Os contornos precisam se parecer com um círculo, ou seja, a área deles precisa estar próxima da área pi*r2 do contorno.

Faixa de teste

O 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.
• 10 vezes ou o máximo de android.control.zoomRatioRange é testado.
• O raio do círculo é dimensionado com o 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 foi atingido (2x).

Aumento dos testes de câmera LIMITED

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 o primeiro nível da API 30 ou mais recente.

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

Figura 10. Anel de decodificação secreto do Android 11