Se incluyen varios cambios en la cámara ITS en la versión de Android 12. Esta página resume los cambios que se dividen en cuatro categorías amplias:
Refactorizar 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:
- Python 3.7.9 o Python 3.7.10
- OpenCV 3.4.2
- Numerosos 1.19.2
- Matplotlib 3.3.2
- Scipy 1.5.2
- pySerial 3.5
- Almohada 8.1.0
- PyYAML 5.3.1
El iniciador de pruebas principal, tools/run_all_tests.py , sigue siendo el mismo que las versiones Android 11 o inferiores y está refactorizado a Python 3.
Todas las pruebas individuales se refactorizan y utilizan la nueva clase de configuración de prueba definida 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 general de la 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 Mobly
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 archivo config.yml (YAML) para crear un banco de pruebas de 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 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 del dispositivo, en la clase de prueba se pasan otros parámetros como brightness de la tableta, chart_distance , debug_mode , camera_id y scene_id . Los valores de 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 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 camera y scene en la línea de comando usando comandos similares a Android 11 o anterior.
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 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 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 tableta 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 siendo compatibles con 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 identificación 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 las escenas 0 y 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 el ID de serie de la tableta debe ser válido aunque no se utilice porque la configuración de la clase de prueba asigna el valor de ID de serie para la tableta.
Ejecute 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 del artefacto de prueba
/tmptieneCameraITS_antepuesto a la cadena aleatoria de 8 caracteres para mayor claridad. - Los resultados de las pruebas 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 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 físicas ocultas en Android 12.
escena1_1/prueba_negro_blanco.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 API | Afirmaciones |
|---|---|---|
| escena1_1/prueba_negro_blanco.py | TODO | Exposición corta, valores RGB de baja ganancia ~[0, 0, 0] Exposición larga, valores RGB de alta ganancia ~[255, 255, 255] |
| escena1_1/test_channel_saturation.py | 29 | Tolerancia reducida en diferencias [255, 255, 255] para eliminar el tinte de color en imágenes blancas. |
La siguiente tabla describe la prueba fusionada, scene1_1/test_black_white.py, en Android 12.
| Nombre de la prueba | Primer nivel API | Afirmaciones |
|---|---|---|
| escena1_1/prueba_negro_blanco.py | TODO | 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 físicas ocultas 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/test_yuv_plus_raw.py
La prueba test_yuv_plus_raw se ejecuta en cámaras físicas ocultas en Android 12.
escena2_a/test_format_combos.py
La prueba test_format_combos se ejecuta en cámaras LIMITADAS en Android 12.
escena3/test_flip_mirror.py
La prueba test_flip_mirror se ejecuta en cámaras LIMITADAS en Android 12.
escena4/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 utilizaban 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 implica encontrar todos los contornos y luego filtrar para encontrar las características más circulares . Para eliminar 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 del recorte del cuadro delimitador en algunas tabletas con pantalla. Todos los candidatos al 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 inferiores omiten las afirmaciones de la prueba de cultivo para dispositivos FULL .
La siguiente tabla enumera las aserciones para test_aspect_ratio_and_crop.py que corresponden a un nivel de dispositivo determinado y al primer nivel de API.
| Nivel de dispositivo | Primer nivel API | Afirmaciones |
|---|---|---|
| LIMITADO | TODO | 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 | TODO | Cultivo relación de aspecto FoV para formatos 4:3, 16:9, 2:1 |
escena4/test_multi_camera_alignment.py
El método undo_zoom() para capturas YUV en scene4/test_multi_camera_alignment.py fue refactorizado 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 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 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 características en imágenes para la prueba de fusión de sensores.
En versiones inferiores a Android 12, la imagen completa se utiliza para encontrar las mejores 240 funciones que luego se enmascaran en el centro un 20 % para evitar efectos de persiana enrollable y el requisito mínimo de funciones es 30 funciones.
Si las funciones encontradas con este método son insuficientes, Android 12 enmascara primero el área de detección de funciones hacia el centro un 20 % 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 funciones 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 mala calidad y afecta negativamente a las mediciones.
Figura 2. Diferencia en la detección de funciones entre Android 11 y Android 12
Nuevas pruebas
escena0/test_solid_color_test_pattern.py
Hay una nueva prueba, test_solid_color_test_pattern , 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 API | Descripción |
|---|---|---|---|
| 0 | prueba_color_sólido_patrón_prueba | 31 | Confirma la salida de imágenes en colores sólidos y la programabilidad del color de las imágenes. |
Los patrones de prueba de colores sólidos deben estar habilitados para admitir el modo de privacidad de la cámara. La prueba test_solid_color_test_pattern confirma la salida de la imagen YUV en 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 utilizaSOLID_COLOR. -
android.sensor.testPatternData: establece los valores del 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
Se capturan fotogramas YUV para los parámetros establecidos y se valida el contenido de la imagen. El patrón de prueba sale directamente del sensor de imagen, por lo que no se requiere ninguna escena en particular. Si se admite PER_FRAME_CONTROL , se captura un único fotograma YUV para cada configuración probada. Si no se admite PER_FRAME_CONTROL , se capturan cuatro fotogramas y solo se analiza el último fotograma para maximizar la cobertura de la prueba en cámaras LIMITED .
Las capturas YUV están configuradas en patrones de prueba BLACK , WHITE , RED , GREEN y BLUE completamente saturados. Como la definición del patrón de prueba se basa en el patrón Bayer del sensor, los canales de color deben configurarse para cada color como se muestra en la siguiente tabla.
| Color | pruebaPatternData (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 afirmaciones de prueba para test_solid_color_test_pattern.py .
| Cámara Primer nivel 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
escena2_c/test_camera_launch_perf_class.py
Verifica que el inicio de la cámara sea inferior a 500 ms para las cámaras principales delantera y trasera con la escena de rostro scene2_c.
escena2_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 principales delantera y trasera con la escena de rostro scene2_c.