Note sulla versione di Android 12 Camera Image Test Suite

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Nella versione Android 12 sono incluse numerose modifiche a Camera ITS . Questa pagina riassume le modifiche che rientrano in quattro grandi categorie:

Refactoring in Python 3

A causa della deprecazione di Python 2.7 nel gennaio 2020, l'intera base di codice di Camera ITS è stata refactoring in Python 3. In Android 12 sono richieste le seguenti versioni e librerie di Python:

Il programma di avvio del test principale, tools/run_all_tests.py , rimane lo stesso delle versioni Android 11 o precedenti e viene rifattorizzato in Python 3.

Tutti i singoli test vengono rifattorizzato e utilizzano la nuova classe di configurazione del test definita in tests/its_base_test.py . La maggior parte dei nomi e delle funzionalità dei test rimangono gli stessi. In Android 12 tutti i singoli test ora caricano le loro scene. Sebbene il caricamento delle scene per ogni test aumenti il ​​tempo complessivo del test, consente il debug dei singoli test.

Per ulteriori informazioni sulle singole modifiche ai test, vedere Modifiche ai test .

I seguenti moduli Python vengono rifattorizzato con un cambio di nome:

  • pymodules/its/caps.pyutils/camera_properties_utils.py
  • pymodules/its/cv2image.pyutils/opencv_processing_utils.py
  • pymodules/its/device.pyutils/its_session_utils.py
  • pymodules/its/error.pyutils/error_util.py
  • pymodules/its/image.pyutils/image_processing_utils.py
  • pymodules/its/objects.pyutils/capture_request_utils.py
  • pymodules/its/target.pyutils/target_exposure_utils.py
  • tools/hw.pyutils/sensor_fusion_utils.py

Adozione del framework di test mobili

Mobly è un framework di test basato su Python che supporta casi di test che richiedono più dispositivi con configurazioni hardware personalizzate. Camera ITS utilizza l'infrastruttura di test Mobly per consentire un migliore controllo e registrazione dei test.

Camera ITS utilizza l'infrastruttura di test Mobly per consentire un migliore controllo e registrazione dei test. Mobly è un framework di test basato su Python che supporta casi di test che richiedono più dispositivi con configurazioni hardware personalizzate. Per ulteriori informazioni su Mobly, vedere google/mobly .

config.yml

Con il framework Mobly, puoi configurare un dispositivo in prova (DUT) e una tavoletta grafica nella classe its_base_test . Un file config.yml (YAML) viene utilizzato per creare un banco di prova Mobly. È possibile configurare più banchi di prova all'interno di questo file di configurazione, ad esempio un tablet e un banco di prova per la fusione dei sensori. All'interno della sezione del controller di ogni banco di prova, puoi specificare device_ids per identificare i dispositivi Android appropriati per il test runner. Oltre agli ID dispositivo, nella classe di test vengono passati altri parametri come la brightness del tablet , chart_distance , debug_mode , camera_id e scene_id . I valori dei parametri di test comuni sono:

brightness: 192  (all tablets except Pixel C)
chart_distance: 31.0  (rev1/rev1a box for FoV < 90° cameras)
chart_distance: 22.0 (rev2 test rig for FoV > 90° cameras)

Test su tablet

Per i test basati su tablet, la parola chiave TABLET deve essere presente nel nome del banco di prova. Durante l'inizializzazione, Mobly test runner inizializza TestParams e li passa ai singoli test.

Di seguito è riportato un file config.yml di esempio per le esecuzioni basate su tablet.

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

Il banco di prova può essere richiamato utilizzando tools/run_all_tests.py . Se non sono presenti valori della riga di comando, i test vengono eseguiti con i valori del file config.yml . Inoltre, puoi sovrascrivere i valori del file di configurazione della camera e della scene dalla riga di comando utilizzando comandi simili ad Android 11 o precedenti.

Per 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=1 scenes=2,1,0

Test di fusione dei sensori

Per il test di fusione del sensore , il nome del banco di prova deve includere la parola chiave SENSOR_FUSION . Il banco di prova corretto è determinato dalle scene testate. Android 12 supporta sia i controller Arduino che Canakit per la fusione dei sensori .

Di seguito è riportato un file config.yml di esempio per le esecuzioni di sensor fusion.

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         # cntl can be arduino or canakit
      rotator_ch: 1
      camera: 0

Per eseguire i test di fusione dei sensori con il banco di prova per la fusione dei sensori, utilizzare:

python tools/run_all_tests.py scenes=sensor_fusion
python tools/run_all_tests.py scenes=sensor_fusion camera=0

Più banchi di prova

È possibile includere più banchi di prova nel file di configurazione. La combinazione più comune consiste nell'avere sia un banco di prova per tablet che un banco di prova per la fusione del sensore.

Quello che segue è un file config.yml di esempio con i banchi di prova per la fusione di sensori e tablet.

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

Test manuali

Il test manuale continua a essere supportato in Android 12. Tuttavia, il banco di prova deve identificare il test in quanto tale con la parola chiave MANUAL nel nome del banco di prova. Inoltre, il banco di prova non può includere un ID tablet.

Di seguito è riportato un file config.yml di esempio per il test manuale.

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

    TestParams:
      debug_mode: "False"
      chart_distance: 31.0
      camera: 0
      scene: scene1

Test di scene senza tablet

Il test per la scena 0 e la scena 5 può essere eseguito con TEST_BED_TABLET_SCENES o con TEST_BED_MANUAL . Tuttavia, se il test viene eseguito con TEST_BED_TABLET_SCENES , il tablet deve essere connesso e l'ID seriale del tablet deve essere valido anche se il tablet non viene utilizzato perché l'impostazione della classe di test assegna il valore dell'ID seriale per il tablet.

Esecuzione di test individuali

I singoli test possono essere eseguiti solo a scopo di debug perché i loro risultati non vengono segnalati a CTS Verifier . Poiché i file config.yml non possono essere sovrascritti dalla riga di comando per camera e scene , questi parametri devono essere corretti nel file config.yml per il singolo test in questione. Inoltre, se è presente più di un banco di prova nel file di configurazione, è necessario specificare il banco di prova con il flag --test_bed . Per esempio:

python tests/scene1_1/test_black_white.py --config config.yml --test_bed TEST_BED_TABLET_SCENES

Testare gli artefatti

In Android 12, gli artefatti di test per Camera ITS vengono archiviati in modo simile ad Android 11 o versioni precedenti, ma con le seguenti modifiche:

  • La directory test artefact /tmp ha CameraITS_ anteposto alla stringa casuale di 8 caratteri per chiarezza.
  • L'output del test e gli errori vengono archiviati in test_log.DEBUG per ogni test invece di test_name_stdout.txt e test_name_stderr.txt .
  • I logcat DUT e tablet di ogni singolo test sono archiviati nella /tmp/CameraITS_######## , semplificando il debug poiché tutte le informazioni necessarie per eseguire il debug dei problemi 3A vengono registrate.

Prova le modifiche

In Android 12 le scene del tablet sono file PNG anziché file PDF. L'uso di file PNG consente a più modelli di tablet di visualizzare correttamente le scene.

scena0/test_jitter.py

Il test test_jitter viene eseguito su telecamere nascoste fisiche in Android 12.

scena1_1/test_nero_bianco.py

Per Android 12, test_black_white ha la funzionalità sia di test_black_white che di test_channel_saturation .

La tabella seguente descrive i due test individuali in Android 11.

Nome della prova Primo livello API Affermazioni
scena1_1/test_nero_bianco.py TUTTO Esposizione breve, valori RGB a basso guadagno ~[0, 0, 0]
Esposizione lunga, valori RGB ad alto guadagno ~[255, 255, 255]
scene1_1/test_channel_saturation.py 29 Tolleranza ridotta sulle differenze [255, 255, 255] per eliminare la sfumatura di colore nelle immagini bianche.

La tabella seguente descrive il test unito, scene1_1/test_black_white.py, in Android 12.

Nome della prova Primo livello API Affermazioni
scena1_1/test_nero_bianco.py TUTTO Esposizione breve, valori RGB a basso guadagno ~[0, 0, 0]
Lunga esposizione, valori RGB ad alto guadagno ~[255, 255, 255] e tolleranza ridotta tra i valori per eliminare la sfumatura di colore nelle immagini bianche.

scene1_1/test_burst_sameness_manual.py

Il test test_burst_sameness_manual viene eseguito su telecamere nascoste fisiche in Android 12.

scene1_2/test_tonemap_sequence.py

Il test test_tonemap_sequence viene eseguito su fotocamere LIMITED in Android 12.

scene1_2/test_yuv_plus_raw.py

Il test test_yuv_plus_raw viene eseguito su telecamere nascoste fisiche in Android 12.

scene2_a/test_format_combos.py

Il test test_format_combos viene eseguito su fotocamere LIMITED in Android 12.

scene3/test_flip_mirror.py

Il test test_flip_mirror viene eseguito su fotocamere LIMITED in Android 12.

scene4/test_aspect_ratio_and_crop.py

Trovare cerchi in scene4/test_aspect_ratio_and_crop.py è stato refactoring in Android 12.

Le versioni precedenti di Android utilizzavano un metodo che prevedeva la ricerca di un contorno figlio (il cerchio) all'interno del contorno padre (il quadrato) con filtri per dimensioni e colore. Android 12 utilizza un metodo che prevede la ricerca di tutti i contorni e quindi il filtraggio trovando le caratteristiche più circolari . Per schermare i cerchi spuri sul display, è richiesta un'area di contorno minima e il contorno del cerchio deve essere nero.

I contorni e i relativi criteri di selezione sono mostrati nell'immagine seguente.

Disegno concettuale dei contorni e criteri di selezione

Figura 1. Disegno concettuale dei contorni e criteri di selezione

Il metodo Android 12 è più semplice e funziona per risolvere il problema del ritaglio del riquadro di delimitazione in alcuni tablet con display. Tutti i candidati alla cerchia vengono registrati per scopi di debug.

In Android 12, il crop test viene eseguito per i dispositivi FULL e LEVEL3 . Android 11 o versioni precedenti ignorano le asserzioni del test di ritaglio per i dispositivi FULL .

La tabella seguente elenca le asserzioni per test_aspect_ratio_and_crop.py che corrispondono a un determinato livello di dispositivo e al primo livello API.

Livello del dispositivo Primo livello API Affermazioni
LIMITATO TUTTO Proporzioni
FoV per i formati 4:3, 16:9, 2:1
COMPLETO < 31 Proporzioni
FoV per i formati 4:3, 16:9, 2:1
COMPLETO ≥ 31 Raccolto
Proporzioni
FoV per i formati 4:3, 16:9, 2:1
LIVELLO 3 TUTTO Raccolto
Proporzioni
FoV per i formati 4:3, 16:9, 2:1

scene4/test_multi_camera_alignment.py

Il metodo undo_zoom() per le acquisizioni YUV in scene4/test_multi_camera_alignment.py è stato rifattorizzato per tenere conto in modo più accurato del ritaglio sui sensori che non corrispondono alle proporzioni dell'acquisizione.

Codice Android 11 Python 2

zoom_ratio = min(1.0 * yuv_w / cr_w, 1.0 * yuv_h / cr_h)
circle[i]['x'] = cr['left'] + circle[i]['x'] / zoom_ratio
circle[i]['y'] = cr['top'] + circle[i]['y'] / zoom_ratio
circle[i]['r'] = circle[i]['r'] / zoom_ratio

Codice Android 12 Python 3

yuv_aspect = yuv_w / yuv_h
relative_aspect = yuv_aspect / (cr_w/cr_h)
if relative_aspect > 1:
  zoom_ratio = yuv_w / cr_w
  yuv_x = 0
  yuv_y = (cr_h - cr_w / yuv_aspect) / 2
else:
  zoom_ratio = yuv_h / cr_h
  yuv_x = (cr_w - cr_h * yuv_aspect) / 2
  yuv_y = 0
circle['x'] = cr['left'] + yuv_x + circle['x'] / zoom_ratio
circle['y'] = cr['top'] + yuv_y + circle['y'] / zoom_ratio
circle['r'] = circle['r'] / zoom_ratio

sensor_fusion/test_sensor_fusion.py

In Android 12 viene aggiunto un metodo per rilevare le caratteristiche nelle immagini per il test di fusione del sensore.

Nelle versioni inferiori ad Android 12, l'intera immagine viene utilizzata per trovare le migliori 240 funzionalità che vengono quindi mascherate al centro del 20% per evitare effetti di tapparella con il requisito minimo di funzionalità di 30 funzionalità.

Se le funzionalità trovate con questo metodo sono insufficienti, Android 12 maschera prima l'area di rilevamento delle funzionalità al centro del 20% e limita le funzionalità massime a due volte il requisito minimo di funzionalità.

L'immagine seguente mostra la differenza tra il rilevamento delle funzionalità di Android 11 e Android 12. L'aumento della soglia minima dei requisiti di funzionalità determina il rilevamento di funzionalità di scarsa qualità e influisce negativamente sulle misurazioni.

differenza nel rilevamento delle funzionalità tra Android 11 e Android 12 sensor_fusion rilevamento della funzione

Figura 2. Differenza nel rilevamento delle funzionalità tra Android 11 e Android 12

Nuovi test

scene0/test_solid_color_test_pattern.py

Un nuovo test, test_solid_color_test_pattern , è abilitato per Android 12. Questo test è abilitato per tutte le fotocamere ed è descritto nella tabella seguente.

Scena Nome della prova Primo livello API Descrizione
0 test_solid_color_test_pattern 31 Conferma l'output dell'immagine in tinta unita e la programmabilità del colore dell'immagine.

I modelli di prova in tinta unita devono essere abilitati per supportare la modalità privacy della fotocamera. Il test test_solid_color_test_pattern conferma l'output dell'immagine YUV a colori solidi con il colore definito dal motivo selezionato e il colore dell'immagine cambia in base alle specifiche.

Parametri

  • cameraPrivacyModeSupport : determina se la fotocamera supporta la modalità privacy.
  • android.sensor.testPatternMode : Imposta la modalità del modello di prova. Questo test utilizza SOLID_COLOR .
  • android.sensor.testPatternData : imposta i valori del modello di test R, Gr, Gb, G per la modalità del modello di test.

Per una descrizione del modello di prova in tinta unita, vedere SENSOR_TEST_PATTERN_MODE_SOLID_COLOR .

Metodo

I fotogrammi YUV vengono acquisiti per i parametri impostati e il contenuto dell'immagine viene convalidato. Il modello di prova viene emesso direttamente dal sensore di immagine, quindi non è richiesta una scena particolare. Se PER_FRAME_CONTROL è supportato, viene catturato un singolo fotogramma YUV per ogni impostazione testata. Se PER_FRAME_CONTROL non è supportato, vengono acquisiti quattro fotogrammi con solo l'ultimo fotogramma analizzato per massimizzare la copertura del test nelle telecamere LIMITED .

Le acquisizioni YUV sono impostate su modelli di test BLACK , WHITE , RED , GREEN e BLUE completamente saturati. Poiché la definizione del modello di prova è per il modello Bayer del sensore, i canali di colore devono essere impostati per ciascun colore come mostrato nella tabella seguente.

Colore testPatternData (RGGB)
NERO (0, 0, 0, 0)
BIANCA (1, 1, 1, 1)
ROSSO (1, 0, 0, 0)
VERDE (0, 1, 1, 0)
BLU (0, 0, 0, 1)

Tabella delle asserzioni

La tabella seguente descrive le asserzioni di test per test_solid_color_test_pattern.py .

Telecamera
Primo livello API
Tipo di fotocamera Colori affermati
31 Bayer NERO, BIANCO, ROSSO, VERDE, BLU
31 MONO NERO BIANCO
< 31 Bayer/MONO NERO

Test di classe di prestazione

scene2_c/test_camera_launch_perf_class.py

Verifica che l'avvio della telecamera sia inferiore a 500 ms per le telecamere primarie anteriori e posteriori con la scena del viso scene2_c.

scene2_c/test_jpeg_capture_perf_class.py

Verifica che la latenza di acquisizione JPEG 1080p sia inferiore a 1 secondo per entrambe le fotocamere principali anteriori e posteriori con la scena del viso scene2_c.