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 tomas y examinar las tomas 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 pruebas del verificador del CTS en cts/apps/CameraITS. Los dispositivos deben aprobar las pruebas de ITS correspondientes a las funciones admitidas que anuncia el framework de la cámara para las apps de terceros como un subconjunto del CTS.

Configuración

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

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

Configuración del dispositivo en 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. Configura las opciones para desarrolladores en el DUT:
    • Activa No desactivar y Depuración por USB.
    • DESACTIVA Actualizaciones automáticas del sistema y Verificar apps por USB.
  3. Otorga permisos al host para acceder al DUT a través de ADB.

  4. Instala la app de CTS Verifier (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

  5. En el DUT, inicia la app de cámara predeterminada y cierra todas las ventanas que aparezcan al iniciarla para evitar interferencias durante la prueba.

Configuración del host

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

Las herramientas de la plataforma del SDK de Android deben estar instaladas 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 pública 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 incluida para garantizar la compatibilidad con las 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 el siguiente comando:

pip install mobly

Configuración del entorno

Para configurar el entorno de prueba, ejecuta el siguiente comando:

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 Camera ITS-in-a-box para facilitar la automatización, la confiabilidad y la eficiencia en las pruebas. Los equipos de prueba de ITS en una caja admiten todos los requisitos de iluminación, centrado y cambio de gráficos para ITS. Además, se requiere ITS integrado en la cámara para probar las extensiones de cámara.

Para las pruebas manuales, asegúrate de cumplir con los siguientes requisitos:

  • El DUT está sobre un trípode
  • La cámara del DUT apunta a la escena correcta para cada prueba. (La secuencia de comandos de la 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 ejecución de la prueba.
  • La escena está iluminada con una fuente de luz constante y sin fluctuaciones. (No uses una luz fluorescente, ya que parpadea).

La secuencia de comandos de prueba de ITS muestra un mensaje que le solicita 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 forma más sencilla de verificar esto es con las escenas de rostros en scene2. La mayoría de los teléfonos se muestran en orientación horizontal, rotados en sentido contrario a las agujas del reloj para la cámara posterior y en el sentido de las agujas del reloj 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 banco de pruebas de Mobly. A continuación, se muestran ejemplos para diferentes casos de uso.

Archivo config.yml de escenas basadas en tablets

El siguiente es un ejemplo de un archivo config.yml para escenas basadas en tablets. En el caso de las pruebas basadas en tablets, la palabra clave TABLET debe estar en el nombre del banco de pruebas. 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 banco de pruebas, 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 las cámaras o las escenas, estos anulan los valores de 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 los gráficos para los dispositivos con cámara de teleobjetivo con un campo visual (FoV) más amplio, lo que evita el recorte de la escena y garantiza 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 no está disponible.

A continuación, se muestra 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 los gráficos del ITS de la cámara. Si una prueba que usas no admite esta función, informa un error.

A continuación, se muestra 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 archivo config_yml de ejemplo para las pruebas de sensor_fusion. Para las pruebas de sensor_fusion, la palabra clave SENSOR_FUSION debe estar en el nombre del banco de pruebas. Android 13 y versiones posteriores solo admiten el controlador de Arduino para la fusión de sensores debido a las pruebas de estabilización de vista previa y video. Android 12 admite los controles de 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 de 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 varias plataformas de pruebas

El siguiente es un ejemplo de un archivo config.yml con varios bancos de pruebas, un banco de pruebas de tablet y un banco de pruebas de sensor_fusion. El banco de pruebas 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 archivo config.yml de ejemplo para pruebas manuales. Android 14 y versiones posteriores admiten pruebas manuales para todas las pruebas, excepto las de scene_extensions. Para las pruebas manuales, la palabra clave MANUAL debe estar en el nombre del banco de pruebas. Además, la sección AndroidDevice no puede incluir una sección 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 prueba de la cámara Gen2

El siguiente es un archivo config.yml de ejemplo de una plataforma de pruebas TEST_BED_GEN2. Este banco de pruebas se usa para las pruebas de scene_ip, que utilizan una estructura de soporte Gen2](/docs/compatibility/cts/camera-its-box-gen2). En el siguiente ejemplo, se muestran los parámetros del banco de pruebas cuando el equipo Gen2 está disponible y no se omiten las pruebas de 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: 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 banco de pruebas cuando el equipo Gen2 no está disponible y se omiten las pruebas de 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

Cómo ejecutar pruebas de ITS

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

Cómo invocar 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 de CTS Verifier. En el menú de pruebas, selecciona Camera ITS Test. En Android 17 y versiones posteriores, las pruebas sensor_fusion y feature_combination se encuentran en una actividad adicional llamada Prueba de la estructura de fusión de sensores del ITS de la cámara.

  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 traseras, 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 depurar la configuración, te recomendamos que ejecutes una de las escenas de scene2 con una sola prueba para obtener resultados 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 un archivo JPEG, imprime la ruta de acceso al archivo JPEG en la consola y le pide al usuario que confirme si la imagen es correcta. Este flujo de captura y confirmación se repite hasta que el usuario confirma que la imagen es correcta. A continuación, se muestran 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, se informará como PASS en CtsVerifier. SKIP indica que la prueba se aprobó porque el dispositivo no anunció la capacidad subyacente que se estaba 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, presiona el botón de marca de verificación verde. La entrada Camera ITS Test en el menú de pruebas de CTS Verifier se vuelve verde y significa que el teléfono pasó la prueba de ITS de la cámara.

Pruebas paralelas del DUT

Los dispositivos que ejecutan Android 14 o versiones posteriores admiten pruebas paralelas del DUT. Esto te permite probar los DUT en paralelo con varios soportes para acelerar las pruebas generales. Por ejemplo, las pruebas en paralelo te permiten probar la cámara 0 en una estructura y la cámara 1 en otra estructura al mismo tiempo. En Android 17 y versiones posteriores, dado que las pruebas del ITS de la cámara se dividen en dos actividades, puedes ejecutar las pruebas sensor_fusion y feature_combination en un DUT y otras pruebas en otro DUT en paralelo. Todas las pruebas de las sesiones de pruebas paralelas se agregan en la sesión del verificador del 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 del mismo controlador Arduino controle la iluminación de cada estructura.

El siguiente es un archivo config.yml de muestra que define tres bancos de pruebas 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 las plataformas de pruebas 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 agregados de las pruebas de ITS de la cámara para la aprobación de la compilación. CTS Verifier te permite probar varias escenas de forma simultánea en varios dispositivos y agregar los resultados de las pruebas de varios informes de CTS Verifier (de diferentes ejecuciones de pruebas o dispositivos) en un solo envío unificado.

Proceso de envío

Para enviar los resultados agregados de Camera ITS para la aprobación de la compilación, sigue estos pasos:

  1. Prepara los dispositivos: Reúne entre dos y tres dispositivos en prueba (DUT) que tengan exactamente 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. Monta los DUT en soportes 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 de CTS Verifier después de cada ejecución. Esto incluye los informes en los que fallaron las escenas. Solo vuelve a ejecutar las escenas con errores en 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 la prueba, se muestra una lista completa de todas las escenas ejecutadas.

    • Las escenas que no se ejecutaron o fallaron se enumeran en la sección Fallidas.

      result-aggregation-image-1

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

    • Las escenas de pases se enumeran en la sección Pase agregado.

      result-aggregation-image-2

      Figura 2: Escenas categorizadas como Pase Agregado

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 completaron correctamente en los informes agregados.

Modelo de ruido DNG

Los dispositivos que anuncian la capacidad de capturar imágenes en formato RAW o DNG deben proporcionar un modelo de ruido en los metadatos del resultado de captura de cada toma en formato RAW. Este modelo de ruido se debe incorporar en la HAL de la cámara para cada cámara (por ejemplo, las cámaras frontal y posterior) del dispositivo que afirma ser compatible.

Implementación del modelo de ruido

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

  1. Para generar un modelo de ruido para cada cámara, ejecuta la secuencia de comandos dng_noise_model.py en el directorio tools. Esto genera un fragmento de código en 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 del 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 de forma marginal (estado de prueba PASS*)

En Android 17 y versiones posteriores, un aprobado marginal (PASS*) indica que una prueba se aprobó, 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 análisis más detallado.

Beneficios del pase marginal

El estado PASS* ofrece varios beneficios:

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

  • Optimización proactiva: Alienta a los equipos a optimizar las pruebas y el código que tienen un rendimiento 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, ya que marca las áreas que podrían ser susceptibles a regresiones futuras con cambios menores en el código.

  • Reducción del tiempo de depuración: Al detectar las pruebas de PASS* de forma anticipada, se puede reducir significativamente el tiempo y el esfuerzo necesarios para depurar las fallas completas en el futuro.

Detalles de PASS*

El estado PASS* incluye lo siguiente:

  • Definición de umbrales: Se definen umbrales de aprobación marginales específicos para cada prueba pertinente 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 alertas: Los equipos reciben alertas automatizadas sobre 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 los paneles de pruebas para una mejor visibilidad como PASS* en el informe de ItsTestSummary, de manera similar a Fail* para las pruebas de not_yet_mandated. La prueba mantiene un estado correcto, ya que sigue pasando dentro de los umbrales establecidos, para evitar más confusiones. 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 sobre las pruebas que se aprueban de forma marginal en un dispositivo. Esto permite supervisar las futuras mejoras de la cámara que realicen los OEM si estas pruebas pasan a tener el estado PASS.

A continuación, se muestra un ejemplo de los resultados de la prueba 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:

  • Supervisa las alertas de PASS*
  • Investiga la causa raíz de las pruebas de 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.