Panoramica di ITS della videocamera

Camera Image Test Suite (ITS) è un framework per l'esecuzione di test sulle immagini prodotte da una fotocamera Android. L'obiettivo generale di ogni test in ITS è configurare la videocamera in un modo specifico, acquisire uno o più scatti ed esaminare gli scatti per verificare se contengono i dati immagine previsti. Molti test richiedono che la videocamera sia puntata su un grafico target specifico o che sia illuminata a un'intensità specifica.

ITS si trova nell'ambiente di test CTS Verifier in cts/apps/CameraITS. I dispositivi devono superare i test ITS corrispondenti alle funzionalità supportate pubblicizzate dal framework della fotocamera per le app di terze parti come sottoinsieme di CTS.

Configurazione

Per eseguire i test ITS, è necessario configurare quanto segue:

• Un dispositivo in fase di test (DUT)
• Una macchina host (ad esempio, un computer fisso o portatile Linux)
• Una scena che la videocamera fotografa

Configurazione del dispositivo in fase di test (DUT)

Per configurare un DUT:

1. Collega il DUT a una macchina host tramite USB.
2. Configura le opzioni sviluppatore sul DUT:
   • Attiva Rimanere attivo e Debug USB.
   • DISATTIVA Aggiornamenti automatici del sistema e Verifica app tramite USB.
3. Concedi all'host le autorizzazioni per accedere al DUT tramite ADB.

4. Installa l'app CTS Verifier (CtsVerifier.apk) sul dispositivo. Per maggiori informazioni, consulta Utilizzo di CTS Verifier.

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

5. Sul DUT, avvia l'app Fotocamera predefinita e chiudi tutte le finestre che vengono visualizzate all'avvio per evitare interferenze durante il test.

Configurazione dell'host

ITS richiede che la macchina host sia collegata al DUT tramite USB, sia in grado di utilizzare ADB per il controllo e la comunicazione del dispositivo e abbia il software richiesto installato.

Per configurare la macchina host, assicurati che sia installato il seguente software.

Strumenti della piattaforma SDK Android

Gli strumenti della piattaforma SDK Android devono essere installati e ADB deve trovarsi nel percorso eseguibile della shell o del terminale in esecuzione sulla macchina host. Per la versione rilasciata pubblicamente degli strumenti della piattaforma SDK Android, consulta le note di rilascio degli strumenti della piattaforma SDK.

Python

Python deve essere installato sulla macchina host. Ti consigliamo di utilizzare una distribuzione Python in bundle per garantire il supporto delle versioni compatibili. Per informazioni dettagliate su quali versioni di Python e dei pacchetti installare per una release specifica, consulta le note di rilascio di Camera ITS per la release corrispondente.

Mobly

Per Android 12 e versioni successive, installa il framework di test Mobly. Mobly ti consente di configurare un DUT e un tablet grafico nella classe its_base_test. Per installare il framework di test Mobly, esegui:

pip install mobly

Configurazione dell'ambiente

Per configurare l'ambiente di test, esegui:

cd CameraITS
source build/envsetup.sh

Questo comando controlla l'installazione di Python, imposta la variabile di ambiente PYTHONPATH e esegue test delle unità sui moduli utils/*.py. Se non vengono stampati errori nel terminale, l'ambiente è pronto per eseguire i test ITS.

Configurazione della scena

Per configurare le scene, ti consigliamo di utilizzare la configurazione Camera ITS-in-a-box per semplificare l'automazione, l'affidabilità e l'efficienza dei test. I banchi di prova ITS-in-a-box supportano tutti i requisiti di illuminazione, centratura e cambio del grafico per ITS. Inoltre, ITS-in-a-box è necessario per i test delle estensioni della videocamera.

Per i test manuali, assicurati che:

• Il DUT è su un treppiede
• Il DUT è puntato sulla scena corretta per ogni test. Lo script per il test ITS fornisce prompt per modificare la configurazione della scena prima di iniziare i test in una nuova scena.
• Il DUT è connesso alla macchina host tramite USB.
• Il DUT non si muove durante l'esecuzione del test.
• La scena è illuminata da una fonte di luce costante e non fluttuante. Non utilizzare una luce fluorescente perché introduce sfarfallio.

Lo script per il test ITS mostra un prompt che chiede all'utente di modificare la configurazione della scena prima di iniziare i test in una nuova scena.

L'orientamento dello smartphone deve essere impostato in modo che la fotocamera scatti immagini senza rotazione. Il modo più semplice per verificarlo è con le scene di volti in scene2. La maggior parte degli smartphone ha lo smartphone in orientamento orizzontale con lo smartphone ruotato in senso antiorario per la fotocamera posteriore e in senso orario per la fotocamera anteriore.

File di configurazione

Utilizzando il framework Mobly, devi creare un file di configurazione config.yml per definire il testbed Mobly. Di seguito sono riportati alcuni esempi per diversi casi d'uso.

File config.yml delle scene basate su tablet

Di seguito è riportato un esempio di file config.yml per le scene basate su tablet. Per i test basati su tablet, la parola chiave TABLET deve essere presente nel nome del banco di prova. Durante l'inizializzazione, il test runner Mobly inizializza i parametri nel file e li passa ai singoli test.

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

Per richiamare il test bed, esegui tools/run_all_tests.py. Se non sono presenti valori della riga di comando che specificano videocamere o scene, il test viene eseguito con i valori del file config.yml. Se sono presenti valori della riga di comando per le videocamere o le scene, questi sovrascrivono i valori nella sezione TestParams del file config.yml. Ad esempio:

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

Parametro chart_scaling

In Android 17 e versioni successive, il parametro chart_scaling è incluso in config.yml per TEST_BED_TABLET_SCENES. Questo parametro risolve i problemi di scalabilità dei grafici per i dispositivi con telecamera con un campo visivo più ampio, impedendo il ritaglio della scena e garantendo la corretta messa a fuoco del dispositivo durante i test.

I valori supportati per chart_scaling sono 1, 0.33, 0.5 o 0.67, con None come valore predefinito. Questo approccio consente ai dispositivi di utilizzare un fattore di scalabilità ottimale adattato ai loro requisiti specifici, mantenendo i test funzionali su tutti i dispositivi.

Se chart_scaling è impostato su None, i test determinano automaticamente il fattore di scalabilità utilizzando chart_scaling_logic. In caso contrario, viene utilizzato il valore specificato in config.yml oppure viene segnalato un errore se il ridimensionamento non è disponibile.

Di seguito è riportato un esempio di config.yml con il parametro 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

Per attivare le funzionalità di scalabilità del grafico ITS della fotocamera, sono necessari aggiustamenti lato test. Se un test che stai utilizzando non lo supporta, segnala un bug.

Di seguito è riportato un esempio di modifica del lato test con il parametro 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)

File sensor_fusion scene config.yml

Di seguito è riportato un esempio di file config_yml per i test sensor_fusion. Per i test sensor_fusion, la parola chiave SENSOR_FUSION deve essere presente nel nome del testbed. Android 13 e versioni successive supportano solo il controller Arduino per la fusione dei sensori a causa dei test di anteprima e stabilizzazione video. Android 12 supporta i controller Arduino e 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

Per eseguire i test sensor_fusion con la scatola di fusione dei sensori, esegui:

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

File config.yml di più testbed

Di seguito è riportato un esempio di file config.yml con più testbed, un testbed per tablet e un testbed sensor_fusion. Il banco di prova corretto viene determinato dalle scene testate.

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

File config.yml per i test manuali

Di seguito è riportato un esempio di file config.yml per i test manuali. Android 14 e versioni successive supportano i test manuali per tutti i test, ad eccezione dei test scene_extensions. Per i test manuali, la parola chiave MANUAL deve essere presente nel nome del banco di prova. Inoltre, la sezione AndroidDevice non può includere una sezione con numero di serie o etichetta per un tablet.

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

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

File config.yml di test dell'impianto di perforazione Gen2

Di seguito è riportato un esempio di file config.yml di un testbed TEST_BED_GEN2. Questo banco di prova viene utilizzato per i test scene_ip, che utilizzano un rig Gen2](/docs/compatibility/cts/camera-its-box-gen2). L'esempio seguente mostra i parametri del banco di prova quando il rig Gen2 è disponibile e i test scene_ip non vengono ignorati.

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

L'esempio seguente mostra i parametri del banco di prova quando il rig Gen2 non è disponibile e i test scene_ip vengono ignorati.

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

Per eseguire il test scene_ip, utilizza uno dei seguenti comandi:

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

Esecuzione dei test ITS

Questa sezione descrive come eseguire i test ITS.

Richiamare test

Dopo aver configurato il dispositivo, la macchina host (incluso l'ambiente) e la scena fisica, esegui i test ITS utilizzando la seguente procedura.

1. Apri l'app CTS Verifier. Nel menu dei test, seleziona Camera ITS Test. Per Android 17 e versioni successive, i test sensor_fusion e feature_combination si trovano in un'attività aggiuntiva denominata Camera ITS Sensor Fusion Rig Test.

2. Dalla macchina host, esegui i test ITS dalla directory CameraITS/. Ad esempio, per un dispositivo con fotocamere anteriore e posteriore, esegui il seguente comando:

   python tools/run_all_tests.py

   Lo script scorre le videocamere e le scene di test in base al file config.yml. Per il debug delle configurazioni, ti consigliamo di eseguire una delle scene scene2 con un singolo test per ottenere risultati più rapidi.

   Per i test manuali, prima di iniziare a eseguire il set di test ITS su ogni scena, lo script scatta una foto della scena corrente, la salva come JPEG, stampa il percorso del JPEG nella console e chiede all'utente di confermare se l'immagine è corretta. Questo flusso di acquisizione e conferma si ripete finché l'utente non conferma che l'immagine è corretta. Di seguito sono riportati i messaggi in questo flusso.

   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)
   

   Ogni esecuzione dello script stampa un log che mostra PASS, FAIL, FAIL* o SKIP per ogni test ITS. FAIL* indica che il test non è riuscito, ma poiché il test non è ancora obbligatorio, verrà segnalato come PASS a CtsVerifier. SKIP indica che il test è stato superato perché il dispositivo non ha pubblicizzato la funzionalità sottostante in fase di test. Ad esempio, se un dispositivo non annuncia tramite le interfacce della videocamera che supporta DNG, i test relativi all'acquisizione di file DNG vengono ignorati e conteggiati come PASS.

3. Per confermare che i test soddisfano i requisiti, tocca il pulsante con il segno di spunta verde. La voce Camera ITS Test nel menu dei test di CTS Verifier diventa verde e indica che lo smartphone ha superato il test ITS della fotocamera.

Test parallelo del DUT

I dispositivi con Android 14 o versioni successive supportano i test DUT paralleli. In questo modo puoi testare i DUT in parallelo con più configurazioni per velocizzare i test complessivi. Ad esempio, i test paralleli ti consentono di testare la videocamera 0 in un rig e la videocamera 1 in un altro rig contemporaneamente. Per Android 17 e versioni successive, poiché i test ITS della fotocamera sono suddivisi in due attività, puoi eseguire i test sensor_fusion e feature_combination su un DUT e altri test su un altro DUT in parallelo. Tutti i test per le sessioni di test parallele vengono aggregati nella sessione CTS Verifier sul DUT di riferimento. Devi eseguire test paralleli con il controllo dell'illuminazione Arduino, poiché il controllo manuale dell'illuminazione non è supportato con i test paralleli. Assicurati che un canale diverso sullo stesso controller Arduino controlli l'illuminazione di ogni impianto.

Di seguito è riportato un file config.yml di esempio che definisce tre testbed da eseguire in parallelo.

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"

Per eseguire i testbed in parallelo, utilizza il comando seguente:

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

Inviare i risultati aggregati dei test

In Android 17 e versioni successive, puoi inviare risultati di test ITS della videocamera aggregati per l'approvazione della build. CTS Verifier consente di testare contemporaneamente più scenari su più dispositivi e aggregare i risultati dei test di più report CTS Verifier (da test eseguiti o dispositivi diversi) in un unico invio unificato.

Procedura di invio

Per inviare i risultati ITS della videocamera aggregati per l'approvazione della build:

1. Prepara i dispositivi:raccogli da due a tre dispositivi in test (DUT) che abbiano tutti la stessa impronta della build.
2. Installa CTS Verifier:installa l'APK di CTS Verifier più recente, che può essere ottenuto dall'explorer delle build fornito.

3. Esegui test in parallelo:

   1. Monta i DUT in supporti separati.
   2. Esegui contemporaneamente scene ITS della videocamera diverse su ogni dispositivo.
   3. Raccolta dei report:estrai il report CTS Verifier dopo ogni esecuzione. Sono inclusi i report in cui le scene non sono state generate. Esegui nuovamente solo le scene non riuscite nelle esecuzioni successive.

4. Invia report:carica più report CTS Verifier raccolti da tutti i dispositivi.

5. Esamina i risultati:una volta caricati i report, esamina i risultati aggregati:

   • La sezione Analisi test mostra un elenco completo di tutte le scene eseguite.

   • Le scene non eseguite o non riuscite sono elencate nella sezione Non riuscito.

     

     Figura 1. Documentazione delle scene che non sono state eseguite o non sono andate a buon fine.

   • Le scene di passaggio sono elencate nella sezione Passaggio aggregato.

     

     Figura 2. Scene classificate come Aggregated Pass

Stato di approvazione della build

L'approvazione della build viene concessa una volta completate correttamente tutte le scene richieste nei report aggregati.

Modello di rumore DNG

I dispositivi che pubblicizzano la possibilità di acquisire immagini RAW o DNG devono fornire un modello di rumore nei metadati dei risultati di acquisizione di ogni scatto RAW. Questo modello di rumore deve essere incorporato nell'HAL della videocamera per ogni videocamera (ad esempio, anteriore e posteriore) sul dispositivo che dichiara il supporto.

Implementazione del modello di rumore

Per implementare un modello di rumore, segui questi passaggi per generare un modello di rumore e incorporarlo nell'HAL della videocamera.

1. Per generare un modello di rumore per ogni videocamera, esegui lo script dng_noise_model.py nella directory tools. Viene generato uno snippet di codice C. Per maggiori informazioni su come configurare la videocamera e l'ambiente di acquisizione, consulta il documento DngNoiseModel.pdf nella directory tools.

2. Per implementare il modello di rumore per il dispositivo, taglia e incolla lo snippet di codice C nell'HAL della videocamera.

Convalida del modello di rumore

Il test ITS automatizzato tests/scene1_1/test_dng_noise_model.py convalida il modello di rumore verificando che i valori di rumore per l'esposizione e il guadagno dello scatto forniti nei dati della videocamera siano corretti.

Test superati marginalmente (stato del test PASS*)

In Android 17 e versioni successive, un superamento marginale (PASS*) indica che un test è stato superato, ma le sue metriche di rendimento sono molto vicine alla soglia di superamento predefinita. Sebbene il test soddisfi tecnicamente i criteri di superamento, la vicinanza al limite di errore suggerisce la necessità di un esame più approfondito.

Vantaggi del superamento marginale

Lo stato PASS* offre diversi vantaggi:

• Sistema di avviso rapido: identifica i test che stanno per non superare la prova, consentendo ai team di risolvere i problemi prima che portino a errori totali.

• Ottimizzazione proattiva: incoraggia i team a ottimizzare i test e il codice che hanno un rendimento inferiore rispetto al range accettabile, migliorando la stabilità complessiva.

• Qualità migliorata: contribuisce a mantenere uno standard di qualità più elevato segnalando le aree che potrebbero essere soggette a regressioni future con modifiche minori del codice.

• Riduzione del tempo di debug: rilevando i test PASS* in anticipo, il tempo e l'impegno necessari per eseguire il debug degli errori completi in futuro possono essere ridotti in modo significativo.

Dettagli PASS*

Lo stato PASS* include:

• Definizione delle soglie: per ogni test pertinente in Camera ITS vengono definite soglie di superamento marginale specifiche.

• Rilevamento automatico: il sistema di automazione dei test rileva e classifica i test come PASS* in base alle soglie definite.

• Meccanismo di avviso: i team ricevono avvisi automatici per tutti i test contrassegnati come PASS*, che li indirizzano a esaminare il test specifico e le relative metriche.

• Report: gli stati di superamento marginale sono indicati chiaramente nei report sui test e nelle dashboard per una migliore visibilità come PASS* nel report ItsTestSummary, in modo simile a Fail* per i test not_yet_mandated. Il test mantiene lo stato verde, in quanto continua a superare le soglie stabilite, per evitare ulteriore confusione. Lo stato PASS* si applica solo a una classe di test, non all'intera scena. Ad esempio, Scene_0 può essere considerato PASS anche se test_jitter e test_metadata sono PASS*.

• Monitoraggio: i dati sul rendimento vengono raccolti sui test che superano marginalmente un dispositivo. Ciò consente di monitorare i futuri miglioramenti della videocamera apportati dagli OEM se questi test passano allo stato PASS.

Di seguito è riportato un esempio di risultati del test 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'}}

I partner sono invitati a:

• Monitorare gli avvisi PASS*
• Esamina la causa principale di PASS* test
• Ottimizza in modo proattivo i test e il codice identificati come PASS*

Lo stato PASS* mira a migliorare la robustezza e l'affidabilità dei test ITS della videocamera, portando a un prodotto stabile e di alta qualità.