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
- Testare in mobilità l'adozione del framework
- Testare le modifiche
- Nuovi test
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:
- Python 3.7.9 o Python 3.7.10
- OpenCV3.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
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.py
→utils/camera_properties_utils.py
-
pymodules/its/cv2image.py
→utils/opencv_processing_utils.py
-
pymodules/its/device.py
→utils/its_session_utils.py
-
pymodules/its/error.py
→utils/error_util.py
-
pymodules/its/image.py
→utils/image_processing_utils.py
-
pymodules/its/objects.py
→utils/capture_request_utils.py
-
pymodules/its/target.py
→utils/target_exposure_utils.py
-
tools/hw.py
→utils/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
haCameraITS_
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é intest_name_stdout.txt
etest_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.
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.
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 utilizzaSOLID_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.