Descripción general del ITS de la cámara

El Paquete de pruebas de imagen de la cámara (ITS) es un framework para ejecutar pruebas en imágenes producidas por una cámara de Android. El objetivo general de cada prueba en ITS es configurar la cámara de una manera específica, capturar una o más fotos y examinarlas para ver si contienen los datos de imagen esperados. Muchas de las pruebas requieren que la cámara apunte a un gráfico de destino específico o que se ilumine con una intensidad específica.

El ITS se encuentra en el arnés de prueba del Verificador de CTS en cts/apps/CameraITS. Los dispositivos deben pasar las pruebas de ITS correspondientes a las funciones compatibles que anuncia el framework de la cámara para apps de terceros como un subconjunto del CTS.

Configuración

Para ejecutar las pruebas de ITS, se debe configurar lo siguiente:

• Un dispositivo bajo prueba (DUT)
• Una máquina anfitrión (por ejemplo, una computadora de escritorio o portátil con Linux)
• Una escena que la cámara fotografía

Configuración del dispositivo bajo prueba (DUT)

Para configurar un DUT, sigue estos pasos:

1. Conecta el DUT a una máquina anfitrión a través de USB.
2. Otorga permisos para que el host acceda al DUT a través de ADB.

3. Instala la app del Verificador de CTS (CtsVerifier.apk) en el dispositivo. Para obtener más información, consulta Cómo usar el verificador del CTS.

   extract root/out/host/linux-x86/cts-verfier/android-cts-verifier.zip
   cd android-cts-verifier
   adb install -r -g CtsVerifier.apk

4. En el DUT, inicia la app de cámara predeterminada y borra todas las ventanas que aparecen al iniciarla para evitar interferencias durante las pruebas.

Configuración del host

El ITS requiere que la máquina anfitrión esté conectada al DUT a través de USB, que pueda usar ADB para el control y la comunicación del dispositivo, y que tenga instalado el software necesario.

Para configurar tu máquina anfitrión, asegúrate de que esté instalado el siguiente software.

Herramientas de la plataforma del SDK de Android

Deben instalarse las herramientas de la plataforma del SDK de Android, y ADB debe estar en la ruta ejecutable del shell o la terminal que se ejecuta en la máquina host. Para obtener información sobre la versión publicada públicamente de las herramientas de la plataforma del SDK de Android, consulta las notas de la versión de las herramientas de la plataforma del SDK.

Python

Python debe estar instalado en la máquina anfitrión. Te recomendamos que uses una distribución de Python agrupada para garantizar la compatibilidad con versiones compatibles. Para obtener detalles sobre qué versiones de Python y de paquetes instalar para una versión específica, consulta las notas de la versión de ITS de la cámara para la versión correspondiente.

Mobly

Para Android 12 y versiones posteriores, instala el framework de pruebas de Mobly. Mobly te permite configurar un DUT y una tablet de gráficos en la clase its_base_test. Para instalar el framework de pruebas de Mobly, ejecuta lo siguiente:

pip install mobly

Configuración del entorno

Para configurar el entorno de pruebas, ejecuta lo siguiente:

cd CameraITS
source build/envsetup.sh

Este comando verifica la instalación de Python, configura la variable de entorno PYTHONPATH y ejecuta pruebas de unidades en los módulos utils/*.py. Si no se imprimen errores en la terminal, el entorno está listo para ejecutar las pruebas de ITS.

Configuración de la escena

Para configurar las escenas, te recomendamos que uses la configuración de ITS de la cámara en una caja para facilitar la automatización, la confiabilidad y la eficiencia en las pruebas. Los equipos de prueba de ITS de la cámara en una caja admiten todos los requisitos de iluminación, centrado y cambio de gráficos para ITS. Además, se requiere ITS de la cámara en una caja para las pruebas de extensiones de cámara.

Para las pruebas manuales, asegúrate de lo siguiente:

• El DUT está en un trípode.
• El DUT apunta a la escena correcta para cada prueba. (La secuencia de comandos de prueba de ITS proporciona instrucciones para cambiar la configuración de la escena antes de comenzar las pruebas en una escena nueva).
• El DUT está conectado a la máquina anfitrión a través de USB.
• El DUT no se mueve durante la prueba.
• La escena está iluminada con una fuente de luz estable y sin fluctuaciones. (No uses una luz fluorescente, ya que introduce parpadeo).

La secuencia de comandos de prueba de ITS muestra un mensaje en el que se le pide al usuario que cambie la configuración de la escena antes de comenzar las pruebas en una escena nueva.

La orientación del teléfono debe configurarse de modo que la cámara tome imágenes sin rotación. La manera más fácil de verificar esto es con las escenas de rostro en scene2. La mayoría de los teléfonos tienen el teléfono en orientación horizontal con el teléfono girado en sentido antihorario para la cámara posterior y en sentido horario para la cámara frontal.

Archivos de configuración

Con el framework de Mobly, debes crear un archivo de configuración config.yml para definir el testbed de Mobly. Los siguientes son ejemplos para diferentes casos de uso.

Archivo config.yml de escenas basadas en tablets

El siguiente es un ejemplo de archivo config.yml para escenas basadas en tablets. Para las pruebas basadas en tablets, la palabra clave TABLET debe estar en el nombre del testbed. Durante la inicialización, el ejecutor de pruebas de Mobly inicializa los parámetros en el archivo y los pasa a las pruebas individuales.

TestBeds:
  - Name: TEST_BED_TABLET_SCENES
    # Test configuration for scenes[0:4, 6, _change]
    Controllers:
        AndroidDevice:
          - serial: 8A9X0NS5Z
            label: dut
          - serial: 5B16001229
            label: tablet

    TestParams:
      brightness: 192
      chart_distance: 22.0
      debug_mode: "False"  # "True" or "False"; quotes needed
      lighting_cntl: <controller-type>  # "arduino" or "None"; quotes needed
      lighting_ch: <controller-channel>
      camera: 0
      foldable_device: "False". # set "True" if testing foldable
      scene: <scene-name>  # if <scene-name> runs all scenes

Para invocar el testbed, ejecuta tools/run_all_tests.py. Si no hay valores de línea de comandos que especifiquen cámaras o escenas, la prueba se ejecuta con los valores del archivo config.yml. Si hay valores de línea de comandos para cámaras o escenas, estos anulan los valores en la sección TestParams del archivo config.yml. Por ejemplo:

python tools/run_all_tests.py
python tools/run_all_tests.py camera=1
python tools/run_all_tests.py scenes=2,1,0
python tools/run_all_tests.py camera=0 scenes=scene_tele
python tools/run_all_tests.py camera=0.4 scenes=4,scene6_tele

Parámetro chart_scaling

En Android 17 y versiones posteriores, el parámetro chart_scaling se incluye en config.yml para TEST_BED_TABLET_SCENES. Este parámetro aborda los problemas de ajuste de escala de gráficos para dispositivos con cámara teleobjetivo con un campo de visión (FoV) más amplio, lo que evita el recorte de escenas y aplica el enfoque adecuado del dispositivo durante las pruebas.

Los valores admitidos para chart_scaling son 1, 0.33, 0.5 o 0.67, con None como valor predeterminado. Este enfoque permite que los dispositivos usen un factor de ajuste de escala óptimo adaptado a sus requisitos específicos, lo que mantiene las pruebas funcionales en todos los dispositivos.

Si chart_scaling se establece en None, las pruebas determinan automáticamente el factor de ajuste de escala con chart_scaling_logic. De lo contrario, se usa el valor especificado en config.yml o se marca un error si el ajuste de escala no está disponible.

El siguiente es un ejemplo de config.yml con el parámetro chart_scaling.

TestBeds:
  -   Name: TEST_BED_TABLET_SCENES  # Need 'tablet' in name for tablet scenes
    # Use TEST_BED_MANUAL for manual testing and remove below lines:
    #     - serial <tablet_id>
    #       label: tablet
    # Test configuration for scenes[0:4, 6]
    Controllers:
        AndroidDevice:
          -   serial: <device-id>  # quotes needed if serial id entirely numeric
            label: dut
          -   serial: <tablet-id>  # quotes needed if serial id entirely numeric
            label: tablet
    TestParams:
      brightness: 192
      chart_distance: 22.0
      debug_mode: "False"  # quotes needed
      lighting_cntl: <controller-type>  # can be arduino or "None"
      lighting_ch: <controller-channel>
      camera: <camera-id>
      scene: <scene-name>  # if <scene-name> runs all scenes
      foldable_device: "False"  # "True" if testing foldable device
      chart_scaling: "None"  # use the values available for scene to be tested
      resultstore_upload: "False"  # "True" if results should be uploaded to ResultStore

Se requieren ajustes del lado de la prueba para habilitar las capacidades de ajuste de escala de gráficos de ITS de la cámara. Si una prueba que usas no admite esto, informa un error.

El siguiente es un ejemplo de cambio del lado de la prueba con el parámetro chart_scaling.

# load chart for scene
      its_session_utils.load_scene(
          cam, props, self.scene, self.tablet, self.chart_distance,
          chart_scaling=self.chart_scaling)

Archivo config.yml de la escena sensor_fusion

El siguiente es un ejemplo de archivo config_yml para pruebas sensor_fusion. Para las pruebas sensor_fusion, la palabra clave SENSOR_FUSION debe estar en el nombre del testbed. Android 13 y versiones posteriores solo admiten el controlador Arduino para la fusión de sensores debido a las pruebas de estabilización de video y vista previa. Android 12 admite controladores Arduino y Canakit.

Testbeds
  - Name: TEST_BED_SENSOR_FUSION
    # Test configuration for sensor_fusion/test_sensor_fusion.py
    Controllers:
        AndroidDevice:
          - serial: 8A9X0NS5Z
            label: dut

    TestParams:
      fps: 30
      img_size: 640,480
      test_length: 7
      debug_mode: "False"
      chart_distance: 25
      rotator_cntl: arduino
      rotator_ch: 1
      camera: 0

Para ejecutar pruebas sensor_fusion con la caja de fusión de sensores, ejecuta lo siguiente:

python tools/run_all_tests.py scenes=sensor_fusion
python tools/run_all_tests.py scenes=sensor_fusion camera=0
python tools/run_all_tests.py scenes=scene_flash,feature_combination
python tools/run_all_tests.py scenes=checkerboard camera=1

Archivo config.yml de varios testbeds

El siguiente es un ejemplo de archivo config.yml con varios testbeds, un testbed de tablets y un testbed sensor_fusion. El testbed correcto se determina según las escenas probadas.

Testbeds
  - Name: TEST_BED_TABLET_SCENES
    # Test configuration for scenes[0:4, 6, _change]
    Controllers:
        AndroidDevice:
          - serial: 8A9X0NS5Z
            label: dut
          - serial: 5B16001229
            label: tablet

    TestParams:
      brightness: 192
      chart_distance: 22.0
      debug_mode: "False"
      chart_loc_arg: ""
      camera: 0
      scene: <scene-name>           # if <scene-name> runs all scenes

  - Name: TEST_BED_SENSOR_FUSION
    # Test configuration for sensor_fusion/test_sensor_fusion.py
    Controllers:
        AndroidDevice:
          - serial: 8A9X0NS5Z
            label: dut

    TestParams:
      fps: 30
      img_size: 640,480
      test_length: 7
      debug_mode: "False"
      chart_distance: 25
      rotator_cntl: arduino         # cntl can be arduino or canakit
      rotator_ch: 1
      camera: 0

Archivo config.yml de pruebas manuales

El siguiente es un ejemplo de archivo config.yml para pruebas manuales. Android 14 y versiones posteriores admiten pruebas manuales para todas las pruebas, excepto las scene_extensions pruebas. Para las pruebas manuales, la palabra clave MANUAL debe estar en el nombre del testbed. Además, la sección AndroidDevice no puede incluir una sección de número de serie o etiqueta para una tablet.

TestBeds:
  - Name: TEST_BED_MANUAL
    Controllers:
        AndroidDevice:
          - serial: 8A9X0NS5Z
            label: dut

    TestParams:
      debug_mode: "False"
      camera: 0
      scene: 1

Archivo config.yml de pruebas de equipos Gen2

El siguiente es un ejemplo de archivo config.yml de un testbed TEST_BED_GEN2. Este testbed se usa para pruebas scene_ip, que usan un equipo Gen2](/docs/compatibility/cts/camera-its-box-gen2). En el siguiente ejemplo, se muestran los parámetros del testbed cuando el equipo Gen2 está disponible y no se omiten las scene_ip pruebas.

Testbeds
  - Name: TEST_BED_GEN2
    # Test configuration for scene_ip/test_default_jca_ip.py
    Controllers:
        AndroidDevice:
          - serial: <device-id>  # quotes needed if serial id entirely numeric
            label: dut
    TestParams:
      debug_mode: "False"  # quotes are needed here
      chart_distance: 30
      rotator_cntl: gen2_rotator   # gen2 rig specific. "None" if gen2 rig not available
      rotator_ch: 0
      camera: <camera-id>
      foldable_device: "False"  # "True" if testing foldable device
      tablet_device: "False"  # "True" if testing tablet device
      lighting_cntl: gen2_lights  # gen2 rig specific. "None" if gen2 rig not available
      lighting_ch: 1
      scene: scene_ip

En el siguiente ejemplo, se muestran los parámetros del testbed cuando el equipo Gen2 no está disponible y se omiten las pruebas scene_ip.

Testbeds
  - Name: TEST_BED_GEN2
    # Test configuration for scene_ip/test_default_jca_ip.py
    Controllers:
        AndroidDevice:
          - serial: <device-id>  # quotes needed if serial id entirely numeric
            label: dut
    TestParams:
      debug_mode: "False"  # quotes are needed here
      chart_distance: 30
      rotator_cntl: "None"   # gen2 rig specific. "None" if gen2 rig not available
      rotator_ch: <controller-channel>
      camera: <camera-id>
      foldable_device: "False"  # "True" if testing foldable device
      tablet_device: "False"  # "True" if testing tablet device
      lighting_cntl: "None"  # gen2 rig specific. "None" if gen2 rig not available
      lighting_ch: <controller-channel>
      scene: scene_ip

Para ejecutar la prueba scene_ip, usa uno de los siguientes comandos:

python tests/scene_ip/test_default_jca_ip.py -c config.yml
python tools/run_all_tests.py camera=<camera-id> scenes=scene_ip

Ejecuta pruebas de ITS

En esta sección, se describe cómo ejecutar pruebas de ITS.

Invoca pruebas

Después de configurar el dispositivo, la máquina anfitrión (incluido el entorno) y la escena física, ejecuta las pruebas de ITS con el siguiente proceso.

1. Abre la app del Verificador de CTS. En el menú de pruebas, selecciona Camera ITS Test. Para Android 17 y versiones posteriores, las pruebas sensor_fusion y feature_combination se encuentran en una actividad adicional llamada Camera ITS Sensor Fusion Rig Test.

2. Desde la máquina anfitrión, ejecuta las pruebas de ITS desde el directorio CameraITS/. Por ejemplo, para un dispositivo con cámaras frontales y posteriores, ejecuta el siguiente comando:

   python tools/run_all_tests.py

   La secuencia de comandos itera a través de las cámaras y las escenas de prueba según el archivo config.yml. Para las configuraciones de depuración, te recomendamos que ejecutes una de las escenas scene2 con una sola prueba para obtener el tiempo de respuesta más rápido.

   Para las pruebas manuales, antes de comenzar a ejecutar el conjunto de pruebas de ITS en cada escena, la secuencia de comandos toma una foto de la escena actual, la guarda como JPEG, imprime la ruta de acceso al JPEG en la consola y le pide al usuario que confirme si la imagen está bien. Este flujo de captura y confirmación se repite hasta que el usuario confirma que la imagen está bien. Los siguientes son los mensajes de este flujo.

   Preparing to run ITS on camera 0
   Start running ITS on camera:  0
   Press Enter after placing camera 0 to frame the test scene:
   scene1_1
   The scene setup should be: A grey card covering at least the   middle 30% of the scene
   Running vendor 3A on device
   Capture an image to check the test scene
   Capturing 1 frame with 1 format [yuv]
   Please check scene setup in /tmp/tmpwBOA7g/0/scene1_1.jpg
   Is the image okay for ITS scene1_1? (Y/N)
   

   Cada ejecución de la secuencia de comandos imprime un registro que muestra PASS, FAIL, FAIL* o SKIP para cada prueba de ITS. FAIL* indica que la prueba falló, pero, como aún no es obligatoria, la prueba informará PASS a CtsVerifier. SKIP indica que se pasó la prueba porque el dispositivo no anunció la capacidad subyacente que se está probando. Por ejemplo, si un dispositivo no anuncia a través de las interfaces de la cámara que admite DNG, se omiten las pruebas relacionadas con la captura de archivos DNG y se cuentan como PASS.

3. Para confirmar que las pruebas cumplieron con los requisitos de prueba, presiona el botón de marca de verificación verde. La entrada Camera ITS Test en el menú de pruebas del Verificador de CTS se vuelve verde y significa que el teléfono pasó el ITS de la cámara.

Pruebas de DUT paralelas

Los dispositivos que ejecutan Android 14 o versiones posteriores admiten pruebas de DUT paralelas. Esto te permite probar los DUT en paralelo con varios equipos para acelerar las pruebas generales. Por ejemplo, las pruebas paralelas te permiten probar la cámara 0 en un equipo y la cámara 1 en otro equipo al mismo tiempo. Para Android 17 y versiones posteriores, como las pruebas de ITS de la cámara se dividen en dos actividades, puedes ejecutar pruebas sensor_fusion y feature_combination en un DUT, y otras pruebas en otro DUT en paralelo. Todas las pruebas para las sesiones de pruebas paralelas se agregan en la sesión del Verificador de CTS en el DUT de referencia. Debes ejecutar pruebas paralelas con el control de iluminación de Arduino, ya que el control de iluminación manual no es compatible con las pruebas paralelas. Asegúrate de que un canal diferente en el mismo controlador Arduino controle la iluminación de cada equipo.

El siguiente es un ejemplo de archivo config.yml que define tres testbeds para ejecutar en paralelo.

TestBeds:
  - Name: TEST_BED_TABLET_SCENES_INDEX_0
    Controllers:
        AndroidDevice:
          - serial: <device-id-0>
            label: dut
          - serial: <tablet-id-0>
            label: tablet
    TestParams:
      brightness: 192
      chart_distance: 22.0
      debug_mode: "False"
      lighting_cntl: "arduino"
      lighting_ch: <controller-channel-0>
      camera: 0
      scene: <scene-name>  # if <scene-name> left as-is runs all scenes
      foldable_device: "False"

  - Name: TEST_BED_TABLET_SCENES_INDEX_1
    Controllers:
        AndroidDevice:
          - serial: <device-id-1>
            label: dut
          - serial: <tablet-id-1>
            label: tablet
    TestParams:
      brightness: 192
      chart_distance: 22.0
      debug_mode: "False"
      lighting_cntl: "arduino"
      lighting_ch: <controller-channel-1>
      camera: 1
      scene: <scene-name>  # if <scene-name> left as-is runs all scenes
      foldable_device: "False"

  # TEST_BED_SENSOR_FUSION represents testbed index 2
  # Parallel sensor_fusion is currently unsupported due to Arduino requirements
  - Name: TEST_BED_SENSOR_FUSION
    # Test configuration for sensor_fusion
    Controllers:
        AndroidDevice:
          - serial: <device-id>
            label: dut
    TestParams:
      fps: 30
      img_size: 640,480
      test_length: 7
      debug_mode: "False"
      chart_distance: 25
      rotator_cntl: "arduino"
      rotator_ch: <controller-channel-2>
      camera: <camera-id>
      foldable_device: "False"
      tablet_device: "False"
      lighting_cntl: "None"
      lighting_ch: <controller-channel>
      scene: "sensor_fusion"

Para ejecutar los testbeds en paralelo, usa el siguiente comando:

for i in 0 1 2; do python3 tools/run_all_tests.py testbed_index=$i num_testbeds=3 & done; wait

Envía resultados de pruebas agregados

En Android 17 y versiones posteriores, puedes enviar resultados de pruebas de ITS de la cámara agregados para la aprobación de la compilación. El Verificador de CTS te permite probar varias escenas de forma simultánea en varios dispositivos y agregar resultados de pruebas de varios informes del Verificador de CTS (de diferentes ejecuciones de pruebas o dispositivos) en un solo envío unificado.

Proceso de envío

Para enviar resultados de ITS de la cámara agregados para la aprobación de la compilación, sigue estos pasos:

1. Prepara los dispositivos: Reúne de dos a tres dispositivos bajo prueba (DUT) que tengan la misma huella digital de compilación.
2. Instala el Verificador de CTS: Instala el APK más reciente del Verificador de CTS, que se puede obtener del explorador de compilaciones proporcionado.

3. Ejecuta pruebas en paralelo:

   1. Activa los DUT en equipos separados.
   2. Ejecuta diferentes escenas de ITS de la cámara en cada dispositivo de forma simultánea.
   3. Recopilación de informes: Extrae el informe del Verificador de CTS después de cada ejecución. Esto incluye informes en los que fallaron las escenas. Solo vuelve a ejecutar las escenas con errores en las ejecuciones posteriores.

4. Envía informes: Sube varios informes del Verificador de CTS recopilados de todos los dispositivos.

5. Revisa los resultados: Una vez que se suban los informes, revisa los resultados agregados:

   • En la sección Análisis de pruebas , se muestra una lista completa de todas las escenas ejecutadas.

   • Las escenas no ejecutadas o con errores se enumeran en la sección Con errores.

     

     Figura 1: Documentación de escenas que no se ejecutaron o fallaron

   • Las escenas aprobadas se enumeran en la sección Aprobadas agregadas.

     

     Figura 2: Escenas categorizadas como Aprobadas agregadas

Estado de aprobación de la compilación

La aprobación de la compilación se otorga una vez que todas las escenas requeridas se completan correctamente en los informes agregados.

Modelo de ruido DNG

Los dispositivos que anuncian la capacidad de capturar RAW o DNG deben proporcionar un modelo de ruido en los metadatos de resultado de captura de cada toma sin procesar. Este modelo de ruido debe incorporarse a la HAL de la cámara para cada cámara (por ejemplo, cámaras frontales y posteriores) en el dispositivo que declara compatibilidad.

Implementación del modelo de ruido

Para implementar un modelo de ruido, sigue estos pasos para generar un modelo de ruido y, luego, incorporarlo a la HAL de la cámara.

1. Para generar un modelo de ruido para cada cámara, ejecuta la dng_noise_model.py secuencia de comandos en el tools directorio. Esto genera un fragmento de código C. Para obtener más información sobre cómo configurar la cámara y el entorno de captura, consulta el documento DngNoiseModel.pdf en el directorio tools.

2. Para implementar el modelo de ruido para el dispositivo, corta y pega el fragmento de código C en la HAL de la cámara.

Validación del modelo de ruido

La prueba de ITS automatizada tests/scene1_1/test_dng_noise_model.py valida el modelo de ruido verificando que los valores de ruido para la exposición y la ganancia de la toma proporcionados en los datos de la cámara sean correctos.

Pruebas aprobadas marginalmente (estado de prueba PASS*)

En Android 17 y versiones posteriores, una aprobación marginal (PASS*) indica que se pasó una prueba, pero sus métricas de rendimiento están muy cerca del umbral de aprobación predefinido. Si bien la prueba cumple técnicamente con los criterios de aprobación, la proximidad al límite de falla sugiere la necesidad de un examen más detallado.

Beneficios de la aprobación marginal

El estado PASS* ofrece varios beneficios:

• Sistema de alerta temprana: Identifica las pruebas que están a punto de fallar, lo que permite a los equipos abordar los problemas antes de que provoquen fallas directas.

• Optimización proactiva: Alienta a los equipos a optimizar las pruebas y el código que se ejecutan en el extremo inferior del rango aceptable, lo que mejora la estabilidad general.

• Calidad mejorada: Ayuda a mantener un estándar de calidad más alto marcando las áreas que podrían ser susceptibles a regresiones futuras con cambios de código menores.

• Tiempo de depuración reducido: Si se detectan las pruebas PASS* con anticipación, se puede reducir significativamente el tiempo y el esfuerzo necesarios para depurar fallas completas en el futuro.

Detalles de PASS*

El estado PASS* incluye lo siguiente:

• Definición de umbrales: Se definen umbrales de aprobación marginal específicos para cada prueba relevante en ITS de la cámara.

• Detección automatizada: El sistema de automatización de pruebas detecta y categoriza las pruebas como PASS* según los umbrales definidos.

• Mecanismo de alerta: Los equipos reciben alertas automatizadas para cualquier prueba marcada como PASS*, lo que los dirige a investigar la prueba específica y sus métricas.

• Informes: Los estados de aprobación marginal se indican claramente en los informes y paneles de pruebas para una mejor visibilidad como PASS* en el informe ItsTestSummary, de manera similar a Fail* para las pruebas not_yet_mandated. La prueba mantiene un estado verde, ya que sigue pasando dentro de los umbrales establecidos, para evitar más confusión. El estado PASS* solo se aplica a una clase de prueba, no a toda la escena. Por ejemplo, Scene_0 se puede considerar PASS incluso si test_jitter y test_metadata son PASS*.

• Supervisión: Se recopilan datos de rendimiento en las pruebas que pasan marginalmente en un dispositivo. Esto permite supervisar las mejoras futuras de la cámara que realizan los OEM si estas pruebas pasan a un estado PASS.

El siguiente es un ejemplo de resultados de pruebas con PASS*:

INFO:root:Reporting camera 1 ITS results to CtsVerifier
INFO:root:ITS results to CtsVerifier: {'scene0': {'result': 'PASS', 'TEST_STATUS': [{'test': 'test_jitter', 'status': 'PASS*'}, {'test': 'test_metadata', **'status': 'PASS*'**}, {'test': 'test_request_capture_match', 'status': 'PASS'}, {'test': 'test_sensor_events', 'status': 'PASS'}, {'test': 'test_solid_color_test_pattern', 'status': 'PASS'}, {'test': 'test_test_patterns', 'status': 'SKIP'}, {'test': 'test_tonemap_curve', 'status': 'SKIP'}, {'test': 'test_unified_timestamps', 'status': 'PASS'}, {'test': 'test_vibration_restriction', 'status': 'PASS'}], 'mpc_metrics': [], 'performance_metrics': [], 'feature_query_proto': [], 'feature_query_proto_path': [], 'summary': '/tmp/CameraITS_zojk4sdr/cam_id_1/scene0/scene_test_summary.txt', 'start': 1754330630345, 'end': 1754330764534}, 'scene1_1': {'result': 'NOT_EXECUTED'}, 'scene1_2': {'result': 'NOT_EXECUTED'}, 'scene1_3': {'result': 'NOT_EXECUTED'}, 'scene2_a': {'result': 'NOT_EXECUTED'}, 'scene2_b': {'result': 'NOT_EXECUTED'}, 'scene2_c': {'result': 'NOT_EXECUTED'}, 'scene2_d': {'result': 'NOT_EXECUTED'}, 'scene2_e': {'result': 'NOT_EXECUTED'}, 'scene2_f': {'result': 'NOT_EXECUTED'}, 'scene2_g': {'result': 'NOT_EXECUTED'}, 'scene3': {'result': 'NOT_EXECUTED'}, 'scene4': {'result': 'NOT_EXECUTED'}, 'scene6': {'result': 'NOT_EXECUTED'}, 'scene7': {'result': 'NOT_EXECUTED'}, 'scene8': {'result': 'NOT_EXECUTED'}, 'scene9': {'result': 'NOT_EXECUTED'}, 'scene_extensions/scene_hdr': {'result': 'NOT_EXECUTED'}, 'scene_extensions/scene_low_light': {'result': 'NOT_EXECUTED'}, 'scene_tele/scene6_tele': {'result': 'NOT_EXECUTED'}, 'scene_tele/scene7_tele': {'result': 'NOT_EXECUTED'}, 'scene_video': {'result': 'NOT_EXECUTED'}, 'scene5': {'result': 'NOT_EXECUTED'}, 'sensor_fusion': {'result': 'NOT_EXECUTED'}, 'feature_combination': {'result': 'NOT_EXECUTED'}, 'scene_flash': {'result': 'NOT_EXECUTED'}, 'scene_ip': {'result': 'NOT_EXECUTED'}}

Se recomienda a los socios que hagan lo siguiente:

• Supervisar las alertas PASS*
• Investigar la causa raíz de las pruebas PASS*
• Optimizar de forma proactiva las pruebas y el código identificados como PASS*

El estado PASS* tiene como objetivo mejorar la solidez y la confiabilidad de las pruebas de ITS de la cámara, lo que lleva a un producto estable y de alta calidad.