Note sulla versione di Android 12 Camera Image Test Suite

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'intero codice base di Camera ITS è stato sottoposto a refactoring in Python 3. Le seguenti versioni e librerie Python sono richieste in Android 12:

L'avvio principale del test, tools/run_all_tests.py , rimane lo stesso delle versioni Android 11 o precedenti ed è stato sottoposto a refactoring in Python 3.

Tutti i test individuali vengono sottoposti a refactoring 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 test individuali ora caricano le proprie scene. Sebbene il caricamento della scena per ciascun test aumenti il ​​tempo complessivo del test, consente il debug dei singoli test.

Per ulteriori informazioni sulle singole modifiche di test, consulta Modifiche di test .

I seguenti moduli Python vengono sottoposti a refactoring con una modifica del 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

Testare in mobilità l'adozione del framework

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 .

file config.yml

Con il framework Mobly, puoi impostare un dispositivo sotto test (DUT) e una tavoletta cartografica nella classe its_base_test . Un file config.yml (YAML) viene utilizzato per creare un banco di prova Mobly. All'interno di questo file di configurazione è possibile configurare più banchi di prova, ad esempio un tablet e un banco di prova per la fusione di 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 del dispositivo, nella classe di test vengono passati altri parametri come brightness del tablet, chart_distance , debug_mode , camera_id e scene_id . I valori comuni dei parametri di test 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 basati 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 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 camera e scene dalla riga di comando utilizzando comandi simili ad Android 11 o versioni 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 i test di fusione dei sensori , 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 fusione dei sensori.

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 test di fusione dei sensori con il banco prova di fusione dei sensori , utilizzare:

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

Banchi di prova multipli

È possibile includere più banchi di prova nel file di configurazione. La combinazione più comune è quella di avere sia un banco di prova per tablet che un banco di prova per la fusione di sensori.

Di seguito è riportato un file config.yml di esempio con banchi di prova per tablet e fusione di sensori.

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 manuale

I test manuali continuano a essere supportati in Android 12. Tuttavia, il banco di prova deve identificare i test come tali con la parola chiave MANUAL nel nome del banco di prova. Inoltre, il banco di prova non può includere un ID tablet.

Quello che segue è 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

Prova le 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 al tablet.

Esegui test individuali

I singoli test possono essere eseguiti solo a scopo di debug perché i relativi 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 nel file di configurazione è presente più di un testbed, è necessario specificare il testbed 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 dell'artefatto di test /tmp ha CameraITS_ anteposto alla stringa casuale di 8 caratteri per chiarezza.
  • L'output e gli errori del test vengono archiviati in test_log.DEBUG per ogni test anziché in test_name_stdout.txt e test_name_stderr.txt .
  • I logcat del DUT e del tablet di ogni singolo test sono archiviati nella directory /tmp/CameraITS_######## semplificando il debug poiché tutte le informazioni necessarie per eseguire il debug dei problemi 3A vengono registrate.

Testare 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.

scene0/test_jitter.py

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

scene1_1/test_black_white.py

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

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

Nome della prova Primo livello API Affermazioni
scene1_1/test_black_white.py TUTTO Esposizione breve, valori RGB a basso guadagno ~[0, 0, 0]
Lunga esposizione, 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
scene1_1/test_black_white.py TUTTO Esposizione breve, valori RGB a basso guadagno ~[0, 0, 0]
Esposizione lunga, 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 LIMITATE 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 LIMITATE in Android 12.

scene3/test_flip_mirror.py

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

scene4/test_aspect_ratio_and_crop.py

La ricerca dei cerchi in scene4/test_aspect_ratio_and_crop.py è stata sottoposta a 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 genitore (il quadrato) con filtri per dimensione e colore. Android 12 utilizza un metodo che prevede la ricerca di tutti i contorni e quindi il filtraggio individuando le caratteristiche più circolari . Per escludere cerchi spuri sul display, è necessaria un'area minima del contorno 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 a scopo di debug.

In Android 12 il test di ritaglio viene eseguito per i dispositivi FULL e LEVEL3 . Android 11 o versioni precedenti saltano 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
PIENO <31 Proporzioni
FoV per i formati 4:3, 16:9, 2:1
PIENO ≥ 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 dei sensori.

Nelle versioni precedenti ad Android 12, l'intera immagine viene utilizzata per trovare le 240 funzionalità migliori che vengono poi mascherate al centro del 20% per evitare effetti rolling shutter con un requisito minimo di funzionalità pari a 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 della 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 il rilevamento delle funzionalità sensor_fusion di Android 11 e Android 12

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 a colori solidi e la programmabilità del colore dell'immagine.

I modelli di prova a 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 modello 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 test. Questo test utilizza SOLID_COLOR .
  • android.sensor.testPatternData : imposta i valori del modello di test R, Gr, Gb, G per la modalità modello di test.

Per una descrizione del modello di prova del colore solido, 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 alcuna scena particolare. Se PER_FRAME_CONTROL è supportato, viene acquisito un singolo frame YUV per ciascuna impostazione testata. Se PER_FRAME_CONTROL non è supportato, vengono acquisiti quattro fotogrammi e solo l'ultimo fotogramma viene analizzato per massimizzare la copertura del test nelle telecamere LIMITED .

Le acquisizioni YUV sono impostate sui modelli di prova BLACK , WHITE , RED , GREEN e BLUE completamente saturi. Poiché la definizione del modello di prova è basata sul 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)
BIANCO (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 delle classi di prestazione

scene2_c/test_camera_launch_perf_class.py

Verifica che l'avvio della fotocamera sia inferiore a 500 ms sia per la fotocamera principale anteriore che per quella posteriore con la scena del volto scene2_c.

scene2_c/test_jpeg_capture_perf_class.py

Verifica che la latenza di acquisizione JPEG 1080p sia inferiore a 1 secondo sia per la fotocamera principale anteriore che per quella posteriore con la scena del volto scene2_c.