En la versión de Android 12 se incluyen varios cambios de Camera ITS . Esta página resume los cambios que se dividen en cuatro amplias categorías:
Refactorización a Python 3
Debido a la obsolescencia de Python 2.7 en enero de 2020, todo el código base de Camera ITS se refactorizó a Python 3. Se requieren las siguientes versiones y bibliotecas de Python en Android 12:
- Pitón 3.7.9 o Pitón 3.7.10
- OpenCV 3.4.2
- Numpy 1.19.2
- Matplotlib 3.3.2
- Scipy 1.5.2
- PySerial 3.5
- Almohada 8.1.0
- PyYAML 5.3.1
El lanzador de pruebas principal, tools/run_all_tests.py , sigue siendo el mismo que las versiones de Android 11 o anteriores y se refactorizó 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 ahora cargan sus escenas. Si bien la carga de escenas para cada prueba aumenta el tiempo total de prueba, permite la depuración de pruebas individuales.
Para obtener más información sobre los cambios de prueba individuales, consulte Cambios de prueba .
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 marco de prueba de Mobilly
Mobly es un marco de prueba basado en Python que admite casos de prueba que requieren múltiples dispositivos con configuraciones de hardware personalizadas. 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 múltiples dispositivos con configuraciones de hardware personalizadas. Para obtener más información sobre Mobly, consulte google/mobly .
archivos config.yml
Con el marco Mobly, puede configurar un dispositivo bajo prueba (DUT) y una tableta gráfica en la clase its_base_test . Se utiliza un config.yml (YAML) para crear un banco de pruebas de Mobly. Se pueden configurar múltiples 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 del controlador de cada banco de pruebas, puede especificar device_ids para identificar los dispositivos Android apropiados para el ejecutor de pruebas. Además de los ID de dispositivo, en la clase de prueba se pasan otros parámetros como el brightness de la tableta, chart_distance , debug_mode , camera_id y scene_id . Los valores comunes de los parámetros de prueba 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 tabletas, la palabra clave TABLET debe estar presente en el nombre del banco de pruebas. 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 tabletas.
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 usando tools/run_all_tests.py . Si no hay valores de línea de comando presentes, las pruebas se ejecutan con los valores del archivo config.yml . Además, puede anular los valores del archivo de configuración de la camera y la scene en la línea de comandos usando 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 banco de pruebas debe incluir la palabra clave SENSOR_FUSION . El banco de pruebas correcto está determinado por las escenas probadas. Android 12 es compatible con los 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 pruebas de fusión de sensores , utilice:
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 archivo config.yml de muestra con bancos de pruebas de fusión de sensores y tabletas.
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 siguen admitiéndose en Android 12. Sin embargo, el banco de pruebas debe identificar las pruebas como tales con la palabra clave MANUAL en el nombre del banco de pruebas. Además, el banco de pruebas no puede incluir una ID de tableta.
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
Escenas de prueba sin tabletas
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 tableta debe estar conectada y la identificación de serie de la tableta debe ser válida aunque la tableta no se use porque la configuración de la clase de prueba asigna el valor de identificación de serie para la tableta.
Ejecución de pruebas individuales
Las pruebas individuales se pueden ejecutar solo con fines de depuración porque sus resultados no se informan a CTS Verifier . Debido a que los archivos config.yml no se pueden sobrescribir en la línea de comando 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 banco de pruebas en el archivo de configuración, debe especificar el banco de pruebas con el indicador --test_bed . Por ejemplo:
python tests/scene1_1/test_black_white.py --config config.yml --test_bed TEST_BED_TABLET_SCENES
Artefactos de prueba
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 directorio
/tmpdel artefacto de prueba tieneCameraITS_a la cadena aleatoria de 8 caracteres para mayor claridad. - La salida de la prueba y los errores se almacenan en
test_log.DEBUGpara cada prueba en lugar detest_name_stdout.txtytest_name_stderr.txt. - Los logcats del DUT y de la tableta 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 los problemas de 3A.
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.
escena0/test_jitter.py
La prueba test_jitter se ejecuta en cámaras ocultas físicas en Android 12.
escena1_1/prueba_blanco_negro.py
Para Android 12, test_black_white tiene la funcionalidad de 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 |
|---|---|---|
| escena1_1/prueba_blanco_negro.py | TODOS | Exposición corta, valores RGB de baja ganancia ~[0, 0, 0] Larga exposición, valores RGB de alta ganancia ~[255, 255, 255] |
| escena1_1/prueba_canal_saturación.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 |
|---|---|---|
| escena1_1/prueba_blanco_negro.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. |
escena1_1/test_burst_sameness_manual.py
La prueba test_burst_sameness_manual se ejecuta en cámaras ocultas físicas en Android 12.
escena1_2/test_tonemap_sequence.py
La prueba test_tonemap_sequence se ejecuta en cámaras LIMITADAS en Android 12.
escena1_2/prueba_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 LIMITADAS en Android 12.
scene3/test_flip_mirror.py
La prueba test_flip_mirror se ejecuta en cámaras LIMITADAS 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 consistía en encontrar un contorno secundario (el círculo) dentro del contorno principal (el cuadrado) con filtros de tamaño y color. Android 12 usa un método que implica encontrar todos los contornos y luego filtrar para encontrar las características que son más circulares . Para descartar 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.
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 tabletas de pantalla. Todos los candidatos del círculo 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 afirmaciones de prueba de recorte para dispositivos FULL .
La siguiente tabla enumera las aserciones para test_aspect_ratio_and_crop.py que corresponden a un nivel de dispositivo dado y al primer nivel de API.
| Nivel de dispositivo | Primer nivel de API | afirmaciones |
|---|---|---|
| LIMITADO | TODOS | Relación de aspecto FoV para formatos 4:3, 16:9, 2:1 |
| COMPLETO | < 31 | Relación de aspecto FoV para formatos 4:3, 16:9, 2:1 |
| COMPLETO | ≥ 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 capturas YUV en scene4/test_multi_camera_alignment.py se refactorizó 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 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/prueba_sensor_fusion.py
En Android 12, se agrega un método para detectar características en imágenes para la prueba de fusión de sensores.
En versiones anteriores a Android 12, la imagen completa se usa para encontrar las mejores 240 funciones que luego se enmascaran en el centro en un 20 % para evitar efectos de persiana enrollable con un requisito mínimo de 30 funciones.
Si las funciones encontradas por este método son insuficientes, Android 12 enmascara el área de detección de funciones al centro en un 20 % primero y limita las funciones máximas a dos veces el requisito mínimo de funciones.
La siguiente imagen muestra la diferencia entre la detección de características de Android 11 y Android 12. Elevar el umbral mínimo de requisitos de características da como resultado la detección de características de baja calidad y afecta 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
Una nueva prueba, test_solid_color_test_pattern , está habilitada para Android 12. Esta prueba está habilitada 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_patrón | 31 | Confirma la salida de imagen en 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. 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 el color de la imagen cambia 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 usaSOLID_COLOR. -
android.sensor.testPatternData: establece los valores de patrón de prueba R, Gr, Gb, G para el modo de patrón de prueba.
Para obtener una descripción del patrón de prueba de color sólido, consulte SENSOR_TEST_PATTERN_MODE_SOLID_COLOR .
Método
Los cuadros 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 ninguna escena en particular. Si se admite PER_FRAME_CONTROL , se captura un solo marco YUV para cada configuración probada. Si PER_FRAME_CONTROL no es compatible, se capturan cuatro cuadros y solo se analiza el último cuadro para maximizar la cobertura de prueba en cámaras LIMITED .
Las capturas YUV están configuradas en patrones de prueba BLACK , WHITE , RED , GREEN y BLUE completamente saturados. Dado que 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 | datos de patrón de prueba (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
La siguiente tabla describe las aserciones 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 principal delantera y trasera 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 principal delantera y trasera con la escena de rostros scene2_c.