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) no Android 11. As mudanças se enquadram nas seguintes categorias:

• Mudanças de hardware
• Primeiros testes OBRIGATÓRIOS de nível de API
• Teste de iluminação validado
• Mudanças no nome da cena
• 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 custos e aumentar a disponibilidade. Essas mudanças se enquadram nas seguintes categorias:

• Fabricante adicional
• Métodos de fabricação unificados
• Mais 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 de ITS, além do nosso fornecedor atual, a MYWAY design. 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

• Design MYWAY
  4F., Nº 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) rev1 foi reprojetado para usar os métodos de fabricação usados pelos invólucros de teste do ITS-in-a-box de campo de visão amplo (WFoV) e do quadro elétrico do sensor. A funcionalidade é idêntica e, para simplificar, o design é chamado de rev1a. Com o novo design, os fabricantes podem estocar um único tipo de plástico para fabricar todos os compartimentos de teste. Além disso, o suporte para tablet e os porta-luzes foram reformulados para lidar com uma variação maior de tablets e barras de luz 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 de tablet

Os tablets, incluindo o Samsung Galaxy Tab A 10.1 e o Chuwi Hi9 Air 10.1, foram adicionados à lista de tablets recomendados. É importante que o tablet não tenha modulação por largura de pulso (PWM, na sigla em inglês) para ajustar o brilho da tela e eliminar o efeito de faixa nas imagens capturadas.

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

Abertura reduzida de tablets

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 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 redesenhado para melhorar a capacidade de fabricação. O novo controlador é baseado no Arduino, com um shield de placa de roteamento personalizada que é montada no 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 completamente 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 de um shield do Arduino

Figura 2. Design de edículas

O Android 11 é compatível com versões anteriores dos controles. 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 do 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 para que dispositivos atualizados passem em todos os testes MANDATED atrasou a conversão de testes em MANDATED, já que dispositivos mais antigos também precisam passar nos testes.

No Android 11, os testes MANDATED são controlados pela primeira flag de nível da API das propriedades do smartphone. Para dispositivos que estão fazendo upgrade para o Android 11, os testes são executados como testes NOT_YET_MANDATED. Isso 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 de API maior que 29.
• No Android 10, o teste test_channel_saturation é MANDATED para todos os dispositivos.

Validar a iluminação da cena

No Android 11, a iluminação da cena é validada analisando o brilho nos cantos dela. 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á informado e o teste vai 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 repetição de toda a cena reduz a passagem de testes marginais. No Android 11, os tempos de nova execuçã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 em diferentes cenas. O número de testes é dividido para igualar o tempo de teste, não o número de testes.

Além disso, há uma limpeza de nomes. A cena 2 é dividida com letras, e a cena 1, 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 mesmos testes: *_a,b,c

Testar mudanças

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

Testes com mudanças

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 exige uma cena específica, mas o dispositivo em teste (DUT) precisa ser colocado ou montado em uma superfície rígida. Isso inclui a montagem nos gabinetes de teste do 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 dois bytes. Para mais informações, consulte JPEG.

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

O 0 para o marcador da matriz de luminância e o 1 para o marcador de croma aparecem de forma consistente em vários dispositivos, incluindo smartphones que separam as duas matrizes em seções DQT separadas no arquivo JPEG. As matrizes de luminância tendem a ter uma variedade maior de valores em comparação com as matrizes de croma, já que o olho humano é mais sensível à luminância do que ao croma, e as imagens JPEG levam isso em consideração.

Abaixo, mostramos exemplos de matrizes de luma e croma extraídas para fatores de qualidade de 85 e 25 da câmera traseira do Pixel 4 capturando a cena2_a com o equipamento de teste do ITS. Os valores da matriz aumentam (indicando 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 variação maior nas entradas das matrizes de luminância em comparação com as 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 em comparação com a qualidade JPEG. À medida que a qualidade do JPEG aumenta, o nível de compressão (média da matriz DQT de luma/croma) diminui.

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

Declarações

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

A Figura 4 mostra um exemplo de smartphone que não passou no teste. Para imagens de qualidade muito baixa (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 de detecção facial. Com testes repetidos de várias câmeras, espera-se que o rosto mais difícil seja o da 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

Declarações

• num_faces == 3

scene2_e/test_continuous_picture

Método

O teste test_continuous_picture usa scene2_e, mas pode ser ativado com qualquer uma das cenas de rostos. 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).

Espera-se que o sistema 3A esteja estabilizado ao final de uma captura de 50 frames.

Declarações

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

scene_change/test_scene_change

Método

Um novo teste é ativado para verificar se a flag android.control.afSceneChange é declarada com uma mudança de cena. A mudança de cena usa o tablet mostrando uma cena de rosto e depois 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 necessário do tablet.

Além disso, para testes manuais, a mudança de cena pode ser feita 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 vai 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 afSceneChange ser declarado.
• Se não houver mudança de cena e afSceneChange == 1, o teste vai retornar FAIL.
• Se não houver uma mudança de cena e afSceneChange == 0, a mudança de cena será deslocada 30 frames antes para ser capturada.

Declarações

• Alternância de tela (cena).
• A flag afSceneChange está em [0, 1].
• Se não houver mudança de cena, o 3A vai convergir (funcionalmente idêntico a test_continuous_picture).
• Se afSceneChange == 1, o brilho precisa mudar na cena.
• PASS em seis tentativas com tempo alterado com base nos resultados anteriores.

scene6/test_zoom

Método

Uma nova cena é necessária para testar android.control.zoomRatioRange, já que 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 facilmente identificados, o que dificulta 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 flexibiliza os requisitos de centralização do DUT/gráfico e permite que um círculo esteja sempre perto do 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. Imagens de zoom da câmera do Pixel 4 [0] = [1, 3.33, 5.67, 8] 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 o uso da abertura de teste do smartphone com duas aberturas para permitir o teste das câmeras frontal e traseira. É esperado um deslocamento do centro, que é observado quando o tablet do gráfico fica 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 aos círculos desejados testando o seguinte:

• Os contornos precisam ter uma área maior 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 ser próxima à área pi*r2 do contorno.

Intervalo de teste

android.control.zoomRatioRange é dividido em 10 etapas.

• [1, 7] testa [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 nas bordas 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 o máximo de android.control.zoomRatioRange é testado.
• O raio do círculo é dimensionado com o zoom (RTOL 10% do esperado).
• O deslocamento do centro do círculo em relação ao centro é dimensionado com o zoom (RTOL 10% do esperado).
• O nível de zoom suficiente é atingido (2x).

Aumento nos 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 um nível 30 da API ou mais recente.

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

Figura 10. Anel decodificador secreto do Android 11