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 fotocamera in un modo specifico, acquisire uno o più scatti ed esaminarli per verificare se contengono i dati immagine previsti. Molti test richiedono che la fotocamera 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 fotografata dalla fotocamera

Configurazione del dispositivo in fase di test (DUT)

Per configurare un DUT:

1. Collega il DUT a una macchina host tramite USB.
2. Concedi all'host le autorizzazioni per accedere al DUT tramite ADB.

3. Installa l'app CTS Verifier (CtsVerifier.apk) sul dispositivo. Per saperne di più, consulta Utilizzare CTS Verifier.

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

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

Configurazione dell'host

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

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 essere 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 con 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 ed esegue i test delle unità sui moduli utils/*.py. Se non vengono stampati errori nel terminale, l'ambiente è pronto per l'esecuzione dei test ITS.

Configurazione della scena

Per configurare le scene, ti consigliamo di utilizzare la configurazione Camera ITS-in-a-box per facilitare 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 di grafici per ITS. Inoltre, ITS-in-a-box è obbligatorio per i test delle estensioni della fotocamera.

Per i test manuali, assicurati che:

• Il DUT sia su un treppiede
• Il DUT sia puntato sulla scena corretta per ogni test. (Lo script di test ITS fornisce prompt per modificare la configurazione della scena prima di avviare i test in una nuova scena.)
• Il DUT sia collegato alla macchina host tramite USB.
• Il DUT non si muova durante l'esecuzione del test.
• La scena sia illuminata da una sorgente luminosa stabile e non fluttuante. (Non utilizzare una luce fluorescente perché introduce sfarfallio.)

Lo script per il test ITS visualizza un prompt che chiede all'utente di modificare la configurazione della scena prima di avviare 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 è utilizzare le scene con i volti in scene2. La maggior parte degli smartphone ha l'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 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 nel nome del testbed. Durante l'inizializzazione, il runner di test 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 testbed, esegui tools/run_all_tests.py. Se non sono presenti valori della riga di comando che specificano fotocamere o scene, il test viene eseguito con i valori del file config.yml. Se sono presenti valori della riga di comando per fotocamere o scene, questi sostituiscono 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 (FoV) più ampio, impedisce il ritaglio della scena e impone una messa a fuoco corretta 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 la scalabilità 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à dei grafici di Camera ITS, sono necessarie modifiche lato test. Se un test che stai utilizzando non supporta questa funzionalità, segnala un bug.

Di seguito è riportato un esempio di modifica 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 config.yml della scena sensor_fusion

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 nel nome del testbed. Android 13 e versioni successive supportano solo il controller Arduino per la fusione dei sensori a causa dei test di stabilizzazione di anteprima e 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 testbed 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 dei 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 scene_extensions test. Per i test manuali, la parola chiave MANUAL deve essere nel nome del testbed. Inoltre, la sezione AndroidDevice non può includere una sezione seriale o di 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 dei test del banco di prova Gen2

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

Richiamo dei 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 fotocamere e le scene di test in base al file config.yml. Per le configurazioni di debug, ti consigliamo di eseguire una delle scene scene2 con un singolo test per una risposta più rapida.

   Per i test manuali, prima di iniziare a eseguire la serie 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 viene ripetuto 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 pubblicizza tramite le interfacce della fotocamera il supporto di DNG, i test relativi all'acquisizione di file DNG vengono ignorati e conteggiati come PASS.

3. Per confermare che i test soddisfano i requisiti di test, 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 Camera ITS.

Test DUT paralleli

I dispositivi con Android 14 o versioni successive supportano i test DUT paralleli. In questo modo puoi testare i DUT in parallelo con più banchi di prova per velocizzare i test complessivi. Ad esempio, i test paralleli ti consentono di testare la fotocamera 0 in un banco di prova e la fotocamera 1 in un altro banco di prova contemporaneamente. Per Android 17 e versioni successive, poiché i test Camera ITS 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 paralleli vengono aggregati nella sessione CTS Verifier sul DUT di riferimento. Devi eseguire i 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 banco di prova.

Di seguito è riportato un esempio di file config.yml 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 seguente comando:

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

Inviare i risultati dei test aggregati

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

Procedura di invio

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

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

3. Esegui i test in parallelo:

   1. Monta i DUT in banchi di prova separati.
   2. Esegui contemporaneamente scene Camera ITS 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 riuscite. Esegui nuovamente solo le scene non riuscite nelle esecuzioni successive.

4. Invia i 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 dei test mostra un elenco completo di tutte le scene eseguite.

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

     

     Figura 1. Documentazione delle scene non eseguite o non riuscite.

   • Le scene superate sono elencate nella sezione Superate aggregate.

     

     Figura 2. Scene classificate come Superate aggregate

Stato di approvazione della build

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

Modello di rumore DNG

I dispositivi che pubblicizzano la possibilità di acquisire 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 fotocamera per ogni fotocamera (ad esempio, fotocamere 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 fotocamera.

1. Per generare un modello di rumore per ogni fotocamera, esegui lo dng_noise_model.py script nella tools directory. Viene generato uno snippet di codice C. Per saperne di più su come configurare la fotocamera 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 fotocamera.

Convalida del modello di rumore

Il test ITS automatico 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 fotocamera 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 relative 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 allerta precoce: identifica i test che sono sul punto di non riuscire, consentendo ai team di risolvere i problemi prima che portino a errori completi.

• Ottimizzazione proattiva: incoraggia i team a ottimizzare i test e il codice che hanno un rendimento nella parte inferiore dell'intervallo accettabile, migliorando la stabilità complessiva.

• Miglioramento della qualità: aiuta a mantenere uno standard di qualità più elevato segnalando le aree che potrebbero essere soggette a regressioni future con modifiche minime del codice.

• Riduzione del tempo di debug: rilevando i test PASS* in anticipo, è possibile ridurre significativamente il tempo e l'impegno necessari per eseguire il debug degli errori completi in futuro.

Dettagli di PASS*

Lo stato PASS* include quanto segue:

• 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 e nelle dashboard dei test per una migliore visibilità come PASS* nel report ItsTestSummary, in modo simile a Fail* per i test not_yet_mandated. Il test mantiene uno stato verde, poiché 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. In questo modo è possibile monitorare i futuri miglioramenti della fotocamera apportati dagli OEM se questi test passano allo stato PASS.

Di seguito è riportato un esempio di risultati dei 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*
• Esaminare la causa principale dei test PASS*
• Ottimizzare in modo proattivo i test e il codice identificati come PASS*

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