Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Notas de la versión del conjunto de pruebas de imágenes de la cámara de Android 12

Una serie de su cámara de cambios se incluye en la versión de Android 12. Esta página resume los cambios que se dividen en cuatro categorías generales:

Refactorización a Python 3

Debido a la desaprobación de Python 2.7 en enero de 2020, todo el código base de ITS de la cámara se refactorizó a Python 3. Las siguientes versiones y bibliotecas de Python son necesarias en Android 12:

El lanzador prueba principal, tools/run_all_tests.py , se mantiene igual que las versiones de Android 11 o inferior y se readaptado a Python 3.

Todas las pruebas individuales se refactorizan y utilizar la nueva clase de instalación de prueba definido en tests/its_base_test.py . La mayoría de los nombres y funciones de las pruebas siguen siendo los mismos. En Android 12, todas las pruebas individuales ahora cargan sus escenas. Si bien la carga de escenas para cada prueba aumenta el tiempo total de la prueba, permite la depuración de pruebas individuales.

Para obtener más información sobre los cambios de las pruebas individuales, ver los cambios de prueba .

Los siguientes módulos de Python se refactorizan con un cambio de nombre:

  • 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

Adopción del marco de prueba de Mobly

Mobly es un marco de pruebas basado en Python apoyo a los casos de prueba que requieren múltiples dispositivos con configuraciones de hardware personalizado. Camera ITS utiliza la infraestructura de prueba de Mobly para permitir un mejor control y registro de las pruebas.

Camera ITS utiliza la infraestructura de prueba de Mobly para permitir un mejor control y registro de las pruebas. Mobly es un marco de prueba basado en Python que admite casos de prueba que requieren varios dispositivos con configuraciones de hardware personalizadas. Para obtener más información sobre Mobly, consulte Google / mobly .

archivos config.yml

Con el marco Mobly, se puede configurar un dispositivo bajo prueba (DUT) y una tableta gráfica en el its_base_test clase. Un config.yml archivo (YAML) se utiliza para crear un banco de pruebas Mobly. Se pueden configurar varios bancos de pruebas dentro de este archivo de configuración, por ejemplo, una tableta y un banco de pruebas de fusión de sensores. Dentro de la sección de control de cada banco de pruebas, puede especificar device_ids para identificar los dispositivos Android apropiadas para el corredor de prueba. Además de los ID de dispositivos, otros parámetros tales como la tableta brightness , chart_distance , debug_mode , camera_id , y scene_id se pasan en la clase de prueba. Los valores de los parámetros de prueba comunes son:

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)

Pruebas basadas en tabletas

Para las pruebas basadas en la tableta, la palabra clave TABLET debe estar presente en el nombre de banco de pruebas. Durante la inicialización, el corredor de prueba Mobly inicializa TestParams y los pasa a las pruebas individuales.

La siguiente es una muestra config.yml archivo de carreras basado en la tableta.

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

El banco de pruebas se puede invocar utilizando tools/run_all_tests.py . Si no hay valores de la línea de comandos están presentes, las pruebas se ejecutan con los config.yml valores del archivo. Además, puede anular las camera y scene los valores del archivo de configuración en la línea de comandos mediante comandos similares a Android 11 o inferior.

Por ejemplo:

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

Prueba de fusión de sensores

Para las pruebas de fusión de sensores , el nombre de banco de pruebas debe incluir la palabra clave SENSOR_FUSION . El banco de pruebas correcto está determinado por las escenas probadas. Android 12 soporta ambas Arduino y Canakit controladores para fusión de sensores .

La siguiente es una muestra config.yml archivo para carreras de fusión 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 ejecutar sensor pruebas de fusión con el banco de pruebas de fusión de sensores , el uso:

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

Múltiples bancos de pruebas

Se pueden incluir varios bancos de pruebas en el archivo de configuración. La combinación más común es tener un banco de pruebas de tabletas y un banco de pruebas de fusión de sensores.

El siguiente es un ejemplo config.yml archivo con ambos bancos de pruebas de fusión de la tableta y el 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

Prueba manual

Las pruebas manuales sigue siendo apoyado en Android 12. Sin embargo, el banco de pruebas debe identificar la prueba como tal con la palabra clave MANUAL en el nombre de banco de pruebas. Además, el banco de pruebas no puede incluir una ID de tableta.

La siguiente es una muestra config.yml archivo para las pruebas manuales.

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

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

Prueba de escenas sin tabletas

Las pruebas para la escena 0 y 5 escena se puede hacer con TEST_BED_TABLET_SCENES o con TEST_BED_MANUAL . Sin embargo, si la prueba se realiza con TEST_BED_TABLET_SCENES , el comprimido debe estar conectada y el ID de serie de la tableta debe ser válido a pesar de que la tableta no se utiliza debido a los cesionarios de configuración de clase de prueba el valor de ID de serie para la tableta.

Ejecución de pruebas individuales

Las pruebas individuales se pueden ejecutar sólo para fines de depuración debido a que sus resultados no son reportados a CTS Verificador . Debido a que los config.yml archivos no se pueden sobrescribir en la línea de comandos para camera y la scene , estos parámetros deben ser correctos en el config.yml de archivo para la prueba individual de que se trate. Además, si hay más de un banco de pruebas en el archivo de configuración, debe especificar el banco de pruebas con el --test_bed bandera. Por ejemplo:

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

Prueba de artefactos

En Android 12, los artefactos de prueba para Camera ITS se almacenan de manera similar a Android 11 o versiones anteriores, pero con los siguientes cambios:

  • El artefacto de prueba /tmp directorio tiene CameraITS_ antepone a la cadena aleatoria de 8 caracteres para mayor claridad.
  • Salida de prueba y los errores son almacenados en test_log.DEBUG para cada prueba en lugar de test_name_stdout.txt y test_name_stderr.txt .
  • Los DUT y tabletas logcats de cada prueba individual están en las almacenado /tmp/CameraITS_######## directorio de simplificar la depuración como toda la información necesaria para temas 3A está en el sistema de depuración.

Cambios de prueba

En Android 12, las escenas de la tableta son archivos PNG en lugar de archivos PDF. El uso de archivos PNG permite que más modelos de tabletas muestren las escenas correctamente.

scene0 / test_jitter.py

El test_jitter pruebas de funcionamiento en cámaras físicas ocultas en Android 12.

scene1_1 / test_black_white.py

Para Android 12, test_black_white tiene la funcionalidad tanto test_black_white y test_channel_saturation .

La siguiente tabla describe las dos pruebas individuales en Android 11.

Nombre de la prueba Primer nivel de API Afirmaciones
scene1_1 / test_black_white.py TODOS Exposición corta, valores RGB de baja ganancia ~ [0, 0, 0]
Exposición prolongada, valores RGB de alta ganancia ~ [255, 255, 255]
scene1_1 / test_channel_saturation.py 29 Tolerancia reducida en las diferencias [255, 255, 255] para eliminar el tinte de color en las imágenes en blanco.

La siguiente tabla describe la prueba combinada, scene1_1 / test_black_white.py, en Android 12.

Nombre de la prueba Primer nivel de API Afirmaciones
scene1_1 / test_black_white.py TODOS Exposición corta, valores RGB de baja ganancia ~ [0, 0, 0]
Exposición prolongada, valores RGB de alta ganancia ~ [255, 255, 255] y tolerancia reducida entre valores para eliminar el tinte de color en imágenes blancas.

scene1_1 / test_burst_sameness_manual.py

El test_burst_sameness_manual pruebas de funcionamiento en cámaras físicas ocultas en Android 12.

scene1_2 / test_tonemap_sequence.py

El test_tonemap_sequence pruebas de funcionamiento en cámaras limitado en Android 12.

scene1_2 / test_yuv_plus_raw.py

Los test_yuv_plus_raw pruebas de funcionamiento de las cámaras físicas ocultos en Android 12.

scene2_a / test_format_combos.py

El test_format_combos pruebas de funcionamiento en cámaras limitado en Android 12.

scene3 / test_flip_mirror.py

El test_flip_mirror pruebas de funcionamiento en cámaras limitado en Android 12.

scene4 / test_aspect_ratio_and_crop.py

Encontrar los círculos en scene4/test_aspect_ratio_and_crop.py fue rediseñado en Android 12.

Las versiones anteriores de Android usaban un método que implicaba encontrar un contorno secundario (el círculo) dentro del contorno principal (el cuadrado) con filtros de tamaño y color. Android 12 utiliza un método que consiste en encontrar todos los contornos y luego filtrar mediante la búsqueda de características que son los más circlish. Para eliminar círculos espurios en la pantalla, se requiere un área de contorno mínima, y ​​el contorno del círculo debe ser negro.

Los contornos y sus criterios de selección se muestran en la siguiente imagen.

Dibujo conceptual de contornos y criterios de selección

Figura 1. Dibujo conceptual de contornos y criterios de selección

El método de Android 12 es más simple y funciona para resolver el problema del recorte del cuadro delimitador en algunas tabletas de visualización. Todos los candidatos del círculo se registran con fines de depuración.

En Android 12, la prueba del cultivo se ejecuta por FULL y LEVEL3 dispositivos. Android 11 o más bajas versiones se saltan las afirmaciones de las pruebas de cultivos para FULL dispositivos.

La siguiente tabla enumera las afirmaciones para test_aspect_ratio_and_crop.py que corresponden a un nivel de dispositivo dado y primer nivel API.

Nivel de dispositivo Primer nivel de API Afirmaciones
LIMITADO TODOS Relación de aspecto
FoV para formatos 4: 3, 16: 9, 2: 1
LLENO <31 Relación de aspecto
FoV para formatos 4: 3, 16: 9, 2: 1
LLENO ≥ 31 Cultivo
Relación de aspecto
FoV para formatos 4: 3, 16: 9, 2: 1
NIVEL 3 TODOS Cultivo
Relación de aspecto
FoV para formatos 4: 3, 16: 9, 2: 1

scene4 / test_multi_camera_alignment.py

El método undo_zoom() para YUV capturas en scene4/test_multi_camera_alignment.py fue refactorizado a la cuenta más exactamente para el cultivo en los sensores que no coinciden con la relación de aspecto de la captura.

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

En Android 12, se agrega un método para detectar características en imágenes para la prueba de fusión del sensor.

En las versiones anteriores a Android 12, la imagen completa se usa para encontrar las mejores 240 características que luego se enmascaran al centro un 20% para evitar los efectos de persiana rodante con el requisito mínimo de características de 30 características.

Si las características encontradas por este método son insuficientes, Android 12 enmascara el área de detección de características al centro un 20% primero y limita las características máximas a dos veces el requisito de característica mínima.

La siguiente imagen muestra la diferencia entre la detección de funciones de Android 11 y Android 12. El aumento del umbral mínimo de requisitos de características da como resultado la detección de características de baja calidad y afecta negativamente a las mediciones.

diferencia en la detección de funciones entre Android 11 y Android 12 sensor_fusion función de detección

Figura 2. Diferencia en la detección de características entre Android 11 y 12 Android

Nuevas pruebas

scene0 / test_solid_color_test_pattern.py

Una nueva prueba, test_solid_color_test_pattern , está habilitado para Android 12. Esta prueba está habilitado para todas las cámaras y se describe en la siguiente tabla.

Escena Nombre de la prueba Primer nivel de API Descripción
0 test_solid_color_test_pattern 31 Confirma la salida de la imagen de color sólido y la programabilidad del color de la imagen.

Los patrones de prueba de color sólido deben estar habilitados para admitir el modo de privacidad de la cámara. El test_solid_color_test_pattern prueba confirma de color YUV de salida de imagen sólida con el color definido por el patrón seleccionado, y el color cambia la imagen de acuerdo con la especificación.

Parámetros

  • cameraPrivacyModeSupport : Determina si el modo de privacidad soportes de cámara.
  • android.sensor.testPatternMode : Establece el modo de patrón de prueba. Esta prueba utiliza SOLID_COLOR .
  • android.sensor.testPatternData : Establece el R, los valores del patrón de prueba Gr, GB, G para el modo de patrón de prueba.

Para una descripción del patrón de prueba de color sólido, ver SENSOR_TEST_PATTERN_MODE_SOLID_COLOR .

Método

Los fotogramas YUV se capturan para los parámetros establecidos y se valida el contenido de la imagen. El patrón de prueba se emite directamente desde el sensor de imagen, por lo que no se requiere una escena en particular. Si PER_FRAME_CONTROL es compatible, un solo marco YUV es capturado para cada ajuste de la prueba. Si PER_FRAME_CONTROL no es compatible, cuatro marcos son capturados con sólo el último cuadro analizado para maximizar la cobertura de las pruebas en LIMITED cámaras.

Capturas YUV se fijan a totalmente saturado BLACK , WHITE , RED , GREEN , y BLUE patrones de prueba. Como la definición del patrón de prueba es según el patrón Bayer del sensor, los canales de color deben configurarse para cada color como se muestra en la siguiente tabla.

Color testPatternData (RGGB)
NEGRO (0, 0, 0, 0)
BLANCO (1, 1, 1, 1)
ROJO (1, 0, 0, 0)
VERDE (0, 1, 1, 0)
AZUL (0, 0, 0, 1)

Tabla de afirmaciones

En la siguiente tabla se describen las afirmaciones de prueba para test_solid_color_test_pattern.py .

Cámara
Primer nivel de API
Tipo de cámara Colores afirmados
31 Bayer NEGRO, BLANCO, ROJO, VERDE, AZUL
31 MONONUCLEOSIS INFECCIOSA BLANCO NEGRO
<31 Bayer / MONO NEGRO

Pruebas de clase de rendimiento

scene2_c / test_camera_launch_perf_class.py

Verifica que el inicio de la cámara sea inferior a 500 ms para las cámaras primarias delantera y trasera con la escena facial scene2_c.

scene2_c / test_jpeg_capture_perf_class.py

Verifica que la latencia de captura de JPEG de 1080p sea inferior a 1 segundo tanto para la cámara principal delantera como para la trasera con la escena facial scene2_c.