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

Notas de versão do pacote de teste de imagem de câmera do Android 12

Uma série de Câmera SEUS mudanças estão incluídas na versão Android 12. Esta página resume as mudanças que se enquadram em quatro grandes categorias:

Refatorando para Python 3

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

A principal lançador de teste, tools/run_all_tests.py , continua a ser o mesmo que as versões Android 11 ou inferior e é reformulado para Python 3.

Todos os testes individuais são reformulado e usar a nova classe de instalação de ensaio definidas no tests/its_base_test.py . A maioria dos nomes de teste e funcionalidade permanecem os mesmos. No Android 12, todos os testes individuais agora carregam suas cenas. Embora o carregamento da cena para cada teste aumente o tempo geral do teste, ele permite a depuração de testes individuais.

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

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 é um framework de teste baseado em Python apoiar casos de teste que exigem vários dispositivos com configurações de hardware personalizado. O ITS da câmera usa a infraestrutura de teste Mobly para permitir um melhor controle e registro dos testes.

O ITS da câmera usa a infraestrutura de teste Mobly para permitir um melhor controle e registro dos testes. Mobly é uma estrutura de teste baseada em Python que suporta casos de teste que requerem vários dispositivos com configurações de hardware personalizadas. Para mais informações sobre Mobly, veja google / mobly .

arquivos config.yml

Com o quadro Mobly, você pode configurar um dispositivo em teste (DUT) e um tablet gráfico no its_base_test classe. A config.yml arquivo (YAML) é usado para criar um testbed Mobly. Vários testbeds podem ser configurados neste arquivo de configuração, por exemplo, um tablet e um sensor de fusão testbed. Dentro seção controlador de cada testbed, você pode especificar device_ids para identificar os dispositivos Android apropriadas para o corredor de teste. Além dos códigos de dispositivo, os outros parâmetros, tais como comprimido brightness , 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

Por testes baseados em comprimido, a palavra-chave TABLET deve estar presente no nome de banco de ensaio. Durante a inicialização, o corredor de teste Mobly inicializa TestParams e passa-os para os ensaios individuais.

O seguinte é uma amostra config.yml arquivo para corridas baseado 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 testbed pode ser invocado usando tools/run_all_tests.py . Se nenhum valor de linha de comando estão presentes, os testes executados com as config.yml valores de arquivo. Além disso, você pode substituir as camera e scene valores do arquivo de configuração 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 sensor

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

O seguinte é uma amostra config.yml arquivo para corridas 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 sensores de fusão com o dispositivo de ensaio de fusão de sensores , o uso:

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 uma base de teste para tablet e uma base de teste de fusão de sensores.

O seguinte é um exemplo config.yml arquivo com ambos os bancos de ensaio de fusão de comprimidos e de 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

Teste manual

Teste manual continua a ser apoiada em 12. Android No entanto, o testbed deve identificar testar como tal com a palavra chave MANUAL em nome testbed. Além disso, o testbed não pode incluir um ID de tablet.

O seguinte é uma amostra config.yml arquivo para o teste manual.

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

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

Testando cenas sem tablets

Testando para a cena 0 e cena 5 pode ser feito com TEST_BED_TABLET_SCENES ou com TEST_BED_MANUAL . No entanto, se o teste é feito com TEST_BED_TABLET_SCENES , o tablet deve ser ligado ea série ID tablet deve ser válido mesmo que o tablet não é utilizado porque os cessionários de configuração de classe teste o valor de ID de série para o tablet.

Executando testes individuais

Testes individuais pode ser executado somente para fins de depuração, porque seus resultados não são relatados para CTS Verificador . Porque os config.yml arquivos não podem ser substituídos na linha de comando para a camera e scene , estes parâmetros devem ser corretas na config.yml arquivo 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 --test_bed bandeira. 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 ITS de câmera são armazenados de forma semelhante ao Android 11 ou anterior, mas com as seguintes alterações:

  • O artefato de teste /tmp diretório tem CameraITS_ colocado no início do seqüência aleatória de 8 caracteres para maior clareza.
  • 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 .
  • O DUT e tablets logcats de cada teste individual estão em armazenados os /tmp/CameraITS_######## diretório simplificar a depuração como todas as informações necessárias para as questões 3A depuração são registradas.

Mudanças 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 de maneira adequada.

scene0 / test_jitter.py

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

scene1_1 / test_black_white.py

Para Android 12, test_black_white tem a funcionalidade de ambos 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 de API Afirmações
scene1_1 / test_black_white.py TUDO 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 nas diferenças [255, 255, 255] para eliminar a tonalidade da 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 de API Afirmações
scene1_1 / test_black_white.py TUDO 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 nas imagens brancas.

scene1_1 / test_burst_sameness_manual.py

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

scene1_2 / test_tonemap_sequence.py

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

scene1_2 / test_yuv_plus_raw.py

Os test_yuv_plus_raw teste é executado em câmeras escondidas físicas no Android 12.

scene2_a / test_format_combos.py

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

scene3 / test_flip_mirror.py

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

scene4 / test_aspect_ratio_and_crop.py

Encontrar círculos em scene4/test_aspect_ratio_and_crop.py foi reformulado em 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 para tamanho e cor. Android 12 utiliza um método que envolve encontrar todos os contornos e depois filtrando por encontrar recursos que são os mais circlish. Para filtrar círculos espúrios no visor, há uma área de contorno mínima necessária 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 conceptual de contornos e critérios de selecção

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

No Android 12, o teste é executado para colheita FULL e LEVEL3 dispositivos. Android 11 ou inferiores versões ignorar as afirmações de ensaio para colheita FULL dispositivos.

A tabela seguinte lista as afirmações para test_aspect_ratio_and_crop.py que correspondem a um determinado nível de dispositivo e nível de primeira API.

Nível do dispositivo Primeiro nível de API Afirmações
LIMITADO TUDO 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 Cortar
Proporção da tela
FoV para formatos 4: 3, 16: 9, 2: 1
NÍVEL 3 TUDO Cortar
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 YUV capturas em scene4/test_multi_camera_alignment.py foi reformulado para a conta com mais precisão para cultivo em sensores que não correspondem o formato da captura.

Código 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 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.

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

Se os recursos encontrados por este método forem insuficientes, o Android 12 mascara a área de detecção de recursos para o centro em 20% primeiro e limita o máximo de recursos 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 de requisito mínimo 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 Android 11 e Android 12 sensor_fusion detecção de recursos

Figura 2. A diferença na detecção de características entre Android 11 e 12 Android

Novos testes

scene0 / test_solid_color_test_pattern.py

Um novo teste, test_solid_color_test_pattern , está habilitado para Android 12. Este teste é habilitado para todas as câmeras e é descrito na tabela a seguir.

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

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

Parâmetros

  • cameraPrivacyModeSupport : Determina se o modo de privacidade câmera suporta.
  • android.sensor.testPatternMode : Define o modo padrão de teste. Este teste utiliza SOLID_COLOR .
  • android.sensor.testPatternData : Define o R, Gr, Gb, G valores padrão de teste para o modo 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 quadros YUV são capturados para os parâmetros definidos e o conteúdo da imagem é validado. O padrão de teste é enviado diretamente do sensor de imagem, portanto, nenhuma cena em particular é necessária. Se PER_FRAME_CONTROL é suportado, um único quadro de YUV é capturado para cada configuração testado. Se PER_FRAME_CONTROL não é suportado, quatro quadros são capturados com apenas o último quadro analisados para maximizar a cobertura de teste em LIMITED câmeras.

Captura YUV são definidas para totalmente saturada BLACK , WHITE , RED , GREEN e BLUE padrões de teste. Como a definição do padrão de teste é feita 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 Asserção

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

Câmera
Primeiro nível de API
Tipo de câmera Cores afirmadas
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 frontais e traseiras com a cena de rosto scene2_c.

scene2_c / test_jpeg_capture_perf_class.py

Verifica se a latência de captura de 1080p JPEG é inferior a 1 segundo para as câmeras primárias frontais e traseiras com a cena de rosto scene2_c.