En la versión de Android 12, se incluyen varios cambios en las ITS de la cámara. En esta página, se resumen los cambios, que se dividen en cuatro categorías generales:
- Refactorización a Python 3
- Adopción del marco de trabajo de pruebas de Mobly
- Probar cambios
- Pruebas nuevas
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 refactorizó a Python 3.
Todas las pruebas individuales se refactorizan y usan la nueva clase de configuración de pruebas definida en tests/its_base_test.py. La mayoría de los nombres y las 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 prueba, permite depurar pruebas individuales.
Para obtener más información sobre los cambios en las pruebas individuales, consulta Cambios en las pruebas.
Los siguientes módulos de Python se refactorizaron con un cambio de nombre:
pymodules/its/caps.py→utils/camera_properties_utils.pypymodules/its/cv2image.py→utils/opencv_processing_utils.pypymodules/its/device.py→utils/its_session_utils.pypymodules/its/error.py→utils/error_util.pypymodules/its/image.py→utils/image_processing_utils.pypymodules/its/objects.py→utils/capture_request_utils.pypymodules/its/target.py→utils/target_exposure_utils.pytools/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. El ITS de la cámara usa la infraestructura de pruebas de Mobly para permitir un mejor control y registro de las pruebas.
El 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 bajo prueba (DUT) y una tablet de gráficos en la clase its_base_test. Se usa un archivo config.yml (YAML) para crear un banco de pruebas de Mobly. Se pueden configurar varios bancos de pruebas en este archivo de configuración, por ejemplo, un banco de pruebas de tablet y otro de fusión de sensores. En la sección del controlador de cada banco de pruebas, puedes especificar device_ids para identificar los dispositivos Android adecuados para el ejecutor de pruebas. Además de los IDs de dispositivo, en la clase de prueba se pasan otros parámetros, como brightness, chart_distance, debug_mode, camera_id y scene_id de la tablet. 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
En el caso de las pruebas basadas en tablets, 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 ejemplo 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
El banco de pruebas se puede invocar 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 de los archivos de configuración camera y scene en la línea de comandos con comandos similares a los de 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 de la plataforma de pruebas debe incluir la palabra clave SENSOR_FUSION. El banco de pruebas correcto se determina según las escenas probadas. Android 12 admite los controladores de Arduino y Canakit para la fusión de sensores.
A continuación, se muestra un ejemplo de archivo config.yml 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
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 una plataforma de pruebas de tablet y una plataforma de pruebas de fusión de sensores.
El siguiente es un ejemplo de un archivo config.yml con bancos de pruebas de tablet 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 seguirán 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 testbed no puede incluir un ID de tablet.
El siguiente es un archivo config.yml de ejemplo 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
Cómo probar 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 las pruebas se realizan 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 la tablet, ya que la configuración de la clase de prueba asigna el valor del ID de serie para la tablet.
Cómo ejecutar 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 reemplazar 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 banco de pruebas en el archivo de configuración, debes especificar el banco de pruebas con la marca --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 del ITS de la cámara se almacenan de manera similar a Android 11 o versiones anteriores, pero con los siguientes cambios:
- Para mayor claridad, el directorio del artefacto de prueba
/tmptieneCameraITS_antepuesto a la cadena aleatoria de 8 caracteres. - Los errores y los resultados de las pruebas se almacenan en
test_log.DEBUGpara cada prueba en lugar detest_name_stdout.txtytest_name_stderr.txt. - Los registros de logcat del DUT y la tablet de cada prueba individual se almacenan en el directorio
/tmp/CameraITS_########, lo que simplifica la depuración, ya que se registran todos los datos necesarios para depurar problemas de 3A.
Prueba los cambios
En Android 12, las escenas de la tablet 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
En 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.
| Nombre de la prueba | Primer nivel de API | Aserciones |
|---|---|---|
| scene1_1/test_black_white.py | TODOS | Valores RGB de exposición corta y ganancia baja: ~[0, 0, 0] Valores RGB de exposición larga y ganancia alta: ~[255, 255, 255] |
| scene1_1/test_channel_saturation.py | 29 | Se redujo la tolerancia en las diferencias de [255, 255, 255] para eliminar el tinte de color en las imágenes blancas. |
En la siguiente tabla, se describe la prueba combinada, scene1_1/test_black_white.py, en Android 12.
| Nombre de la prueba | Primer nivel de API | Aserciones |
|---|---|---|
| scene1_1/test_black_white.py | TODOS | Valores RGB de exposición corta y ganancia baja ~[0, 0, 0] Valores RGB de exposición larga y ganancia alta ~[255, 255, 255] y tolerancia reducida entre los valores para eliminar el tinte de color en las imágenes blancas. |
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 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 por las características más circulares. Para filtrar los círculos falsos en la pantalla, se requiere un área de contorno mínima, y el contorno del círculo debe ser negro.
En la siguiente imagen, se muestran los contornos y sus criterios de selección.
Figura 1: Dibujo conceptual de los contornos y los criterios de selección
El método de Android 12 es más simple y funciona para resolver el problema de recorte de la caja delimitadora en algunas tablets con pantalla. Todos los candidatos a círculos se registran para fines de depuración.
En Android 12, la prueba de recorte se ejecuta para dispositivos FULL y LEVEL3. Android 11 y las versiones anteriores omiten las aserciones de prueba de recorte para los 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.
| Nivel del dispositivo | Primer nivel de API | Aserciones |
|---|---|---|
| LIMITED | TODOS | Relación de aspecto FOV para formatos 4:3, 16:9 y 2:1 |
| COMPLETO | < 31 | Relación de aspecto FOV para formatos 4:3, 16:9 y 2:1 |
| COMPLETO | ≥ 31 | Recorte Relación de aspecto FOV para formatos 4:3, 16:9 y 2:1 |
| LEVEL3 | TODOS | Recorte Relación de aspecto FOV para formatos 4:3, 16:9 y 2:1 |
scene4/test_multi_camera_alignment.py
Se refactorizó el método undo_zoom() para las capturas de YUV en scene4/test_multi_camera_alignment.py para tener en cuenta con mayor precisión el recorte en los 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 agregó un método para detectar características en imágenes para la prueba de fusión de sensores.
En versiones anteriores a Android 12, se usa la imagen completa para encontrar las mejores 240 características, que luego se enmascaran en el 20% central para evitar los efectos de obturador rotatorio, con un requisito mínimo de 30 características.
Si las características que encuentra este método son insuficientes, Android 12 enmascara el área de detección de características en el 20% central primero y limita las características máximas al doble del requisito mínimo de características.
En la siguiente imagen, se muestra la diferencia entre la detección de funciones de Android 11 y Android 12. Aumentar el umbral mínimo de requisitos de funciones genera la detección de funciones 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
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.
| Scene | Nombre de la prueba | Primer nivel de API | Descripción |
|---|---|---|---|
| 0 | test_solid_color_test_pattern | 31 | Confirma la salida de imágenes de color sólido y la capacidad de programación del color de la imagen. |
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 imágenes 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. En esta prueba, se usaSOLID_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 los 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 parámetro de configuración probado. Si no se admite PER_FRAME_CONTROL, se capturan cuatro fotogramas, y solo se analiza el último para maximizar la cobertura de la prueba en las 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 se basa en el patrón de Bayer del sensor, los canales de color se deben establecer para cada color, como se muestra en la siguiente tabla.
| Color | testPatternData (RGGB) |
|---|---|
| NEGRO |
(0, 0, 0, 0)
|
| BLANCO |
(1, 1, 1, 1)
|
| RED |
(1, 0, 0, 0)
|
| VERDE |
(0, 1, 1, 0)
|
| AZUL |
(0, 0, 0, 1)
|
Tabla de aserción
En la siguiente tabla, se describen 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 | MONO | BLANCO Y 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 principales 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 principales frontal y posterior con la escena de rostro scene2_c.