Pruebas de ITS de la cámara

En esta página, se proporciona una lista completa de las pruebas del Conjunto de pruebas de imagen de la cámara (ITS), que forma parte del verificador del Conjunto de pruebas de compatibilidad (CTS) de Android. Las pruebas ITS son pruebas funcionales, lo que significa que no miden la calidad de la imagen, sino que todas las funciones de la cámara anunciadas funcionan como se espera. Este documento permite a los desarrolladores y verificadores comprender qué hacen las pruebas individuales y cómo depurar las fallas de prueba.

Los controles de acceso de ITS de la cámara realizan pruebas según las propiedades de cámara requeridas, el nivel de API y el nivel de clase de rendimiento multimedia (MPC). En el caso del nivel de API, ITS usa ro.product.first_api_level para controlar las pruebas agregadas en un nivel de API específico que prueban experiencias negativas del usuario para la funcionalidad en niveles de API inferiores. ITS usa ro.vendor.api_level para controlar las pruebas de funciones agregadas en un nivel de API específico que requieren una nueva función de hardware. Si se define ro.odm.build.media_performance_class para un dispositivo, ITS requiere que se ejecuten pruebas específicas según el nivel de MPC.

Las pruebas se agrupan por escena de la siguiente manera:

  • scene0: Captura metadatos, jitter, giroscopio y vibración.
  • scene1: Exposición, sensibilidad, compensación del valor de exposición (EV), YUV en comparación con JPEG y RAW
  • scene2: Detección de rostro, pruebas que requieren escenas en color
  • scene3: Refuerzo de bordes, movimiento del lente
  • scene4: Relación de aspecto, recorte y campo de visión
  • scene5: Sombra de lente
  • scene6: Zoom
  • scene7: Interruptor de varias cámaras
  • scene8: Medición de la región de exposición automática (AE) y balance de blancos automático (AWB)
  • scene9: Compresión JPEG
  • scene_extensions: Extensiones de la cámara
  • scene_tele: Cambio de lente teleobjetivo
  • scene_flash: Flash automático, velocidad de fotogramas mínima
  • scene_video: Pérdidas de fotogramas
  • sensor_fusion: Compensación de tiempo de la cámara y el giroscopio
  • feature_combination: Combinaciones de atributos
  • scene_ip: Paridad de imágenes entre la app de cámara predeterminada y la app de cámara de Jetpack (JCA)

Consulta las secciones individuales para obtener una descripción de cada escena.

scene0

Las pruebas no requieren información de escena específica. Sin embargo, el teléfono debe estar quieto para realizar pruebas de giroscopio y vibración.

test_jitter

Mide el jitter en las marcas de tiempo de la cámara.

APIs probadas:

Aprobación: Hay al menos una diferencia de 30 ms entre fotogramas.

En la siguiente figura, observa el pequeño rango del eje y. El jitter es pequeño en este gráfico.

Gráfico de test_jitter

Figura 1: Gráfico de test_jitter.

test_metadata

Prueba la validez de las entradas de metadatos y observa los resultados de la captura y los objetos de características de la cámara. Esta prueba usa valores de exposición y ganancia de auto_capture_request porque el contenido de la imagen no es importante.

APIs probadas:

Aprobación: Las etiquetas rollingShutterSkew, frameDuration, timestampSource, croppingType, blackLevelPattern, pixel_pitch, campo de visión (FoV) y distancia hiperfocal a nivel del hardware están presentes y tienen valores válidos.

test_request_capture_match

Prueba que el dispositivo escribe los valores de exposición y ganancia correctos leyendo los metadatos de captura.

APIs probadas:

Aprobación: Los valores de metadatos de solicitud y captura coinciden en todas las tomas.

test_sensor_events

En el caso de los dispositivos que anuncian compatibilidad con la fusión de sensores, esta prueba verifica si el dispositivo consulta e imprime eventos de sensores. Los sensores esperados son el acelerómetro, el giroscopio y el magnetómetro. Esta prueba solo funciona si la pantalla está encendida, lo que significa que el dispositivo no está en modo de espera.

APIs probadas:

Pasa: Se reciben los eventos de cada sensor.

test_solid_color_test_pattern

Prueba que los patrones de prueba de color sólido se generan correctamente para silenciar la cámara. Si se admite la inhabilitación del sonido de la cámara, también se deben admitir patrones de prueba de colores sólidos. Si no se admite la función de silenciamiento de la cámara, los patrones de prueba de color sólido solo se prueban si se anuncia la función.

Si se admiten imágenes sin procesar, también se prueba la asignación de colores. Los colores probados son negro, blanco, rojo, azul y verde. En el caso de las cámaras que no admiten imágenes sin procesar, solo se prueba el negro.

APIs probadas:

Aprobación: Los patrones de prueba sólidos admitidos son del color correcto y hay una baja variación en la imagen.

test_test_pattern

Prueba el parámetro android.sensor.testPatternMode para capturar fotogramas de cada patrón de prueba válido y verifica que los fotogramas se generen correctamente para los colores sólidos y las barras de color. Esta prueba incluye los siguientes pasos:

  1. Captura imágenes para todos los patrones de prueba admitidos.
  2. Realiza una verificación de exactitud del patrón de prueba de color sólido y las barras de color.

APIs probadas:

Aprobación: Los patrones de prueba admitidos se generan correctamente.

Ejemplo de test_test_patterns

Figura 2: Ejemplo de test_test_patterns.

test_tonemap_curve

Prueba la conversión del patrón de prueba de sin procesar a YUV con un mapa de tonos lineal. Esta prueba requiere android.sensor.testPatternMode = 2 (COLOR_BARS) para generar un patrón de imagen perfecto para la conversión de mapas de tonos. Verifica 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).

APIs probadas:

Aprobación: El YUV y el RAW se ven similares.

Ejemplo sin procesar de test_tonemap_curve

Figura 3: Ejemplo sin procesar de test_tonemap_curve.

Ejemplo de YUV de test_tonemap_curve

Figura 4: Ejemplo de YUV de test_tonemap_curve.

test_unified_timestamp

Prueba si los eventos del sensor de imagen y movimiento están en el mismo dominio de tiempo.

APIs probadas:

Pasa: Las marcas de tiempo de movimiento se encuentran entre las dos marcas de tiempo de imagen.

test_vibration_restriction

Prueba si la vibración del dispositivo funciona como se espera.

APIs probadas:

Aprobación: El dispositivo no vibra cuando la API de restricción de audio de la cámara lo silencia.

scene1_1

scene1 es un gráfico gris. El gráfico gris debe cubrir el 30% central del campo de visión de la cámara. Se espera que el gráfico gris desafie a 3A (AE, AWB y AF) de manera moderada, ya que la región central no tiene características. Sin embargo, la solicitud de captura especifica toda la escena, que incluye características suficientes para que converja el 3A.

Las cámaras de RFoV se pueden probar en el sistema de prueba de WFoV o RFoV. Si se prueba una cámara de RFoV en el equipo de prueba de WFoV, el gráfico se ajusta en 2/3 para especificar algunos límites para el gráfico gris en el campo visual y ayudar a que la 3A converja. Para obtener descripciones más detalladas de los sistemas de prueba de la cámara, consulta ITS integrado en la cámara.

ejemplo de scene1

Figura 5: Gráfico de escena 1 de tamaño completo (izquierda) y gráfico ajustado a 2/3 (derecha).

test_ae_precapture_trigger

Prueba la máquina de estados de AE cuando se usa el activador de captura previa. Captura cinco solicitudes manuales con AE inhabilitada. La última solicitud tiene un activador de captura previa de AE, que se debe ignorar porque AE está inhabilitado.

APIs probadas:

Aprobación: La AE converge.

test_auto_vs_manual

Las pruebas que capturaron tomas automáticas y manuales se ven iguales.

APIs probadas:

Aprobación: Las ganancias y la transformación del balance de blancos manuales que se informan en cada resultado de captura coinciden con el balance de blancos automático estimate del algoritmo 3A de la cámara.

Ejemplo de prueba automática de test_auto_vs_manual

Figura 6: Ejemplo de test_auto_vs_manual.

Ejemplo de balance de blancos test_auto_vs_manual

Figura 7: Ejemplo de balance de blancos test_auto_vs_manual.

Ejemplo de transformación de balance de blancos manual test_auto_vs_manual

Figura 8: Ejemplo de transformación de balance de blancos manual test_auto_vs_manual.

test_black_white

Prueba que el dispositivo produce imágenes en blanco y negro. Realiza dos capturas: la primera con una ganancia extremadamente baja y una exposición corta, lo que genera una foto en negro, y la segunda con una ganancia extremadamente alta y una exposición larga, lo que genera una foto en blanco.

APIs probadas:

Pasar: Produce imágenes en blanco y negro. Los canales saturados de las imágenes blancas tienen valores RGB de [255, 255, 255] con un margen de error de menos del 1% de diferencia.

test_black_white, ejemplo de negro

Figura 9: test_black_white, ejemplo en negro.

Ejemplo de transformación de balance de blancos manual test_auto_vs_manual

Figura 10: test_black_white, ejemplo en blanco.

El diagrama test_black_white significa ejemplo.

Figura 11: test_black_white, plot significa ejemplo.

test_burst_capture

Verifica que toda la canalización de captura pueda seguir el ritmo de la velocidad de la captura de tamaño completo y el tiempo de la CPU.

APIs probadas:

Aprobación: Captura una ráfaga de imágenes de tamaño completo, verifica si hay fallas de fotogramas y brillo de la imagen.

test_burst_sameness_manual

Toma 5 ráfagas de 50 imágenes con la configuración de captura manual y verifica que sean todas idénticas. Usa esta prueba para identificar si hay fotogramas esporádicos que se procesan de forma diferente o tienen artefactos.

APIs probadas:

Aprobado: Las imágenes son idénticas visualmente y en los valores RGB.

Error: Muestra un aumento o una disminución del gráfico promedio de RGB al comienzo de cada ráfaga.

  • La tolerancia es del 3% para first_API_level < 30.
  • La tolerancia es del 2% para first_API_level >= 30.

test_burst_sameness_manual_mean

Figura 12: Ejemplo de la media de test_burst_sameness_manual.

test_burst_sameness_manual_plot_means

Figura 13: test_burst_sameness_manual_plot_means

test_crop_region_raw

Pruebas que las transmisiones en formato RAW no se pueden recortar.

APIs probadas:

Aprobación: Las imágenes YUV se recortan en el centro, pero no las imágenes RAW.

Ejemplo de recorte sin procesar de comp_test_crop_region_raw

Figura 14: Ejemplo de recorte sin procesar de la composición test_crop_region_raw.

Ejemplo completo de la comparación de test_crop_region_raw sin procesar

Figura 15: Ejemplo completo de la comparación sin procesar de test_crop_region_raw.

Ejemplo de recorte YUV de la composición test_crop_region_raw

Figura 16: Ejemplo de recorte YUV de la composición test_crop_region_raw.

Ejemplo de test_crop_region_raw_yuv_full

Figura 17: Ejemplo completo de YUV de test_crop_region_raw.

test_crop_regions

Prueba que las regiones de recorte funcionen. Toma una imagen completa y crea parches de cinco regiones diferentes (esquinas y centro). Toma imágenes con el recorte establecido para las cinco regiones. Compara el parche y los valores de la imagen recortada.

APIs probadas:

Aprobado: La imagen de la región recortada coincide con el parche que corresponde a la imagen del recorte.

test_ev_compensation

Prueba que se aplica la compensación del valor de exposición (VE). La prueba consta de una sección básica y una avanzada.

En la sección básica, se prueba que la compensación de EV se aplica con un rango creado con CONTROL_AE_COMPENSATION_STEP. Se capturan ocho fotogramas en cada valor de compensación.

La sección avanzada aumenta la exposición en ocho pasos y verifica el brillo medido en comparación con el brillo esperado. Los valores esperados se calculan a partir del brillo de la imagen sin aplicar compensación de EV, y el valor esperado se satura si los valores calculados superan el rango de valores de imagen real. La prueba falla si los valores esperados y los valores medidos no coinciden o si las imágenes se sobreexponen en cinco pasos.

APIs probadas:

Paso de sección básico: Las imágenes muestran una exposición creciente sin sobreexponerlas en cinco pasos.

test_ev_compensation_basic

Figura 18: test_ev_compensation_basic.

Paso de sección avanzado: Captura un aumento en la luma a medida que aumenta la configuración de compensación de EV. Los ocho fotogramas capturados para cada configuración de compensación de EV tienen valores de luma estables.

test_ev_compensation_advanced_plot_means

Figura 19: test_ev_compensation_advanced_plot_means.

test_exposure_x_iso

Pruebas que comprueban que se logra una exposición constante a medida que varían el ISO y el tiempo de exposición. Toma una serie de fotos con el ISO y el tiempo de exposición elegidos para equilibrarse entre sí. Los resultados deben tener el mismo brillo, pero a lo largo de la secuencia, la imagen debería ser más ruidosa. Verifica que los valores promedio de los píxeles de muestra estén cerca unos de otros. Verifica que las imágenes no estén limitadas a 0 o 1 (lo que las haría parecer líneas planas). La prueba también se puede ejecutar con imágenes RAW si configuras la marca debug en tu archivo de configuración.

APIs probadas:

Aprobación: Las imágenes tienen el mismo brillo, pero se vuelven más ruidosas con un ISO más alto. Los planos RGB son planos cuando el valor de ISO*exposición es constante en el espacio de ganancia probado.

Mecanismo de falla: En la siguiente imagen, a medida que aumentan los valores del multiplicador de ganancia (eje X), los valores promedio del plano RGB normalizado (eje Y) comienzan a desviarse de los valores del multiplicador de ganancia baja.

test_exposure_plot_means

Figura 20: test_exposure_plot_means.

test_exposure_mult=1.00.jpg

Figura 21: test_exposure_mult=1.00.

test_exposure_mult=64.00

Figura 22: test_exposure_mult=64.00.

test_latching

Prueba que la configuración (exposición y ganancia) se bloquee en el marco correcto para las cámaras FULL y LEVEL_3. Toma una serie de fotos con solicitudes consecutivas y varía los parámetros de solicitud de captura entre las fotos. Verifica que las imágenes tengan las propiedades esperadas.

APIs probadas:

Aprobación: Las imágenes [2, 3, 6, 8, 10, 12 y 13] tienen un ISO o una exposición más altos y aparecen con valores medios de RGB más altos en el gráfico de la siguiente imagen.

Ejemplo de gráfico de medios de bloqueo de test_latching

Figura 23: Ejemplo de gráfico de bloqueo de prueba.

test_latching i=00

Figura 24: test_latching i=00.

test_latching i=01

Figura 25: test_latching i=01.

test_latching i=02

Figura 26: test_latching i=02.

test_latching i=03

Figura 27: test_latching i=03.

test_latching i=04

Figura 28: test_latching i=04.

test_latching i=05

Figura 29: test_latching i=05.

test_latching i=06

Figura 30: test_latching i=06.

test_latching i=07

Figura 31: test_latching i=07.

test_latching i=08

Figura 32: test_latching i=08.

test_latching i=09

Figura 33: test_latching i=09.

test_latching i=10

Figura 34: test_latching i=10.

test_latching i=11

Figura 35: test_latching i=11.

test_latching i=12

Figura 36: test_latching i=12.

test_linearity

Pruebas que el procesamiento del dispositivo se puede invertir a píxeles lineales. Captura una secuencia de tomas con el dispositivo enfocado en un objetivo uniforme.

APIs probadas:

Aprobación: Los valores de R, G y B deben aumentar de forma lineal a medida que aumenta la sensibilidad.

Ejemplo de los valores medios del gráfico de test_linearity

Figura 37: Ejemplo de gráfico de test_linearity.

test_locked_burst

Prueba el bloqueo 3A y la ráfaga YUV (con configuración automática). Esta prueba está diseñada para aprobar incluso en dispositivos limitados que no tienen MANUAL_SENSOR o PER_FRAME_CONTROLS. La prueba verifica la coherencia de la imagen YUV mientras la verificación de la velocidad de fotogramas está en CTS.

APIs probadas:

Aprobación: Las capturas se ven coherentes.

Ejemplo de fotograma 0 de test_locked_burst

Figura 38: Ejemplo de fotograma 0 de test_locked_burst.

Ejemplo de fotograma 1 de test_locked_burst

Figura 39: Ejemplo de fotograma 1 de test_locked_burst.

test_locked_burst_frame2

Figura 40: Ejemplo de fotograma 2 de test_locked_burst.

scene1_2

scene 1_2 es una copia funcionalmente idéntica de scene 1_1, que implementa una estructura de subescena para aliviar la duración extendida de scene 1.

test_param_color_correction

Prueba que los parámetros android.colorCorrection.* se apliquen cuando se configuren. Toma fotos con diferentes valores de transformación y ganancia, y prueba que se vean diferentes según corresponda. La transformación y las ganancias se eligen para que el resultado sea cada vez más rojo o azul. Usa un mapa de tonos lineal.

La asignación de tonos es una técnica que se usa en el procesamiento de imágenes para asignar un conjunto de colores a otro y aproximar la apariencia de las imágenes de alto rango dinámico en un medio que tiene un rango dinámico más limitado.

APIs probadas:

Pasar: Los valores de R y B se aumentan según la transformación.

Ejemplo de gráfico de medias de test_param_color_correction

Figura 41: Ejemplo de gráfico de medias de test_param_color_correction.

En las siguientes figuras, el eje x son las solicitudes de captura: 0 = unidad, 1 = mejora roja y 2 = mejora azul.

Ejemplo de Unity de test_param_color_correction req=0

Figura 42: Ejemplo de Unity de test_param_color_correction req=0.

Ejemplo de aumento rojo de test_param_color_correctness req=1

Figura 43: Ejemplo de aumento rojo de test_param_color_correctness req=1.

Ejemplo de aumento de color azul con test_param_color_correction req=2

Figura 44: Ejemplo de aumento de color azul test_param_color_correction req=2.

test_param_flash_mode

Prueba que se aplica el parámetro android.flash.mode. Establece de forma manual la exposición en el lado oscuro, de modo que sea obvio si se activó el flash o no, y usa un mapa de tonos lineal. Verifica el centro con la imagen de la tarjeta para ver si se crea un gradiente grande que permita verificar si se activó el flash.

APIs probadas:

Aprobación: El centro de la imagen de la tarjeta tiene un gradiente grande, lo que significa que se activó el flash.

Ejemplo 1 de test_param_flash_mode

Figura 45: Ejemplo de test_param_flash_mode 1.

Ejemplo de tarjeta 1 de test_param_flash_mode

Figura 46: Ejemplo de una tarjeta de test_param_flash_mode.

Ejemplo de test_param_flash_mode_2

Figura 47: Ejemplo de test_param_flash_mode 2.

Ejemplo de tarjeta 2 de test_param_flash_mode

Figura 48: Ejemplo de dos tarjetas de test_param_flash_mode.

test_param_noise_reduction

Prueba que el parámetro android.noiseReduction.mode se aplica correctamente cuando se configura. Captura imágenes con la cámara con poca iluminación. Usa una ganancia analógica alta para ayudar a garantizar que la imagen capturada tenga ruido. Captura tres imágenes: sin NR, rápida y de alta calidad. También captura una imagen con ganancia baja y NR desactivada, y usa la variación de esta como referencia. Cuanto mayor sea la relación señal/ruido (SNR), mejor será la calidad de la imagen.

APIs probadas:

Pasa: La SNR varía con los diferentes modos de reducción de ruido y se comporta de manera similar al siguiente gráfico:

Ejemplo de SNRs de gráfico test_param_noise_reduction

Figura 49: Ejemplo de SNRs en el gráfico test_param_noise_reduction.

0: DESACTIVADO, 1: RÁPIDO, 2: HQ, 3: MÍNIMO , 4: ZSL

Ejemplo de test_param_noise_reduction de ganancia alta nr=0

Figura 50: Ejemplo de test_param_noise_reduction con ganancia alta nr=0.

Ejemplo de test_param_noise_reduction de alta ganancia nr=1

Figura 51: Ejemplo de test_param_noise_reduction con ganancia alta nr=1.

Ejemplo de test_param_noise_reduction con ganancia alta nr=2

Figura 52: Ejemplo de test_param_noise_reduction con ganancia alta nr=2.

Ejemplo de test_param_noise_reduction de ganancia alta nr=3

Figura 53: Ejemplo de test_param_noise_reduction con ganancia alta nr=3.

Ejemplo de ganancia baja de test_param_noise_reduction

Figura 54: Ejemplo de ganancia baja de test_param_noise_reduction.

test_param_shading_mode

Prueba que se aplica el parámetro android.shading.mode.

APIs probadas:

Pasa: Se cambian los modos de sombreado y se modifican los mapas de sombreado de lentes como se espera.

Ejemplo de mapa de sombreado de lentes test_param_shading_mode, modo 0, bucle 0

Figura 55: Ejemplo de mapa de sombreado del lente test_param_shading_mode, modo 0, bucle 0.

Ejemplo de mapa de sombreado de lentes test_param_shading_mode, modo 1, bucle 0

Figura 56: Ejemplo de mapa de sombreado de lentes test_param_shading_mode, modo 1, bucle 0.

Ejemplo de mapa de sombreado de lentes test_param_shading_mode, modo 2, bucle 0

Figura 57: Ejemplo de mapa de sombreado de lentes test_param_shading_mode, modo 2, bucle 0.

test_param_tonemap_mode

Prueba que se aplica el parámetro android.tonemap.mode. Aplica diferentes curvas de mapa de tonos a cada canal R, G y B, y verifica que las imágenes de salida se modifiquen como se espera. Esta prueba consta de dos pruebas: test1 y test2.

APIs probadas:

Aprobación:

  • test1: Ambas imágenes tienen un mapa de tonos lineal, pero n=1 tiene un gradiente más abrupto. El canal G (verde) es más brillante para la imagen n=1.
  • test2: Mismo mapa de tonos, pero con una longitud diferente. Las imágenes son iguales.

test_param_tonemap_mode con n=0

Figura 58: test_param_tonemap_mode con n=0

test_param_tonemap_mode con n=1

Figura 59: test_param_tonemap_mode con n=1.

test_post_raw_sensitivity_boost

Verifica el aumento de sensibilidad sin procesar de la publicación. Captura un conjunto de imágenes YUV y sin procesar con distinta sensibilidad, publica la combinación de aumento de sensibilidad sin procesar y comprueba si la media de píxeles de salida coincide con la configuración de la solicitud.

APIs probadas:

Aprobación: Las imágenes sin procesar se oscurecen a medida que aumenta la mejora, mientras que el brillo de las imágenes YUV permanece constante.

Ejemplo de test_post_raw_sensitivity_boost raw s=3583 boost=0100

Figura 60: Ejemplo de test_post_raw_sensitivity_boost raw s=3583 boost=0100.

Ejemplo de test_post_raw_sensitivity_boost raw s=1792 boost=0200

Figura 61: Ejemplo de test_post_raw_sensitivity_boost raw s=1792 boost=0200.

Ejemplo de test_post_raw_sensitivity_boost raw s=0896 boost=0400

Figura 62: Ejemplo de test_post_raw_sensitivity_boost raw s=0896 boost=0400.

Ejemplo de test_post_raw_sensitivity_boost raw s=0448 boost=0800

Figura 63: Ejemplo de test_post_raw_sensitivity_boost raw s=0448 boost=0800.

Ejemplo de test_post_raw_sensitivity_boost raw s=0224 boost=1600

Figura 64: Ejemplo de test_post_raw_sensitivity_boost raw s=0224 boost=1600.

Ejemplo de test_post_raw_sensitivity_boost raw s=0112 boost=3199

Figura 65: Ejemplo de test_post_raw_sensitivity_boost raw s=0112 boost=3199.

Ejemplo de la media del gráfico sin procesar de test_post_raw_sensitivity_boost

Figura 66: Ejemplo de gráfico sin procesar de test_post_raw_sensitivity_boost.

Ejemplo de test_post_raw_sensitivity_boost YUV s=0112 boost=3199

Figura 67: Ejemplo de test_post_raw_sensitivity_boost YUV s=0112 boost=3199.

Ejemplo de test_post_raw_sensitivity_boost YUV s=0448 boost=0800

Figura 68: Ejemplo de test_post_raw_sensitivity_boost YUV s=0448 boost=0800.

Ejemplo de test_post_raw_sensitivity_boost YUV s=0896 boost=0400

Figura 69: Ejemplo de test_post_raw_sensitivity_boost YUV s=0896 boost=0400.

Ejemplo de test_post_raw_sensitivity_boost YUV s=1792 boost=0200

Figura 70: Ejemplo de test_post_raw_sensitivity_boost YUV s=1792 boost=0200.

Ejemplo de test_post_raw_sensitivity_boost YUV s=3585 boost=0100

Figura 71: Ejemplo de test_post_raw_sensitivity_boost YUV s=3585 boost=0100.

test_post_raw_sensitivity_boost_yuv_plot_means

Figura 72: test_post_raw_sensitivity_boost_yuv_plot_means

test_raw_exposure

Captura un conjunto de imágenes sin procesar con un tiempo de exposición creciente y mide los valores de píxeles.

APIs probadas:

Pasa: Aumentar el ISO (ganancia) hace que los píxeles sean más sensibles a la luz, por lo que la trama se mueve hacia la izquierda.

Ejemplo de test_raw_exposure ISO=55

Figura 73: Ejemplo de ISO=55 de test_raw_exposure.

10⁰ es 1 ms, 10¹ es 10 ms y 10⁻¹ es 0.1 ms.

Ejemplo de ISO=132 de test_raw_exposure

Figura 74: Ejemplo de test_raw_exposure ISO=132.

Ejemplo de ISO=209 de test_raw_exposure

Figura 75: Ejemplo de test_raw_exposure ISO=209.

Ejemplo de ISO=286 de test_raw_exposure

Figura 76: Ejemplo de ISOs de test_raw_exposure ISOs=286.

Ejemplo de ISO=363 de test_raw_exposure

Figura 77: Ejemplo de test_raw_exposure ISO=363.

test_raw_exposure_s=440

Figura 78: Ejemplo de ISO=440 de test_raw_exposure.

test_reprocess_noise_reduction

Pruebas en las que se aplica android.noiseReduction.mode para volver a procesar solicitudes. Captura imágenes reprocesadas con la cámara con poca iluminación. Usa una ganancia analógica alta para verificar que la imagen capturada tenga ruido. Captura tres imágenes reprocesadas: sin NR, rápida y de alta calidad. Captura una imagen repreprocesada con ganancia baja y NR desactivada, y usa la varianza de esta como referencia.

APIs probadas:

Aprobación: FAST >= OFF, HQ >= FAST y HQ >> OFF.

Gráfico típico de SNR en comparación con el modo NR

Figura 79: Ejemplo típico de gráfico de SNR en comparación con el modo NR.

test_tonemap_sequence

Prueba una secuencia de tomas con diferentes curvas de tono. Captura 3 tomas manuales con un mapa de tonos lineal. Captura 3 tomas manuales con el mapa de tonos predeterminado. Calcula la delta entre cada par de fotogramas consecutivos.

APIs probadas:

Aprobación: Hay tres fotogramas idénticos seguidos de un conjunto diferente de tres fotogramas idénticos.

Ejemplo de test_tonemap_sequence i=0

Figura 80: Ejemplo de test_tonemap_sequence i=0.

Ejemplo de test_tonemap_sequence i=1

Figura 81: Ejemplo de test_tonemap_sequence i=1.

Ejemplo de test_tonemap_sequence i=2

Figura 82: Ejemplo de test_tonemap_sequence i=2.

Ejemplo de test_tonemap_sequence i=3

Figura 83: Ejemplo de test_tonemap_sequence i=3.

Ejemplo de test_tonemap_sequence_i=4

Figura 84: Ejemplo de test_tonemap_sequence i=4.

Ejemplo de test_tonemap_sequence i=5

Figura 85: Ejemplo de test_tonemap_sequence i=5.

test_yuv_jpeg_all

Prueba que todos los tamaños y formatos informados para la captura de imágenes funcionen. Usa una solicitud manual con un mapa de tonos lineal para que YUV y JPEG se vean igual cuando el módulo image_processing_utils los convierta. Las imágenes no se guardan de forma predeterminada, pero se pueden guardar si habilitas debug_mode.

APIs probadas:

Aprobación: Todos los centros de imagen tienen una diferencia máxima de raíz cuadrada media (RMS) (valor de una señal) en las imágenes convertidas a RGB con el 3% de la imagen YUV de resolución más alta.

Ejemplo de test_yuv_jpeg_all

Figura 86: Ejemplo de test_yuv_jpeg_all.

test_yuv_plus_dng

Prueba que los tamaños y formatos informados para la captura de imágenes funcionen.

APIs probadas:

Aprobación: La prueba se completa y muestra las imágenes solicitadas.

Ejemplo de test_yuv_plus_dng

Figura 87: Ejemplo de test_yuv_plus_dng.

scene1_3

scene 1_3 es una copia funcionalmente idéntica de scene 1_1, que implementa una estructura de subescena para aliviar la duración extendida de scene 1.

test_capture_result

Prueba que los datos válidos se muestran en objetos CaptureResult. La prueba consiste en una captura automática, una captura manual y una segunda captura automática.

APIs probadas:

Aprobación: Los metadatos son válidos para todas las capturas y la configuración manual no se filtra en la segunda captura automática. Traza la corrección de sombreado del lente para las capturas.

test_capture_result_plot_lsc_auto_ch0

Figura 88: test_capture_result_plot_lsc_auto_ch0.

test_dng_noise_model

Verifica que los parámetros del modelo sin procesar DNG sean correctos. El gráfico muestra la variación medida de un parche central de la tarjeta gris en tomas sin procesar capturadas en un rango de sensibilidades y compara estos valores con la variación que se espera en cada sensibilidad por el modelo de ruido DNG en el HAL de la cámara (según los parámetros O y S que se muestran en los objetos de resultados de captura). Para obtener más detalles sobre el modelo de ruido DNG, descarga el siguiente documento sobre el modelo de ruido DNG.

APIs probadas:

Aprobación: Los parámetros del modelo sin procesar DNG son correctos. Los valores RGB esperados coinciden con los valores RGB reales medidos.

test_dng_noise_model_plog

Figura 89: test_dng_noise_model_plog.

test_jpeg

Pruebas que comprueban que las imágenes YUV convertidas y las imágenes JPEG del dispositivo se ven igual. La prueba toma el 10% central de la imagen, calcula el valor RGB y verifica que coincidan.

APIs probadas:

Aprobación: La diferencia promedio de RGB entre cada imagen es inferior al 3%.

test_jpeg_fmt=jpg.jpg

Figura 90: test_jpeg_fmt=jpg.jpg.

test_jpeg=fmt=yuv.jpg

Figura 91: test_jpeg=fmt=yuv.jpg.

test_raw_burst_sensitivity

Captura un conjunto de imágenes sin procesar con ganancias crecientes y mide el ruido. Captura solo en formato sin procesar, en una ráfaga.

APIs probadas:

Pasa: Cada toma tiene más ruido que la anterior, ya que la ganancia aumenta.

Usa la varianza de la celda de la cuadrícula de estadísticas del centro.

test_raw_burst_sensitivity_variance

Figura 92: test_raw_burst_sensitivity_variance.

test_raw_sensitivity

Captura un conjunto de imágenes sin procesar con sensibilidades crecientes y mide el ruido (varianza) en el 10% central de la imagen. Prueba que cada toma es más ruidosa que la anterior.

APIs probadas:

Pase: La varianza aumenta con cada toma.

test_raw_sensitivity_variance

Figura 93: test_raw_sensitivity_variance.

test_yuv_plus_jpeg

Pruebas de captura de un solo fotograma como salidas YUV y JPEG Usa una solicitud manual con un mapa de tonos lineal para que YUV y JPEG se vean igual cuando el módulo image_processing_utils los convierta.

APIs probadas:

Aprobación: Las imágenes YUV y JPEG son similares y tienen una diferencia de RMS (valor de una señal) inferior al 1%.

test_yuv_plus_jpeg con formato JPEG

Figura 94: test_yuv_plus_jpeg con formato JPEG

test_yuv_plus_jpeg con formato YUV

Figura 95: test_yuv_plus_jpeg con formato YUV

test_yuv_plus_raw

Pruebas de captura de una sola fotograma como salidas YUV y sin procesar (sin procesar de 10 y 12 bits) si se admite. Usa una solicitud manual con un mapa de tonos lineal, por lo que se espera que los archivos YUV y sin procesar sean iguales. Compara el 10% de los valores RGB del centro de las imágenes convertidas a RGB. Registrosandroid.shading.mode.

APIs probadas:

Aprobación: Las imágenes YUV y sin procesar son similares y tienen una diferencia de RMS (valor de raíz cuadrada de la media de una señal) inferior al 3.5%.

test_yuv_plus_raw_shading=1_raw.jpg

Figura 96: test_yuv_plus_raw_shading=1_raw.jpg.

test_yuv_plus_raw_shading=1_yuv.jpg

Figura 97: test_yuv_plus_raw_shading=1_yuv.jpg.

test_sensitivity_priority

Prueba CONTROL_AE_PRIORITY_MODE_SENSOR_SENSITIVITY_PRIORITY en varios parámetros de configuración de ISO para confirmar una correlación entre un ISO más alto y un aumento de los niveles de ruido.

APIs probadas:

Aprobación: Un ISO más alto genera niveles de ruido más altos.

Criterios para omitir pruebas

Se omite la prueba test_sensitivity_priority.py si se cumple alguno de los siguientes criterios:

test_exposure_time_priority

Prueba CONTROL_AE_PRIORITY_MODE_SENSOR_EXPOSURE_TIME_PRIORITY en varios tiempos de exposición y verifica si hay un brillo estable en el rango en el que ISO puede compensar.

APIs probadas:

Aprobado: El brillo es estable (dentro de la tolerancia) en todos los tiempos de exposición si el ISO está dentro de su rango de compensación.

Criterios para omitir pruebas

Se omite la prueba test_exposure_time_priority si se cumple alguno de los siguientes criterios:

escena2_a

scene2_a tiene tres caras con un fondo gris y ropa neutra. Se eligieron para tener una amplia variedad de tonos de piel. El gráfico debe tener la orientación correcta para que la detección de rostro funcione de manera óptima.

Ejemplo de scene2_a

Figura 98: Ejemplo de scene2_a.

test_autoframing

Prueba el comportamiento del enmarcado automático del dispositivo de la cámara. Realiza un zoom grande de modo que ninguno de los rostros de la escena sea visible, habilita el modo de enmarcado automático configurando AUTOFRAMING en CaptureRequest como True y verifica si se pueden detectar todos los rostros de la escena original cuando el estado converge (es decir, cuando AUTOFRAMING_STATE en CaptureResult se establece como AUTOFRAMING_STATE_CONVERGED).

APIs probadas:

Aprobado: Se detectan los tres rostros.

test_display_p3

Prueba la captura de Display P3 en JPEG con la API de ColorSpaceProfiles. Prueba que el JPEG capturado tenga un perfil ICC apropiado en su encabezado y que la imagen contenga colores fuera de la gama sRGB.

APIs probadas:

Aprobado: El archivo JPEG contiene un perfil ICC de Display P3 y colores fuera de la gama sRGB.

test_effects

Captura el fotograma para los efectos de cámara compatibles y verifica si se generan correctamente. La prueba solo verifica los efectos OFF y MONO, pero guarda imágenes para todos los efectos admitidos.

APIs probadas:

Pasa: Captura la imagen de la escena con los efectos OFF y una imagen monocromática con los efectos establecidos en MONO.

test_effects_MONO

Figura 99: test_effects_MONO.

test_exposure_keys_consistent

Esta prueba compara la luma promedio de una captura habilitada para la AE con una captura inhabilitada para la AE que aplica manualmente los parámetros de exposición (sensibilidad, tiempo de exposición, duración del fotograma, aumento de sensibilidad posterior a la captura sin procesar) recibidos en el CaptureResult de la captura habilitada para la AE.

APIs probadas:

Aprobación: La diferencia relativa en luma entre las dos capturas es inferior al 4%.

test_format_combos

Prueba diferentes combinaciones de formatos de salida.

APIs probadas:

Aprobado: Todas las combinaciones se capturan correctamente.

test_num_faces

Prueba la detección de rostros.

APIs probadas:

Aprobado: Se encuentran tres rostros.

Ejemplo del modo 1 de detección de rostros test_num_faces

Figura 100: Ejemplo del modo 1 de detección de rostros test_num_faces.

test_reprocess_uv_swap

Prueba que el reprocesamiento YUV no cambie los planos U y V. Para detectar esto, se calcula la suma de las diferencias absolutas (SAD) entre la imagen que se volvió a procesar y una captura que no se volvió a procesar. Si intercambiar los planos U y V de salida de la captura repreprocesa genera un aumento de la SAD, se supone que el resultado tiene los planos U y V correctos.

APIs probadas:

Pasa: Los planos U y V no se intercambian.

test_reprocess_uv_swap

Figura 101: Ejemplo de test_reprocess_uv_swap.

scene2_b

test_preview_num_faces

Prueba la detección de rostros en la vista previa con una mayor diversidad de tonos de piel en las escenas de rostros.

APIs probadas:

Aprobación: Se encuentran tres rostros con puntos de referencia en los cuadros de límite de los rostros.

test_num_faces_fd_mode_1

Figura 102: Ejemplo del modo 1 de detección de rostros test_num_faces.

test_yuv_jpeg_capture_sameness

Captura dos imágenes con los formatos YUV y JPEG comunes más grandes con la misma relación de aspecto que el formato JPEG más grande que no supere una resolución de 1920 × 1440. Establece jpeg.quality en 100 y captura una solicitud de doble superficie. Convierte ambas imágenes en arreglos RGB y calcula la diferencia de raíz cuadrada media (RMS) 3D entre las dos imágenes.

Además, esta prueba verifica que los resultados YUV de todos los casos de uso de transmisión compatibles sean bastante similares a los YUV con el caso de uso de STILL_CAPTURE.

APIs probadas:

Aprobación: Las imágenes YUV y JPEG del caso de uso de STILL_CAPTURE tienen una diferencia de menos del 3% en RMS (valor raíz cuadrada media de una señal). Las imágenes YUV de todos los casos de uso admitidos tienen una diferencia de menos del 10% en RMS con las imágenes YUV del caso de uso de STILL_CAPTURE.

scene2_c

test_num_faces

Prueba la detección de rostros con mayor diversidad de tonos de piel en escenas de rostros.

APIs probadas:

Aprobado: Se encuentran tres rostros.

test_num_faces_fd_mode_1

Figura 103: Ejemplo del modo de detección de rostros test_num_faces.

test_jpeg_capture_perf_class

Prueba la latencia de captura de JPEG para la clase de rendimiento S, como se especifica en la sección 2.2.7.2 Cámara del CDD.

Aprobación: DEBE tener una latencia de captura de JPEG de camera2 inferior a 1,000 ms para una resolución de 1080p, según lo mida la prueba de rendimiento de la cámara CTS en condiciones de iluminación ITS (3,000 K) para ambas cámaras principales.

test_camera_launch_perf_class

Prueba la latencia de inicio de la cámara para la clase de rendimiento S, como se especifica en la sección 2.2.7.2 Cámara del CDD.

Aprobación: DEBE tener una latencia de inicio de Camera2 (abrir la cámara hasta el primer fotograma de vista previa) inferior a 600 ms, según lo mida la prueba de rendimiento de la cámara CTS en las condiciones de iluminación de ITS (3000 K) para ambas cámaras principales.

test_default_camera_hdr

Pruebas que la captura predeterminada de la cámara es Ultra HDR para la clase de rendimiento 15, como se especifica en la sección 2.2.7.2 Cámara del CDD

Aprobación: La captura predeterminada del paquete de la cámara DEBE ser Ultra HDR para un dispositivo de clase de rendimiento 15.

scene2_d

test_preview_num_faces

Prueba la detección de rostros en la vista previa con una mayor diversidad de tonos de piel en las escenas de rostros.

APIs probadas:

Aprobación: Se encuentran tres rostros con puntos de referencia en los cuadros de límite de los rostros.

scene2_e

test_continuous_picture

Se capturan 50 fotogramas de resolución VGA con el primer parámetro de configuración de la solicitud de captura.android.control.afMode = 4 (CONTINUOUS_PICTURE).

APIs probadas:

Aprobación: El sistema 3A se estabiliza al final de una captura de 50 fotogramas.

test_num_faces

Prueba la detección de rostros con mayor diversidad de tonos de piel en escenas de rostros.

APIs probadas:

Aprobado: Se detectan 3 rostros.

scene2_f

scene2_f tiene tres caras con un fondo y ropa blancos. Los rostros tienen una amplia variedad de tonos de piel y un alto contraste con el fondo.

Ejemplo de scene2_f

Figura 104: Ejemplo de scene2_f.

test_preview_num_faces

Prueba la detección de rostros con mayor diversidad de tonos de piel en escenas de rostros.

APIs probadas:

Aprobación: Se encuentran tres rostros con puntos de referencia en los cuadros de límite de los rostros.

test_num_faces_fd_mode_1

Figura 105: Ejemplo de test_num_faces_fd_mode_1.

scene2_g

scene2_g tiene tres rostros de perfil con fondo y ropa blancos. Los rostros tienen una amplia variedad de tonos de piel y un alto contraste con el fondo.

scene2_g.png

Figura 106: Ejemplo de scene2_g.

test_preview_num_faces

Prueba la detección de rostros con mayor diversidad de tonos de piel en escenas de rostros.

APIs probadas:

Aprobación: Se encuentran tres rostros con puntos de referencia en los cuadros de límite de los rostros.

test_preview_num_faces

Figura 107: Ejemplo de test_preview_num_faces.

scene3

scene3 usa el gráfico ISO12233, y la mayoría de las pruebas usan un método de extractor de gráficos para encontrar el gráfico en la escena. Por este motivo, la mayoría de las imágenes guardadas no tienen bordes como las imágenes de las escenas 1, 2 o 4, sino solo el gráfico. El gráfico debe estar en la orientación correcta para que el buscador de gráficos funcione de manera óptima.

test_edge_enhancement

Prueba que el parámetro android.edge.mode se aplique correctamente. Captura imágenes que no se vuelven a procesar para cada modo de borde y muestra la nitidez de la imagen de salida y los metadatos del resultado de la captura. Procesa una solicitud de captura con un modo de borde, una sensibilidad, un tiempo de exposición, una distancia de enfoque y un parámetro de superficie de salida determinados.

Aprobación: El modo HQ (2) es más nítido que el modo OFF (0). El modo FAST (1) es más nítido que el modo OFF. El modo HQ es más nítido o igual que el modo FAST.

APIs probadas:

Parámetros de cámara afectados:

  • EDGE_MODE

test_edge_enhancement_edge=0

Figura 108: Ejemplo de test_edge_enhancement edge=0.

Ejemplo de test_edge_enhancement edge=1

Figura 109: Ejemplo de test_edge_enhancement edge=1 (modo rápido).

Ejemplo de test_edge_enhancement edge=2

Figura 110: Ejemplo de test_edge_enhancement edge=2 (modo de alta calidad).

test_flip_mirror

Prueba si la imagen está orientada correctamente según el artículo 7.5.2 Cámara frontal del CDD.

Las imágenes reflejadas, invertidas o rotadas se pueden identificar por la función de diamante cerca del centro.

Aprobado: La imagen no está invertida, reflejada ni rota.

Ejemplo de parche de escena test_flip_mirror

Figura 111: Ejemplo de parche de escena test_flip_mirror.

test_imu_drift

Prueba si la unidad de medición inercial (IMU) tiene una salida estable durante 30 segundos mientras el dispositivo está inmóvil y captura una vista previa de alta definición.

APIs probadas:

Aprobación:

  • La deriva del giroscopio es inferior a 0.01 rad durante el tiempo de prueba.
  • La varianza de la lectura del giroscopio es inferior a 1E-7 rad2/s2/Hz durante el tiempo de prueba.
  • La deriva del vector de rotación es inferior a 0.01 rad durante el tiempo de prueba.
  • (Aún no es obligatorio) La deriva del giroscopio es inferior a 1 grado por segundo.

Ejemplo de deriva del giroscopio test_imu_drift

Figura 112: Ejemplo de deriva del giroscopio test_imu_drift.

Ejemplo de deriva del vector de rotación test_imu_drift

Figura 113: Ejemplo de deriva del vector de rotación test_imu_drift.

test_landscape_to_portrait

Prueba si la anulación de horizontal a vertical funciona correctamente para los sensores orientados horizontalmente.

APIs probadas:

Aprobación: La prueba encuentra un gráfico con la rotación esperada (0 grados cuando la anulación de horizontal a vertical está inhabilitada, 90 grados cuando está habilitada).

Ejemplo de test_landscape_to_portrait

Figura 114: Ejemplo de test_landscape_to_portrait.

test_lens_movement_reporting

Prueba si la marca de movimiento del lente se informa correctamente. Captura una ráfaga de 24 imágenes con los primeros 12 fotogramas a la distancia de enfoque óptima (como lo encontró 3A) y los últimos 12 fotogramas a la distancia de enfoque mínima. Alrededor del fotograma 12, el lente se mueve, lo que hace que disminuya la nitidez. La nitidez se estabiliza a medida que el objetivo se mueve a la posición final.

La marca de movimiento del lente debe confirmarse en todos los fotogramas en los que la nitidez es intermedia a la nitidez en los primeros fotogramas con el lente estacionario en la distancia focal óptima y los últimos fotogramas en los que el lente está estacionario en la distancia focal mínima. No es importante el fotograma exacto en el que se mueve el lente. Lo importante es que se confirme la marca de movimiento cuando el lente se mueve.

APIs probadas:

Aprobación: La marca de movimiento del lente es True en el fotograma con cambio de nitidez.

Mecanismos de fallo:

  • lens_moving: True (android.hardware.camera2.CaptureResult#LENS_STATE = 1) en test_log.DEBUG solo se confirma en los fotogramas en los que no cambia la nitidez.
  • Los fotogramas con lens_moving: False (android.hardware.camera2.CaptureResult#LENS_STATE = 0) en test_log.DEBUG tienen una diferencia de nitidez en comparación con los primeros fotogramas a la distancia focal óptima o los últimos fotogramas a la distancia focal mínima.

test_reprocess_edge_enhancement

Prueba si los métodos de procesamiento compatibles para la mejora de los bordes funcionan correctamente. Procesa una solicitud de captura con un modo de borde de procesamiento nuevamente determinado y compara los diferentes modos de captura con los modos de borde de procesamiento nuevamente inhabilitados.

APIs probadas:

Aprobado: La nitidez de los diferentes modos de bordes es correcta. HQ (modo 2) es más nítido que OFF (modo 0), y la mejora entre los diferentes modos es similar.

Ejemplo de gráfico de test_reprocess_edge_enhancement

Figura 115: Ejemplo de gráfico de test_reprocess_edge_enhancement.

scene4

scene4 consta de un círculo negro sobre un fondo blanco dentro de un cuadrado.

Las pruebas en scene4 pueden ser sensibles a la alineación, por lo que, a partir de Android 15, puedes usar check_alignment.py en el directorio de herramientas para habilitar una verificación de la alineación del DUT y del gráfico.

ejemplo de escena4

Figura 116: Ejemplo de escena 4.

test_30_60fps_preview_fov_match

Prueba que los videos de vista previa de 30 FPS y 60 FPS tienen el mismo FoV. La prueba captura dos videos, uno con 30 FPS y otro con 60 FPS. Se selecciona un fotograma representativo de cada video y se analiza para verificar que los cambios del campo de visión en los dos videos estén dentro de las especificaciones. Pruebas que la relación de aspecto del círculo permanece constante, el centro del círculo permanece estable y el radio del círculo permanece constante.

APIs probadas:

Aprobado: Las imágenes no se estiran, el centro de las imágenes no difiere en más del 3% y el cambio máximo de relación de aspecto entre los videos de 30 FPS y 60 FPS no es superior al 7.5%.

Mecanismos de fallo:

  • El círculo del video de 30 FPS es muy diferente en tamaño al del video de 60 FPS.
  • La canalización de procesamiento distorsiona el círculo en la imagen capturada.
  • El círculo de la imagen capturada se recorta debido a una solicitud de captura de relación de aspecto extrema que reduce la altura o el ancho de la imagen.
  • El círculo de la imagen capturada tiene un reflejo en el centro y no se muestra completamente relleno.

test_aspect_ratio_and_crop

Prueba si las imágenes se distorsionan o se recortan de forma inesperada en la canalización de imágenes. Toma fotos de un círculo en todos los formatos. Verifica que el círculo no esté distorsionado, que no se mueva del centro de la imagen y que no cambie de tamaño de forma incorrecta con diferentes relaciones de aspecto o resoluciones.

APIs probadas:

Aprobado: Las imágenes no se estiran, el centro de las imágenes no difiere en más del 3% y se conserva el FoV máximo posible.

Mecanismos de fallo:

  • La cámara no está alineada con el círculo que se muestra en la tablet en el centro de la escena capturada.
  • La canalización de procesamiento distorsiona el círculo en la imagen capturada.
  • La imagen de menor resolución se recorta dos veces en la canalización de imágenes, lo que crea un campo de visión diferente entre las imágenes de alta y baja resolución.
  • El círculo de la imagen capturada se recorta debido a una solicitud de captura de relación de aspecto extrema que reduce la altura o el ancho de la imagen.
  • El círculo de la imagen capturada tiene un reflejo en el centro y no se muestra completamente relleno.

test_multi_camera_alignment

Prueba los parámetros de calibración de la cámara relacionados con el posicionamiento de la cámara para sistemas de varias cámaras. Con las subcámaras físicas multicámara, toma una foto con una de las cámaras físicas. Encuentra el centro del círculo. Proyecta el centro del círculo en las coordenadas mundiales de cada cámara. Compara la diferencia entre los centros de los círculos de las cámaras en coordenadas mundiales. Vuelve a proyectar las coordenadas mundiales en coordenadas de píxeles y las compara con las originales como una verificación de validez. Compara los tamaños de los círculos para verificar si las distancias focales de las cámaras son diferentes.

APIs probadas:

Aprobación: Los centros y tamaños de los círculos son los esperados en las imágenes proyectadas en comparación con las imágenes capturadas con datos de calibración de la cámara y distancias focales.

Mecanismos de fallo:

  • LENS_INTRINSIC_CALIBRATION, LENS_POSE_TRANSLATION y LENS_POSE_ROTATION son valores de diseño y no datos de calibración reales.
  • El sistema de cámaras no es adecuado para la configuración de prueba, por ejemplo, probar un sistema de cámaras gran angular y ultra gran angular con el equipo de prueba de RFoV. Para obtener más información, consulta la Pregunta 1 de las preguntas frecuentes sobre el sistema ITS integrado en la cámara.

test_preview_aspect_ratio_and_crop

Al igual que la prueba test_aspect_ratio_and_crop para capturas estáticas, verifica los formatos de vista previa admitidos para comprobar que los fotogramas de vista previa no se estiren ni recorten de forma incorrecta. Verifica que la relación de aspecto del círculo no cambie, que las imágenes recortadas mantengan el círculo en el centro del marco y que el tamaño del círculo no cambie para un formato constante o con diferentes resoluciones (verificación del campo de visión).

APIs probadas:

Aprobado: Las imágenes no se estiran, el centro de las imágenes no difiere en más del 3% y se conserva el FoV máximo posible.

test_preview_stabilization_fov

Verifica los tamaños de vista previa admitidos para garantizar que el campo de visión se recorte de forma correcta. La prueba captura dos videos, uno con estabilización de vista previa ON y otro con estabilización de vista previa OFF. Se selecciona un fotograma representativo de cada video y se analiza para verificar que los cambios de FoV en los dos videos estén dentro de las especificaciones.

APIs probadas:

Aprobación: La relación de aspecto del círculo permanece constante, la ubicación central del círculo permanece estable y el tamaño del círculo no cambia más del 20%.

test_video_aspect_ratio_and_crop

Toma videos de un círculo dentro de un cuadrado en todos los formatos de video. Extrae los fotogramas clave y verifica que la relación de aspecto del círculo no cambie, que las imágenes recortadas mantengan el círculo en el centro y que el tamaño del círculo no cambie para un formato constante o con una resolución diferente (verificación del campo de visión).

APIs probadas:

Aprobado: Los fotogramas de video no se estiran, el centro de los fotogramas no difiere en más del 3% y se conserva el campo de visión máximo posible.

scene5

scene5 requiere una escena gris con iluminación uniforme. Esto se logra con un difusor que se coloca sobre el lente de la cámara. Te recomendamos el siguiente difusor: www.edmundoptics.com/optics/window-diffusers/optical-diffusers/opal-diffusing-glass/46168.

Para preparar la escena, coloca un difusor frente a la cámara y apúntalo hacia una fuente de iluminación de alrededor de 2,000 lux. Las imágenes capturadas para scene5 requieren una iluminación difusa sin características evidentes. La siguiente es una imagen de ejemplo:

Ejemplo de escena 5

Figura 117: Ejemplo de captura de escena 5.

test_lens_shading_and_color_uniformity

Prueba que la corrección de sombras del lente se aplica de forma adecuada y que el color de una escena monocromática uniforme se distribuye de manera uniforme. Realiza esta prueba en un fotograma YUV con 3A automático. La atenuación de la lente se evalúa en función del canal Y. Mide el valor promedio de Y para cada bloque de muestra especificado y determina si se aprueba o no en función de la comparación con el valor de Y central. La prueba de uniformidad de color se evalúa en el espacio rojo-verde y azul-verde.

APIs probadas:

Aprobación: En el radio especificado de la imagen, la variación del valor rojo-verde y azul-verde debe ser inferior al 20% para aprobar la prueba.

scene6

scene6 es una cuadrícula de marcadores ArUco que se pueden identificar de forma única. Las pruebas en scene6 pueden ser sensibles a la alineación, por lo que, a partir de la versión 15, puedes usar check_alignment.py en el directorio de herramientas para habilitar una verificación del DUT y la alineación del gráfico.

scene6

Figura 118: Ejemplo de escena 6.

test_in_sensor_zoom

Prueba el comportamiento de la función de zoom en el sensor de la cámara, que produce imágenes sin procesar recortadas.

Con el caso de uso de transmisión configurado en CROPPED_RAW, la prueba toma dos capturas en el rango de zoom, una imagen sin procesar del campo de visión completo y una imagen sin procesar recortada. La prueba convierte las imágenes en arrays RGB, reduce la imagen sin procesar recortada de tamaño completo al tamaño que informa SCALER_RAW_CROP_REGION y calcula la diferencia RMS 3D entre las dos imágenes.

APIs probadas:

Aprobado: La diferencia RMS 3D entre la imagen sin procesar recortada y reducida y la imagen sin procesar del campo de visión completo es inferior al umbral establecido en la prueba.

test_zoom

Prueba el comportamiento del zoom de la cámara del lente ultra gran angular al lente gran angular. Realiza capturas en el rango de zoom y comprueba si los marcadores de ArUco se hacen más grandes a medida que la cámara se acerca. La prueba también verifica si la posición del marcador central cambia de manera predecible en cada captura. La distancia del centro del marcador central al centro de la imagen puede cambiar a una velocidad constante con respecto a la relación de zoom hasta que se cambia la cámara física, o bien puede cambiar de forma monótona hacia la ubicación del mismo marcador después de cambiar la cámara física. La app de Jetpack Camera (JCA) se debe instalar en el dispositivo antes de realizar la prueba.

APIs probadas:

Aprobado: El tamaño relativo del marcador ArUco capturado es preciso en función de la relación de zoom solicitada para verificar que la cámara realice el zoom correctamente, y la distancia del marcador al centro de la imagen cambia según los criterios establecidos en la descripción de la prueba.

test_zoom para encontrar el contorno del marcador ArUco más cercano al centro

Figura 119: test_zoom para encontrar el contorno del marcador ArUco más cercano al centro.

test_low_latency_zoom

Prueba el comportamiento del zoom de baja latencia de la cámara. Realiza capturas en el rango de zoom con android.control.settingsOverride = 1 (SETTINGS_OVERRIDE_ZOOM) y comprueba si los marcadores en las imágenes de salida coinciden con las relaciones de zoom en los metadatos de captura. Se usa la misma sesión de captura de la cámara para converger el 3A y realizar capturas.

APIs probadas:

Aprobación: El tamaño relativo del marcador capturado es preciso en función de los metadatos del resultado de la proporción de zoom.

test_preview_video_zoom_match

Pruebas que, mientras se graba y se acerca, la vista previa y la salida de video muestran y graban el mismo resultado. Calcula el tamaño del marcador más cercano al centro en diferentes relaciones de zoom y comprueba si el tamaño del marcador aumenta a medida que aumenta la relación de zoom.

APIs probadas:

Aprobación: El tamaño relativo del marcador capturado es preciso en función de la relación de zoom solicitada en el video y la vista previa.

HD_1280x720_key_frame.png

Figura 120: HD_1280x720_key_frame.png (antes del zoom).

preview_1280x720_key_frame.png

Figura 121: preview_1280x720_key_frame.png (antes del zoom).

HD_1280x720_key_frame_zoomed.png

Figura 122: HD_1280x720_key_frame.png (después del zoom).

preview_1280x720_key_frame_zoomed.png

Figura 123: preview_1280x720_key_frame.png (después del zoom).

test_preview_zoom

Prueba que la relación de zoom de cada fotograma de vista previa coincida con los metadatos de captura correspondientes del lente ultraancho al lente ancho. La prueba toma marcos de vista previa sobre el rango de zoom y encuentra el marcador de ArUco más cercano al centro. Luego, la prueba verifica si la posición del marcador central cambia de manera predecible en cada captura. La distancia del centro del marcador central al centro de la imagen puede cambiar a una velocidad constante con respecto a la relación de zoom hasta que se cambia la cámara física, o bien puede cambiar de forma monótona hacia la ubicación del mismo marcador después de cambiar la cámara física.

APIs probadas:

Aprobación: El tamaño relativo del marcador ArUco seleccionado es preciso para la relación de zoom informada del resultado de captura correspondiente para todos los fotogramas de vista previa. La distancia relativa del marcador seleccionado desde el centro de la imagen es precisa para la relación de zoom informada del resultado de captura correspondiente de todos los fotogramas de vista previa.

Imágenes de test_preview_zoom que muestran el marcador seleccionado más cercano al centro

Figura 124: Imágenes de test_preview_zoom que muestran el marcador seleccionado más cercano al centro

test_session_characteristics_zoom

Prueba el rango de relación de zoom para todas las configuraciones de sesión compatibles que se enumeran en CameraCharacteristics#INFO_SESSION_CONFIGURATION_QUERY_VERSION. Para cada una de esas configuraciones, si CameraDeviceSetup#isSessionConfigurationSupported muestra true, la prueba verifica que se pueda alcanzar el rango de relación de zoom que se muestra en CameraDeviceSetup#getSessionCharacteristics.

APIs probadas:

Aprobación: Se pueden alcanzar las relaciones de zoom mínimas y máximas para cada SessionConfiguration compatible que se enumera en CameraCharacteristics#INFO_SESSION_CONFIGURATION_QUERY_VERSION.

scene7

scene7 es un marco rectangular dividido en cuatro cuadrantes iguales, cada uno con un color diferente. En el centro del rectángulo, hay un gráfico de bordes inclinados para las verificaciones de nitidez. Cuatro marcadores ArUco están alineados con las cuatro esquinas externas del rectángulo para ayudar a obtener coordenadas precisas del marco del rectángulo principal con diferentes relaciones de zoom.

scene7

Figura 125. Escena 7.

test_multi_camera_switch

Esta prueba verifica que, durante la grabación de vista previa con diferentes relaciones de zoom, el cambio entre los lentes ultraanchos (UW) y anchos (W) genera valores RGB similares.

La prueba usa diferentes relaciones de zoom dentro del rango predefinido para realizar una grabación de vista previa dinámica e identificar el punto en el que cambia la cámara física. Este punto marca el cruce del lente UW al lente W.

Los fotogramas capturados en el punto de intersección y antes de él se analizan para la exposición automática (AE), el balance de blancos automático (AWB) y el enfoque automático (AF).

La verificación de AE verifica que el cambio de luma esté dentro del rango esperado para las imágenes de lentes UW y W. La verificación del balance de blancos verifica que las relaciones de rojo-verde y azul-verde estén dentro de los valores umbrales para las imágenes de lentes UW y W. La verificación de AF evalúa el valor de estimación de nitidez en función de la magnitud promedio del gradiente entre las imágenes de los lentes UW y W.

Mientras ejecutas esta prueba, si el efecto Moiré interfiere en los resultados, usa una tablet de mayor resolución de la lista de tablets aprobadas por el ITS de la cámara.

APIs probadas:

Aprobación: Para que la prueba se apruebe, las verificaciones de AE y AWB deben ser correctas. Los resultados de la verificación de AF solo se usan con fines de registro. Los siguientes son los criterios para cada verificación:

  • Verificación de AE: El cambio de luma (valor Y) entre las imágenes de los lentes UW y W debe ser inferior al 4% para todos los parches de color si el dispositivo admite ae_regions y awb_regions. Si solo se admite ae_regions, solo los valores de parche de color gris deben cumplir con los criterios.
  • Verificación del balance de blancos automático: La diferencia entre los valores rojo-verde y azul-verde para las imágenes de los lentes UW y W debe ser inferior al 3% para el parche de color gris y debe ser inferior al 10% para otros parches de color si el dispositivo admite ae_regions y awb_regions.
  • Verificación del enfoque automático: La nitidez de la imagen para la captura con el lente W debe ser mayor que la nitidez con la captura UW.

test_multi_camera_switch_gray_uw_y

Figura 126: Parche gris tomado con lente UW.

test_multi_camera_switch_gray_w_y

Figura 127: Parche gris tomado con lente W.

scene8

scene8 es un marco rectangular dividido en cuatro regiones iguales, cada una de las cuales contiene un retrato tomado con una exposición diferente o superpuesto con un tono de color diferente (tono azul, aumento de la exposición, disminución de la exposición, tono amarillo). Cuatro marcadores ArUco se alinean con las cuatro esquinas externas del rectángulo para obtener coordenadas precisas del marco del rectángulo principal.

ejemplo de escena8

Figura 128: Ejemplo de escena 8.

test_ae_awb_regions

Prueba que los valores de RGB y luma difieren cuando se graba la vista previa en diferentes regiones de AE y AWB.

La prueba graba una vista previa de 8 segundos y realiza la medición de AE y AWB en cada cuadrante durante 2 segundos cada uno. Luego, la prueba extrae un fotograma de la grabación de vista previa de cada región y usa los fotogramas extraídos para realizar las siguientes verificaciones de AE y AWB:

  • Verificación de AE: Verifica que el fotograma que mide la región con una exposición disminuida tenga un valor de luma aumentado de más del 1% en comparación con el fotograma que mide la región con una exposición aumentada. Esto verifica que las imágenes se iluminen cuando se mide una región oscura.
  • Verificación del balance de blancos automático: Verifica que la proporción de rojo a azul (de los valores RGB promedio de la imagen) en el fotograma con la región de medición azul sea más del 2% superior al fotograma con la región de medición amarilla. Esto verifica que las imágenes tengan un valor de RGB equilibrado cuando se mide una región amarilla (cálida) o azul (fría).

APIs probadas:

Aprobación: La AE y el AWB pasan las verificaciones.

test_ae_awb_regions_dark_region

Figura 129: Región oscura de medición de fotogramas con mayor exposición.

test_ae_awb_regions_light_region

Figura 130: Región más clara de medición de fotogramas con menor exposición.

Mecanismos de fallo:

  • La detección precisa de los cuatro marcadores ArUco es esencial para esta prueba. Si la detección inicial falla, el sistema intenta un segundo pase de detección con una versión en blanco y negro de la imagen. La siguiente imagen en escala de grises representa el paso de procesamiento secundario:

    Desallineamiento de los marcadores de ArUco

    Figura 131: Alineación incorrecta de los marcadores ArUco

test_color_correction_mode_cct

Prueba COLOR_CORRECTION_MODE en diferentes temperaturas y tonos de color, y verifica los cambios en las relaciones RGB en comparación con la escena de captura, scene8.

APIs probadas:

Aprobación: Las relaciones RGB muestran los aumentos o disminuciones previstos en relación con las temperaturas de color y los tonos seleccionados.

Criterios para omitir pruebas

Se omite la prueba test_color_correction_mode_cct si se cumple alguno de los siguientes criterios:

scene9

scene9 consta de miles de círculos de tamaño y color aleatorios para crear una escena con una repetibilidad muy baja para estresar los algoritmos de compresión JPEG.

Ejemplo de escena 9

Figura 132: Ejemplo de escena 9.

test_jpeg_high_entropy

Pruebas que la compresión JPEG de la cámara funciona en scene9 con alta entropía y el factor de calidad de JPEG establecido en 100%. El factor de zoom aumenta para verificar que la escena que se muestra en la tablet ocupe todo el campo de visión de la cámara.

APIs probadas:

Aprobación: El archivo JPEG se comprime, se escribe y se vuelve a leer correctamente desde el disco.

test_jpeg_quality

Prueba la calidad de compresión JPEG de la cámara. Pasa las calidades de JPEG a través de android.jpeg.quality y verifica que las tablas de cuantificación cambien correctamente.

APIs probadas:

Pasa: La matriz de cuantificación disminuye con el aumento de la calidad. (La matriz representa el factor de división).

Promedios de matrices DQT de luma y crominancia de la cámara posterior del Pixel 4 en comparación con la calidad de JPEG

Figura 133: Promedios de matrices de DQT de luma y crominancia de la cámara posterior del Pixel 4 en comparación con la calidad de JPEG.

Ejemplo de prueba fallida de test_jpeg_quality

Figura 134: Ejemplo de prueba fallida.

scene_video

scene_video es una escena de video que consta de cuatro círculos de colores diferentes que se mueven hacia adelante y hacia atrás a diferentes velocidades de fotogramas sobre un fondo blanco.

Figura 135: Ejemplo de scene_video.

test_preview_frame_drop

Prueba que la velocidad de fotogramas de vista previa solicitada se mantenga con una escena dinámica. Esta prueba se ejecuta en todas las cámaras que están expuestas a apps de terceros.

APIs probadas:

Aprobación: La velocidad de fotogramas de la vista previa es el máximo del rango de velocidad de fotogramas solicitada, y la variación promedio entre fotogramas consecutivos es inferior a la tolerancia relativa establecida en la prueba.

scene_extensions

Las pruebas de scene_extensions son para extensiones de cámara y deben usar ITS integrado en la cámara, ya que requieren un control preciso del entorno de prueba. Además, se debe controlar toda la fuga de luz. Esto puede requerir cubrir el equipo de prueba, el DUT y la tablet con una cubierta protectora, así como eliminar la fuga de luz de la pantalla frontal del DUT.

scene_hdr

La escena scene_hdr consta de un retrato a la izquierda y un código QR de bajo contraste a la derecha.

scene_hdr

Figura 136: Ejemplo de scene_hdr.

test_hdr_extension

Prueba la extensión HDR. Toma capturas con y sin la extensión habilitada, y comprueba si la extensión hace que el código QR sea más detectable.

APIs probadas:

Aprobación: La extensión HDR reduce la cantidad de cambios de contraste necesarios para detectar el código QR o reduce el gradiente en el código QR.

scene_low_light

La escena scene_low_light consta de una cuadrícula de cuadrados de diferentes tonos de gris sobre un fondo negro, y la cuadrícula de cuadrados está unida por un contorno rojo. Los cuadrados están dispuestos en una orientación de curva de Hilbert.

Ejemplo de scene_low_light

Figura 137: Ejemplo de scene_low_light.

test_night_extension

Prueba la extensión de Night. Realiza capturas con la extensión habilitada y realiza las siguientes acciones:

  • Detecta la presencia de 20 cuadrados.
  • Calcula la luma delimitada por cada cuadrado.
  • Calcula el valor de luma promedio de los primeros 6 cuadrados según la orientación de la cuadrícula de la curva de Hilbert.
  • Calcula la diferencia en el valor de luma de cuadrados consecutivos (por ejemplo, cuadrado2 - cuadrado1) hasta los cuadrados 5 y 6 (cuadrado6 - cuadrado5) y encuentra el promedio de las cinco diferencias calculadas.

En el caso de los dispositivos que ejecutan Android 16 o versiones posteriores, la solicitud de captura incluye una región medida que corresponde al rectángulo que limita la cuadrícula de cuadrados. Esta adición cambia los criterios de aprobación del umbral.

APIs probadas:

Aprobación:

  • Para dispositivos con Android 16 o versiones posteriores, el valor promedio de luma de los primeros 6 cuadrados debe ser de al menos 80, y la diferencia promedio en el valor de luma de los cuadrados consecutivos hasta los cuadrados 5 y 6 debe ser de al menos 18.75.
  • En el caso de los dispositivos que ejecutan Android 15 y versiones anteriores, el valor promedio de luma de los primeros 6 cuadrados debe ser de al menos 85, y la diferencia promedio en el valor de luma de los cuadrados consecutivos hasta los cuadrados 5 y 6 debe ser de al menos 17.

En el siguiente gráfico de luminancia, se muestra cómo se ve un resultado de prueba aprobado.

Ejemplo de prueba aprobada de escena nocturna con poca luz

Figura 138: Ejemplo de prueba aprobada de una escena nocturna con poca luz.

test_low_light_boost_extension

Prueba el modo de AE con mejora con poca luz. Si Camera2 admite el modo de AE con aumento de poca luz, esta prueba se realiza para Camera2. Si la extensión de la cámara del modo nocturno es compatible y la extensión admite el modo de AE con poca luz, esta prueba también se realiza para la extensión de la cámara del modo nocturno. Esta prueba establece el modo de AE en el aumento de poca luz, toma un fotograma de la vista previa y realiza lo siguiente:

  • Detecta la presencia de 20 cuadros
  • Calcula la luma delimitada por cada cuadro.
  • Calcula el valor de luma promedio de los primeros 6 cuadrados según la orientación de la cuadrícula de la curva de Hilbert.
  • Calcula la diferencia en el valor de luma de cuadrados consecutivos (por ejemplo, cuadrado2 - cuadrado1) hasta los cuadrados 5 y 6 (cuadrado6 - cuadrado5) y encuentra el promedio de las cinco diferencias calculadas.

En el caso de los dispositivos que ejecutan Android 16 o versiones posteriores, la solicitud de captura incluye una región medida que corresponde al rectángulo que limita la cuadrícula de cuadrados. Esta adición cambia los criterios de aprobación del umbral.

APIs probadas:

Aprobación:

  • En el caso de los dispositivos que ejecutan Android 16 o versiones posteriores, el valor promedio de luma de los primeros 6 cuadrados debe ser de al menos 54, y la diferencia promedio en el valor de luma de los cuadrados consecutivos hasta los cuadrados 5 y 6 debe ser de al menos 17.

  • Para los dispositivos que ejecutan Android 15 y versiones anteriores, el valor promedio de luma de los primeros 6 cuadrados debe ser de al menos 70, y la diferencia promedio en el valor de luma de los cuadrados consecutivos hasta los cuadrados 5 y 6 debe ser de al menos 18.

scene_tele

Un requisito clave para las pruebas de scene_tele es que la distancia del gráfico debe ser de al menos la distancia de enfoque mínima del lente telefoto. Como esta distancia de enfoque mínima puede diferir entre dispositivos, debes configurar tu configuración para que se adapte a la cámara telefoto específica.

Configuración de scene_tele según la distancia de enfoque de la cámara gran angular y teleobjetivo

Figura 139: Configuración de scene_tele según la distancia de enfoque de la cámara gran angular y teleobjetivo.

Para obtener más información sobre la configuración del hardware de prueba, consulta Configuración del equipo de extensión de tele.

scene6_tele

La escena scene6_tele consta de una cuadrícula de marcadores ArUco sobre un fondo blanco.

Si las capturas de scene6_tele se ven sobreexpuestas en la plataforma modular, quita la placa frontal de la plataforma modular.

Desconecta el equipo de prueba de WFoV de la extensión y quita el soporte para teléfono.

Desconecta el equipo de prueba de WFoV de la extensión y quita el soporte para teléfono.

Figura 140: Desconecta el equipo de prueba de WFoV de la extensión y quita el soporte para teléfono.

remove_front_plate

Figura 141: Quita la placa frontal.

test_zoom_tele

Prueba el comportamiento del zoom de la cámara del lente gran angular al teleobjetivo. La prueba es idéntica a test_zoom, pero prueba el comportamiento del zoom de la cámara del lente gran angular al teleobjetivo.

APIs probadas:

Aprobación: El tamaño relativo del marcador ArUco capturado es preciso en función de la relación de zoom solicitada para verificar que la cámara realice el zoom correctamente, y la distancia del marcador al centro de la imagen cambia según los criterios que se indican en test_zoom.

test_preview_zoom_tele

Prueba el comportamiento del zoom de la cámara para los fotogramas de vista previa del lente gran angular al teleobjetivo. La prueba es idéntica a test_preview_zoom, pero prueba el comportamiento del zoom de la cámara para los fotogramas de vista previa del lente gran angular al teleobjetivo.

APIs probadas:

Aprobado: El tamaño relativo del marcador ArUco capturado es preciso en función de la relación de zoom solicitada para verificar que la cámara realice el zoom correctamente, y la distancia del marcador al centro de la imagen cambia según los criterios que se indican en test_preview_zoom.

scene7_tele

scene7_tele es idéntico a scene7, pero está configurado para pruebas de lentes teleobjetivos. Es un marco rectangular dividido en cuatro cuadrantes iguales, cada uno con un color diferente. En el centro del rectángulo, hay un gráfico de bordes inclinados para las verificaciones de nitidez. Cuatro marcadores ArUco están alineados con las cuatro esquinas externas del rectángulo para ayudar a obtener coordenadas precisas del marco del rectángulo principal con diferentes relaciones de zoom.

test_multi_camera_switch_tele

Esta prueba verifica que, durante la grabación de vista previa con diferentes relaciones de zoom, el cambio entre los lentes gran angular (W) y telefoto (tele) genera valores RGB similares.

La prueba usa diferentes relaciones de zoom dentro del rango predefinido para realizar una grabación de vista previa dinámica e identificar el punto en el que cambia la cámara física. Este punto marca el cruce del objetivo gran angular al teleobjetivo.

Los fotogramas capturados en el punto de intersección y antes de este se analizan para la AE, el AWB y el AF.

La verificación de AE verifica que el cambio de luma esté dentro del rango esperado para las imágenes de los lentes W y tele. La verificación del balance de blancos verifica que las relaciones de rojo-verde y azul-verde estén dentro de los valores umbrales para las imágenes de los lentes W y tele. La verificación de AF evalúa el valor de estimación de nitidez en función de la magnitud promedio del gradiente entre las imágenes del lente gran angular y del teleobjetivo.

APIs probadas:

Aprobación: Para que la prueba se apruebe, las verificaciones de AE, AWB y AF deben aprobarse. Los siguientes son los criterios para cada verificación:

  • Verificación de AE: El cambio de luma entre las imágenes del objetivo gran angular y del teleobjetivo debe ser inferior al 4%.
  • Verificación del balance de blancos automático: En el espacio de color LAB, el delta C entre el rojo-verde y el azul-verde para el gran angular y el teleobjetivo no puede superar los 10.
  • Verificación del enfoque automático: La nitidez de la imagen del teleobjetivo debe ser mayor que la del objetivo gran angular.

scene_flash

Las pruebas de scene_flash requieren una escena oscura en la caja de fusión de sensores.

test_auto_flash

Pruebas que se activa el flash automático en una escena oscura para las cámaras frontal y posterior En el caso de las cámaras frontales, el flash automático usa la pantalla para iluminar la escena, no una unidad de flash física. La prueba verifica que se active el flash automático comprobando que el centro de la imagen de la tarjeta sea más brillante cuando el flash automático está habilitado. Para activar el flash automático, se deben apagar las luces del equipo de prueba. Las luces se pueden apagar automáticamente con el controlador Arduino. La escena debe estar completamente oscura para que la prueba funcione correctamente. La app de Jetpack Camera (JCA) se debe instalar en el dispositivo antes de realizar la prueba. El flash automático para cámaras posteriores depende de que se active el estado de AE, pero el flash automático para cámaras frontales no depende de AE y siempre se activa.

APIs probadas:

Aprobación: El centro de la imagen de la tarjeta con el flash automático habilitado es más brillante que la imagen de la escena original en todas las cámaras.

test_flash_strength

Pruebas que el control de intensidad de la luz estroboscópica en el modo SINGLE se implementa correctamente.

Verifica que, si el dispositivo admite el control de intensidad del flash durante el uso de la cámara en el modo SINGLE, la intensidad del flash cambie con los diferentes niveles de intensidad solicitados. Verifica que el control de intensidad del flash funcione con diferentes AE_MODES. Por ejemplo, si el modo de exposición automática es ON o OFF, el nivel de intensidad del flash tiene un efecto en el brillo, y si el modo es ON_AUTO_FLASH, el nivel de intensidad del flash no tiene ningún efecto en el brillo.

Para realizar la prueba, se deben apagar las luces del sistema de prueba. Las luces se pueden apagar automáticamente con el controlador Arduino. La escena debe estar completamente oscura para que la prueba funcione correctamente.

APIs probadas:

Aprobación:

Cuando el modo de exposición automática es ON o OFF, el brillo de los parches de imagen aumenta a medida que el nivel de intensidad del flash aumenta de no tener flash a FLASH_SINGLE_STRENGTH_MAX_LEVEL. Cuando el modo de exposición automática es ON_AUTO_FLASH, la diferencia en el brillo de los parches de imagen está dentro de la tolerancia a medida que el nivel de intensidad del flash aumenta de sin flash a FLASH_SINGLE_STRENGTH_MAX_LEVEL.

test_led_snapshot

Prueba que las instantáneas de LED no saturen ni tinten la imagen.

En esta prueba, se agrega un controlador de iluminación a la caja de fusión de sensores para controlar las luces. Con las luces configuradas en OFF, la prueba toma una captura con el modo AUTO_FLASH configurado en ON. Durante esta captura, la prueba ejecuta una secuencia previa a la captura con el activador aePrecapture establecido en START y establece el intent de captura en Preview para tomar la captura con flash.

Debido a que la captura tiene un punto de acceso distintivo debido al flash, la prueba calcula el promedio de la imagen del flash de toda la captura y verifica si el valor está dentro del rango (68, 102). Para comprobar si la imagen tiene un balance de blancos razonable, la prueba calcula las proporciones rojo-verde y azul-verde, y verifica si las proporciones están entre 0.95 y 1.05.

APIs probadas:

Aprobado: Las relaciones rojo-verde y azul-verde están entre 0.95 y 1.05. El promedio de la imagen con flash está dentro del rango (68, 102).

test_night_mode_indicator

Prueba la funcionalidad del indicador de modo nocturno, una función que indica si la cámara está funcionando en condiciones de poca luz y se beneficiará de una captura fija de la extensión de la cámara del modo nocturno. Esta función solo está disponible en dispositivos compatibles con las extensiones de cámara del modo nocturno.

Esta prueba verifica que el indicador del modo nocturno refleje correctamente las condiciones de iluminación durante la vista previa de la cámara. La prueba realiza los siguientes pasos:

  1. Inicialización: La prueba inicializa un ItsSession y recupera las propiedades de la cámara. También establece una conexión con el controlador de iluminación.
  2. Condiciones de omisión: Se omite la prueba si el dispositivo no admite el nivel de API requerido o la función del indicador de modo nocturno.
  3. Sesión de Camera2:
    • La prueba inicia una sesión de captura de vista previa con una sesión de Camera2.
    • Se enciende la luz y se captura un fotograma de vista previa.
    • La prueba verifica que el indicador de modo nocturno esté en el estado OFF.
    • Se apaga la luz y se captura un fotograma de vista previa.
    • La prueba verifica que el indicador de modo nocturno esté en el estado ON.
  4. Sesión de extensión de la cámara:
    • La prueba repite el mismo procedimiento que para la sesión Camera2, pero con una sesión CameraExtension con la extensión EXTENSION_NIGHT.
  5. Limpieza: La prueba cierra ItsSession y libera el controlador de iluminación.

APIs probadas:

Aprobación:

  • Cuando la luz está encendida, el indicador del modo nocturno debe estar en el estado OFF.
  • Cuando la luz está apagada, el indicador del modo nocturno debe estar en el estado ON.
  • Se aplica a las sesiones de Camera2 y CameraExtension.

test_preview_min_frame_rate

Prueba que la velocidad de fotogramas de la vista previa disminuye correctamente en una escena oscura. Para que esta prueba funcione correctamente, el operador de prueba o el controlador deben apagar las luces del equipo de prueba.

APIs probadas:

Aprobación: La velocidad de fotogramas de la vista previa está en el mínimo del rango de velocidad de fotogramas solicitado y la variación entre fotogramas es menor que la tolerancia absoluta establecida en la prueba.

test_torch_strength

Pruebas que el control de intensidad de la luz estroboscópica en el modo TORCH se implementa correctamente.

Verifica que, si el dispositivo admite el control de intensidad del flash durante el uso de la cámara en el modo TORCH, la intensidad de la linterna cambie con los diferentes niveles de intensidad solicitados. Verifica que el control de intensidad del flash funcione con diferentes AE_MODES. Por ejemplo, si el modo de exposición automática es ON o OFF, el nivel de intensidad del flash tiene un efecto en el brillo, y si el modo es ON_AUTO_FLASH, el nivel de intensidad del flash no tiene ningún efecto en el brillo. Verifica que la intensidad de la linterna permanezca igual durante la duración de una ráfaga, lo que simula una sesión de captura de video. Para realizar la prueba, se deben apagar las luces del equipo de prueba. Las luces se pueden apagar automáticamente con el controlador Arduino. La escena debe estar completamente oscura para que la prueba funcione correctamente.

APIs probadas:

Aprobación:

Cuando el modo de exposición automática es ON o OFF, el brillo de los parches de ráfaga de imagen aumenta a medida que el nivel de intensidad del flash aumenta de no tener flash a FLASH_TORCH_STRENGTH_MAX_LEVEL. Cuando el modo de exposición automática es ON_AUTO_FLASH, la diferencia en la brillantez de los parches de ráfaga de imágenes está dentro de la tolerancia a medida que el nivel de intensidad del flash aumenta de no tener flash a FLASH_TORCH_STRENGTH_MAX_LEVEL.

sensor_fusion

Las pruebas de fusión de sensores requieren un movimiento específico del teléfono frente a un patrón de tablero de ajedrez y marcadores de ArUco. Para obtener resultados óptimos, verifica que el gráfico de prueba esté montado de manera plana. Los gráficos que no son planos afectan los cálculos de rotación de muchas de las pruebas. El gráfico debe ocupar toda la parte posterior de la caja de fusión de sensores cuando se imprime a 43.2 cm x 43.2 cm. (43 x 43 cm). Las pruebas de sensor_fusion se pueden automatizar con la Sensor Fusion Box.

Gráfico de fusión de sensores

Figura 142: Gráfico de fusión de sensores.

Gráfico de fusión de sensores en el sistema

Figura 143: Gráfico de fusión de sensores que cubre la parte posterior de la caja de fusión de sensores.

test_lens_intrinsic_calibration

Prueba que el centro óptico del lente cambia de forma intrínseca cuando el lente se mueve debido a la estabilización de imagen óptica (OIS). Si se admiten muestras intrínsecas del lente, prueba que el centro óptico de las muestras intrínsecas del lente cambie cuando el lente se mueva debido a la OIS.

APIs probadas:

Aprobación: El centro óptico del lente cambia de forma intrínseca en 1 píxel o más. Si se admiten muestras intrínsecas del lente, los centros ópticos de las muestras intrínsecas del lente cambian en 1 píxel o más.

La siguiente figura es un ejemplo de gráfico test_lens_intrinsic_calibration que muestra los cambios de los puntos principales en píxeles para cada fotograma:

test_lens_intrinsic_calibration_example.png

Figura 144: Ejemplo de gráfico de test_lens_intrinsic_calibration que muestra los cambios de los puntos principales en píxeles para cada fotograma.

test_multi_camera_frame_sync

Prueba que las marcas de tiempo de fotogramas capturadas por la cámara lógica estén dentro de 10 ms calculando los ángulos de los cuadrados dentro del tablero de ajedrez para determinar la marca de tiempo.

APIs probadas:

Aprobación: El ángulo entre las imágenes de cada cámara no cambia de forma significativa a medida que se gira el teléfono.

test_preview_distortion

Pruebas que comprueban que la distorsión se corrige en cada fotograma de vista previa tomado en varios niveles de zoom. Para cada fotograma de vista previa, la prueba calcula puntos ideales según los elementos intrínsecos y extrínsecos de la cámara.

En la imagen de ejemplo, los puntos ideales se muestran en verde y los puntos reales se muestran en rojo. El error de distorsión se calcula en función de la distancia RMS en píxeles entre los puntos reales y los ideales. Los elementos destacados en verde y rojo de la imagen se usan para detectar visualmente el área del error de distorsión.

test_preview_distortion_example.jpg

Figura 145: Imagen de un tablero de ajedrez con puntos ideales en verde y puntos reales en rojo.

APIs probadas:

Aprobación: El error de distorsión normalizado de cada fotograma de vista previa es inferior al umbral establecido en la prueba.

test_preview_stabilization

Se realizaron pruebas que indican que el video de vista previa estabilizado rota menos que el giroscopio.

APIs probadas:

Aprobación: La rotación máxima del ángulo en los fotogramas es inferior al 70% de la rotación del giroscopio.

Los siguientes son videos de muestra con y sin estabilización:

Figura 146: Video de muestra con estabilización.

Figura 147: Video de ejemplo sin estabilización.

test_sensor_fusion

Prueba la diferencia de marca de tiempo entre la cámara y el giroscopio para aplicaciones de RA y VR. El teléfono se gira 90 grados 10 veces frente al patrón de tablero de ajedrez. El movimiento es de aproximadamente 2 s de ida y vuelta. Esta prueba se omite si no se incluye un giroscopio o si no está habilitado el parámetro REALTIME de la fuente de marca de tiempo.

La prueba test_sensor_fusion genera una serie de gráficos. Los dos diagramas más importantes para la depuración son los siguientes:

  • test_sensor_fusion_gyro_events: Muestra los eventos del giroscopio del teléfono durante la prueba. El movimiento en las direcciones x e y implica que el teléfono no está montado de forma segura en la placa de montaje, lo que reduce la probabilidad de que se apruebe la prueba. La cantidad de ciclos en la trama depende de la velocidad de escritura para guardar fotogramas.

    Ejemplo de eventos de giroscopio de test_sensor_fusion

    Figura 148: Ejemplo de eventos del giroscopio test_sensor_fusion.

  • test_sensor_fusion_plot_rotations: Muestra la alineación del giroscopio y los eventos de la cámara. Este gráfico debe mostrar un movimiento coincidente entre la cámara y el giroscopio de +/- 1 ms.

    Ejemplo de rotaciones de gráfico de test_sensor_fusion

    Figura 149: Ejemplo de rotaciones de gráfico de test_sensor_fusion.

APIs probadas:

Aprobación: La compensación de las marcas de tiempo de la cámara y el giroscopio es inferior a 1 ms según el artículo 7.3.9 Sensores de alta fidelidad del CDD.

Mecanismos de fallo:

  • Error de compensación: El desplazamiento del giroscopio de la cámara no está calibrado correctamente dentro de +/- 1 ms.
  • Pérdidas de fotogramas: La canalización no es lo suficientemente rápida como para capturar 200 fotogramas de forma consecutiva.
  • Errores de socket: adb no puede conectarse de forma confiable al DUT el tiempo suficiente para ejecutar la prueba.
  • El gráfico no está montado de forma plana. El gráfico test_sensor_fusion_plot_rotations tiene fotogramas en los que el giroscopio y la rotación de la cámara varían considerablemente a medida que la cámara rota a través de las partes del gráfico que no son planas.
  • La cámara no está montada en posición horizontal. El gráfico test_sensor_fusion_gyro_events muestra el movimiento en los planos X e Y. Esta falla es más común en las cámaras frontales, ya que la cámara posterior suele tener una protuberancia elevada en el resto del cuerpo del teléfono, lo que genera una inclinación cuando se monta la parte posterior del teléfono en la placa de montaje.

test_video_stabilization

Pruebas que indican que el video estabilizado rota menos que el giroscopio.

APIs probadas:

Aprobación: La rotación máxima del ángulo en los fotogramas es inferior al 60% de la rotación del giroscopio.

Los siguientes son videos de muestra con y sin estabilización.

Figura 150: Video de muestra con estabilización.

Figura 151: Video de ejemplo sin estabilización.

test_video_stabilization_jca

Las pruebas que estabilizan el video capturado con la JCA rotan menos que el giroscopio. El JCA se debe instalar en el dispositivo antes de realizar la prueba.

APIs probadas:

Aprobación: La rotación máxima del ángulo sobre los fotogramas extraídos del video capturado con la JCA es inferior al 70% de la rotación del giroscopio.

feature_combination

Las pruebas de feature_combination verifican que las funciones funcionen correctamente cuando se habilitan varias funciones de la cámara al mismo tiempo. En estas pruebas, se usa la misma imagen de tablero de ajedrez que se usa en la escena de fusión de sensores.

test_feature_combination

Prueba todas las combinaciones de diferentes combinaciones de transmisiones, el modo de estabilización de video, el rango de FPS objetivo, el video HDR de 10 bits y el Ultra HDR que admite el dispositivo de la cámara.

En Android 16 y versiones posteriores, la prueba ejecuta todas las combinaciones de funciones compatibles y registra los resultados en un archivo proto. Las aserciones de fallas solo se llaman para combinaciones de atributos para los que isSessionConfigurationSupported muestra True.

APIs probadas:

Aprobación: Para cada combinación de atributos admitida:

  • La transmisión de vista previa se estabiliza si la estabilización de vista previa está activada.
  • La velocidad de fotogramas de la vista previa se encuentra dentro del AE_TARGET_FPS_RANGE configurado.
  • El espacio de color de la transmisión de vista previa grabada coincide con el establecido.
  • La captura Ultra HDR tiene un mapa de ganancia válido.

scene_ip

En Android 16 y versiones posteriores, la escena scene_ip habilita las verificaciones de paridad de imágenes entre la app de cámara predeterminada y la app de cámara de Jetpack (JCA) para identificar las diferencias principales entre las imágenes capturadas. El JCA replica las capturas de la app de redes sociales y proporciona una imagen de referencia que las apps de redes sociales luego procesan y refinan.

Requisitos de configuración de hardware

Para las pruebas de scene_ip, se requiere la siguiente configuración de hardware:

  • Las pruebas se ejecutan en el ITS integrado en la cámara Gen2.
  • Los controladores de iluminación y servos que forman parte del equipo de la Gen2 se usan para controlar el entorno de prueba.
  • Se coloca un gráfico de componentes de prueba dentro de la plataforma de la Gen2.

test_chart_gen2

Figura 152: Ejemplo de gen2chart_sample.

Criterios para omitir pruebas

Se omiten las pruebas de scene_ip si se cumple alguno de los siguientes criterios:

  • El dispositivo tiene un primer nivel de API (first_api_level) de 35 o inferior.
  • El dispositivo no es un teléfono con cámaras principales frontal y posterior (por ejemplo, una tablet o una TV).

test_default_jca_ip

Toma capturas del gráfico de componentes de prueba en condiciones de iluminación controladas con la app de cámara predeterminada y la JCA, y realiza las siguientes verificaciones:

  • FoV: Verifica que la app de cámara predeterminada y las capturas de JCA tengan el mismo FoV. Esta verificación usa la función de código QR central extraída de la imagen del gráfico de capturas.

  • Brillo: Verifica que la diferencia de brillo medida entre la app de cámara predeterminada y la JCA no supere los 10. Esta verificación usa el parche de rango dinámico para la medición del brillo.

  • Balance de blancos: Verifica que la diferencia de balance de blancos entre la app de cámara predeterminada y la JCA no supere los 4. Esta verificación usa el parche de rango dinámico para la medición del brillo.

Aprobación de la sección básica: La prueba pasa las verificaciones de FoV, brillo y balance de blancos. En Android 16, esta prueba no es obligatoria (NOT_YET_MANDATED).