O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Notas de lançamento do Android 12 Camera Image Test Suite

Várias alterações no ITS da câmera estão incluídas na versão do Android 12. Esta página resume as alterações que se enquadram em quatro grandes categorias:

Refatorando para Python 3

Devido à descontinuação 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 inicializador de teste principal, tools/run_all_tests.py , permanece o mesmo das versões Android 11 ou inferior 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 de teste e funcionalidades permanecem os mesmos. No Android 12, todos os testes individuais agora carregam suas cenas. Embora o carregamento de cena para cada teste aumente o tempo geral de teste, ele permite a depuração de testes individuais.

Para obter mais informações sobre alterações de teste individuais, consulte Alterações de teste .

Os seguintes módulos Python são refatorados com uma mudança de nome:

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

Adoção da estrutura de teste Mobly

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 Mobly para permitir um melhor controle e registro dos testes.

O Camera ITS usa a infraestrutura de teste Mobly para permitir um melhor controle e registro dos testes. 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 obter mais informações sobre o Mobly, consulte google/mobly .

arquivos config.yml

Com o framework Mobly, você pode configurar um dispositivo em teste (DUT) e um tablet gráfico na classe its_base_test . Um config.yml (YAML) é usado para criar um testbed Mobly. Vários testbeds podem ser configurados dentro deste arquivo de configuração, por exemplo, um tablet e um sensor de fusão testbed. Dentro da seção do controlador de cada testbed, você pode especificar device_ids para identificar os dispositivos Android apropriados para o executor de teste. Além dos IDs do dispositivo, outros parâmetros como brightness do tablet , chart_distance , debug_mode , camera_id e scene_id são passados ​​na classe de teste. Os valores comuns dos parâmetros de teste são:

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 baseado em tablet

Para testes baseados em tablet, a palavra-chave TABLET deve estar presente no nome do testbed. Durante a inicialização, o executor de testes Mobly inicializa TestParams e os passa para os testes individuais.

Veja a seguir um arquivo config.yml de amostra para execuções baseadas em tablet.

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 testbed 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, você pode substituir os valores do arquivo de configuração da camera e da scene na linha de comando usando comandos semelhantes ao Android 11 ou inferior.

Por 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 de sensores

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

Veja a seguir um arquivo config.yml de amostra 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 do sensor com o equipamento de teste de fusão do sensor, use:

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

Vários bancos de teste

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

Veja a seguir um arquivo config.yml de amostra com os testbeds de fusão do tablet e do sensor.

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

Testes manuais

O teste manual continua a ser suportado no Android 12. No entanto, o testbed deve identificar o teste como tal com a palavra-chave MANUAL no nome do testbed. Além disso, o testbed não pode incluir um ID de tablet.

Veja a seguir um arquivo config.yml de amostra para teste manual.

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

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

Testando cenas sem tablets

O teste para cena 0 e cena 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 deve estar conectado e o ID serial do tablet deve 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.

Executando testes individuais

Testes individuais podem ser executados apenas para fins de depuração porque seus resultados não são relatados 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 devem estar corretos no arquivo config.yml para o teste individual em questão. Além disso, se houver mais de um testbed no arquivo de configuração, você deve especificar o testbed com o sinalizador --test_bed . Por 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 Camera ITS são armazenados de forma semelhante ao Android 11 ou inferior, mas com as seguintes alterações:

  • O /tmp do artefato de teste tem CameraITS_ anexado à string aleatória de 8 caracteres para maior clareza.
  • A saída de teste e os erros 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 estão armazenados no /tmp/CameraITS_######## , simplificando a depuração, pois todas as informações necessárias para depurar problemas 3A são registradas.

Alterações de teste

No Android 12, as cenas do tablet são arquivos PNG em vez de arquivos PDF. O uso de arquivos PNG permite que mais modelos de tablet exibam 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

Para o 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 de teste Primeiro nível da API Asserções
scene1_1/test_black_white.py TODO Exposição curta, valores RGB de baixo ganho ~[0, 0, 0]
Exposição longa, valores RGB de alto ganho ~[255, 255, 255]
scene1_1/test_channel_saturation.py 29 Tolerância reduzida em [255, 255, 255] diferenças 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 de teste Primeiro nível da API Asserções
scene1_1/test_black_white.py TODO 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 os valores para eliminar a tonalidade da 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 LIMITADAS no Android 12.

scene3/test_flip_mirror.py

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

scene4/test_aspect_ratio_and_crop.py

Encontrar círculos em scene4/test_aspect_ratio_and_crop.py foi refatorado 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, em seguida, filtrar por encontrar os recursos mais circulares . Para excluir círculos espúrios na tela, é necessária uma área de contorno mínima e o contorno do círculo deve ser preto.

Os contornos e seus critérios de seleção 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 Android 12 é mais simples e funciona para resolver o problema de recorte de caixa delimitadora em alguns tablets de exibição. Todos os candidatos do círculo são registrados para fins de depuração.

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

A tabela a seguir lista as declaraçõ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 Asserções
LIMITADO TODO Proporção da tela
FoV para formatos 4:3, 16:9, 2:1
CHEIO < 31 Proporção da tela
FoV para formatos 4:3, 16:9, 2:1
CHEIO ≥ 31 Colheita
Proporção da tela
FoV para formatos 4:3, 16:9, 2:1
NÍVEL 3 TODO Colheita
Proporção da tela
FoV para formatos 4:3, 16:9, 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 contabilizar com mais precisão o corte em sensores que não correspondem à proporção da captura.

Código do Android 11 Python 2

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 do Android 12 Python 3

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 é adicionado para o teste de fusão de sensores.

Nas versões anteriores ao Android 12, a imagem inteira é usada para encontrar os melhores 240 recursos que são mascarados no centro 20% para evitar efeitos de obturador com o requisito mínimo de recursos de 30 recursos.

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

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 requisito de recurso 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 sensor_fusion detecção de recursos

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 , está ativado para o Android 12. Esse teste está ativado para todas as câmeras e é descrito na tabela a seguir.

Cena Nome de teste Primeiro nível da API Descrição
0 teste_solid_color_test_pattern 31 Confirma a saída de imagem em cores sólidas e a programação de cores da imagem.

Os padrões de teste de cores sólidas devem ser ativados para suportar o modo de privacidade da câmera. O teste test_solid_color_test_pattern confirma a saída da imagem YUV de cor sólida com a cor definida pelo padrão selecionado e a cor da imagem muda de acordo com a especificação.

Parâmetros

  • cameraPrivacyModeSupport : determina se a câmera suporta 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, G para o modo de padrão de teste.

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

Método

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

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

Cor testPatternData (RGGB)
PRETO (0, 0, 0, 0)
BRANCO (1, 1, 1, 1)
VERMELHO (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 confirmadas
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 primárias 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 1080p é inferior a 1 segundo para as câmeras primárias frontal e traseira com a cena de rosto scene2_c.