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

Várias mudanças no Camera ITS estão incluídas no lançamento do Android 12. Esta página resume as mudanças, que se enquadram em quatro categorias gerais:

Refatorar para Python 3

Devido à suspensão de uso do Python 2.7 em janeiro de 2020, toda a base de código do Camera ITS foi refatorada para o Python 3. As seguintes versões e bibliotecas do Python são necessárias no Android 12:

O iniciador de teste principal, tools/run_all_tests.py, permanece o mesmo das versões Android 11 ou anteriores e é refatorado para Python 3.

Todos os testes individuais são refatorados e usam a nova classe de configuração de teste definida em tests/its_base_test.py. A maioria dos nomes e funcionalidades dos testes permanece a mesma. No Android 12, todos os testes individuais agora carregam as cenas. Embora o carregamento de cenas para cada teste aumente o tempo total do teste, ele permite a depuração de testes individuais.

Para mais informações sobre mudanças em testes individuais, consulte Mudanças nos testes.

Os seguintes módulos do Python foram refatorados com uma mudança de nome:

  • pymodules/its/caps.py → utils/camera_properties_utils.py
  • pymodules/its/cv2image.py → utils/opencv_processing_utils.py
  • pymodules/its/device.py → utils/its_session_utils.py
  • pymodules/its/error.py → utils/error_util.py
  • pymodules/its/image.py → utils/image_processing_utils.py
  • pymodules/its/objects.py → utils/capture_request_utils.py
  • pymodules/its/target.py → utils/target_exposure_utils.py
  • tools/hw.py → utils/sensor_fusion_utils.py

Adoção da estrutura de teste do Mobly.

O Mobly é uma estrutura de teste baseada em Python que oferece suporte a casos de teste que exigem vários dispositivos com configurações de hardware personalizadas. O Camera ITS usa a infraestrutura de teste do Mobly para permitir melhor controle e registro dos testes.

O Camera ITS usa a infraestrutura de teste do Mobly para permitir melhor controle e registro dos testes. O Mobly é uma estrutura de teste baseada em Python que oferece suporte a casos de teste que exigem vários dispositivos com configurações de hardware personalizadas. Para mais informações sobre o Mobly, consulte google/mobly.

Arquivos config.yml

Com a estrutura Mobly, é possível configurar um dispositivo em teste (DUT) e um tablet de gráficos na classe its_base_test. Um arquivo config.yml (YAML) é usado para criar um ambiente de teste do Mobly. Vários testbeds podem ser configurados nesse arquivo de configuração, por exemplo, um tablet e um testbed de fusão de sensores. Na seção de controlador de cada testbed, é possível especificar device_ids para identificar os dispositivos Android adequados ao executor de testes. Além dos IDs de dispositivo, outros parâmetros, como brightness, chart_distance, debug_mode, camera_id e scene_id de tablet, são transmitidos na classe de teste. Valores comuns de parâmetros de teste:

brightness: 192  (all tablets except Pixel C)
chart_distance: 31.0  (rev1/rev1a box for FoV < 90° cameras)
chart_distance: 22.0 (rev2 test rig for FoV > 90° cameras)

Teste em tablets

Para testes baseados em tablets, a palavra-chave TABLET precisa estar presente no nome do ambiente de teste. Durante a inicialização, o executor de testes do Mobly inicializa TestParams e os transmite aos testes individuais.

Confira a seguir um exemplo de arquivo config.yml para execuções baseadas em tablets.

TestBeds:
  - Name: TEST_BED_TABLET_SCENES
    # Test configuration for scenes[0:4, 6, _change]
    Controllers:
        AndroidDevice:
          - serial: 8A9X0NS5Z
            label: dut
          - serial: 5B16001229
            label: tablet

    TestParams:
      brightness: 192
      chart_distance: 22.0
      debug_mode: "False"
      chart_loc_arg: ""
      camera: 0
      scene: <scene-name>  # if <scene-name> runs all scenes

O ambiente de teste pode ser invocado usando tools/run_all_tests.py. Se nenhum valor de linha de comando estiver presente, os testes serão executados com os valores do arquivo config.yml. Além disso, é possível substituir os valores do arquivo de configuração camera e scene na linha de comando usando comandos semelhantes ao Android 11 ou versões anteriores.

Exemplo:

python tools/run_all_tests.py
python tools/run_all_tests.py camera=1
python tools/run_all_tests.py scenes=2,1,0
python tools/run_all_tests.py camera=1 scenes=2,1,0

Teste de fusão do sensor

Para testes de fusão de sensores, o nome do testbed precisa incluir a palavra-chave SENSOR_FUSION. O testbed correto é determinado pelas cenas testadas. O Android 12 é compatível com controladores Arduino e Canakit para fusão de sensores.

Confira abaixo um exemplo de arquivo config.yml para execuções de fusão de sensores.

Testbeds
  - Name: TEST_BED_SENSOR_FUSION
    # Test configuration for sensor_fusion/test_sensor_fusion.py
    Controllers:
        AndroidDevice:
          - serial: 8A9X0NS5Z
            label: dut

    TestParams:
      fps: 30
      img_size: 640,480
      test_length: 7
      debug_mode: "False"
      chart_distance: 25
      rotator_cntl: arduino         # cntl can be arduino or canakit
      rotator_ch: 1
      camera: 0

Para executar testes de fusão de sensores com o equipamento de teste de fusão de sensores, use:

python tools/run_all_tests.py scenes=sensor_fusion
python tools/run_all_tests.py scenes=sensor_fusion camera=0

Vários testbeds

Vários testbeds podem ser incluídos no arquivo de configuração. A combinação mais comum é ter um ambiente de teste de tablet e um ambiente de teste de fusão de sensores.

Confira a seguir um exemplo de arquivo config.yml com plataformas de teste de fusão de sensores e tablets.

Testbeds
  - Name: TEST_BED_TABLET_SCENES
    # Test configuration for scenes[0:4, 6, _change]
    Controllers:
        AndroidDevice:
          - serial: 8A9X0NS5Z
            label: dut
          - serial: 5B16001229
            label: tablet

    TestParams:
      brightness: 192
      chart_distance: 22.0
      debug_mode: "False"
      chart_loc_arg: ""
      camera: 0
      scene: <scene-name>  # if <scene-name> runs all scenes

  - Name: TEST_BED_SENSOR_FUSION
    # Test configuration for sensor_fusion/test_sensor_fusion.py
    Controllers:
        AndroidDevice:
          - serial: 8A9X0NS5Z
            label: dut

    TestParams:
      fps: 30
      img_size: 640,480
      test_length: 7
      debug_mode: "False"
      chart_distance: 25
      rotator_cntl: arduino         # cntl can be arduino or canakit
      rotator_ch: 1
      camera: 0

Teste manual

Os testes manuais ainda são compatíveis com o Android 12. No entanto, o ambiente de teste precisa identificar o teste como tal com a palavra-chave MANUAL no nome. Além disso, o testbed não pode incluir um ID de tablet.

Confira a seguir um exemplo de arquivo config.yml para testes manuais.

TestBeds:
  - Name: TEST_BED_MANUAL
    Controllers:
        AndroidDevice:
          - serial: 8A9X0NS5Z
            label: dut

    TestParams:
      debug_mode: "False"
      chart_distance: 31.0
      camera: 0
      scene: scene1

Testar cenas sem tablets

O teste das cenas 0 e 5 pode ser feito com TEST_BED_TABLET_SCENES ou com TEST_BED_MANUAL. No entanto, se o teste for feito com TEST_BED_TABLET_SCENES, o tablet precisará estar conectado e o ID serial dele precisará ser válido, mesmo que o tablet não seja usado, porque a configuração da classe de teste atribui o valor do ID serial ao tablet.

Executar testes individuais

Os testes individuais só podem ser executados para fins de depuração porque os resultados não são informados ao CTS Verifier. Como os arquivos config.yml não podem ser substituídos na linha de comando para camera e scene, esses parâmetros precisam estar corretos no arquivo config.yml para o teste individual em questão. Além disso, se houver mais de um ambiente de teste no arquivo de configuração, especifique o ambiente com a flag --test_bed. Exemplo:

python tests/scene1_1/test_black_white.py --config config.yml --test_bed TEST_BED_TABLET_SCENES

Artefatos de teste

No Android 12, os artefatos de teste para o Camera ITS são armazenados de maneira semelhante ao Android 11 ou versões anteriores, mas com as seguintes mudanças:

  • O diretório do artefato de teste /tmp tem CameraITS_ adicionado à string aleatória de oito caracteres para maior clareza.
  • A saída e os erros de teste são armazenados em test_log.DEBUG para cada teste, em vez de test_name_stdout.txt e test_name_stderr.txt.
  • Os logcats do DUT e do tablet de cada teste individual são armazenados no diretório /tmp/CameraITS_########, simplificando a depuração, já que todas as informações necessárias para depurar problemas de 3A são registradas.

Testar mudanças

No Android 12, as cenas de tablet são arquivos PNG em vez de PDF. O uso de arquivos PNG permite que mais modelos de tablet mostrem as cenas corretamente.

scene0/test_jitter.py

O teste test_jitter é executado em câmeras ocultas físicas no Android 12.

scene1_1/test_black_white.py

No Android 12, test_black_white tem a funcionalidade de test_black_white e test_channel_saturation.

A tabela a seguir descreve os dois testes individuais no Android 11.

Nome do teste Primeiro nível da API Declarações
scene1_1/test_black_white.py TODOS Exposição curta, valores RGB de ganho baixo ~[0, 0, 0]
Exposição longa, valores RGB de ganho alto ~[255, 255, 255]
scene1_1/test_channel_saturation.py 29 Tolerância reduzida em diferenças de [255, 255, 255] para eliminar a tonalidade de cor em imagens brancas.

A tabela a seguir descreve o teste mesclado, scene1_1/test_black_white.py, no Android 12.

Nome do teste Primeiro nível da API Declarações
scene1_1/test_black_white.py TODOS Exposição curta, valores RGB de baixo ganho ~[0, 0, 0]
Exposição longa, valores RGB de alto ganho ~[255, 255, 255] e tolerância reduzida entre valores para eliminar a tonalidade de cor em imagens brancas.

scene1_1/test_burst_sameness_manual.py

O teste test_burst_sameness_manual é executado em câmeras ocultas físicas no Android 12.

scene1_2/test_tonemap_sequence.py

O teste test_tonemap_sequence é executado em câmeras LIMITED no Android 12.

scene1_2/test_yuv_plus_raw.py

O teste test_yuv_plus_raw é executado em câmeras ocultas físicas no Android 12.

scene2_a/test_format_combos.py

O teste test_format_combos é executado em câmeras LIMITED no Android 12.

scene3/test_flip_mirror.py

O teste test_flip_mirror é executado em câmeras LIMITED no Android 12.

scene4/test_aspect_ratio_and_crop.py

A descoberta de círculos em scene4/test_aspect_ratio_and_crop.py foi refatorada no Android 12.

As versões anteriores do Android usavam um método que envolvia encontrar um contorno filho (o círculo) dentro do contorno pai (o quadrado) com filtros de tamanho e cor. O Android 12 usa um método que envolve encontrar todos os contornos e filtrar encontrando os recursos mais circulares. Para evitar círculos falsos na tela, é necessária uma área de contorno mínima, e o contorno do círculo precisa ser preto.

Os contornos e os critérios de seleção deles são mostrados na imagem a seguir.

Desenho conceitual de contornos e critérios de seleção

Figura 1. Desenho conceitual de contornos e critérios de seleção

O método do Android 12 é mais simples e funciona para resolver o problema de corte da caixa delimitadora em alguns tablets de tela. Todos os candidatos a círculo são registrados para fins de depuração.

No Android 12, o teste de corte é executado em dispositivos FULL e LEVEL3. O Android 11 ou versões anteriores ignoram as declarações de teste de corte para dispositivos FULL.

A tabela a seguir lista as asserções para test_aspect_ratio_and_crop.py que correspondem a um determinado nível de dispositivo e primeiro nível de API.

Nível do dispositivo Primeiro nível da API Declarações
LIMITADA TODOS Proporção
Campo de visão para formatos 4:3, 16:9 e 2:1
COMPLETO < 31 Proporção
Campo de visão para formatos 4:3, 16:9 e 2:1
COMPLETO ≥ 31 Corte
Proporção
Campo de visão para formatos 4:3, 16:9 e 2:1
LEVEL3 TODOS Corte
Proporção
Campo de visão para formatos 4:3, 16:9 e 2:1

scene4/test_multi_camera_alignment.py

O método undo_zoom() para capturas YUV em scene4/test_multi_camera_alignment.py foi refatorado para considerar de forma mais precisa o corte em sensores que não correspondem à proporção da captura.

Código Python 2 do Android 11

zoom_ratio = min(1.0 * yuv_w / cr_w, 1.0 * yuv_h / cr_h)
circle[i]['x'] = cr['left'] + circle[i]['x'] / zoom_ratio
circle[i]['y'] = cr['top'] + circle[i]['y'] / zoom_ratio
circle[i]['r'] = circle[i]['r'] / zoom_ratio

Código Python 3 do Android 12

yuv_aspect = yuv_w / yuv_h
relative_aspect = yuv_aspect / (cr_w/cr_h)
if relative_aspect > 1:
  zoom_ratio = yuv_w / cr_w
  yuv_x = 0
  yuv_y = (cr_h - cr_w / yuv_aspect) / 2
else:
  zoom_ratio = yuv_h / cr_h
  yuv_x = (cr_w - cr_h * yuv_aspect) / 2
  yuv_y = 0
circle['x'] = cr['left'] + yuv_x + circle['x'] / zoom_ratio
circle['y'] = cr['top'] + yuv_y + circle['y'] / zoom_ratio
circle['r'] = circle['r'] / zoom_ratio

sensor_fusion/test_sensor_fusion.py

No Android 12, um método para detectar recursos em imagens foi adicionado ao teste de fusão de sensores.

Em versões anteriores ao Android 12, toda a imagem é usada para encontrar os 240 melhores recursos, que são mascarados para os 20% centrais para evitar efeitos de obturador rolante. O requisito mínimo é de 30 recursos.

Se os recursos encontrados por esse método forem insuficientes, o Android 12 vai mascarar a área de detecção de recursos para os 20% centrais primeiro e limitar os recursos máximos a duas vezes o requisito mínimo.

A imagem a seguir mostra a diferença entre a detecção de recursos do Android 11 e do Android 12. Aumentar o limite mínimo de requisitos de recursos resulta na detecção de recursos de baixa qualidade e afeta negativamente as medições.

diferença na detecção de recursos entre o Android 11 e o Android 12 detecção de recursos de sensor_fusion

Figura 2. Diferença na detecção de recursos entre o Android 11 e o Android 12

Novos testes

scene0/test_solid_color_test_pattern.py

Um novo teste, test_solid_color_test_pattern, foi ativado para o Android 12. Esse teste está ativado para todas as câmeras e é descrito na tabela a seguir.

Scene Nome do teste Primeiro nível da API Descrição
0 test_solid_color_test_pattern 31 Confirma a saída de imagem de cor sólida e a capacidade de programação de cores da imagem.

Os padrões de teste de cor sólida precisam estar ativados para oferecer suporte ao modo de privacidade da câmera. O teste test_solid_color_test_pattern confirma a saída de imagem YUV de cor sólida com a cor definida pelo padrão selecionado, e as mudanças de cor da imagem de acordo com a especificação.

Parâmetros

  • cameraPrivacyModeSupport: determina se a câmera é compatível com o modo de privacidade.
  • android.sensor.testPatternMode: define o modo de padrão de teste. Este teste usa SOLID_COLOR.
  • android.sensor.testPatternData: define os valores de padrão de teste R, Gr, Gb e G para o modo de padrão de teste.

Para uma descrição do padrão de teste de cor sólida, consulte SENSOR_TEST_PATTERN_MODE_SOLID_COLOR.

Método

Os frames YUV são capturados para os parâmetros definidos, e o conteúdo da imagem é validado. O padrão de teste é gerado diretamente do sensor de imagem, então não é necessário uma cena específica. Se PER_FRAME_CONTROL for compatível, um único frame YUV será capturado para cada configuração testada. Se PER_FRAME_CONTROL não for compatível, quatro frames serão capturados, e apenas o último será analisado para maximizar a cobertura de teste em câmeras LIMITED.

As capturas YUV são definidas como padrões de teste totalmente saturados BLACK, WHITE, RED, GREEN e BLUE. Como a definição do padrão de teste é por padrão Bayer do sensor, os canais de cores precisam ser definidos para cada cor, conforme mostrado na tabela a seguir.

Cor testPatternData (RGGB)
PRETO (0, 0, 0, 0)
BRANCO (1, 1, 1, 1)
RED (1, 0, 0, 0)
VERDE (0, 1, 1, 0)
AZUL (0, 0, 0, 1)

Tabela de declarações

A tabela a seguir descreve as declarações de teste para test_solid_color_test_pattern.py.

Câmera
Primeiro nível da API		 Tipo de câmera Cores declaradas
31 Bayer PRETO, BRANCO, VERMELHO, VERDE, AZUL
31 MONO PRETO, BRANCO
< 31 Bayer/MONO PRETO

Testes de classe de desempenho

scene2_c/test_camera_launch_perf_class.py

Verifica se a inicialização da câmera é inferior a 500 ms para as câmeras principais frontal e traseira com a cena de rosto scene2_c.

scene2_c/test_jpeg_capture_perf_class.py

Verifica se a latência de captura JPEG de 1080p é inferior a 1 segundo para as câmeras principais frontal e traseira com a cena de rosto scene2_c.