Notas de la versión del paquete de pruebas de imagen de la cámara de Android 12

En la versión de Android 12, se incluyen varios cambios en ITS de la cámara. En esta página, se resumen los cambios que se incluyen en estas categorías generales:

• Refactorización a Python 3
• Adopción del framework de pruebas de Mobly
• Probar cambios
• Nuevas pruebas

Refactoriza a Python 3

Debido a la baja de Python 2.7 en enero de 2020, se refactorizó toda la base de código de ITS de la cámara a Python 3. En Android 12, se requieren las siguientes versiones y bibliotecas de Python:

• Python 3.7.9 o Python 3.7.10
• OpenCV 3.4.2
• Numpy 1.19.2
• Matplotlib 3.3.2
• Scipy 1.5.2
• pySerial 3.5
• Pillow 8.1.0
• PyYAML 5.3.1

El selector de pruebas principal, tools/run_all_tests.py, sigue siendo el mismo que en las versiones de Android 11 o anteriores y se refactoriza a Python 3.

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

Para obtener más información sobre los cambios en las pruebas individuales, consulta Probar cambios.

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

• 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

Adopción del framework de pruebas de Mobly

Mobly es un framework de pruebas basado en Python que admite casos de prueba que requieren varios dispositivos con configuraciones de hardware personalizadas. ITS de la cámara usa la infraestructura de pruebas de Mobly para permitir un mejor control y registro de las pruebas.

ITS de la cámara usa la infraestructura de pruebas de Mobly para permitir un mejor control y registro de las pruebas. Mobly es un framework de pruebas 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, consulta google/mobly.

Archivos config.yml

Con el framework de Mobly, puedes configurar un dispositivo en prueba (DUT) y una tablet de gráficos en la clase its_base_test. Se usa un archivo config.yml (YAML) para crear un testbed de Mobly. Se pueden configurar varios testbeds en este archivo de configuración, por ejemplo, una tablet y un testbed de fusión de sensores. Dentro de la sección del controlador de cada testbed, puedes especificar device_ids para identificar los dispositivos Android adecuados para el ejecutor de pruebas. Además de los IDs de dispositivo, otros parámetros, como brightness, chart_distance, debug_mode, camera_id y scene_id de la tablet, se pasan en la clase de prueba. Los valores de parámetros de prueba comunes son los siguientes:

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 tablets

Para las pruebas basadas en tablets, la palabra clave TABLET debe estar presente en el nombre del testbed. Durante la inicialización, el ejecutor de pruebas de Mobly inicializa TestParams y los pasa a las pruebas individuales.

El siguiente es un archivo config.yml de muestra para ejecuciones basadas en 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

Se puede invocar el testbed con tools/run_all_tests.py. Si no hay valores de línea de comandos, las pruebas se ejecutan con los valores del archivo config.yml. Además, puedes anular los valores del archivo de configuración camera y scene en la línea de comandos con comandos similares a Android 11 o versiones anteriores.

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

Pruebas de fusión de sensores

Para las pruebas de fusión de sensores, el nombre del testbed debe incluir la palabra clave.SENSOR_FUSION El testbed correcto se determina según las escenas probadas. Android 12 admite controladores Arduino y Canakit para la fusión de sensores.

El siguiente es un archivo config.yml de muestra para ejecuciones 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 pruebas de fusión de sensores con el equipo de prueba de fusión de sensores, usa lo siguiente:

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

Varios testbeds

Se pueden incluir varios testbeds en el archivo de configuración. La combinación más común es tener un testbed de tablets y un testbed de fusión de sensores.

El siguiente es un archivo config.yml de muestra con testbeds de tablets y de fusión de sensores.

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

Pruebas manuales

Las pruebas manuales siguen siendo compatibles con Android 12. Sin embargo, el testbed debe identificar las pruebas como tales con la palabra clave MANUAL en el nombre del testbed. Además, el testbed no puede incluir un ID de tablet.

El siguiente es un archivo config.yml de muestra para pruebas manuales.

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

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

Prueba escenas sin tablets

Las pruebas para la escena 0 y la escena 5 se pueden realizar con TEST_BED_TABLET_SCENES o con TEST_BED_MANUAL. Sin embargo, si la prueba se realiza con TEST_BED_TABLET_SCENES, la tablet debe estar conectada y el ID de serie de la tablet debe ser válido, aunque no se use, ya que la configuración de la clase de prueba asigna el valor del ID de serie para la tablet.

Ejecuta pruebas individuales

Las pruebas individuales solo se pueden ejecutar con fines de depuración, ya que sus resultados no se informan a CTS Verifier. Debido a que los archivos config.yml no se pueden anular en la línea de comandos para camera y scene, estos parámetros deben ser correctos en el archivo config.yml para la prueba individual en cuestión. Además, si hay más de un testbed en el archivo de configuración, debes especificar el testbed con la marca --test_bed. Por ejemplo:

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

Probar artefactos

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

• El directorio /tmp del artefacto de prueba tiene CameraITS_ antepuesto a la cadena aleatoria de 8 caracteres para mayor claridad.
• Los errores y la salida de prueba se almacenan en test_log.DEBUG para cada prueba en lugar de test_name_stdout.txt y test_name_stderr.txt.
• Los logcats de DUT y tablets de cada prueba individual se almacenan en el directorio /tmp/CameraITS_########, lo que simplifica la depuración, ya que se registra toda la información necesaria para depurar problemas de 3A.

Probar cambios

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

scene0/test_jitter.py

La prueba test_jitter se ejecuta en cámaras ocultas físicas en Android 12.

scene1_1/test_black_white.py

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

En la siguiente tabla, se describen las dos pruebas individuales en Android 11.

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

scene1_1/test_burst_sameness_manual.py

La prueba test_burst_sameness_manual se ejecuta en cámaras ocultas físicas en Android 12.

scene1_2/test_tonemap_sequence.py

La prueba test_tonemap_sequence se ejecuta en cámaras LIMITED en Android 12.

scene1_2/test_yuv_plus_raw.py

La prueba test_yuv_plus_raw se ejecuta en cámaras ocultas físicas en Android 12.

scene2_a/test_format_combos.py

La prueba test_format_combos se ejecuta en cámaras LIMITED en Android 12.

scene3/test_flip_mirror.py

La prueba test_flip_mirror se ejecuta en cámaras LIMITED en Android 12.

scene4/test_aspect_ratio_and_crop.py

La búsqueda de círculos en scene4/test_aspect_ratio_and_crop.py se refactorizó en Android 12.

Las versiones anteriores de Android usaban un método que implicaba encontrar un contorno secundario (el círculo) dentro del contorno superior (el cuadrado) con filtros de tamaño y color. Android 12 usa un método que implica encontrar todos los contornos y, luego, filtrar por la búsqueda de funciones que sean más circulares. Para descartar círculos falsos 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.

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 con el recorte del cuadro delimitador en algunas tablets de pantalla. Todos los candidatos a círculos se registran con fines de depuración.

En Android 12, la prueba de recorte se ejecuta para dispositivos FULL y LEVEL3. Android 11 o versiones anteriores omiten las aserciones de prueba de recorte para dispositivos FULL.

En la siguiente tabla, se enumeran las aserciones para test_aspect_ratio_and_crop.py que corresponden a un nivel de dispositivo y un primer nivel de API determinados.

scene4/test_multi_camera_alignment.py

Se refactorizó el método undo_zoom() para capturas YUV en scene4/test_multi_camera_alignment.py para tener en cuenta con mayor precisión el recorte en sensores que no coinciden con la relación de aspecto de la captura.

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

En Android 12, se agrega un método para detectar funciones en imágenes para la prueba de fusión de sensores.

En Android 11 y versiones anteriores, se usa toda la imagen para encontrar las 240 funciones más adecuadas, que luego se enmascaran al 20% central para evitar efectos de obturador rodante, con el requisito mínimo de funciones de 30 funciones.

Si las funciones que encuentra este método son insuficientes, Android 12 enmascara el área de detección de funciones al 20% central primero y limita las funciones máximas a dos veces el requisito mínimo de funciones.

En la siguiente imagen, se muestra la diferencia entre la detección de funciones de Android 11 y Android 12. Si se aumenta el umbral mínimo de requisitos de funciones, se detectan funciones de baja calidad y se afectan negativamente las mediciones.

Figura 2: Diferencia en la detección de funciones entre Android 11 y Android 12

Nuevas pruebas

scene0/test_solid_color_test_pattern.py

Se habilitó una nueva prueba, test_solid_color_test_pattern, para Android 12. Esta prueba está habilitada para todas las cámaras y se describe en la siguiente tabla.

Se deben habilitar los patrones de prueba de color sólido para admitir el modo de privacidad de la cámara. La prueba test_solid_color_test_pattern confirma la salida de imagen YUV de color sólido con el color definido por el patrón seleccionado, y los cambios de color de la imagen según la especificación.

Parámetros

• cameraPrivacyModeSupport: Determina si la cámara admite el modo de privacidad.
• android.sensor.testPatternMode: Establece el modo de patrón de prueba. Esta prueba usa SOLID_COLOR.
• android.sensor.testPatternData: Establece los valores de patrón de prueba R, Gr, Gb y G para el modo de patrón de prueba.

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

Método

Se capturan fotogramas YUV para los parámetros establecidos y se valida el contenido de la imagen. El patrón de prueba se genera directamente desde el sensor de imagen, por lo que no se requiere ninguna escena en particular. Si se admite PER_FRAME_CONTROL, se captura un solo fotograma YUV para cada configuración probada. Si no se admite PER_FRAME_CONTROL, se capturan cuatro fotogramas y solo se analiza el último para maximizar la cobertura de prueba en cámaras LIMITED.

Las capturas YUV se configuran en patrones de prueba BLACK, WHITE, RED, GREEN y BLUE completamente saturados. Como la definición del patrón de prueba es según el patrón Bayer del sensor, los canales de color deben establecerse para cada color, como se muestra en la siguiente tabla.

Tabla de aserciones

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

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 frontal y posterior con la escena de rostro scene2_c.

scene2_c/test_jpeg_capture_perf_class.py

Verifica que la latencia de captura JPEG de 1080p sea inferior a 1 segundo para las cámaras primarias frontal y posterior con la escena de rostro scene2_c.