En esta página, se resumen los cambios en el Paquete de prueba de imagen de la cámara (ITS) en Android 11. Los cambios se dividen en las siguientes categorías:
- Cambios de hardware
- Primeras pruebas OBLIGATORIAS a nivel de la API
- Validación de la iluminación de prueba
- Cambios en los nombres de las escenas
- Prueba los cambios y las incorporaciones
- Se aumentaron las pruebas LIMITADAS de la cámara
Cambios de hardware
Android 11 presenta varios cambios de hardware para reducir el costo y aumentar la disponibilidad. Estos cambios se incluyen en las siguientes categorías:
- Fabricante adicional
- Métodos de fabricación unificados
- Más opciones para tablets
- Reducción de la apertura de la tablet
- Nuevo controlador de fusión de sensores
Fabricante adicional
Rahi Systems está calificado para producir gabinetes de prueba de ITS, además de nuestro proveedor existente, MYWAY design. La información de la empresa de los proveedores calificados es la siguiente:
Rahi Systems Inc.
48303 Fremont Blvd, Fremont CA 94538, EE.UU.
rahisystems.com/products/android-device-testing-equipment/
androidpartner@rahisystems.com
+1-510-319-3802Diseño MYWAY
4F., No. 163, Fu-Ying Road, XinZhuang District, New Taipei City, Taiwán
twmyway.com
sales@myway.tw
+886-2-29089060
Métodos de fabricación unificados
El recinto de prueba del ITS integrado de campo visual regular (RFoV) de la revisión 1 se rediseñó para usar los métodos de fabricación que se usan en los recintos de prueba de la caja de campo visual amplio (WFoV) y de la caja de fusión de sensores. La funcionalidad es idéntica y, para simplificar, el diseño se conoce como rev1a. El rediseño permite a los fabricantes almacenar un solo tipo de plástico para fabricar todos los recintos de prueba. Además, el soporte para la tablet y los soportes de luz se rediseñaron para admitir una mayor variación en las tablets y las barras de luz LED.
Para descargar las descripciones y los dibujos mecánicos más recientes, consulta la caja de RFoV (rev1a) y la caja de WFoV (rev2.9).
Más opciones para tablets
Se agregaron a la lista de tablets recomendadas las tablets Samsung Galaxy Tab A 10.1 y Chuwi Hi9 Air 10.1. Es importante que la tablet no tenga modulación de ancho de pulso (PWM) para ajustar el brillo de la pantalla y eliminar las bandas en las imágenes capturadas.
Para obtener la información más reciente sobre las tablets recomendadas, consulta Requisitos de las tablets.
Se redujo la apertura de la tablet
Para permitir el uso de la Galaxy Tab A 10.1, la abertura de la tablet se reduce ligeramente en altura para las carcasas de prueba de RFoV (rev1a) y WFoV (rev2). Las revisiones que reflejan estos cambios son rev1a.1 y rev2.9. Para ver estos dibujos, consulta el cuadro de RFoV (rev1a) y el cuadro de WFoV (rev2.9).
Nuevo controlador de fusión de sensores
Se rediseñó el hardware del controlador de fusión de sensores para mejorar la manufacturabilidad. El nuevo controlador se basa en Arduino, con una placa de protección de la placa de enrutamiento personalizada que se monta encima del Arduino. En la figura 1, se muestra el blindaje y, en la figura 2, el dibujo mecánico del gabinete. El nuevo controlador se alimenta de una sola fuente de 5 V que alimenta el motor directamente. La electrónica se controla por completo a través del conector USB. La fuente de alimentación independiente permite un aislamiento completo entre la electrónica de control y el servomotor. Además, un solo controlador puede controlar hasta seis servomotores.
Figura 1: Vista superior de la placa Arduino
Figura 2: Diseño del gabinete
Android 11 es retrocompatible con los controladores existentes. Para invocar pruebas con el controlador basado en Arduino, usa lo siguiente:
python tools/run_all_tests.py device=# camera=# rot_rig=arduino:1 scenes=sensor_fusion
Primer nivel de API
En Android 10, las pruebas del ITS se designan como MANDATED y NOT_YET_MANDATED. Para iniciarse como un dispositivo Android 10, todas las pruebas de MANDATED deben aprobarse. Las pruebas de NOT_YET_MANDATED pueden fallar, pero se tabulan como PASS para los informes del verificador de CTS. El requisito de pruebas de MANDATED también se aplica a los dispositivos actualizados. Este requisito de que los dispositivos actualizados aprueben todas las pruebas de MANDATED provocó que las pruebas se retrasaran en convertirse en pruebas de MANDATED, ya que los dispositivos más antiguos también deben aprobarlas.
En Android 11, las pruebas de MANDATED están controladas por la primera marca de nivel de API de las propiedades del teléfono. En el caso de los dispositivos que se actualizan a Android 11, las pruebas se ejecutan como pruebas NOT_YET_MANDATED, lo que significa que una prueba puede fallar, pero se tabula como PASS en CtsVerifier.apk.
Por ejemplo:
- En Android 11, la prueba
test_channel_saturationesMANDATEDpara dispositivos con un primer nivel de API superior a 29. - En Android 10, la prueba
test_channel_saturationesMANDATEDpara todos los dispositivos.
Validación de la iluminación de la escena
En Android 11, se valida la iluminación de la escena analizando el brillo en las esquinas de la escena. Todas las escenas manuales se validan para la iluminación, y las escenas basadas en tablets se validan para las cámaras RFoV en la plataforma de prueba RFoV y las cámaras WFoV en la plataforma de prueba WFoV. Si los niveles de iluminación son inadecuados, se informa un error y la prueba falla.
Cambios en el nombre de la escena
En Android 10, la escena 1 representa la mayoría de las pruebas y un gran porcentaje del tiempo total de prueba. Si falla alguna prueba de la escena 1, se debe volver a ejecutar toda la escena. De forma predeterminada, volver a ejecutar toda la escena reduce el paso de pruebas marginales. En Android 11, se reducen los tiempos de repetición dividiendo la escena 1 en dos escenas: scene1_1 y scene1_2.
En la siguiente tabla, se muestran los tiempos de prueba tabulados de la cámara posterior del Pixel 4 para diferentes escenas. La cantidad de pruebas se divide para igualar el tiempo de prueba, no para igualar la cantidad de pruebas.
Además, se realiza una limpieza de nombres. La escena 2 se divide con letras y la escena 1 se divide con números. La nomenclatura de las diferentes extensiones es la siguiente:
- Escenas con el mismo gráfico, pero con diferentes pruebas:
*_1,2,3 - Escenas con gráficos diferentes, pero con las mismas pruebas:
*_a,b,c
| Scene | Cantidad de pruebas | Tiempo de ejecución del Pixel 4 (min:seg) |
|---|---|---|
| 0 | 11 | 1:12 |
| 1_1 | 22 | 5:12 |
| 1_2 | 13 | 5:20 |
| 2_a | 5 | 3:22 |
| 2_b | 1 | 0:24 |
| 2_c | 1 | 0:24 |
| 3 | 6 | 2:04 |
| 4 | 2 | 2:46 |
Prueba los cambios
Se actualizaron las pruebas para usar el primer nivel de API
En Android 11, las pruebas de la siguiente tabla se actualizaron para usar la primera marca de nivel de API. Todas estas pruebas usan un primer nivel de API de 29, excepto la prueba de test_tonemap_curve, que usa un primer nivel de API de 30.
| Scene | Nombre de la prueba | Primer nivel de API | Descripción |
|---|---|---|---|
| 0 | test_tonemap_curve |
30 | Asegúrate de que la canalización tenga salidas de color adecuadas con un mapa de tonos lineal y una entrada de imagen ideal (depende de test_test_patterns). |
| 1 | test_ae_precapture_trigger |
29 | Prueba la máquina de estados de AE cuando uses el activador de captura previa. Asegúrate de que el activador previo a la captura inhabilitado de AE no tenga efecto. |
test_channel_saturation |
29 | Asegúrate de que los canales RGB saturen a valores similares para eliminar el tono en las regiones saturadas. | |
| 2_a/b/c | test_num_faces |
29 | Aumenta la diversidad de edades en las escenas de rostros. |
Pruebas con cambios
Las pruebas de la siguiente tabla se actualizaron en Android 11. Los cambios se describen en la columna Descripción de los cambios.
| Scene | Nombre de la prueba | Primer nivel de API | Descripción de los cambios |
|---|---|---|---|
| 1 | test_burst_sameness_manual |
30 | Reduce la tolerancia al 2%. |
| 4 | test_aspect_ratio_and_crop |
30 | Se cambió para ejecutarse en dispositivos LIMITADOS. |
test_multi_camera_alignment |
30 | Pasa por las cámaras de forma individual si no se admite la captura con varias cámaras. Reformula la lógica de selección de cámaras para tener en cuenta los sistemas de tres y cuatro cámaras, y omite las cámaras mono, solo de profundidad y de IR. |
Pruebas nuevas
Las pruebas de la siguiente tabla están habilitadas en Android 11. Las pruebas se resumen en la tabla y se proporcionan descripciones detalladas en las siguientes secciones.
| Scene | Nombre de la prueba | Primer nivel de API | Descripción |
|---|---|---|---|
| 0 | test_vibration_restrictions |
30 | Asegúrate de que no se activen las alertas ni las vibraciones durante la captura de imágenes. |
| 2_a | test_jpeg_quality |
30 | Prueba que las tablas de cuantificación disminuyan la compresión para mejorar la calidad de JPEG. |
| 2_d/2_e | test_num_faces |
30 | Aumenta la diversidad de edad de los rostros. |
| 2_e | test_continuous_picture |
30 | Asegúrate de que 3A se establezca en android.control.afAvailableModes =
CONTINUOUS_PICTURE.. |
| cambiar | test_scene_change |
31 | android.control.afSceneChange se afirmaba cuando cambiaba la escena. |
| 6 | test_zoom |
30 | Prueba android.control.zoomRatioRange. |
scene0/test_vibration_restriction
Esta prueba no requiere una escena específica, pero el dispositivo en prueba (DUT) debe colocarse o montarse en una superficie dura. Esto incluye el montaje en los gabinetes de prueba de ITS en una caja.
Aserciones
- No hay vibraciones durante el uso de la cámara.
scene2_a/test_jpeg_quality
Método
Las diferentes partes del archivo JPEG se definen con marcadores de 2 bytes. Para obtener más información, consulta JPEG.
La prueba extrae las matrices de cuantificación de la captura de JPEG. El marcador para las matrices de cuantificación en la captura de JPEG es la secuencia [255, 219]. Cuando se encuentra el marcador, los siguientes dos elementos de la lista son el tamaño. El marcador de tamaño de DQT JPEG suele ser [0, 132] = 256 × 0 + 132 = 132, que representa el tamaño de los datos de DQT en la captura de JPEG. Los datos incorporados tienen el siguiente formato: [255, 219, 0, 132, 0 (marcador de luma), matriz de luma de 8 × 8, 1 (marcador de crominancia), matriz de crominancia de 8 × 8].
El 0 para el marcador de matriz de luma y el 1 para el marcador de crominancia parecen ser coherentes para varios dispositivos, incluidos los teléfonos que separan las dos matrices en secciones DQT independientes en el archivo JPEG. Las matrices de luma suelen tener una variedad de valores más alta en comparación con las matrices de crominancia, ya que el ojo humano es más sensible a la luma que a la crominancia, y las imágenes JPEG tienen esto en cuenta.
A continuación, se muestran ejemplos de matrices de luma y croma extraídas para factores de calidad de 85 y 25 para la cámara posterior del Pixel 4 que captura la escena2_a con el equipo de prueba de ITS.
Los valores de la matriz aumentan (lo que indica una mayor compresión) de manera significativa para la configuración de calidad más baja. Estas matrices solo se imprimen con la secuencia de comandos si se aplica la marca debug=True. Observa la mayor variación en las entradas de las matrices de luma en comparación con las matrices de crominancia.
luma matrix (quality = 85) chroma matrix (quality = 85)
[[ 5 3 4 4 4 3 5 4] [[ 5 5 5 7 6 7 14 8]
[ 4 4 5 5 5 6 7 12] [ 8 14 30 20 17 20 30 30]
[ 8 7 7 7 7 15 11 11] [30 30 30 30 30 30 30 30]
[ 9 12 17 15 18 18 17 15] [30 30 30 30 30 30 30 30]
[17 17 19 22 28 23 19 20] [30 30 30 30 30 30 30 30]
[26 21 17 17 24 33 24 26] [30 30 30 30 30 30 30 30]
[29 29 31 31 31 19 23 34] [30 30 30 30 30 30 30 30]
[36 34 30 36 28 30 31 30]] [30 30 30 30 30 30 30 30]]
luma matrix (quality = 25) chroma matrix (quality = 25)
[[ 32 22 24 28 24 20 32 28] [[ 34 36 36 48 42 48 94 52]
[ 26 28 36 34 32 38 48 80] [ 52 94 198 132 112 132 198 198]
[ 52 48 44 44 48 98 70 74] [198 198 198 198 198 198 198 198]
[ 58 80 116 102 122 120 114 102] [198 198 198 198 198 198 198 198]
[112 110 128 144 184 156 128 136] [198 198 198 198 198 198 198 198]
[174 138 110 112 160 218 162 174] [198 198 198 198 198 198 198 198]
[190 196 206 208 206 124 154 226] [198 198 198 198 198 198 198 198]
[242 224 200 240 184 202 206 198]] [198 198 198 198 198 198 198 198]]
En la Figura 3, se muestran los valores promedio de la matriz de la cámara posterior del Pixel 4 en comparación con la calidad JPEG. A medida que aumenta la calidad del JPEG, disminuye el nivel de compresión (promedio de la matriz de DQT de luma/croma).
Figura 3: Promedios de la matriz DQT de luma/croma de la cámara posterior del Pixel 4 en comparación con la calidad de JPEG
Aserciones
- Para [25, 45, 65, 86], +20 en calidad tiene un 20% de reducción en los promedios de la matriz de cuantificación.
- Las cargas útiles de la matriz DQT son números cuadrados.
En la Figura 4, se muestra un ejemplo de un teléfono que no pasa la prueba. Ten en cuenta que, para las imágenes de muy baja calidad (jpeg.quality < 50), no hay un aumento en la compresión en la matriz de cuantificación.
Figura 4: Ejemplo de prueba fallida
scene2_d/e test_num_faces
Se agregaron dos escenas de detección de rostros nuevas para aumentar la diversidad facial de las verificaciones del algoritmo de detección de rostros. Con pruebas repetidas de varias cámaras, se espera que el rostro más desafiante sea el de la izquierda en scene2_d. En particular, la modelo tiene un sombrero y una barba, algo nuevo en las escenas de rostro. Las escenas nuevas se muestran en las figuras 5 y 6.
Figura 5: scene2_d
Figura 6: scene2_e
Aserciones
num_faces == 3
scene2_e/test_continuous_picture
Método
La prueba test_continuous_picture usa scene2_e, pero se puede habilitar con cualquiera de las escenas de rostros. En esta prueba, se capturan 50 fotogramas de resolución VGA con la solicitud de captura que primero establece android.control.afMode = 4
(CONTINUOUS_PICTURE).
Se espera que el sistema de 3A se haya estabilizado al final de una captura de 50 fotogramas.
Aserciones
- 3A está en estado de convergencia al final de la captura.
scene_change/test_scene_change
Método
Se habilitó una prueba nueva para verificar si se confirma la marca android.control.afSceneChange con un cambio de escena. El cambio de escena usa la tablet para mostrar una escena de rostro y, luego, encender y apagar la tablet para crear un cambio de escena. La escena reutiliza scene2_e, pero está en una escena independiente debido al control de la tablet requerido.
Además, para las pruebas manuales, puedes agitar la mano frente a la cámara para cambiar de escena.
En la Figura 7, se muestra un diagrama de tiempos de la prueba. El tiempo entre el apagado de la pantalla y la captura se ajusta en función de los resultados de eventos de capturas anteriores.
Figura 7: Diagrama de tiempos de test_scene_change
Condiciones del turno:
- Si hay un cambio de escena y
afSceneChange == 1, la prueba muestraPASS. - Si hay un cambio de escena y
afSceneChange == 0, el cambio de escena se desplaza 5 fotogramas antes para darle más tiempo aafSceneChangepara confirmar. - Si no hay un cambio de escena y
afSceneChange == 1, la prueba muestraFAIL. - Si no hay un cambio de escena y
afSceneChange == 0, el cambio de escena se desplaza 30 fotogramas antes para obtener el cambio de escena en la captura.
Aserciones
- Activadores de pantalla (escena).
- La marca
afSceneChangeestá en [0, 1]. - Si no hay cambios de escena, 3A converge (funcionalmente idéntico a
test_continuous_picture). - Si es
afSceneChange == 1, el brillo debe cambiar en la escena. PASSen seis intentos con el tiempo modificado en función de los resultados anteriores.
scene6/test_zoom
Método
Se requiere una escena nueva para probar android.control.zoomRatioRange, ya que las escenas establecidas no tienen un componente lo suficientemente pequeño como para que se pueda ampliar (escenas [1, 2, 4]) o tienen muchos objetos que no se identifican fácilmente, lo que complica la extracción de componentes (escena 3).
En la Figura 8, se muestra la nueva escena con un array regular de círculos. El array de círculos relaja los requisitos de centrado del DUT o del gráfico y permite que un círculo siempre esté cerca del centro de la imagen capturada. En esta escena, un array de 9 x 5 círculos con un borde negro cubre toda la tablet. Un círculo se reemplaza por un cuadrado en la esquina superior derecha para mostrar la orientación. Los tamaños de los círculos tienen una característica con un área de alrededor de 7,500 píxeles (radius=50pixels) para un sensor de 4,000 × 3,000 capturado con un campo visual (FoV) de alrededor de 80 grados.
Figura 8: Escena test_zoom
Figura 9: Zoom de la cámara [0] del Pixel 4 = [1, 3.33, 5.67, 8] imágenes con círculo encontrado
En la Figura 9, se muestran las imágenes capturadas de la cámara posterior de un Pixel 4 a medida que el zoom aumenta de 1 a 8 veces con cuatro pasos. Este conjunto de imágenes se captura sin tener cuidado específico en el centrado, excepto por usar la apertura de prueba del teléfono con dos aberturas para permitir la prueba de las cámaras frontal y posterior. Se espera un desplazamiento del centro, que se observa cuando la tablet del gráfico está ligeramente a la izquierda del centro. Además, el gráfico parece ser suficiente para probar con relaciones de zoom superiores a 8x.
Cómo encontrar círculos
La prueba incluye un método find_circle() que usa findContours para encontrar todos los contornos y limita la búsqueda de contornos hasta los círculos deseados probando lo siguiente:
- Los contornos deben tener un área superior a 10 píxeles.
- Los contornos deben tener
NUM_PTS >= 15. - Los contornos deben tener centros negros.
- Los contornos deben parecerse a un círculo, es decir, su área está cerca del área pi*r2 del contorno.
Rango de prueba
android.control.zoomRatioRange se divide en 10 pasos.
- [1, 7] pruebas [1, 1.67, 2.33, 3, 3.67, 4.33, 5, 5.67, 6.33, 7]
El zoom se detiene si el círculo encontrado toca los límites de la imagen. Hay una verificación para asegurarse de que se alcance un nivel de zoom suficiente en la prueba (10x).
Aserciones
- Se encuentra al menos un círculo en cada configuración de zoom.
- Se prueba 10 veces o un máximo de
android.control.zoomRatioRange. - El radio del círculo se ajusta con el zoom (RTOL 10% de lo esperado).
- Desplazamiento del centro del círculo desde el centro de escala con zoom (RTOL 10% de lo esperado).
- Se alcanza un nivel de zoom suficiente (2x).
Se aumentaron las pruebas LIMITADAS de la cámara
En Android 11, las pruebas de la siguiente tabla miden las cámaras LIMITED. Además de las pruebas nuevas, se actualizó la prueba scene4/test_aspect_ratio_and_crop para permitir pruebas de dispositivos LIMITED con un primer nivel de API de 30 o superior.
| Scene | Nombre de la prueba |
|---|---|
| 0 | test_vibration_restrictions |
| 2_a | test_jpeg_quality |
| 2_d/2_e | test_num_faces |
| 4 | test_aspect_ratio_and_crop |
| 6 | test_zoom |
En la Figura 10, se muestra el anillo de decodificación secreto del ITS de Android 11. El anillo de decodificador secreto muestra los parámetros de configuración de prueba que controlan las pruebas individuales. La limitación está codificada por colores para facilitar la visualización. Los elementos de control de acceso principales son los siguientes:
MANUAL_SENSORREAD_3A*requiereMANUAL SENSORCOMPUTE_TARGET_EXPOSURES*requiereMANUAL SENSORPER_FRAME_CONTROLRAWSENSORS*REALTIMEMULTI_CAMERA
MANUAL SENSOR, READ_3A, COMPUTE_TARGET_EXPOSURES y PER_FRAME_CONTROL controlan la mayoría de las pruebas. Además, las pruebas que están habilitadas para dispositivos LIMITED se destacan en verde claro.
Figura 10: Anillo de decodificación secreto de Android 11