A partir de 2026, para alinearnos con nuestro modelo de desarrollo llamado Trunk Stable y garantizar la estabilidad de la plataforma para el ecosistema, publicaremos el código fuente en el AOSP en el segundo y cuarto trimestre. Para compilar el AOSP y contribuir a él, usa android-latest-release. La rama del manifiesto android-latest-release siempre hará referencia a la versión más reciente que se envió al AOSP. Para obtener más información, consulta Cambios en el AOSP.

Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

Pruebas de ITS de la cámara

En esta página, se proporciona una lista completa de las pruebas del paquete de pruebas de imagen de la cámara (ITS), que forma parte del verificador del Conjunto de pruebas de compatibilidad (CTS) de Android. Las pruebas 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 funcionen como se espera. 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 ITS se actualizan o agregan con cada versión de Android, como se detalla en las notas de la versión de ITS de la cámara para esa versión de Android. Las actualizaciones se basan en los errores que informan los usuarios o los desarrolladores. Las adiciones se basan en errores informados por usuarios o desarrolladores, y en la validación del comportamiento correcto de las nuevas funciones del framework de la cámara.

En Android 17 y versiones posteriores, las pruebas de ITS de la cámara se dividen en dos actividades en el Verificador de CTS para permitir la ejecución en paralelo y reducir el tiempo de prueba: una actividad para las pruebas feature_combination y sensor_fusion, y otra para todas las demás pruebas. Para obtener más información, consulta Reduce el tiempo de prueba.

El ITS de la cámara controla las pruebas según las propiedades de la cámara, el nivel de API y el nivel de clase de rendimiento de medios (MPC) requeridos. En el caso del nivel de API, ITS usa ro.product.first_api_level para controlar las pruebas agregadas en un nivel de API específico que prueban experiencias del usuario negativas para la funcionalidad en niveles de API inferiores. ITS usa ro.vendor.api_level para controlar las pruebas de las funciones que se agregaron en un nivel de API específico y que requieren 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 en las siguientes secciones:

Escenas de prueba basadas en tablets

scene0: Captura metadatos, fluctuación, 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: Refuerzo perimetral, movimiento de la lente
scene4: Relación de aspecto, recorte y campo visual
scene6: Zoom
scene7: Cambio de cámara múltiple
scene8: Medición de regiones 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_video: Pérdidas de fotogramas

Escenas de prueba basadas en sensor_fusion o en el equipo de Gen2

feature_combination: Combinaciones de funciones
scene_flash: Flash automático, velocidad de fotogramas mínima
scene_gen2_chart: Pruebas con el gráfico de papel de 2ª gen.
scene_ip: Paridad de imagen entre la app de cámara predeterminada y la app de Jetpack Camera (JCA)
sensor_fusion: Compensación de tiempo de la cámara y el giroscopio

Escena de prueba basada en difusor

scene5: Sombra de lente

Escena de prueba basada en una tablet con amplia gama de colores

scene_wide_gamut: Perfil y rango de amplia gama de colores

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

Escenas de prueba basadas en tablets

scene0

Las pruebas no requieren información específica de la escena. Sin embargo, el teléfono debe estar estacionario 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 una diferencia de al menos 30 ms entre los fotogramas.

En la siguiente figura, observa el pequeño rango del eje Y. La fluctuación es pequeña en este gráfico.

test_jitter plot

Figura 1. Gráfico de test_jitter.

test_metadata

Prueba la validez de las entradas de metadatos, analizando los resultados de la captura y los objetos de características de la cámara. Esta prueba usa valores de exposición y ganancia de auto_capture_request porque el contenido de la imagen no es importante. Esta es una prueba de FALLA rápida, ya que se ejecuta en poco tiempo, requiere una configuración mínima y señala una cantidad significativa de pruebas que fallan en etapas posteriores. No se debe ejecutar todo el paquete de pruebas hasta que test_metadata se apruebe.

APIs probadas:

Aprobado: El nivel de hardware, las etiquetas rollingShutterSkew, frameDuration, timestampSource, croppingType, blackLevelPattern, pixel_pitch, el campo visual (FoV) y la distancia hiperfocal están presentes y tienen valores válidos.

test_request_capture_match

Prueba que el dispositivo escriba los valores correctos de exposición y ganancia leyendo los metadatos de captura. Esta es una prueba de FALLA rápida, ya que requiere una configuración mínima y señala una cantidad significativa de pruebas que fallan en etapas posteriores. No se debe ejecutar todo el paquete de pruebas hasta que test_request_capture_match sea un resultado de APROBADO.

APIs probadas:

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

test_sensor_events

En el caso de los dispositivos que anuncian compatibilidad con la fusión de sensores, esta prueba verifica si el dispositivo consulta y muestra eventos de sensores. Los sensores que se esperan son el acelerómetro, el giroscopio y el magnetómetro. Esta prueba solo funciona si la pantalla está encendida, lo que significa que el dispositivo no está en modo en espera. Esta es una prueba de FALLA rápida, ya que se ejecuta en poco tiempo, requiere una configuración mínima y señala que la prueba de fusión de sensores falla en etapas posteriores. Las pruebas de escena de sensor_fusion no deberían ejecutarse, a menos que test_sensor_events sea PASS o SKIP.

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 silenciamiento de la cámara, se deben admitir los patrones de prueba de color sólido. Si no se admite el silenciamiento 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 probados son negro, blanco, rojo, azul y verde. En el caso de las cámaras que no admiten imágenes sin procesar, solo se prueba el negro.

APIs probadas:

Aprobado: Los patrones de prueba de color sólido admitidos son del 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:

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

APIs probadas:

Aprobado: Los patrones de prueba admitidos se generan correctamente.

Ejemplo de test_test_patterns

Figura 2. Ejemplo de test_test_patterns.

test_tonemap_curve

Prueba la conversión del patrón de prueba de sin procesar a YUV con un mapa de tonos lineal. Esta prueba requiere android.sensor.testPatternMode = 2 (COLOR_BARS) para generar un patrón de imagen perfecto para la conversión de asignación de tonos. Verifica que la canalización tenga salidas de color adecuadas con un mapa de tonos lineal y una entrada de imagen ideal (depende de test_test_patterns).

APIs probadas:

Aprobado: Las imágenes YUV y RAW se ven similares.

Ejemplo sin procesar de test_tonemap_curve

Figura 3. Ejemplo sin procesar de test_tonemap_curve.

Ejemplo de YUV de test_tonemap_curve

Figura 4. Ejemplo de YUV de test_tonemap_curve

test_unified_timestamp

Prueba si los eventos de imagen y del sensor de movimiento están en el mismo dominio de tiempo. Esta es una prueba de FALLA rápida, ya que se ejecuta en poco tiempo, requiere una configuración mínima y señala que la prueba de fusión de sensores falla en etapas posteriores. Las pruebas de escena sensor_fusion no deben ejecutarse, a menos que test_unified_timestamp sea PASS o SKIP.

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 como se espera.

APIs probadas:

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

scene1_1

scene1 es un gráfico gris. El gráfico gris debe cubrir el 30% central del campo visual de la cámara. Se espera que el gráfico gris desafíe moderadamente a 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 funciones para que converja 3A.

Las cámaras de RFoV se pueden probar en el equipo de prueba de WFoV o RFoV. Si se prueba una cámara de RFoV en el equipo de prueba de WFoV, el gráfico se escala en 2/3 para especificar algunos límites para el gráfico gris en el FoV y ayudar a que converja el 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 scene1

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

test_ae_precapture_trigger

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

APIs probadas:

Aprobado: El AE converge.

test_auto_vs_manual

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

APIs probadas:

Aprobado: Las ganancias 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.

Ejemplo de test_auto_vs_manual auto

Figura 6. Ejemplo de test_auto_vs_manual auto.

Ejemplo de balance de blancos de 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 de test_auto_vs_manual

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

test_black_white

Prueba que el dispositivo produzca imágenes completamente en blanco y negro. 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 larga exposición, lo que genera una foto blanca.

APIs probadas:

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

test_black_white, ejemplo de negro

Figura 9. test_black_white, ejemplo de negro.

Ejemplo de transformación de balance de blancos manual de test_auto_vs_manual

Figura 10. test_black_white, ejemplo de blanco.

Ejemplo de gráfico de medias de test_black_white

Figura 11. Ejemplo de test_black_white, plot_means.

test_burst_capture

Verifica que toda la canalización de captura pueda mantenerse al día con la velocidad de la captura de tamaño completo y el tiempo de CPU.

APIs probadas:

android.hardware.camera2.CameraMetadata#REQUEST_AVAILABLE_CAPABILITIES_BURST_CAPTURE

Aprobación: Captura una ráfaga de imágenes de tamaño completo, verifica si hay pérdidas de fotogramas y el 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 sean todas idénticas. Usa esta prueba para identificar si hay fotogramas esporádicos que se procesan de manera diferente o que tienen artefactos.

APIs probadas:

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

Falla: Muestra un aumento o una disminución del 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 media de test_burst_sameness_manual.

test_burst_sameness_manual_plot_means

Figura 13. test_burst_sameness_manual_plot_means

test_crop_region_raw

Prueba que las transmisiones RAW no se puedan recortar.

APIs probadas:

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

Ejemplo de recorte sin procesar de la comparación de test_crop_region_raw

Figura 14. Ejemplo de recorte de comparación sin procesar de test_crop_region_raw.

Ejemplo completo de comparación de imágenes sin procesar de test_crop_region_raw

Figura 15. Ejemplo completo de comparación de RAW de test_crop_region_raw.

Ejemplo de recorte de YUV de comparación de test_crop_region_raw

Figura 16. Ejemplo de recorte de YUV de comp de test_crop_region_raw

Ejemplo de test_crop_region_raw_yuv_full

Figura 17. Ejemplo completo de test_crop_region_raw YUV

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 recortada.

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 avanzada.

En la sección básica, se prueba que la compensación de EV se aplique con un rango creado con CONTROL_AE_COMPENSATION_STEP. Se capturan ocho fotogramas con 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 compensación de EV aplicada, 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:

Aprobación de la sección básica: Las imágenes muestran una exposición creciente sin sobreexposición en cinco pasos.

test_ev_compensation_basic

Figura 18: test_ev_compensation_basic

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

test_ev_compensation_advanced_plot_means

Figura 19: test_ev_compensation_advanced_plot_means.

test_exposure_x_iso

Prueba que se logre 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 tener más ruido. Verifica que los valores medios de los píxeles de muestra estén cerca entre sí. Verifica que las imágenes no estén limitadas a 0 o 1 (lo que haría que se vean como líneas planas). La prueba también se puede ejecutar con imágenes RAW si configuras la marca debug en tu archivo de configuración.

APIs probadas:

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 del plano RGB normalizado (eje Y) comienzan a desviarse de los valores del multiplicador de ganancia baja.

test_exposure_plot_means

Figura 20: test_exposure_plot_means.

test_exposure_mult=1.00.jpg

Figura 21: test_exposure_mult=1.00.

test_exposure_mult=64.00

Figura 22: test_exposure_mult=64.00.

test_latching

Prueba que los parámetros de configuración (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, en las que varían los parámetros de solicitud de captura entre las fotos. Verifica que las imágenes tengan las propiedades esperadas.

APIs probadas:

android.hardware.camera2.CameraCharacteristics#INFO_SUPPORTED_HARDWARE_LEVEL

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

Ejemplo de medias de diagramas de test_latching

Figura 23. Ejemplo de gráfico de 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 a píxeles lineales. Captura una secuencia de fotos con el dispositivo apuntando a un objetivo uniforme.

APIs probadas:

Aprobado: Los valores de R, G y B deben aumentar de forma lineal con una mayor sensibilidad.

Ejemplo de medias del gráfico test_linearity

Figura 37: Ejemplo de gráfico de test_linearity.

test_locked_burst

Prueba el bloqueo de 3A y la ráfaga de YUV (con la configuración automática). 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 que la verificación de la velocidad de fotogramas se realiza en el CTS.

APIs probadas:

Aprobado: Las capturas se ven coherentes.

Ejemplo de test_locked_burst frame0

Figura 38. Ejemplo de frame0 de test_locked_burst.

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 configuren. Toma fotos con diferentes valores de transformación y ganancia, y prueba que se vean de manera diferente. La transformación y las ganancias se eligen para que el resultado sea cada vez más rojo o azul. Usa un mapa de tonos lineal.

La asignación de tono es una técnica que se usa en el procesamiento de imágenes para asignar un conjunto de colores a otro con el objetivo de 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.

Ejemplo de medias de diagramas de test_param_color_correction

Figura 41. Ejemplo de medias del gráfico 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 unity example

Figura 42. Ejemplo de Unity de test_param_color_correction req=0

Ejemplo de test_param_color_correctness req=1 con aumento de rojo

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

Ejemplo de test_param_color_correction req=2 con aumento de azul

Figura 44. Ejemplo de test_param_color_correction req=2 blue boost

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 se activó el flash o no, y usa un mapa de tonos lineal. Verifica el centro con la imagen de mosaico para ver si se creó un gradiente grande para verificar si se activó el flash.

APIs probadas:

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

Ejemplo 1 de test_param_flash_mode

Figura 45. Ejemplo de test_param_flash_mode 1.

Ejemplo de 1 tarjeta de test_param_flash_mode

Figura 46. Ejemplo de un mosaico 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 mosaicos de test_param_flash_mode.

test_param_noise_reduction

Prueba que el parámetro android.noiseReduction.mode se aplique correctamente cuando se establece. Captura imágenes con la cámara con poca luz. Usa una ganancia analógica alta para garantizar que la imagen capturada tenga ruido. Captura tres imágenes: con la reducción de ruido desactivada, rápida y de alta calidad. También captura una imagen con ganancia baja y NR desactivada, 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:

android.hardware.camera2.CaptureRequest#NOISE_REDUCTION_MODE

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

Ejemplo de SNR de trazado de test_param_noise_reduction

Figura 49. Ejemplo de SNR del gráfico test_param_noise_reduction.

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

Ejemplo de test_param_noise_reduction high gain nr=0

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

Ejemplo de test_param_noise_reduction high gain nr=1

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

Ejemplo de test_param_noise_reduction high gain nr=2

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

Ejemplo de test_param_noise_reduction high gain nr=3

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

Ejemplo de ganancia baja de test_param_noise_reduction

Figura 54. Ejemplo de ganancia baja de test_param_noise_reduction.

test_param_shading_mode

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

APIs probadas:

Aprobado: Los modos de sombreado se cambian y los mapas de sombreado de lentes se modifican como se espera.

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

Figura 55. Ejemplo de mapa de sombreado de lentes de test_param_shading_mode, modo 0, bucle 0.

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

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

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

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

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:

Aprobación:

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 duración 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 la amplificación, 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.

Ejemplo de test_post_raw_sensitivity_boost raw s=1792 boost=0200

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

Ejemplo de test_post_raw_sensitivity_boost raw s=0896 boost=0400

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

Ejemplo de test_post_raw_sensitivity_boost raw s=0448 boost=0800

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

test_post_raw_sensitivity_boost raw s=0224 boost=1600 example

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

Ejemplo de test_post_raw_sensitivity_boost raw s=0112 boost=3199

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

Ejemplo de medias de gráficos sin procesar de test_post_raw_sensitivity_boost

Figura 66: Ejemplo de medias de gráficos sin procesar de test_post_raw_sensitivity_boost.

Ejemplo de test_post_raw_sensitivity_boost YUV s=0112 boost=3199

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

Ejemplo de test_post_raw_sensitivity_boost YUV s=0448 boost=0800

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

Ejemplo de test_post_raw_sensitivity_boost YUV s=0896 boost=0400

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

Ejemplo de test_post_raw_sensitivity_boost YUV s=1792 boost=0200

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

Ejemplo de test_post_raw_sensitivity_boost YUV s=3585 boost=0100

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

test_post_raw_sensitivity_boost_yuv_plot_means

Figura 72. Ejemplo de test_post_raw_sensitivity_boost_yuv_plot_means

test_raw_exposure

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

APIs probadas:

Aprobado: El aumento de la ISO (ganancia) hace que los píxeles sean más sensibles a la luz, por lo que el trazado se mueve hacia la izquierda.

Ejemplo de test_raw_exposure ISO=55

Figura 73. Ejemplo de test_raw_exposure con ISO=55.

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

Ejemplo de test_raw_exposure ISO=132

Figura 74. Ejemplo de test_raw_exposure ISO=132.

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 test_raw_exposure ISO=363.

test_raw_exposure_s=440

Figura 78. Ejemplo de test_raw_exposure con ISO=440.

test_reprocess_noise_reduction

Prueba que se aplique android.noiseReduction.mode 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 tenga ruido. Captura tres imágenes reprocesadas, para NR desactivada, rápida y de alta calidad. Captura una imagen reprocesada con ganancia baja y NR desactivada, y usa la varianza de esta como modelo de referencia.

APIs probadas:

android.hardware.camera2.CaptureResult#NOISE_REDUCTION_MODE

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

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

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

test_tonemap_sequence

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

APIs probadas:

Aprobado: Hay tres fotogramas idénticos seguidos de un conjunto diferente de tres fotogramas idénticos.

Ejemplo de test_tonemap_sequence i=0

Figura 80. Ejemplo de test_tonemap_sequence i=0.

Ejemplo de test_tonemap_sequence i=1

Figura 81. Ejemplo de test_tonemap_sequence i=1.

Ejemplo de test_tonemap_sequence i=2

Figura 82. Ejemplo de test_tonemap_sequence i=2

Ejemplo de test_tonemap_sequence i=3

Figura 83. Ejemplo de test_tonemap_sequence i=3

Ejemplo de test_tonemap_sequence_i=4

Figura 84. Ejemplo de test_tonemap_sequence i=4.

Ejemplo de test_tonemap_sequence i=5

Figura 85. Ejemplo de test_tonemap_sequence i=5.

test_yuv_jpeg_all

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

APIs probadas:

Aprobado: Todos los centros de imágenes tienen una diferencia máxima de raíz cuadrada media (RMS) (valor de una señal) en las imágenes convertidas a RGB con un 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:

android.hardware.camera2.CameraMetadata#REQUEST_AVAILABLE_CAPABILITIES_RAW

Aprobada: 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 consiste en 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 los parámetros de configuración manuales no se filtran en la segunda captura automática. Traza la corrección del sombreado de la 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 de DNG sean correctos. El gráfico muestra la varianza medida de un parche central de la tarjeta gris en fotos 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 la HAL de la cámara (según los parámetros O,S que se muestran en los objetos de resultado de la captura). Para obtener más detalles sobre el modelo de ruido de DNG, descarga el siguiente documento sobre el modelo de ruido de DNG.

APIs probadas:

Aprobado: Los parámetros del modelo sin procesar de 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

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

APIs probadas:

android.graphics.ImageFormat#JPEG

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 una 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 central.

test_raw_burst_sensitivity_variance

Figura 92. test_raw_burst_sensitivity_variance.

test_raw_sensitivity

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

APIs probadas:

Pase: La varianza aumenta con cada tiro.

test_raw_sensitivity_variance

Figura 93. test_raw_sensitivity_variance.

test_yuv_plus_jpeg

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

APIs probadas:

Aprobado: Las imágenes YUV y JPEG son similares y tienen menos del 1% de diferencia de RMS (valor de una señal).

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 admite. Usa una solicitud manual con un mapa de tonos lineal, por lo que se espera que los datos sin procesar y YUV sean los mismos. Compara los valores RGB del 10% central de las imágenes convertidas a RGB. Registrosandroid.shading.mode.

APIs probadas:

Aprobado: Las imágenes YUV y sin procesar son similares y tienen una diferencia de RMS (valor cuadrático medio de una señal) inferior al 3.5%.

test_yuv_plus_raw_shading=1_raw.jpg

Figura 96. test_yuv_plus_raw_shading=1_raw.jpg.

test_yuv_plus_raw_shading=1_yuv.jpg

Figura 97. test_yuv_plus_raw_shading=1_yuv.jpg.

test_sensitivity_priority

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

APIs probadas:

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

Criterios para omitir pruebas

La prueba test_sensitivity_priority.py se omite 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 publica anuncios CONTROL_AE_PRIORITY_MODE_SENSOR_SENSITIVITY_PRIORITY en CONTROL_AE_AVAILABLE_PRIORITY_MODES.

test_exposure_time_priority

Prueba CONTROL_AE_PRIORITY_MODE_SENSOR_EXPOSURE_TIME_PRIORITY en varios tiempos de exposición y verifica que el brillo sea estable 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 pruebas

La prueba test_exposure_time_priority se omite 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 publica anuncios CONTROL_AE_PRIORITY_MODE_SENSOR_EXPOSURE_TIME_PRIORITY en CONTROL_AE_AVAILABLE_PRIORITY_MODES.

scene2_a

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

Ejemplo de scene2_a

Figura 98. Ejemplo de scene2_a.

test_autoframing

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

APIs probadas:

Aprobado: Se detectan los tres rostros.

test_display_p3

Prueba la captura de Display P3 en JPEG con la API de ColorSpaceProfiles. Prueba que el JPEG capturado tenga un perfil ICC 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 de sRGB.

test_effects

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

APIs probadas:

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 luma promedio de una captura con AE habilitada con una captura con AE inhabilitada que aplica manualmente los parámetros de exposición (sensibilidad, tiempo de exposición, duración del fotograma, aumento de sensibilidad posterior a RAW) recibidos en el CaptureResult de la captura con AE habilitada.

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 rostro.

APIs probadas:

Aprobado: Se encuentran tres rostros.

Ejemplo 1 del modo de detección de rostros test_num_faces

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 no reprocesada. Si el intercambio de los planos U y V de salida de la captura reprocesada genera un aumento de la 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

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

test_preview_num_faces

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

APIs probadas:

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

test_num_faces_fd_mode_1

Figura 102. Ejemplo del modo de detección de rostros 1 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 1920 × 1440. Establece jpeg.quality en 100 y captura una solicitud de superficie doble. Convierte ambas imágenes en arrays RGB y calcula la diferencia de la raíz cuadrada media (RMS) en 3D entre las dos imágenes.

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

APIs probadas:

Aprobado: Las imágenes YUV y JPEG para el caso de uso STILL_CAPTURE tienen menos del 3% de diferencia de RMS (valor cuadrático medio de una señal). Las imágenes YUV para todos los casos de uso admitidos tienen menos del 4% de diferencia de CIELAB con respecto a las imágenes YUV con el caso de uso STILL_CAPTURE.

scene2_c

test_num_faces

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

APIs probadas:

Aprobado: Se encuentran tres rostros.

test_num_faces_fd_mode_1

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

test_jpeg_capture_perf_class

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

Aprobado: DEBE tener una latencia de captura JPEG de camera2 < 1000 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 de ITS (3000K) 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 (desde que se abre la cámara hasta el primer fotograma de vista previa) < 600 ms, según lo medido por la prueba PerformanceTest de la cámara de CTS en condiciones de iluminación de ITS (3,000 K) para ambas cámaras principales.

test_default_camera_hdr

Prueba que la captura predeterminada de la cámara 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 predeterminada del paquete de la cámara DEBE ser Ultra HDR para un dispositivo de clase de rendimiento 15.

scene2_d

test_preview_num_faces

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

APIs probadas:

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

scene2_e

test_continuous_picture

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

APIs probadas:

Aprobado: El sistema 3A se estabiliza al final de una captura de 50 fotogramas.

test_num_faces

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

APIs probadas:

Aprobado: Se encontraron 3 rostros.

scene2_f

scene2_f tiene tres rostros con un fondo blanco y ropa blanca. 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 una mayor diversidad de tonos de piel en escenas de rostros.

APIs probadas:

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

Figura 106. Ejemplo de scene2_g.

test_preview_num_faces

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

APIs probadas:

Aprobado: Se encuentran 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. En Android 17 y versiones posteriores, scene3 usa marcadores ArUco para la detección de gráficos.

scene3_aruco_chart

Figura 108. Gráfico de scene3.

test_edge_enhancement

Prueba que el parámetro android.edge.mode se aplique correctamente. Captura imágenes sin volver a procesarlas 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. En Android 17 y versiones posteriores, usa marcadores ArUco para definir el área del gráfico que contiene los bordes nítidos necesarios.

Paso: 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. Modo HQ más nítido o igual que el modo FAST.

APIs probadas:

android.hardware.camera2.CaptureRequest#EDGE_MODE

Parámetros de la cámara afectados:

EDGE_MODE

test_edge_enhancement_edge=0

Figura 109. Ejemplo de test_edge_enhancement edge=0.

Ejemplo de test_edge_enhancement edge=1

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

Ejemplo de test_edge_enhancement edge=2

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

test_flip_mirror

Prueba si la imagen está orientada correctamente según la sección 7.5.2 Cámara frontal de la CDD. En Android 17 y versiones posteriores, usa marcadores ArUco para validar la presencia y la orientación del gráfico. Las imágenes reflejadas, volteadas o rotadas se pueden identificar por el atributo de diamante cerca del centro.

Aprobado: Se detectan todos los marcadores y se alinean correctamente. La imagen no está volteada, invertida ni rotada.

Ejemplo de parche de escena test_flip_mirror

Figura 112. Ejemplo de parche de escena de test_flip_mirror.

test_imu_drift

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

APIs probadas:

Aprobación:

La 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 rad²/s²/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.

Ejemplo de desviación del giroscopio test_imu_drift

Figura 113. Ejemplo de desviación del giroscopio test_imu_drift.

Ejemplo de desvío del vector de rotación de test_imu_drift

Figura 114. Ejemplo de desviación del vector de rotación de test_imu_drift.

test_landscape_to_portrait

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

APIs probadas:

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

Ejemplo de test_landscape_to_portrait

Figura 115. Ejemplo de test_landscape_to_portrait

test_lens_movement_reporting

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

La marca de movimiento de la lente se debe confirmar en todos los fotogramas en los que la nitidez sea intermedia a la nitidez de los primeros fotogramas con la lente fija en la distancia focal óptima y los últimos fotogramas en los que la lente esté fija en la distancia focal mínima. El fotograma exacto en el que se mueve la lente no es importante: lo que importa es que se confirme la marca de movimiento cuando la lente se está moviendo.

En Android 17 y versiones posteriores, esta prueba usa marcadores ArUco para definir el área del gráfico que contiene los bordes nítidos necesarios. Este método proporciona una detección estable para las cámaras, desde las de ultra gran angular (UW) hasta las de teleobjetivo.

APIs probadas:

Aprobado: El indicador de movimiento de la 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 se confirma solo 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 con una distancia focal óptima o los últimos fotogramas con una distancia focal mínima.

test_reprocess_edge_enhancement

Prueba si los métodos de reprocesamiento admitidos para el refuerzo perimetral funcionan correctamente. Procesa una solicitud de captura con un modo de borde de reprocesamiento determinado y compara diferentes modos de captura 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 trazado de test_reprocess_edge_enhancement

Figura 116. Ejemplo de trazado 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 del DUT y la alineación del gráfico.

Ejemplo de scene4

Figura 117. 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 FoV. La prueba captura dos videos, uno con 30 FPS y otro con 60 FPS. Se selecciona un fotograma representativo de cada video y se analiza para verificar que los cambios de FoV en los dos videos estén dentro de 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 de 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 tiene un tamaño significativamente diferente al del video de 60 FPS.
La canalización de procesamiento distorsiona el círculo de la imagen capturada.
El círculo de la imagen capturada se recorta debido a una solicitud de captura de relación de aspecto extrema que reduce la altura o el ancho de la imagen.
El círculo de la imagen capturada tiene un reflejo en el centro y no aparece completamente relleno.

test_aspect_ratio_and_crop

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

APIs probadas:

Aprobado: Las imágenes no se estiran, el centro de las imágenes no difiere en más de un 3% y se conserva el FoV 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.
La canalización de procesamiento distorsiona el círculo de la imagen capturada.
La imagen de menor resolución se recorta dos veces en la canalización de imágenes, lo que crea un FoV diferente entre las imágenes de alta y baja resolución.
El círculo de la imagen capturada se recorta debido a una solicitud de captura con una relación de aspecto extrema que reduce la altura o el ancho de la imagen.
El círculo de la imagen capturada tiene un reflejo en el centro y no aparece completamente relleno.

test_multi_camera_alignment

Prueba los parámetros de calibración de la cámara relacionados con su posicionamiento para sistemas de varias cámaras. Usa las cámaras secundarias físicas de varias cámaras para tomar 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 del mundo 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 las compara con las originales como una verificación de validez. Compara los tamaños de los círculos y verifica si las longitudes 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 longitudes 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 equipo de prueba de RFoV. Para obtener más información, consulta la pregunta 1 de las preguntas frecuentes sobre ITS integrado en la cámara.

test_preview_aspect_ratio_and_crop

Es similar a la prueba test_aspect_ratio_and_crop para capturas de imágenes estáticas, ya que 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 fotograma y que el tamaño del círculo no cambie para un formato constante o con diferentes resoluciones (verificación de FoV).

APIs probadas:

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

test_preview_stabilization_fov

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

APIs probadas:

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

test_video_aspect_ratio_and_crop

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

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 FoV máximo posible.

scene6

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

scene6

Figura 118. Ejemplo de 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 RAW recortadas.

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

APIs probadas:

Aprobado: La diferencia de RMS en 3D entre la imagen sin procesar recortada y reducida, y la imagen sin procesar de FoV completo es menor que el umbral establecido en la prueba.

test_zoom

Prueba el comportamiento del zoom de la cámara desde la lente ultra gran angular hasta la lente gran angular. Toma capturas en el rango de zoom y verifica si los marcadores de ArUco se agrandan a medida que la cámara se acerca. La prueba también verifica si la posición del marcador central cambia de manera predecible en cada captura. La distancia desde el centro del marcador central hasta el centro de la imagen puede cambiar a una velocidad constante con respecto a la relación 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 Jetpack Camera (JCA) debe estar instalada en el dispositivo antes de realizar las pruebas.

APIs probadas:

Aprobado: El tamaño relativo del marcador ArUco capturado es preciso en comparación con la relación de zoom solicitada para verificar que la cámara esté haciendo zoom correctamente, y la distancia del marcador al centro de la imagen cambia según los criterios que se indican en la descripción de la prueba.

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

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

test_low_latency_zoom

Prueba el comportamiento del zoom de baja latencia de la cámara. Toma capturas en el rango de zoom con android.control.settingsOverride = 1 (SETTINGS_OVERRIDE_ZOOM) y verifica si los marcadores de las imágenes de salida coinciden con las relaciones de zoom en los metadatos de captura. Se usa la misma sesión de captura de la cámara para hacer 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

Prueba que, mientras se graba y se hace zoom, la vista previa y la salida de video muestren y graben el mismo resultado. Calcula el tamaño del marcador más cercano al centro con 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.

Figura 120. HD_1280x720_key_frame.png (antes del zoom)

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

Figura 122. HD_1280x720_key_frame.png (después de hacer zoom).

Figura 123. preview_1280x720_key_frame.png (después de acercar).

test_preview_zoom

Prueba que la relación de zoom de cada fotograma de vista previa coincida con los metadatos de captura correspondientes de la lente ultra gran angular a la 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 a la relación 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 informada del resultado de captura correspondiente para todos los fotogramas de vista previa. La distancia relativa del marcador seleccionado desde el centro de la imagen es precisa para la proporció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 la relación de zoom para todos los parámetros de configuración de sesión admitidos 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 devuelto en CameraDeviceSetup#getSessionCharacteristics.

APIs probadas:

Aprobado: Se pueden alcanzar las relaciones de zoom mínima y máxima 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 con un color diferente. En el centro del rectángulo, hay un gráfico de borde inclinado para verificar la nitidez. Se alinean cuatro marcadores ArUco con las cuatro esquinas exteriores del rectángulo para ayudar a obtener coordenadas precisas del marco del rectángulo principal en diferentes proporciones 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 proporciones de zoom dentro del rango predefinido para realizar una grabación de vista previa dinámica y, así, identificar el punto en el que cambia la cámara física. Este punto marca el cambio de la lente UW a la W.

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

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

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

APIs probadas:

Aprobación: Para que se apruebe la prueba, se deben aprobar las verificaciones de AE y AWB. Los resultados de la verificación de AF solo se usan para fines de registro. A continuación, se indican los criterios para cada verificación:

Verificación de AE: El cambio de luma (valor Y) entre las imágenes de los lentes UW y W debe ser inferior al 4% para todos los parches de color si el dispositivo admite ae_regions y awb_regions. Si solo se admite ae_regions, solo los valores de los parches de color gris deben cumplir con los criterios.
Verificación de AWB: La diferencia entre los valores de rojo-verde y azul-verde para las imágenes de las lentes UW y W debe ser inferior al 3% para el parche de color gris y debe ser inferior al 10% para otros parches de color si el dispositivo admite ae_regions y awb_regions.
Verificación de AF: La nitidez de la imagen para la captura con la lente W debe ser mayor que la nitidez con la captura con 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 la 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 distinto (tono azul, exposición aumentada, exposición disminuida, tono amarillo). Se alinean cuatro marcadores ArUco con las cuatro esquinas exteriores del rectángulo para obtener coordenadas precisas del marco del rectángulo principal.

Ejemplo de scene8

Figura 128. Ejemplo de scene8.

test_ae_awb_regions

Prueba que los valores de RGB y luma 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 una medición de AE y AWB en cada cuadrante durante 2 segundos cada uno. Luego, la prueba extrae un fotograma de la grabación de vista previa de cada región y usa los fotogramas extraídos para realizar las siguientes verificaciones de AE y AWB:

Verificación de AE: Verifica que el fotograma que mide la región con exposición disminuida tenga un valor de luma aumentado de más del 1% que el fotograma que mide la región con exposición aumentada. 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 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 las verificaciones de AE y AWB.

test_ae_awb_regions_dark_region

Figura 129. Medición de fotogramas de la región oscura con mayor exposición.

test_ae_awb_regions_light_region

Figura 130. Región más clara de la medición de fotogramas con exposición reducida.

Mecanismos de falla:

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

Figura 131. Desalineación de los marcadores ArUco.

test_color_correction_mode_cct

Prueba COLOR_CORRECTION_MODE en diferentes temperaturas de color y matices, 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 matices de color seleccionados.

Criterios para omitir pruebas

La prueba test_color_correction_mode_cct se omite 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 publica anuncios COLOR_CORRECTION_MODE_CCT en COLOR_CORRECTION_AVAILABLE_ABERRATION_MODES.

scene9

scene9 consta de miles de círculos de colores y tamaños aleatorios para crear una escena con muy baja repetibilidad para someter a prueba 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 funcione en scene9 con alta entropía y el factor de calidad JPEG establecido en 100%. Se aumenta el factor de zoom para verificar que la escena que se muestra en la tablet llene el FoV de la cámara.

APIs probadas:

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

test_jpeg_quality

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

APIs probadas:

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

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

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

Ejemplo de prueba fallida de test_jpeg_quality

Figura 134. Ejemplo de prueba con errores.

scene_extensions

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

scene_hdr

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

scene_hdr

Figura 135. Ejemplo de scene_hdr.

test_hdr_extension

Prueba la extensión de 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 de 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 consiste en 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 se organizan en una orientación de curva de Hilbert.

Ejemplo de scene_low_light

Figura 136. Ejemplo de scene_low_light.

test_night_extension

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

Detecta la presencia de 20 cuadrados.
Calcula la luma delimitada por cada cuadrado
Calcula el valor de luma promedio de los primeros 6 cuadrados según la orientación de la cuadrícula de la curva de Hilbert.
Calcula la diferencia en el valor de luma de 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 de medición que corresponde al rectángulo que delimita la cuadrícula de cuadrados. Esta adición cambia los criterios de aprobación del umbral.

APIs probadas:

Aprobación:

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

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

Ejemplo de prueba aprobada de escena nocturna con poca luz

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

test_low_light_boost_extension

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

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

APIs probadas:

Aprobación:

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

scene_tele

Un requisito clave para las pruebas de scene_tele es que la distancia del gráfico debe ser, como mínimo, la distancia de enfoque mínima del lente teleobjetivo. Como esta distancia mínima de enfoque puede variar entre dispositivos, debes configurar tu sistema para que se adapte a la cámara de teleobjetivo específica.

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

Figura 138. Configuración de scene_tele según 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 Configuración del equipo de extensión de teleobjetivo.

scene6_tele

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

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

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

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

remove_front_plate

Figura 140. Quita la placa frontal.

test_zoom_tele

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

APIs probadas:

Aprobación: El tamaño relativo del marcador ArUco capturado es preciso en comparación con la relació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 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 la lente gran angular hasta la lente 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 la lente gran angular hasta la lente teleobjetivo.

APIs probadas:

scene7_tele

scene7_tele es idéntico a scene7, pero está configurado para probar el lente teleobjetivo. Es un marco rectangular dividido en cuatro cuadrantes iguales, cada uno con un color diferente. En el centro del rectángulo, hay un gráfico de borde inclinado para verificar la nitidez. Se alinean cuatro marcadores ArUco con las cuatro esquinas exteriores del rectángulo para ayudar a obtener coordenadas precisas del marco del rectángulo principal en diferentes proporciones 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.

Los fotogramas capturados en el punto de cruce y antes de este se analizan para AE, AWB y AF.

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

APIs probadas:

Aprobación: Para que la prueba se apruebe, deben aprobarse 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 luma entre las imágenes de la lente W y la lente de teleobjetivo debe ser inferior al 4%.
Verificación de AWB: En el espacio de color LAB, el delta C entre rojo-verde y azul-verde para gran angular y teleobjetivo no puede superar 10.
Verificación de AF: La nitidez de la imagen del teleobjetivo debe ser mayor que la del objetivo W.

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 con diferentes velocidades de fotogramas sobre un fondo blanco.

Figura 141. Ejemplo de scene_video.

test_preview_frame_drop

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

APIs probadas:

Aprobada: 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 menor que la tolerancia relativa establecida en la prueba.

Equipo de Gen2 / escenas de prueba basadas en sensor_fusion

feature_combination

Las pruebas de feature_combination verifican que las funciones se ejecuten 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, modo de estabilización de video, rango de FPS objetivo, video HDR de 10 bits y Ultra HDR que admite el dispositivo de la cámara.

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

APIs probadas:

Aprobado: Para cada combinación de funciones compatible, se cumple 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 del flujo de vista previa grabado coincide con el establecido.
La captura Ultra HDR tiene un mapa de ganancia válido.

scene_flash

Las pruebas de scene_flash requieren una escena oscura en la caja de fusión de sensores. En Android 17 y versiones posteriores, las pruebas de scene_flash se pueden realizar con el dispositivo de Gen2.

test_auto_flash

Prueba que el flash automático se active en una escena oscura para las cámaras posterior y frontal. En el caso de las cámaras frontales, el flash automático usa la pantalla para iluminar la escena, no una unidad de flash física. La prueba verifica que se active el flash automático comprobando que el centro de la imagen de mosaico sea más brillante con el flash automático habilitado. Para activar el flash automático, se deben apagar las luces del equipo de prueba. Las luces se pueden apagar automáticamente con el controlador Arduino. La escena debe estar completamente oscura para que la prueba funcione correctamente. La app de Jetpack Camera (JCA) debe estar instalada en el dispositivo antes de realizar las pruebas. 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 la AE y siempre se activa.

En Android 17 y versiones posteriores, prueba los niveles de zoom que no sean 1x para verificar que funcionen correctamente en todos los rangos de zoom admitidos.

APIs probadas:

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

test_flash_strength

Prueba que el control de intensidad del flash en el modo SINGLE se implemente 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 la intensidad del flash funcione con diferentes valores de AE_MODES. Por ejemplo, si el modo de exposición automática es ON o OFF, el nivel de intensidad del flash influye en el brillo, y si el modo es ON_AUTO_FLASH, el nivel de intensidad del flash no influye en el brillo.

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

APIs probadas:

Aprobación:

Cuando el modo de exposición automática es ON o OFF, el brillo de los parches de imagen aumenta a medida que aumenta el nivel de intensidad del flash 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 imagen está dentro de la tolerancia, ya que el nivel de intensidad del flash aumenta de sin flash a FLASH_SINGLE_STRENGTH_MAX_LEVEL.

test_led_snapshot

Prueba que las instantáneas de LED no saturen ni 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 configurado en ON. Durante esta captura, la prueba ejecuta una secuencia de captura previa con el activador aePrecapture establecido en START y establece el intent de captura en Preview para tomar la captura con flash.

Debido a que la captura tiene un punto de acceso distintivo debido al flash, la prueba calcula la media de la imagen con flash de toda la captura y verifica si el valor está dentro del rango (68, 102). Para comprobar si la imagen tiene un balance de blancos razonable, la prueba calcula las proporciones 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 están entre 0.95 y 1.05. La media de la imagen de 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 fotos de la extensión de la cámara en modo nocturno. Esta función solo está disponible en dispositivos que admiten extensiones de cámara con modo nocturno.

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

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.
Condiciones para omitir: La prueba se omite si el dispositivo no admite el nivel de API requerido o la función de indicador del modo nocturno.
Sesión de Camera2:
- La prueba inicia una sesión de captura de vista previa con una sesión de Camera2.
- Se enciende la luz y se captura un fotograma de vista previa.
- La prueba verifica que el indicador 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.
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.
Limpieza: La prueba cierra ItsSession y libera el controlador de iluminación.

APIs probadas:

android.extension.nightModeIndicator

Aprobación:

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

test_preview_min_frame_rate

Prueba que la velocidad de fotogramas de la vista previa 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 fotogramas es menor que la tolerancia absoluta establecida en la prueba.

test_torch_strength

Prueba que el control de intensidad del flash en el modo TORCH se implemente 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 la intensidad del flash funcione con diferentes valores de AE_MODES. Por ejemplo, si el modo de exposición automática es ON o OFF, el nivel de intensidad del flash influye en el brillo, y si el modo es ON_AUTO_FLASH, el nivel de intensidad del flash no influye en el brillo. Verifica que la intensidad de la linterna se mantenga igual durante toda la 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:

Aprobación:

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 aumenta el nivel de intensidad del flash, desde sin flash hasta 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 ráfaga de imágenes está dentro de la tolerancia, ya que el nivel de intensidad del flash aumenta de sin flash a FLASH_TORCH_STRENGTH_MAX_LEVEL.

scene_gen2_chart

En Android 17 y versiones posteriores, scene_gen2_chart usa el gráfico de papel de Gen2.

Este gráfico de prueba consta de muestras faciales, un código QR, parches de escala de grises, una estrella de Siemens, un gráfico de colores y cuadrados inclinados.

test_chart_gen2

Figura 142. Ejemplo de muestra de gráfico de Gen2.

test_tonemap_sequence

Esta prueba evalúa la curva de asignación de tono predeterminada de un dispositivo en comparación con una curva lineal y dos curvas exponenciales (una con puntos uniformes y la otra con puntos no uniformes). Para obtener un resultado de aprobación, el brillo de la curva predeterminada debe superar el de las curvas lineales y exponenciales. Además, la curva lineal debe ser más brillante que las curvas exponenciales, y las dos curvas exponenciales deben tener niveles de brillo similares.

La prueba también verifica la exactitud de la curva predeterminada del dispositivo. Para ello, se extrae la curva predeterminada, se vuelve a ingresar y, luego, se compara el brillo de la imagen resultante con la imagen de la curva predeterminada original.

Gráfico de la secuencia de asignación de tonos de prueba

Figura 143. Gráfico de la secuencia de asignación de tonos de prueba.

APIs probadas:

Aprobado: La diferencia de brillo entre las curvas predeterminada y lineal es superior al 15%, mientras que la diferencia entre las dos curvas exponenciales es inferior al 8%.

test_multi_camera_switch

Esta prueba verifica la coherencia del color y la exposición durante las transiciones de zoom dinámico. Verifica que el cambio entre las lentes ultra gran angular (UW) y gran angular (W) durante la grabación de la vista previa mantenga valores de CIELAB casi idénticos, lo que evita cambios visibles en la experiencia del usuario.

La prueba ejecuta una grabación de vista previa dinámica en un rango de zoom predefinido para activar el punto de "cruce" de la cámara física, en el que el lente ultra gran angular cambia al lente gran angular. La prueba identifica el fotograma exacto en el que se produce el cambio de lente. Los fotogramas que preceden y siguen inmediatamente a este punto de cruce se capturan y analizan para determinar la estabilidad en la exposición automática (AE) y el balance de blancos automático (AWB).

La verificación de AE confirma que las fluctuaciones de Luma se mantengan dentro de un rango aceptable durante el cambio de lente. La verificación de AWB comprueba que las proporciones de rojo-verde y azul-verde se mantengan dentro de los umbrales definidos de neutralidad de color.

APIs probadas:

Aprobación: Para que se apruebe la prueba, se deben aprobar las siguientes verificaciones de AE y AWB:

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

uw_dynamic_range_patch_cell_8

Figura 144. Parche gris tomado con lente UW.

w_dynamic_range_patch_cell_7

Figura 145. Parche gris tomado con la lente W.

scene_ip

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

Requisitos de configuración del hardware

Se requiere la siguiente configuración de hardware para las pruebas de scene_ip:

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

test_chart_gen2

Figura 146. Ejemplo de Gen2chart_sample.

Criterios para omitir pruebas

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 funciones de prueba en condiciones de iluminación controladas con la app de cámara predeterminada y el JCA, y realiza las siguientes verificaciones:

FoV: Verifica que la app de cámara predeterminada y las capturas de JCA tengan el mismo FoV. Esta verificación usa la función de código QR central extraída de la imagen del gráfico de capturas.
Brillo: Verifica que la diferencia de brillo medida entre la app de cámara predeterminada y JCA no supere 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 JCA no supere 4. Esta verificación usa el parche de rango dinámico para la medición del brillo.
Renderización de color: Verifica que la diferencia de renderización de color entre la app de cámara predeterminada y JCA no supere 6.

Aprobado: La prueba aprueba las verificaciones de FoV, brillo y balance de blancos. En Android 16, esta prueba no es obligatoria (NOT_YET_MANDATED). En Android 17 y versiones posteriores, las verificaciones de paridad de FoV, brillo y balance de blancos son obligatorias. La verificación de renderización de color no es obligatoria (NOT_YET_MANDATED) en Android 17.

test_jca_jpegr_ip

Verifica que la diferencia de balance de blancos entre la instantánea de vista previa de JCA JPEG_R y las imágenes capturadas no supere 4.

APIs probadas:

Aprobado: La diferencia de balance de blancos entre la instantánea de vista previa de JCA y la imagen JPEG_R capturada está dentro del umbral (el valor predeterminado es 4).

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 llenar la parte posterior de la caja de fusión de sensores con una impresión de 17 × 17 pulgadas. (43 cm 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 147. Gráfico de fusión de sensores.

Gráfico de fusión de sensores en Rig

Figura 148. 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 de la lente cambie cuando esta se mueva debido a la estabilización de imagen óptica (OIS). Si se admiten las muestras intrínsecas de la lente, se prueba que el centro óptico de las muestras intrínsecas de la lente cambie cuando la lente se mueva debido a la OIS.

APIs probadas:

Aprobado: El centro óptico de los cambios intrínsecos de la lente es de 1 píxel o más. Si se admiten las muestras intrínsecas de la lente, los centros ópticos de las muestras intrínsecas de la lente cambian en 1 píxel o más.

En la siguiente figura, se muestra un trazado de test_lens_intrinsic_calibration de ejemplo con los cambios de los puntos principales en píxeles para cada fotograma:

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

test_multi_camera_frame_sync

Prueba que las marcas de tiempo de los fotogramas capturados por la cámara lógica estén dentro de los 10 ms calculando 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 cuando se rota el teléfono.

test_preview_distortion

Prueba 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 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 ideales. Los elementos destacados en verde y rojo de la imagen se usan para detectar visualmente el área del error de distorsión.

Figura 150. 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 menor que el umbral establecido en la prueba.

test_preview_stabilization

Prueba que el video de vista previa estabilizado rote menos que el giroscopio.

APIs probadas:

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

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

Figura 151. Video de muestra con estabilización.

Figura 152. Video de muestra sin estabilización.

test_sensor_fusion

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

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

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

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

Figura 154. Ejemplo de rotaciones de trazado 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 la sección 7.3.9 Sensores de alta fidelidad de la CDD.

Mecanismos de falla:

Error de compensación: La compensación de la cámara y el giroscopio no está calibrada correctamente dentro de +/-1 ms.
Pérdida de fotogramas: La canalización no es lo suficientemente rápida como para capturar 200 fotogramas de forma consecutiva.
Errores de socket: adb no puede conectarse de forma confiable al DUT durante el tiempo suficiente para ejecutar la prueba.
El gráfico no está montado de forma plana. El trazado test_sensor_fusion_plot_rotations tiene fotogramas en los que la rotación del giroscopio y de la cámara varía considerablemente a medida que la cámara rota 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 una protuberancia elevada con respecto al 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

Obsoleta: Esta prueba dejó de estar disponible a partir de Android 17. En Android 17 y versiones posteriores, esta prueba se reemplaza por test_video_stabilization_jca.

Prueba que el video estabilizado rote menos que el giroscopio.

APIs probadas:

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

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

Figura 155. Video de muestra con estabilización.

Figura 156. Video de muestra sin estabilización.

test_video_stabilization_jca

Pruebas que verifican que el video estabilizado capturado con el JCA rote menos que el giroscopio La JCA debe estar instalada en el dispositivo antes de realizar la prueba.

APIs probadas:

Aprobado: La rotación máxima del ángulo en los fotogramas extraídos del video capturado con la JCA es inferior al 70% de las rotaciones del giroscopio (4).

Escena de prueba basada en difusor

scene5

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

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

Ejemplo de scene5

Figura 157. Ejemplo de captura de scene5

Debido a que no se requieren tablets ni controles para esta escena, las pruebas usan el banco de pruebas TEST_BED_MANUAL. Para ver un ejemplo, consulta Archivo config.yml de pruebas manuales. El archivo config.yml predeterminado no incluye TEST_BED_MANUAL, pero puedes modificarlo para incluir uno.

test_lens_shading_and_color_uniformity

Prueba que la corrección de sombreado de la 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 de la lente se evalúa según el canal Y. Mide el valor de Y promedio para cada bloque de muestra especificado y determina si se aprueba o no comparándolo con el valor de Y central. La prueba de uniformidad de color se evalúa en el espacio rojo-verde y azul-verde.

APIs probadas:

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

Mecanismos de falla:

Viñeteado excesivo en las imágenes
Artefactos de borde negro en las imágenes

test_lens_shading_and_color_uniformity_y_plane

Figura 158. test_lens_shading_and_color_uniformity_y_plane.

test_lens_shading_and_color_uniformity_color_uniformity_result

Figura 159. test_lens_shading_and_color_uniformity_color_uniformity.

test_lens_shading_and_color_uniformity_lens_shading_result

Figura 160. test_lens_shading_and_color_uniformity_lens_shading_result.

Escena de prueba basada en tablets con amplia gama de colores

scene_wide_gamut

scene_wide_gamut es un marco rectangular dividido en cuatro cuadrantes iguales, cada uno con un color diferente. Esto requiere que la tablet muestre el gráfico en una amplia gama y que el DUT capture una fotografía de amplia gama de la pantalla.

Estas pruebas verifican que la imagen capturada se ajuste al perfil y al rango de color correctos.

test_display_p3

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

APIs probadas:

Aprobado: El JPEG contiene un perfil ICC Display P3 y más del 1% de los colores fuera de la gama sRGB.

Ejemplo de test_display_p3

Figura 161. Ejemplo de test_display_p3.

Pruebas de ITS de la cámara Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

Escenas de prueba basadas en tablets

scene0

test_jitter

test_metadata

test_request_capture_match

test_sensor_events

test_solid_color_test_pattern

test_test_pattern

test_tonemap_curve

test_unified_timestamp

test_vibration_restriction

scene1_1

test_ae_precapture_trigger

test_auto_vs_manual

test_black_white

test_burst_capture

test_burst_sameness_manual

test_crop_region_raw

test_crop_regions

test_ev_compensation

test_exposure_x_iso

test_latching

test_linearity

test_locked_burst

scene1_2

test_param_color_correction

test_param_flash_mode

test_param_noise_reduction

test_param_shading_mode

test_param_tonemap_mode

test_post_raw_sensitivity_boost

test_raw_exposure

test_reprocess_noise_reduction

test_tonemap_sequence

test_yuv_jpeg_all

test_yuv_plus_dng

scene1_3

test_capture_result

test_dng_noise_model

test_jpeg

test_raw_burst_sensitivity

test_raw_sensitivity

test_yuv_plus_jpeg

test_yuv_plus_raw

test_sensitivity_priority

test_exposure_time_priority

scene2_a

test_autoframing

test_display_p3

test_effects

test_exposure_keys_consistent

test_format_combos

test_num_faces

test_reprocess_uv_swap

scene2_b

test_preview_num_faces

test_yuv_jpeg_capture_sameness

scene2_c

test_num_faces

test_jpeg_capture_perf_class

test_camera_launch_perf_class

test_default_camera_hdr

scene2_d

test_preview_num_faces

scene2_e

test_continuous_picture

test_num_faces

scene2_f

test_preview_num_faces

scene2_g

test_preview_num_faces

scene3

test_edge_enhancement

test_flip_mirror

test_imu_drift

test_landscape_to_portrait

test_lens_movement_reporting

test_reprocess_edge_enhancement

scene4

Pruebas de ITS de la cámara