Nella release di Android 12 sono incluse diverse modifiche all'ITS della fotocamera. Questa pagina riassume le modifiche che rientrano in quattro ampie categorie:
Esegui il refactoring in Python 3
A causa del ritiro di Python 2.7 a gennaio 2 2020, l'intero codebase ITS della videocamera è stato sottoposto a refactoring in Python 3. In Android 12 sono necessarie le seguenti versioni e librerie Python:
- Python 3.7.9 o Python 3.7.10
- OpenCV 3.4.2
- Numpy 1.19.2
- Matplotlib 3.3.2
- Scipy 1.5.2
- pySerial 3.5
- Cuscino 8.1.0
- PyYAML 5.3.1
Il programma di lancio dei test principale, tools/run_all_tests.py, rimane invariato rispetto alle versioni Android 11 o precedenti e viene ristrutturato in Python 3.
Tutti i singoli test 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 rimane invariata.
In Android 12, ora tutti i singoli test caricano
le proprie scene. Sebbene il caricamento della scena per ogni test aumenti il tempo di test complessivo, consente il debug dei singoli test.
Per ulteriori informazioni sulle modifiche ai singoli test, consulta Modifiche ai test.
I seguenti moduli Python sono stati sottoposti a refactoring con una modifica del nome:
pymodules/its/caps.py→utils/camera_properties_utils.pypymodules/its/cv2image.py→utils/opencv_processing_utils.pypymodules/its/device.py→utils/its_session_utils.pypymodules/its/error.py→utils/error_util.pypymodules/its/image.py→utils/image_processing_utils.pypymodules/its/objects.py→utils/capture_request_utils.pypymodules/its/target.py→utils/target_exposure_utils.pytools/hw.py→utils/sensor_fusion_utils.py
Adozione del framework di test Mobly
Mobly è un framework di test basato su Python che supporta scenari di test che richiedono più dispositivi con configurazioni hardware personalizzate. La ITS della videocamera utilizza l'infrastruttura di test Mobly per consentire un migliore controllo e registrazione dei test.
La ITS della videocamera utilizza l'infrastruttura di test Mobly per consentire un migliore controllo e logging dei test. Mobly è un framework di test basato su Python che supporta scenari di test che richiedono più dispositivi con configurazioni hardware personalizzate. Per ulteriori informazioni su Mobly, visita la pagina google/mobly.
file config.yml
Con il framework Mobly, puoi configurare un dispositivo in test (DUT) e un tablet con grafici nella classe its_base_test. Un file config.yml (YAML) viene utilizzato per creare un testbed Mobly. In questo file di configurazione è possibile configurare più banchi di prova, ad esempio un tablet e un banco di prova di fusione dei sensori. Nella sezione del controller di ogni testbed, puoi specificare device_ids per identificare i dispositivi Android appropriati per il programma di test. Oltre agli ID dispositivo, nella classe di test vengono passati altri parametri come il tablet brightness, 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 testbed. Durante l'inizializzazione, il test runner di 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
La piattaforma di test può essere richiamata 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 sostituire i valori dei file di configurazione camera e scene nella riga di comando utilizzando comandi simili ad Android 11 o versioni precedenti.
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=1 scenes=2,1,0
Test di fusione dei sensori
Per i test di fusione dei sensori, il nome della piattaforma di test deve includere la parola chiaveSENSOR_FUSION. La piattaforma di test corretta è determinata dalle scene testate. Android 12 supporta sia i controller Arduino sia i controller Canakit per la fusione dei sensori.
Di seguito è riportato un file config.yml di esempio per le esecuzioni di fusione dei dati 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 la apparecchiatura di test per la fusione dei sensori, utilizza:
python tools/run_all_tests.py scenes=sensor_fusion
python tools/run_all_tests.py scenes=sensor_fusion camera=0
Più testbed
Nel file di configurazione è possibile includere più banchi di prova. La combinazione più comune è avere sia un banco di prova per tablet che un banco di prova per sensori fusion.
Di seguito è riportato un file config.yml di esempio con i testbed di fusione di tablet e 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 testbed deve identificare
i test come tali con la parola chiave MANUAL nel nome del testbed. Inoltre, il banco di test non può includere un ID tablet.
Di seguito è riportato un file config.yml di esempio per i test manuali.
TestBeds:
- Name: TEST_BED_MANUAL
Controllers:
AndroidDevice:
- serial: 8A9X0NS5Z
label: dut
TestParams:
debug_mode: "False"
chart_distance: 31.0
camera: 0
scene: scene1
Testare le scene senza tablet
I test per la scena 0 e la scena 5 possono essere eseguiti 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 di serie del tablet deve essere valido anche se il tablet non viene utilizzato perché la configurazione della classe di test assegna il valore dell'ID seriale per il tablet.
Esecuzione di singoli test
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 nella 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, devi
specificare il testbed con il flag --test_bed. Ad esempio:
python tests/scene1_1/test_black_white.py --config config.yml --test_bed TEST_BED_TABLET_SCENES
Artefatti di test
In Android 12, gli artefatti di test per Fotocamera ITS vengono archiviati in modo simile ad Android 11 o versioni precedenti, ma con le seguenti modifiche:
- Per maggiore chiarezza, la directory
/tmpdell'artefatto di test haCameraITS_anteposto alla stringa casuale di 8 caratteri. - L'output e gli errori dei test vengono memorizzati in
test_log.DEBUGper ogni test anziché intest_name_stdout.txtetest_name_stderr.txt. - I logcat del DUT e del tablet di ogni singolo test sono memorizzati
nella directory
/tmp/CameraITS_########, semplificando il debug poiché vengono registrate tutte le informazioni necessarie per eseguire il debug dei problemi 3A.
Testa le modifiche
In Android 12 le scene per tablet sono file PNG anziché PDF. L'utilizzo 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 fotocamere 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 sia di test_channel_saturation.
La tabella seguente descrive i due singoli test in Android 11.
| Nome del test | Primo livello API | Verifiche |
|---|---|---|
| scena1_1/test_black_white.py | TUTTE | 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 per le differenze [255, 255, 255] per eliminare la tinta del colore nelle immagini bianche. |
La seguente tabella descrive il test unito, scene1_1/test_black_white.py, in Android 12.
| Nome del test | Primo livello API | Verifiche |
|---|---|---|
| scena1_1/test_black_white.py | TUTTE | 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 tinta del colore nelle immagini bianche. |
scene1_1/test_burst_sameness_manual.py
Il test test_burst_sameness_manual viene eseguito su fotocamere
fisiche nascoste in Android 12.
scene1_2/test_tonemap_sequence.py
Il test test_tonemap_sequence viene eseguito su fotocamere LIMITATE con Android
12.
scena1_2/test_yuv_plus_raw.py
Il test test_yuv_plus_raw viene eseguito su fotocamere
fisiche nascoste in Android 12.
scene2_a/test_format_combos.py
Il test test_format_combos viene eseguito su fotocamere LIMITATE con 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 di 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 il rilevamento di un contorno secondario (il cerchio) all'interno del contorno principale (il quadrato) con filtri per dimensioni e colore. Android 12 utilizza un metodo che prevede di trovare tutti i contorni e poi filtrare in base alle funzionalità più circolari. Per escludere i cerchi spuri sul display, è necessaria un'area con un contorni minimo e il contorno del cerchio deve essere nero.
I contorni e i relativi criteri di selezione sono mostrati nella seguente immagine.
Figura 1. Disegno concettuale di contorni e criteri di selezione
Il metodo per Android 12 è più semplice e consente di risolvere il problema di ritaglio della casella delimitante in alcuni tablet da display. Tutti i candidati al cerchio vengono registrati a scopo di debug.
In Android 12, il test di ritaglio viene eseguito per i dispositivi FULL e LEVEL3. Le versioni di Android 11 o precedenti ignorano le affermazioni 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 del dispositivo e
al primo livello dell'API.
| A livello di dispositivo | Primo livello API | Verifiche |
|---|---|---|
| LIMITATA | TUTTE | Proporzioni Campo visivo per i formati 4:3, 16:9, 2:1 |
| COMPLETO | < 31 | Proporzioni Campo visivo per i formati 4:3, 16:9, 2:1 |
| COMPLETO | ≥ 31 | Ritaglio Proporzioni Campo visivo per i formati 4:3, 16:9, 2:1 |
| LEVEL3 | TUTTE | Ritaglio Proporzioni Campo visivo 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 sottoposto a refactoring per tenere conto in modo più accurato del ritaglio su sensori che non corrispondono alle proporzioni dell'acquisizione.
Codice Python 2 per Android 11
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 Python 3 per Android 12
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 precedenti ad Android 12, viene utilizzata l'intera immagine per trovare le 240 migliori caratteristiche, che vengono poi mascherate al 20% del centro per evitare effetti di scorrimento della serratura. Il requisito minimo di elementi è 30.
Se le funzionalità trovate con questo metodo non sono sufficienti, Android 12 maschera inizialmente il 20% della zona di rilevamento delle funzionalità al centro e limita il numero massimo di funzionalità al doppio del requisito minimo.
L'immagine seguente mostra la differenza tra il rilevamento delle funzionalità di Android 11 e di Android 12. L'aumento della soglia minima dei requisiti delle funzionalità comporta il rilevamento di funzionalità di scarsa qualità e influisce negativamente sulle misurazioni.
Figura 2. Differenza di rilevamento delle funzionalità tra Android 11 e Android 12
Nuovi test
scene0/test_solid_color_test_pattern.py
Per Android 12 è stato attivato un nuovo test, test_solid_color_test_pattern. Questo test è abilitato per tutte le videocamere ed è
descritto nella tabella seguente.
| Scena | Nome del test | Primo livello API | Descrizione |
|---|---|---|---|
| 0 | test_color_solid_test_pattern | 31 | Conferma l'output delle immagini in tinta unita e la programmabilità dei colori dell'immagine. |
I pattern di test con colori a tinta unita devono essere attivati per supportare la modalità Privacy della fotocamera.
Il test test_solid_color_test_pattern conferma l'output dell'immagine YUV con colore a tinta unita
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 pattern di prova. Questo test utilizzaSOLID_COLOR.android.sensor.testPatternData: consente di impostare i valori dei pattern di test R, Gr, Gb, G per la modalità pattern di test.
Per una descrizione del motivo di prova a tinta unita, consulta
SENSOR_TEST_PATTERN_MODE_SOLID_COLOR.
Metodo
I frame YUV vengono acquisiti per i parametri impostati e i contenuti dell'immagine vengono convalidati. Il pattern di prova viene visualizzato direttamente dal sensore di immagine, quindi non è richiesta una scena particolare. Se PER_FRAME_CONTROL è supportato, viene acquisito un singolo frame YUV per ogni impostazione testata. Se PER_FRAME_CONTROL non è supportato, vengono acquisiti quattro fotogrammi e viene analizzato solo l'ultimo fotogramma per massimizzare la copertura dei test su LIMITED videocamere.
Le acquisizioni YUV sono impostate su pattern di test BLACK, WHITE, RED, GREEN e
BLUE completamente saturi. Poiché la definizione del pattern di prova è in base al pattern Bayer del sensore, i canali di colore devono essere impostati per ogni colore come mostrato nella tabella seguente.
| Colore | testPatternData (RGGB) |
|---|---|
| NERO |
(0, 0, 0, 0)
|
| BIANCO |
(1, 1, 1, 1)
|
| RED |
(1, 0, 0, 0)
|
| VERDE |
(0, 1, 1, 0)
|
| BLU |
(0, 0, 0, 1)
|
Tabella di asserzione
La seguente tabella descrive le asserzioni di test per
test_solid_color_test_pattern.py.
| Fotocamera Primo livello API |
Tipo di fotocamera | Colori rivendicati |
|---|---|---|
| 31 | Bayer | NERO, BIANCO, ROSSO, VERDE, BLU |
| 31 | MONO | NERO, BIANCO |
| < 31 | Bayer/MONO | NERO |
Test delle classi di rendimento
scene2_c/test_camera_launch_perf_class.py
Verifica che l'avvio della fotocamera sia inferiore a 500 ms sia per la fotocamera anteriore sia per quella posteriore con la scena di volti scene2_c.
scene2_c/test_jpeg_capture_perf_class.py
Verifica che la latenza di acquisizione JPEG a 1080p sia inferiore a 1 secondo per la fotocamera principale anteriore e posteriore con la scena del volto scene2_c.