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 de la cámara), que forma parte del verificador del Conjunto de pruebas de compatibilidad (CTS) de Android. Las pruebas de 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 según lo previsto. Este documento permite que los desarrolladores y verificadores comprendan qué hacen las pruebas individuales y cómo depurar las fallas de las pruebas.

Las pruebas de puerta de ITS de la cámara se clasifican según las propiedades de la cámara requeridas, el nivel de API y el nivel de la clase de rendimiento de medios (MPC). Para el nivel de API, ITS usa ro.product.first_api_level para controlar las pruebas agregadas en un nivel de API específico que prueban las experiencias negativas del usuario para la funcionalidad en niveles de API inferiores. El ITS usa ro.vendor.api_level para controlar las pruebas de las funciones agregadas en un nivel de API específico que requiere una nueva capacidad de hardware. Si se define ro.odm.build.media_performance_class para un dispositivo, el 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, fluctuaciones, 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 de color
  • scene3: Mejora de bordes, movimiento de 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: Autoflash, frecuencia de fotogramas mínima
  • scene_video: Frame drops
  • sensor_fusion: Compensación de tiempo de la cámara y el giroscopio
  • feature_combination: Combinaciones de funciones
  • 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 específica de la escena. Sin embargo, el teléfono debe estar quieto para las pruebas de giroscopio y vibración.

test_jitter

Mide la fluctuación en las marcas de tiempo de la cámara.

APIs probadas:

Aprobado: Hay al menos un delta de 30 ms entre los fotogramas.

En la siguiente figura, observa el pequeño rango del eje Y. En realidad, la fluctuación es pequeña 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, observando los resultados de captura y los objetos de características de la cámara. En esta prueba, se usan valores de exposición y ganancia de auto_capture_request porque el contenido de la imagen no es importante.

APIs probadas:

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

test_request_capture_match

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

APIs probadas:

Aprobado: Los valores de metadatos de la solicitud y la captura coinciden en todas las tomas.

test_sensor_events

En el caso de los dispositivos que anuncian la 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, es decir, si el dispositivo no está en modo de espera.

APIs probadas:

Aprobado: Se reciben eventos para cada sensor.

test_solid_color_test_pattern

Prueba que los patrones de prueba de color sólido se generen correctamente para silenciar la cámara. Si se admite el silencio de la cámara, se deben admitir los patrones de prueba de color sólido. Si no se admite el silencio de la cámara, los patrones de prueba de color sólido solo se prueban si se anuncia la capacidad.

Si se admiten imágenes sin procesar, también se prueba la asignación de color. Los colores que se probaron 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 color negro.

APIs probadas:

Aprobada: Los patrones de prueba sólidos admitidos tienen el color correcto y hay poca 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 corrección para el patrón de prueba de color sólido y las barras de color.

APIs probadas:

Aprobada: 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 RAW a YUV con la asignación de tonos lineal. Esta prueba requiere android.sensor.testPatternMode = 2 (COLOR_BARS) para generar un patrón de imagen perfecto para la conversión del mapa de tonos. Verifica que la canalización tenga salidas de color adecuadas con asignación de tonos lineal y entrada de imagen ideal (se basa en test_test_patterns).

APIs probadas:

Aprobado: 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 curva de tono de prueba en YUV.

test_unified_timestamp

Prueba si los eventos del sensor de imagen y de movimiento se encuentran en el mismo dominio temporal.

APIs probadas:

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

test_vibration_restriction

Prueba si la vibración del dispositivo funciona según lo previsto.

APIs probadas:

Aprobado: El dispositivo no vibra cuando se silencia con la API de restricción de audio de la cámara.

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 desafíe moderadamente el 3A (AE, AWB y AF), ya que la región central no tiene características. Sin embargo, la solicitud de captura especifica toda la escena, que incluye suficientes atributos para que converjan los ajustes de 3A.

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

Ejemplo de escena 1

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

test_ae_precapture_trigger

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

APIs probadas:

Aprobado: La AE converge.

test_auto_vs_manual

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

APIs probadas:

Aprobado: Los aumentos y la transformación del balance de blancos manual que se informan en cada resultado de captura coinciden con el balance de blancos automático estimate del algoritmo 3A de la cámara.

test_auto_vs_manual, ejemplo de automático

Figura 6: Ejemplo de prueba automática vs.manual.

Ejemplo de balance de blancos test_auto_vs_manual

Figura 7: Ejemplo de balance de blancos de test_auto_vs_manual.

Ejemplo de transformación de balance de blancos manual test_auto_vs_manual

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

test_black_white

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

APIs probadas:

Aprobado: 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 en 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.

test_black_white, ejemplo de diagrama de medias

Figura 11: test_black_white, ejemplo de diagrama de medias.

test_burst_capture

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

APIs probadas:

Aprobada: Captura una ráfaga de imágenes de tamaño completo y verifica si hay pérdida de fotogramas y brillo de la imagen.

test_burst_sameness_manual

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

APIs probadas:

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

Falla: Muestra un aumento o una disminución repentina en el gráfico de 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 de que los streams RAW no se pueden recortar.

APIs probadas:

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

test_crop_region_raw comp raw crop example

Figura 14: Ejemplo de recorte sin procesar de test_crop_region_raw.

test_crop_region_raw comp raw full example

Figura 15: Ejemplo completo sin procesar de test_crop_region_raw.

Ejemplo de recorte YUV de comp test_crop_region_raw

Figura 16: Ejemplo de recorte YUV de comp 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 los valores de la imagen de parche y de recorte.

APIs probadas:

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

test_ev_compensation

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

La sección básica prueba que la compensación de VE se aplique 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 ninguna compensación de EV, y el valor esperado se satura si los valores calculados superan el rango de valores de la 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 básico de la sección: Las imágenes muestran una exposición cada vez mayor sin sobreexponerse en cinco pasos.

test_ev_compensation_basic

Figura 18: test_ev_compensation_basic.

Pase de sección avanzado: Captura un aumento en la luminancia a medida que aumenta el ajuste de compensación de EV. Los ocho fotogramas capturados para cada ajuste de compensación de EV tienen valores de luminancia estables.

test_ev_compensation_advanced_plot_means

Figura 19: test_ev_compensation_advanced_plot_means.

test_exposure_x_iso

Pruebas que demuestran 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 deberían tener el mismo brillo, pero, a lo largo de la secuencia, la imagen debería volverse más ruidosa. Verifica que los valores medios de los píxeles de la muestra sean similares entre sí. Verifica que las imágenes no estén fijadas en 0 o 1 (lo que las haría parecer líneas planas). La prueba también se puede ejecutar con imágenes RAW si se configura la marca debug en el archivo de configuración.

APIs probadas:

Aprobado: 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 figura, a medida que aumentan los valores del multiplicador de ganancia (eje X), los valores promedio normalizados del plano RGB (eje Y) comienzan a desviarse de los valores bajos del multiplicador de ganancia.

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 los ajustes (exposición y ganancia) se fijen en el fotograma correcto para las cámaras FULL y LEVEL_3. Toma una serie de fotos con solicitudes consecutivas y varía los parámetros de la solicitud de captura entre las fotos. Verifica que las imágenes tengan las propiedades esperadas.

APIs probadas:

Aprobado: Las imágenes [2, 3, 6, 8, 10, 12, 13] tienen un ISO o una exposición mayores y se muestran con medias de RGB más altas en el gráfico de la siguiente figura.

test_latching, gráfico de ejemplo de la media

Figura 23: Ejemplo de la media del gráfico test_latching.

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

Prueba que el procesamiento del dispositivo se pueda invertir en píxeles lineales. Captura una secuencia de tomas con el dispositivo apuntando a un objetivo uniforme.

APIs probadas:

Aprobado: Los valores de R, G y B deben aumentar de forma lineal con el aumento de la sensibilidad.

Ejemplo de medias del gráfico test_linearity

Figura 37: Ejemplo de la gráfica test_linearity de las medias.

test_locked_burst

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

APIs probadas:

Aprobado: Las capturas se ven coherentes.

Ejemplo de test_locked_burst frame0

Figura 38: Ejemplo de test_locked_burst frame0.

Ejemplo de test_locked_burst frame1

Figura 39: Ejemplo de frame1 de test_locked_burst.

test_locked_burst_frame2

Figura 40: Ejemplo de test_locked_burst frame2.

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 configuran. 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 una asignación de tonos lineal.

El mapeo 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:

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

test_param_color_correction, ejemplo de medias de diagrama

Figura 41: Ejemplo de la media del gráfico de test_param_color_correction.

En las siguientes figuras, el eje X representa las solicitudes de captura: 0 = unidad, 1 = mejora de rojo y 2 = mejora de azul.

test_param_color_correction req=0 ejemplo de Unity

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

test_param_color_correctness req=1 ejemplo de refuerzo de rojo

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

test_param_color_correction req=2 ejemplo de refuerzo de azul

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

test_param_flash_mode

Prueba que se aplique el parámetro android.flash.mode. Establece manualmente la exposición para que sea oscura, de modo que sea obvio si el flash se activó o no, y usa un mapa de tonos lineal. Verifica el centro con la imagen de la tarjeta para ver si hay un gradiente grande que se creó para verificar si se activó el flash.

APIs probadas:

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

Ejemplo de test_param_flash_mode 1

Figura 45: Ejemplo de test_param_flash_mode 1.

Ejemplo de 1 tarjeta 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 mosaico de test_param_flash_mode 2

Figura 48: Ejemplo de dos tarjetas de test_param_flash_mode.

test_param_noise_reduction

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

APIs probadas:

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

Ejemplo de diagrama de SNR de test_param_noise_reduction

Figura 49: Ejemplo de diagramas de SNR de test_param_noise_reduction.

0: OFF, 1: FAST, 2: HQ, 3: MIN , 4: ZSL

Ejemplo de test_param_noise_reduction con reducción de ruido de ganancia alta nr=0

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

Ejemplo de test_param_noise_reduction con ganancia alta nr=1

Figura 51: Ejemplo de test_param_noise_reduction con reducción de ruido de alta ganancia 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 con ganancia alta nr=3

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

Ejemplo de test_param_noise_reduction con ganancia baja

Figura 54: Ejemplo de ganancia baja de test_param_noise_reduction.

test_param_shading_mode

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

APIs probadas:

Aprobado: Se cambian los modos de sombreado y se modifican los mapas de sombreado del lente según lo esperado.

test_param_shading_mode mapa de sombreado de lente, ejemplo de bucle 0 del modo 0

Figura 55: Mapa de sombreado del lente test_param_shading_mode, ejemplo del bucle 0 del modo 0.

Mapa de sombreado del lente test_param_shading_mode, ejemplo del bucle 0 del modo 1

Figura 56: Mapa de sombreado del lente test_param_shading_mode, ejemplo del modo 1, bucle 0.

test_param_shading_mode mapa de sombreado del lente, ejemplo del bucle 0 del modo 2

Figura 57: Mapa de sombreado del lente test_param_shading_mode, ejemplo del bucle 0 del modo 2.

test_param_tonemap_mode

Prueba que se aplique el parámetro android.tonemap.mode. Aplica diferentes curvas de asignación de tonos a cada canal R, G y B, y verifica que las imágenes de salida se modifiquen según lo esperado. Esta prueba consta de dos pruebas, test1 y test2.

APIs probadas:

Aprobado:

  • test1: Ambas imágenes tienen un mapa de tonos lineal, pero n=1 tiene un gradiente más pronunciado. El canal G (verde) es más brillante para la imagen n=1.
  • test2: Es el 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 sin procesar y YUV con diferente sensibilidad, publica la combinación de aumento de sensibilidad sin procesar y verifica si la media de píxeles de salida coincide con la configuración de la solicitud.

APIs probadas:

Aprobado: Las imágenes sin procesar se oscurecen a medida que aumenta el refuerzo, mientras que el brillo de las imágenes YUV permanece constante.

test_post_raw_sensitivity_boost raw s=3583 boost=0100 example

Figura 60: Ejemplo de test_post_raw_sensitivity_boost con s=3583 y boost=0100 sin procesar.

test_post_raw_sensitivity_boost raw s=1792 boost=0200 example

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

test_post_raw_sensitivity_boost raw s=0896 boost=0400 example

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

test_post_raw_sensitivity_boost raw s=0448 boost=0800 example

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

test_post_raw_sensitivity_boost raw s=0224 boost=1600 example

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

test_post_raw_sensitivity_boost raw s=0112 boost=3199 example

Figura 65: Ejemplo de test_post_raw_sensitivity_boost con s=0112 y boost=3199 sin procesar.

test_post_raw_sensitivity_boost raw plot means example

Figura 66: Ejemplo de la gráfica sin procesar de la potenciación de la sensibilidad de test_post_raw_sensitivity_boost.

test_post_raw_sensitivity_boost YUV s=0112 boost=3199 example

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.

test_post_raw_sensitivity_boost YUV s=0896 boost=0400 example

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

test_post_raw_sensitivity_boost YUV s=1792 boost=0200 example

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

test_post_raw_sensitivity_boost YUV s=3585 boost=0100 example

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 cada vez mayor y mide los valores de píxeles.

APIs probadas:

Aprobada: Aumentar el ISO (ganancia) hace que los píxeles sean más sensibles a la luz, por lo que el gráfico 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 ISO=132 de test_raw_exposure.

Ejemplo de test_raw_exposure ISO=209

Figura 75: Ejemplo de test_raw_exposure ISO=209.

Ejemplo de test_raw_exposure ISO=286

Figura 76: Ejemplo de ISOs=286 de test_raw_exposure.

Ejemplo de test_raw_exposure ISO=363

Figura 77: Ejemplo de ISO=363 de test_raw_exposure.

test_raw_exposure_s=440

Figura 78: Ejemplo de test_raw_exposure ISO=440.

test_reprocess_noise_reduction

Pruebas que android.noiseReduction.mode se aplica para las solicitudes de reprocesamiento. Captura imágenes reprocesadas con la cámara con poca luz. Usa una ganancia analógica alta para verificar que la imagen de captura sea ruidosa. Captura tres imágenes reprocesadas para la reducción de ruido desactivada, rápida y de alta calidad. Captura una imagen reprocesada con ganancia baja y NR desactivado, y usa la varianza de esta como referencia.

APIs probadas:

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

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

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

test_tonemap_sequence

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

APIs probadas:

Aprobado: Hay tres fotogramas idénticos seguidos de otro conjunto 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.

test_tonemap_sequence i=3 example

Figura 83: Ejemplo de test_tonemap_sequence i=3.

test_tonemap_sequence_i=4 example

Figura 84: Ejemplo de test_tonemap_sequence i=4.

test_tonemap_sequence i=5 example

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 una asignación de tonos lineal para que el aspecto de YUV y JPEG sea el mismo 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:

Aprobado: Todos los centros de las imágenes tienen una diferencia máxima de raíz cuadrada de la media (RMS) (valor de un indicador) en las imágenes convertidas a RGB con el 3% de la imagen YUV de mayor resolución.

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:

Aprobado: La prueba se completa y devuelve 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 devuelvan en objetos CaptureResult. La prueba consta de una captura automática, una captura manual y una segunda captura automática.

APIs probadas:

Aprobado: Los metadatos son válidos para todas las capturas y la configuración manual no se filtra en la segunda captura automática. Genera un gráfico de 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 varianza medida de un parche central de la tarjeta gris en las tomas sin procesar capturadas en un rango de sensibilidades y compara estos valores con la varianza que se espera en cada sensibilidad según el modelo de ruido DNG en el HAL de la cámara (basado en los parámetros O y S que se muestran en los objetos de resultado 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:

Aprobado: 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

Las pruebas que convirtieron imágenes YUV y las imágenes JPEG del dispositivo se ven iguales. La prueba toma el 10% central de la imagen y calcula el valor RGB, y verifica que coincidan.

APIs probadas:

Aprobado: 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 RAW, en ráfaga.

APIs probadas:

Aprobado: Cada toma es más ruidosa 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. Pruebas que indican que cada toma es más ruidosa que la anterior.

APIs probadas:

Pase: La varianza aumenta con cada disparo.

test_raw_sensitivity_variance

Figura 93: test_raw_sensitivity_variance.

test_yuv_plus_jpeg

Pruebas que capturan un solo fotograma como salidas YUV y JPEG. Usa una solicitud manual con una asignación de tonos lineal para que el aspecto de YUV y JPEG sea el mismo cuando el módulo image_processing_utils los convierta.

APIs probadas:

Aprobado: Las imágenes YUV y JPEG son similares y tienen menos del 1% de diferencia en RMS (valor de un indicador).

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 que capturan un solo fotograma como salidas sin procesar (sin procesar de 10 y 12 bits) y YUV si se admiten. Usa una solicitud manual con asignación de tonos lineal, por lo que se espera que los formatos RAW y YUV sean iguales. Compara los valores RGB centrales del 10% de las imágenes convertidas a RGB. Registrosandroid.shading.mode.

APIs probadas:

Aprobado: Las imágenes sin procesar y las imágenes YUV son similares y tienen una diferencia de RMS (valor de raíz cuadrada de la media de un valor) 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

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

APIs probadas:

Aprobado: Un ISO más alto genera mayores niveles de ruido.

Criterios para omitir la prueba

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

test_exposure_time_priority

Pruebas CONTROL_AE_PRIORITY_MODE_SENSOR_EXPOSURE_TIME_PRIORITY en varios tiempos de exposición, en las que se verifica la estabilidad del brillo en el rango en el que el 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 la prueba

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

scene2_a

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

Ejemplo de scene2_a

Figura 98: Ejemplo de scene2_a.

test_autoframing

Prueba el comportamiento de encuadre automático del dispositivo de cámara. Realiza un zoom grande de modo que no se vea ningún rostro en la escena, habilita el modo de encuadre automático configurando AUTOFRAMING en CaptureRequest como True y verifica si se pueden detectar todos los rostros de la escena original cuando converge el estado (es decir, cuando AUTOFRAMING_STATE en CaptureResult se configura 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 archivo JPEG capturado tenga un perfil ICC adecuado en su encabezado y que la imagen contenga colores fuera de la gama sRGB.

APIs probadas:

Aprobado: El 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 admitidos 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:

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

test_effects_MONO

Figura 99: test_effects_MONO.

test_exposure_keys_consistent

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

APIs probadas:

Aprobado: La diferencia relativa en la luminancia entre las dos capturas es inferior al 4%.

test_format_combos

Prueba diferentes combinaciones de formatos de salida.

APIs probadas:

Aprobado: Se capturaron correctamente todas las combinaciones.

test_num_faces

Prueba la detección de rostros.

APIs probadas:

Aprobado: Encuentra tres rostros.

test_num_faces ejemplo 1 del modo de detección de rostros

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

test_reprocess_uv_swap

Prueba que el reprocesamiento de YUV no intercambie los planos U y V. Esto se detecta calculando la suma de las diferencias absolutas (SAD) entre la imagen reprocesada y una captura sin reprocesar. Si intercambiar los planos U y V de salida de la captura reprocesada genera un aumento en el SAD, se supone que la salida tiene los planos U y V correctos.

APIs probadas:

Aprobado: 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 mayor diversidad de tonos de piel en las escenas de rostros.

APIs probadas:

Aprobado: Encuentra tres rostros con puntos de referencia faciales en los cuadros delimitadores de rostros.

test_num_faces_fd_mode_1

Figura 102: Ejemplo del modo 1 de detección de rostros de 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 1,920 x 1,440. 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) tridimensional entre las dos imágenes.

Además, esta prueba verifica que las salidas YUV para todos los casos de uso de transmisión admitidos sean razonablemente similares a la salida YUV con el caso de uso de STILL_CAPTURE.

APIs probadas:

Aprobado: Las imágenes YUV y JPEG para el caso de uso de STILL_CAPTURE tienen una diferencia de RMS (valor cuadrático medio de una señal) inferior al 3%; las imágenes YUV para todos los casos de uso admitidos tienen una diferencia de RMS inferior al 10% con respecto a las imágenes YUV con el 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: Encuentra 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.

Aprobado: DEBE tener una latencia de captura JPEG de camera2 inferior a 1,000 ms para una resolución de 1080p, según lo medido por la prueba PerformanceTest de la cámara del CTS en condiciones de iluminación ITS (3000 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.

Aprobado: 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 medido por la prueba PerformanceTest de CTS Camera en condiciones de iluminación de ITS (3,000 K) para ambas cámaras principales.

test_default_camera_hdr

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

Aprobado: La captura del paquete de cámara predeterminado 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 mayor diversidad de tonos de piel en las escenas de rostros.

APIs probadas:

Aprobado: Encuentra tres rostros con puntos de referencia faciales en los cuadros delimitadores de rostros.

scene2_e

test_continuous_picture

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

APIs probadas:

Aprobado: 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 encuentran 3 rostros.

scene2_f

scene2_f tiene tres rostros 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:

Aprobado: Encuentra tres rostros con puntos de referencia faciales en los cuadros delimitadores de 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 un fondo blanco y ropa blanca. 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:

Aprobado: Encuentra tres rostros con puntos de referencia faciales en los cuadros delimitadores de 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 extracción 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 sin reprocesar para cada modo de borde y devuelve 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.

Aprobado: 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 la cámara afectados:

  • EDGE_MODE

test_edge_enhancement_edge=0

Figura 108: Ejemplo de test_edge_enhancement con edge=0.

test_edge_enhancement edge=1 example

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

test_edge_enhancement edge=2 example

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 apartado 7.5.2 Cámara frontal del CDD.

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

Aprobada: La imagen no está invertida, reflejada ni rotada.

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 en alta definición.

APIs probadas:

Aprobado:

  • La desviación 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 desviación del vector de rotación es inferior a 0.01 rad durante el tiempo de prueba.
  • (Aún no es obligatorio) La desviación del giroscopio es inferior a 1 grado por segundo.

test_imu_drift, ejemplo de desviación del giroscopio

Figura 112: Ejemplo de desviación del giroscopio test_imu_drift.

Ejemplo de desviación del vector de rotación de test_imu_drift

Figura 113: Ejemplo de desviación del vector de rotación de 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:

Aprobada: La prueba ubica un gráfico con la rotación esperada (0 grados cuando se inhabilita la anulación de horizontal a vertical y 90 grados cuando se habilita).

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 en la distancia de enfoque óptima (según lo detecta 3A) y los últimos 12 fotogramas en la distancia de enfoque mínima. Alrededor del fotograma 12, el lente se mueve, lo que provoca que la nitidez disminuya. La nitidez se estabiliza a medida que el lente se mueve a la posición final.

La marca de movimiento del lente debe establecerse en todos los fotogramas en los que la nitidez sea intermedia entre la nitidez de los primeros fotogramas con el lente fijo en la distancia focal óptima y la nitidez de los últimos fotogramas con el lente fijo en la distancia focal mínima. El fotograma exacto en el que se mueve el lente no es importante, lo que sí es importante es que la marca de movimiento se establezca cuando el lente se esté moviendo.

APIs probadas:

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

Mecanismos de falla:

  • 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 de enfoque mínima.

test_reprocess_edge_enhancement

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

APIs probadas:

Aprobado: La nitidez de los diferentes modos de borde 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 diagrama de test_reprocess_edge_enhancement

Figura 115: Ejemplo de gráfico de test_reprocess_edge_enhancement.

scene4

scene4 consiste en 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 el gráfico.

Ejemplo de escena 4

Figura 116: Ejemplo de scene4.

test_30_60fps_preview_fov_match

Prueba que los videos de vista previa de 30 FPS y 60 FPS tengan el mismo campo de visión. 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 en el CdV de los dos videos cumplan con las especificaciones. Prueba que la relación de aspecto del círculo permanezca constante, que el centro del círculo permanezca estable y que el radio del círculo permanezca 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 en la relación de aspecto entre los videos de 30 FPS y 60 FPS no supera el 7.5%.

Mecanismos de falla:

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

test_aspect_ratio_and_crop

Prueba si las imágenes se distorsionan o 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 campo de visión máximo posible.

Mecanismos de falla:

  • La cámara no está alineada con el círculo que se muestra en la tablet en el centro de la escena capturada.
  • El círculo de la imagen capturada se distorsiona debido a la canalización de procesamiento.
  • 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 que una solicitud de captura con una relación de aspecto extrema reduce la altura o el ancho de la imagen.
  • El círculo de la imagen capturada tiene un reflejo en el centro y no parece estar 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 para cada cámara. Compara la diferencia entre los centros de los círculos de las cámaras en coordenadas mundiales. Vuelve a proyectar la coordenada mundial en coordenadas de píxeles y la compara con las originales como una verificación de validez. Compara los tamaños de los círculos y verifica si las distancias focales de las cámaras son diferentes.

APIs probadas:

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

Mecanismos de falla:

  • 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ámara no es adecuado para la configuración de la prueba, por ejemplo, probar un sistema de cámara gran angular y ultra gran angular con el soporte de prueba de RFoV. Para obtener más información, consulta Pregunta 1 de las preguntas frecuentes sobre el ITS integrado en la cámara.

test_preview_aspect_ratio_and_crop

De manera similar a la prueba test_aspect_ratio_and_crop para capturas de imágenes fijas, verifica los formatos de vista previa admitidos para comprobar que los fotogramas de vista previa no se estiren ni se recorten de forma inadecuada. 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 encuadre 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 campo de visión 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 adecuada. 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 en el CdV de los dos videos cumplan con las especificaciones.

APIs probadas:

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

test_video_aspect_ratio_and_crop

Graba 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 diferente resolución (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 iluminada de manera uniforme. Esto se logra con un difusor colocado 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 apunta la cámara hacia una fuente de iluminación de alrededor de 2,000 lux. Las imágenes capturadas para scene5 requieren iluminación difusa sin rasgos evidentes. A continuación, se muestra una imagen de ejemplo:

Ejemplo de scene5

Figura 117: Ejemplo de captura de scene5.

test_lens_shading_and_color_uniformity

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

APIs probadas:

Aprobada: En el radio especificado de la imagen, la varianza 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 identificables 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 tools para habilitar una verificación de la alineación del DUT y el gráfico.

scene6

Figura 118: Ejemplo de scene6.

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 RAW con el campo de visión completo y una imagen RAW recortada. La prueba convierte las imágenes en arrays RGB, reduce la escala de la imagen sin procesar recortada de tamaño completo al tamaño que informa SCALER_RAW_CROP_REGION y calcula la diferencia de RMS 3D entre las dos imágenes.

APIs probadas:

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

test_zoom

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

APIs probadas:

Aprobado: El tamaño relativo del marcador ArUco capturado es preciso en relación con la proporción de zoom solicitada para verificar que la cámara haga 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 de zoom de baja latencia de la cámara. Toma capturas en el rango de zoom con android.control.settingsOverride = 1 (SETTINGS_OVERRIDE_ZOOM) y verifica si los marcadores en las imágenes de salida coinciden con las relaciones de zoom en los metadatos de captura. La misma sesión de captura de la cámara se usa para converger 3A y tomar capturas.

APIs probadas:

Aprobado: El tamaño relativo del marcador capturado es preciso en comparación con los metadatos del resultado de la relación de zoom.

test_preview_video_zoom_match

Pruebas que, mientras se graba y se hace zoom, la vista previa y la salida de video muestran y graban la misma salida. Calcula el tamaño del marcador más cercano al centro en diferentes proporciones de zoom y verifica si el tamaño del marcador aumenta a medida que aumenta la proporción de zoom.

APIs probadas:

Aprobado: El tamaño relativo del marcador capturado es preciso en comparación con 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 de aplicar el 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 ultra gran angular al lente gran angular. La prueba toma fotogramas de vista previa en el rango de zoom y encuentra el marcador ArUco más cercano al centro. Luego, la prueba verifica si la posición del marcador central cambia de forma predecible en cada captura. La distancia desde el centro del marcador central hasta el centro de la imagen puede cambiar a una velocidad constante con respecto al factor de zoom hasta que se produzca un cambio de cámara física, o bien puede cambiar de forma monótona hacia la ubicación del mismo marcador después de un cambio de cámara física.

APIs probadas:

Aprobado: El tamaño relativo del marcador ArUco seleccionado es preciso para la relación de zoom registrada 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 admitidas que se indican en CameraCharacteristics#INFO_SESSION_CONFIGURATION_QUERY_VERSION. Para cada una de esas configuraciones, si CameraDeviceSetup#isSessionConfigurationSupported devuelve true, la prueba verifica que se pueda alcanzar el rango de relación de zoom que se devuelve en CameraDeviceSetup#getSessionCharacteristics.

APIs probadas:

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

scene7

scene7 es un marco rectangular dividido en cuatro cuadrantes iguales, cada uno de los cuales está lleno de un color diferente. En el centro del rectángulo, se encuentra un gráfico de borde inclinado para verificar la nitidez. Cuatro marcadores ArUco se alinean con las cuatro esquinas exteriores del rectángulo para ayudar a obtener coordenadas precisas del marco principal del rectángulo en diferentes relaciones de zoom.

scene7

Figura 125: scene7.

test_multi_camera_switch

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

La prueba usa diferentes relaciones de zoom dentro del rango predefinido para realizar una grabación de vista previa dinámica y, luego, 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 cruce y antes de él se analizan para determinar la exposición automática (AE), el balance de blancos automático (AWB) y el enfoque automático (AF).

La verificación de AE comprueba que el cambio de luminancia se encuentre dentro del rango esperado para las imágenes de lentes UW y W. La verificación de AWB comprueba que las proporciones de rojo-verde y azul-verde se encuentren dentro de los valores de umbral para las imágenes de los lentes UW y W. La verificación de AF evalúa el valor de estimación de nitidez según la magnitud promedio del gradiente entre las imágenes de lentes UW y W.

Si, durante la ejecución de esta prueba, el efecto muaré 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:

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

  • Verificación de AE: El cambio de luminancia (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 parches de color gris deben cumplir con los criterios.
  • Verificación de AWB: La diferencia entre los valores rojo-verde y azul-verde de 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 tanto ae_regions como awb_regions.
  • Verificación de AF: 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 el lente W.

scene8

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

Ejemplo de escena8

Figura 128: Ejemplo de scene8.

test_ae_awb_regions

Prueba que los valores de RGB y de luminancia difieran 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. 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 menor exposición tenga un valor de luminancia mayor en más del 1% que el fotograma que mide la región con mayor exposición. Esto verifica que las imágenes se aclaren cuando se mide una región oscura.
  • Verificación de AWB: 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 de un 2% más alta que en el fotograma con la región de medición amarilla. Esto verifica que las imágenes tengan un valor RGB equilibrado cuando se mide una región amarilla (cálida) o azul (fría).

APIs probadas:

Aprobado: Se aprueban ambas verificaciones de AE y AWB.

test_ae_awb_regions_dark_region

Figura 129: Región oscura con medición de fotogramas y 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 falla:

  • La detección precisa de los cuatro marcadores ArUco es fundamental para esta prueba. Si falla la detección inicial, el sistema intenta una segunda pasada 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:

    Desalineación de los marcadores ArUco

    Figura 131: Desalineación 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 proporciones de RGB en comparación con la escena de captura, scene8.

APIs probadas:

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

Criterios para omitir la prueba

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

scene9

scene9 consta de miles de círculos de colores y tamaños aleatorios para crear una escena con muy poca repetibilidad y, así, exigir al máximo los algoritmos de compresión JPEG.

Ejemplo de scene9

Figura 132: Ejemplo de scene9.

test_jpeg_high_entropy

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

APIs probadas:

Aprobado: El archivo JPEG se comprimió correctamente, se escribió y se leyó desde el disco.

test_jpeg_quality

Prueba la calidad de compresión JPEG de la cámara. Aumenta la calidad de JPEG con android.jpeg.quality y verifica que las tablas de cuantificación cambien correctamente.

APIs probadas:

Aprobado: La matriz de cuantificación disminuye a medida que aumenta la calidad. (La matriz representa el factor de división).

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

Figura 133: Promedios de la matriz de DQT de luma y croma de la cámara posterior del Pixel 4 en comparación con la calidad 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 diferentes colores 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 se exponen a apps de terceros.

APIs probadas:

Aprobado: La velocidad de fotogramas de la vista previa se encuentra en el máximo del rango de velocidad de fotogramas solicitado, 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 la 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 fuga de luz. Esto podría requerir cubrir el equipo de prueba, el DUT y la tablet con una lona, así como eliminar las fugas 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 verifica si la extensión hace que el código QR sea más detectable.

APIs probadas:

Aprobado: 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á delimitada por un contorno rojo. Los cuadrados están dispuestos en 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 Noche. Toma capturas con la extensión habilitada y realiza las siguientes acciones:

  • Detecta la presencia de 20 cuadrados.
  • Calcula el luma delimitado por cada cuadrado.
  • Calcula el valor promedio de luma 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 luminancia de los 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:

Aprobado:

  • En el caso de los dispositivos que ejecutan Android 16 o versiones posteriores, el valor de luminancia promedio de los primeros 6 cuadrados debe ser de al menos 80, y la diferencia promedio en el valor de luminancia 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 luminancia de los primeros 6 cuadrados debe ser de al menos 85, y la diferencia promedio en el valor de luminancia 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 de aprobación 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 AE de Mejora con poca luz. Si Camera2 admite el modo AE de refuerzo con poca luz, esta prueba se realiza para Camera2. Si se admite la extensión de cámara en modo nocturno y esta admite el modo AE de refuerzo con poca luz, esta prueba también se realiza para la extensión de cámara en modo nocturno. Esta prueba establece el modo AE en amplificación con poca luz, toma un fotograma de la vista previa y realiza lo siguiente:

  • Detecta la presencia de 20 cajas.
  • Calcula la luminancia delimitada por cada caja.
  • Calcula el valor promedio de luma 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 luminancia de los 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:

Aprobado:

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

  • En el caso de los dispositivos que ejecutan Android 15 y versiones anteriores, el valor promedio de luminancia de los primeros 6 cuadrados debe ser de al menos 70, y la diferencia promedio en el valor de luminancia 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, al menos, la distancia de enfoque mínima del teleobjetivo. Dado que esta distancia de enfoque mínima puede variar entre dispositivos, debes configurar tu equipo para que se adapte a la cámara teleobjetivo específica.

Configuración de scene_tele basada en la distancia de enfoque de la cámara gran angular y la cámara de teleobjetivo

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

Para obtener más información sobre la configuración del hardware de prueba, consulta Cómo configurar el soporte de la extensión de teleobjetivo.

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 demasiado expuestas en la estructura modular, quita la placa frontal de la estructura modular.

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

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

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

remove_front_plate

Figura 141: Quita la placa frontal.

test_zoom_tele

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

APIs probadas:

Aprobado: El tamaño relativo del marcador ArUco capturado es preciso en relación con el factor de zoom solicitado para verificar que la cámara haga 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, desde el objetivo gran angular hasta el 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 desde el objetivo gran angular hasta el teleobjetivo.

APIs probadas:

Aprobado: El tamaño relativo del marcador ArUco capturado es preciso en relación con el factor de zoom solicitado para verificar que la cámara haga 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 teleobjetivo. Es un marco rectangular dividido en cuatro cuadrantes iguales, cada uno con un color diferente. En el centro del rectángulo, se encuentra un gráfico de borde inclinado para verificar la nitidez. Cuatro marcadores ArUco se alinean con las cuatro esquinas exteriores del rectángulo para ayudar a obtener coordenadas precisas del marco principal del rectángulo en diferentes relaciones de zoom.

test_multi_camera_switch_tele

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

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

Los fotogramas capturados en el punto de cruce y antes de él se analizan para determinar la AE, el AWB y el AF.

La verificación de AE comprueba que el cambio de luminancia se encuentre dentro del rango esperado para las imágenes de lentes gran angular y teleobjetivo. La verificación de AWB comprueba que las proporciones de rojo-verde y azul-verde se encuentren dentro de los valores de umbral para las imágenes de lente W y tele. La verificación de AF evalúa el valor de estimación de nitidez según la magnitud promedio del gradiente entre las imágenes de la lente gran angular y la teleobjetivo.

APIs probadas:

Aprobada: Para que la prueba se apruebe, se deben aprobar todas las verificaciones de AE, AWB y AF. A continuación, se indican los criterios para cada verificación:

  • Verificación de AE: El cambio de luminancia entre las imágenes de la lente gran angular y la teleobjetivo debe ser inferior al 4%.
  • Verificación de AWB: En el espacio de color LAB, el delta C entre el rojo y el verde, y el azul y el verde para el lente gran angular y el teleobjetivo no puede superar los 10.
  • Verificación del AF: 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 verifican si 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 el flash automático se active comprobando que el centro de la imagen de la tarjeta sea más brillante con el flash automático habilitado. Para activar el flash automático, las luces del equipo de prueba deben estar apagadas. 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 cámara de Jetpack (JCA) debe estar instalada en el dispositivo antes de la prueba. El flash automático para las cámaras posteriores depende de que se active el estado de AE, pero el flash automático para las cámaras frontales no depende de AE y siempre se activa.

APIs probadas:

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

test_flash_strength

Pruebas que verifican que el control de intensidad del flash en el modo SINGLE se implementó correctamente.

Verifica que, si el dispositivo admite el control de la 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 afecta el brillo, y si el modo es ON_AUTO_FLASH, el nivel de intensidad del flash no afecta el brillo.

Para realizar la prueba, las luces del equipo de prueba deben estar apagadas. 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:

Aprobado:

Cuando el modo de exposición automática es ON o OFF, el brillo de los parches de la imagen aumenta a medida que el nivel de intensidad del flash aumenta de sin 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 la imagen se encuentra 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 los LEDs no saturen ni tiñan la imagen.

Esta prueba 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 establecido en ON. Durante esta captura, la prueba ejecuta una secuencia previa a la captura con el activador aePrecapture establecido en START y establece la intención 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 la media de la imagen con flash de toda la captura y verifica si el valor se encuentra dentro del rango (68, 102). Para verificar si el balance de blancos de la imagen es razonable, la prueba calcula las proporciones de rojo-verde y azul-verde, y verifica si las proporciones están entre 0.95 y 1.05.

APIs probadas:

Aprobado: Las proporciones de rojo-verde y azul-verde se encuentran entre 0.95 y 1.05. La media de la imagen con flash se encuentra 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 de extensión de la cámara en modo nocturno. Esta función solo está disponible en dispositivos que admiten extensiones de la Cámara en modo nocturno.

Esta prueba verifica que el indicador de 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: La prueba se omite si el dispositivo no admite el nivel de API requerido o la función de 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.
    • La luz se enciende y se captura un fotograma de vista previa.
    • La prueba verifica que el indicador del modo nocturno esté en el estado OFF.
    • La luz se apaga y se captura un fotograma de vista previa.
    • La prueba verifica que el indicador del 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 usa 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:

Aprobado:

  • 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 disminuya correctamente en una escena oscura. Para que esta prueba funcione correctamente, el controlador o el operador de la prueba deben apagar las luces del equipo de prueba de forma manual.

APIs probadas:

Aprobado: La velocidad de fotogramas de la vista previa se encuentra en el mínimo del rango de velocidad de fotogramas solicitado, y la variación entre los fotogramas es inferior a la tolerancia absoluta establecida en la prueba.

test_torch_strength

Pruebas que verifican que el control de intensidad del flash en el modo TORCH se implementó correctamente.

Verifica que, si el dispositivo admite el control de la 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 afecta el brillo, y si el modo es ON_AUTO_FLASH, el nivel de intensidad del flash no afecta el brillo. Verifica que la intensidad de la linterna se mantenga igual durante toda la duración de una ráfaga, simulando 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:

Aprobado:

Cuando el modo de exposición automática es ON o OFF, el brillo de los parches de ráfaga de imágenes aumenta a medida que el nivel de intensidad del flash aumenta de sin flash a FLASH_TORCH_STRENGTH_MAX_LEVEL. Cuando el modo de exposición automática es ON_AUTO_FLASH, la diferencia en el brillo de los parches de la ráfaga de imágenes se encuentra dentro de la tolerancia a medida que el nivel de intensidad del flash aumenta de sin 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 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 la parte posterior de la caja de fusión de sensores con una impresión de 17 x 17 pulgadas. (43 x 43 cm). Las pruebas de sensor_fusion se pueden automatizar con la caja de fusión de sensores.

Gráfico de fusión de sensores

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

Gráfico de fusión de sensores en Rig

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

test_lens_intrinsic_calibration

Prueba que el centro óptico de los parámetros intrínsecos del objetivo cambia cuando el objetivo se mueve debido a la estabilización de imagen óptica (OIS). Si se admiten muestras intrínsecas de la lente, se prueba que el centro óptico de las muestras intrínsecas de la lente cambia cuando la lente se mueve debido al OIS.

APIs probadas:

Aprobada: El centro óptico de los parámetros intrínsecos del objetivo cambia en 1 píxel o más. Si se admiten muestras de parámetros intrínsecos del objetivo, los centros ópticos de las muestras de parámetros intrínsecos del objetivo cambian en 1 píxel o más.

En la siguiente figura, se muestra un ejemplo de un diagrama de 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 del gráfico test_lens_intrinsic_calibration que muestra los cambios de los puntos principales en píxeles para cada fotograma.

test_multi_camera_frame_sync

Las pruebas que enmarcan las marcas de tiempo capturadas por la cámara lógica se encuentran dentro de los 10 ms, ya que se calculan los ángulos de los cuadrados dentro del tablero de ajedrez para determinar la marca de tiempo.

APIs probadas:

Aprobado: El ángulo entre las imágenes de cada cámara no cambia de forma apreciable a medida que se rota el teléfono.

test_preview_distortion

Pruebas que verifican que la distorsión se corrija en cada fotograma de vista previa tomado en varios niveles de zoom. Para cada fotograma de vista previa, la prueba calcula los puntos ideales en función de los parámetros 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, 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 puntos ideales. Los resaltados verdes y rojos 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:

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

test_preview_stabilization

Pruebas en las que el video de vista previa estabilizado rota menos que el giroscopio.

APIs probadas:

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

A continuación, se muestran ejemplos de videos con y sin estabilización:

Figura 146: Video de ejemplo con estabilización.

Figura 147: Video de ejemplo sin estabilización.

test_sensor_fusion

Prueba la diferencia de marcas de tiempo entre la cámara y el giroscopio para aplicaciones de RA y RV. El teléfono se rota 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 ningún giroscopio o si no está habilitado el parámetro REALTIME de la fuente de marca de tiempo.

La prueba test_sensor_fusion genera varios diagramas. 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 la prueba se apruebe. La cantidad de ciclos en el gráfico depende de la velocidad de escritura para guardar los fotogramas.

    Ejemplo de eventos de giroscopio de test_sensor_fusion

    Figura 148: Ejemplo de eventos del giroscopio de test_sensor_fusion.

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

    Ejemplo de rotaciones de diagrama de test_sensor_fusion

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

APIs probadas:

Aprobado: El desplazamiento de las marcas de tiempo de la cámara y el giroscopio es inferior a 1 ms según el apartado 7.3.9 Sensores de alta fidelidad del CDD.

Mecanismos de falla:

  • Error de desfase: El desfase entre la cámara y el giroscopio no se calibró correctamente dentro de +/-1 ms.
  • Pérdida de fotogramas: La canalización no es lo suficientemente rápida 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 la rotación del giroscopio y la cámara varían considerablemente a medida que la cámara gira por las partes del gráfico que no son planas.
  • La cámara no está montada de forma plana. 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 un relieve que sobresale del resto del cuerpo del teléfono, lo que crea una inclinación cuando se monta la parte posterior del teléfono en la placa de montaje.

test_video_stabilization

Las pruebas que estabilizaron el video rotan menos que el giroscopio.

APIs probadas:

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

A continuación, se muestran ejemplos de videos con y sin estabilización.

Figura 150: Video de ejemplo con estabilización.

Figura 151 Video de ejemplo sin estabilización.

test_video_stabilization_jca

En las pruebas, el video estabilizado capturado con la JCA rota menos que el giroscopio. El JCA debe instalarse en el dispositivo antes de la prueba.

APIs probadas:

Aprobado: La rotación angular máxima en 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. Estas pruebas usan 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 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 falla solo se llaman para las combinaciones de atributos para las que isSessionConfigurationSupported devuelve True.

APIs probadas:

Aprobado: Para cada combinación de funciones admitidas, haz lo siguiente:

  • 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 que se configuró.
  • La captura Ultra HDR tiene un mapa de ganancia válido.

scene_ip

En Android 16 y versiones posteriores, la escena scene_ip permite realizar 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 principales diferencias entre las imágenes capturadas. La JCA replica las capturas de las apps de redes sociales y proporciona una imagen de referencia que las apps de redes sociales procesan y perfeccionan.

Requisitos de configuración del 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 servo que forman parte de la estructura Gen2 se usan para controlar el entorno de prueba.
  • Se coloca un gráfico de prueba de la función dentro de la estructura de soporte de la cámara Gen2.

test_chart_gen2

Figura 152: Ejemplo de Gen2chart_sample.

Criterios para omitir la prueba

Las pruebas de scene_ip se omiten 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 la función 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 que se extrae 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 el 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 el valor 4. Esta verificación usa el parche de rango dinámico para la medición del brillo.

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