Un certain nombre de modifications de Camera ITS sont incluses dans la version Android 12. Cette page résume les changements qui se répartissent en quatre grandes catégories :
- Refactorisation vers Python 3
- Adoption du cadre de test Mobly
- Tester les modifications
- Nouveaux tests
Refactoriser vers Python 3
En raison de la dépréciation de Python 2.7 en janvier 2020, l'intégralité de la base de code de Camera ITS a été refactorisée vers Python 3. Les versions et bibliothèques Python suivantes sont requises dans Android 12 :
- Python 3.7.9 ou Python 3.7.10
- OpenCV 3.4.2
- Numpy 1.19.2
- Matplotlib 3.3.2
- Scipy 1.5.2
- pySérie 3.5
- Oreiller 8.1.0
- PyYAML 5.3.1
Le lanceur de test principal, tools/run_all_tests.py
, reste le même que les versions Android 11 ou inférieures et est refactorisé vers Python 3.
Tous les tests individuels sont refactorisés et utilisent la nouvelle classe de configuration de test définie dans tests/its_base_test.py
. La plupart des noms et fonctionnalités des tests restent les mêmes. Dans Android 12, tous les tests individuels chargent désormais leurs scènes. Bien que le chargement de scènes pour chaque test augmente la durée globale du test, il permet le débogage de tests individuels.
Pour plus d’informations sur les modifications de test individuelles, consultez Modifications de test .
Les modules Python suivants sont refactorisés avec un changement de nom :
-
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
Adoption du cadre de test Mobly
Mobly est un framework de test basé sur Python prenant en charge les cas de test qui nécessitent plusieurs appareils avec des configurations matérielles personnalisées. Camera ITS utilise l'infrastructure de test Mobly pour permettre un meilleur contrôle et une meilleure journalisation des tests.
Camera ITS utilise l'infrastructure de test Mobly pour permettre un meilleur contrôle et une meilleure journalisation des tests. Mobly est un framework de test basé sur Python prenant en charge les cas de test qui nécessitent plusieurs appareils avec des configurations matérielles personnalisées. Pour plus d'informations sur Mobly, consultez google/mobly .
fichiers config.yml
Avec le framework Mobly, vous pouvez configurer un appareil sous test (DUT) et une tablette graphique dans la classe its_base_test
. Un fichier config.yml
(YAML) est utilisé pour créer un banc de test Mobly. Plusieurs bancs d'essai peuvent être configurés dans ce fichier de configuration, par exemple une tablette et un banc d'essai de fusion de capteurs. Dans la section contrôleur de chaque banc de test, vous pouvez spécifier device_ids
pour identifier les appareils Android appropriés auprès du lanceur de test. En plus des ID d'appareil, d'autres paramètres tels que brightness
de la tablette, chart_distance
, debug_mode
, camera_id
et scene_id
sont transmis dans la classe de test. Les valeurs courantes des paramètres de test sont :
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)
Tests sur tablette
Pour les tests sur tablette, le mot-clé TABLET
doit être présent dans le nom du banc de test. Lors de l'initialisation, le programme d'exécution de tests Mobly initialise TestParams
et les transmet aux tests individuels.
Voici un exemple de fichier config.yml
pour les exécutions sur tablette.
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
Le banc de test peut être invoqué à l'aide tools/run_all_tests.py
. Si aucune valeur de ligne de commande n'est présente, les tests s'exécutent avec les valeurs du fichier config.yml
. De plus, vous pouvez remplacer les valeurs du fichier de configuration camera
et scene
sur la ligne de commande à l'aide de commandes similaires à Android 11 ou version antérieure.
Par exemple:
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
Tests de fusion de capteurs
Pour les tests de fusion de capteurs , le nom du banc d'essai doit inclure le mot clé SENSOR_FUSION
. Le banc d'essai correct est déterminé par les scènes testées. Android 12 prend en charge les contrôleurs Arduino et Canakit pour la fusion de capteurs .
Ce qui suit est un exemple de fichier config.yml
pour les exécutions de fusion de capteurs.
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
Pour exécuter des tests de fusion de capteurs avec le banc d'essai de fusion de capteurs , utilisez :
python tools/run_all_tests.py scenes=sensor_fusion
python tools/run_all_tests.py scenes=sensor_fusion camera=0
Plusieurs bancs d'essai
Plusieurs bancs de test peuvent être inclus dans le fichier de configuration. La combinaison la plus courante consiste à disposer à la fois d’un banc d’essai pour tablettes et d’un banc d’essai pour la fusion de capteurs.
Ce qui suit est un exemple de fichier config.yml
avec des bancs d'essai de fusion de tablettes et de capteurs.
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
Tests manuels
Les tests manuels continuent d'être pris en charge dans Android 12. Cependant, le banc de test doit identifier les tests en tant que tels avec le mot-clé MANUAL
dans le nom du banc de test. De plus, le banc de test ne peut pas inclure d’identifiant de tablette.
Ce qui suit est un exemple de fichier config.yml
pour les tests manuels.
TestBeds:
- Name: TEST_BED_MANUAL
Controllers:
AndroidDevice:
- serial: 8A9X0NS5Z
label: dut
TestParams:
debug_mode: "False"
chart_distance: 31.0
camera: 0
scene: scene1
Tester des scènes sans tablettes
Les tests pour la scène 0 et la scène 5 peuvent être effectués avec TEST_BED_TABLET_SCENES
ou avec TEST_BED_MANUAL
. Toutefois, si le test est effectué avec TEST_BED_TABLET_SCENES
, la tablette doit être connectée et l'ID de série de la tablette doit être valide même si la tablette n'est pas utilisée, car la configuration de la classe de test attribue la valeur de l'ID de série à la tablette.
Exécuter des tests individuels
Les tests individuels peuvent être exécutés uniquement à des fins de débogage, car leurs résultats ne sont pas signalés à CTS Verifier . Étant donné que les fichiers config.yml
ne peuvent pas être écrasés sur la ligne de commande pour camera
et scene
, ces paramètres doivent être corrects dans le fichier config.yml
pour le test individuel en question. De plus, s'il y a plusieurs bancs de test dans le fichier de configuration, vous devez spécifier le banc de test avec l'indicateur --test_bed
. Par exemple:
python tests/scene1_1/test_black_white.py --config config.yml --test_bed TEST_BED_TABLET_SCENES
Tester les artefacts
Dans Android 12, les artefacts de test pour Camera ITS sont stockés de la même manière que dans Android 11 ou version antérieure, mais avec les modifications suivantes :
- Le répertoire de l'artefact de test
/tmp
aCameraITS_
ajouté au début de la chaîne aléatoire de 8 caractères pour plus de clarté. - Les résultats des tests et les erreurs sont stockés dans
test_log.DEBUG
pour chaque test au lieu detest_name_stdout.txt
ettest_name_stderr.txt
. - Les logcats du DUT et de la tablette de chaque test individuel sont stockés dans le répertoire
/tmp/CameraITS_########
, ce qui simplifie le débogage car toutes les informations requises pour déboguer les problèmes 3A sont enregistrées.
Tester les modifications
Dans Android 12, les scènes de la tablette sont des fichiers PNG plutôt que des fichiers PDF. L'utilisation de fichiers PNG permet à davantage de modèles de tablettes d'afficher correctement les scènes.
scène0/test_jitter.py
Le test test_jitter
s'exécute sur des caméras physiques cachées sous Android 12.
scène1_1/test_black_white.py
Pour Android 12, test_black_white
possède les fonctionnalités de test_black_white
et test_channel_saturation
.
Le tableau suivant décrit les deux tests individuels dans Android 11.
Nom du test | Premier niveau API | Affirmations |
---|---|---|
scène1_1/test_black_white.py | TOUS | Exposition courte, valeurs RVB à faible gain ~[0, 0, 0] Exposition longue, valeurs RVB à gain élevé ~[255, 255, 255] |
scène1_1/test_channel_saturation.py | 29 | Tolérance réduite sur les différences [255, 255, 255] pour éliminer la teinte de couleur dans les images blanches. |
Le tableau suivant décrit le test fusionné, scene1_1/test_black_white.py, dans Android 12.
Nom du test | Premier niveau API | Affirmations |
---|---|---|
scène1_1/test_black_white.py | TOUS | Exposition courte, valeurs RVB à faible gain ~[0, 0, 0] Exposition longue, valeurs RVB à gain élevé ~ [255, 255, 255] et tolérance réduite entre les valeurs pour éliminer la teinte de couleur dans les images blanches. |
scene1_1/test_burst_sameness_manual.py
Le test test_burst_sameness_manual
s'exécute sur des caméras physiques cachées sous Android 12.
scène1_2/test_tonemap_sequence.py
Le test test_tonemap_sequence
s'exécute sur les caméras LIMITED sous Android 12.
scène1_2/test_yuv_plus_raw.py
Le test test_yuv_plus_raw
s'exécute sur des caméras physiques cachées sous Android 12.
scene2_a/test_format_combos.py
Le test test_format_combos
s'exécute sur les caméras LIMITED sous Android 12.
scène3/test_flip_mirror.py
Le test test_flip_mirror
s'exécute sur des caméras LIMITED sous Android 12.
scène4/test_aspect_ratio_and_crop.py
La recherche de cercles dans scene4/test_aspect_ratio_and_crop.py
a été refactorisée dans Android 12.
Les versions antérieures d'Android utilisaient une méthode qui consistait à rechercher un contour enfant (le cercle) à l'intérieur du contour parent (le carré) avec des filtres de taille et de couleur. Android 12 utilise une méthode qui consiste à rechercher tous les contours puis à filtrer en trouvant les fonctionnalités les plus circulaires . Pour filtrer les cercles parasites sur l'écran, une zone de contour minimale est requise et le contour du cercle doit être noir.
Les contours et leurs critères de sélection sont présentés dans l'image suivante.
Figure 1. Dessin conceptuel des contours et critères de sélection
La méthode Android 12 est plus simple et permet de résoudre le problème de découpage du cadre de délimitation dans certaines tablettes d'affichage. Tous les candidats au cercle sont enregistrés à des fins de débogage.
Sous Android 12, le test de recadrage est exécuté pour les appareils FULL
et LEVEL3
. Android 11 ou les versions antérieures ignorent les assertions de test de recadrage pour les appareils FULL
.
Le tableau suivant répertorie les assertions pour test_aspect_ratio_and_crop.py
qui correspondent à un niveau d'appareil donné et à un premier niveau d'API.
Niveau de l'appareil | Premier niveau API | Affirmations |
---|---|---|
LIMITÉ | TOUS | Ratio d'aspect FoV pour les formats 4:3, 16:9, 2:1 |
COMPLET | < 31 | Ratio d'aspect FoV pour les formats 4:3, 16:9, 2:1 |
COMPLET | ≥ 31 | Recadrer Ratio d'aspect FoV pour les formats 4:3, 16:9, 2:1 |
NIVEAU 3 | TOUS | Recadrer Ratio d'aspect FoV pour les formats 4:3, 16:9, 2:1 |
scène4/test_multi_camera_alignment.py
La méthode undo_zoom()
pour les captures YUV dans scene4/test_multi_camera_alignment.py
a été refactorisée pour tenir compte plus précisément du recadrage sur les capteurs qui ne correspondent pas au rapport hauteur/largeur de la capture.
Code Python 2 pour 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
Code Python 3 pour 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
Dans Android 12, une méthode de détection des caractéristiques des images est ajoutée pour le test de fusion de capteurs.
Dans les versions inférieures à Android 12, l'image entière est utilisée pour trouver les 240 meilleures fonctionnalités qui sont ensuite masquées au centre à 20 % pour éviter les effets de volet roulant, l'exigence minimale de fonctionnalités étant de 30 fonctionnalités.
Si les fonctionnalités trouvées par cette méthode sont insuffisantes, Android 12 masque d'abord la zone de détection des fonctionnalités au centre de 20 % et limite les fonctionnalités maximales à deux fois l'exigence minimale en fonctionnalités.
L'image suivante montre la différence entre la détection des fonctionnalités d'Android 11 et d'Android 12. L'augmentation du seuil minimum requis pour les fonctionnalités entraîne la détection de fonctionnalités de mauvaise qualité et affecte négativement les mesures.
Figure 2. Différence de détection des fonctionnalités entre Android 11 et Android 12
Nouveaux tests
scène0/test_solid_color_test_pattern.py
Un nouveau test, test_solid_color_test_pattern
, est activé pour Android 12. Ce test est activé pour toutes les caméras et est décrit dans le tableau suivant.
Scène | Nom du test | Premier niveau API | Description |
---|---|---|---|
0 | test_solid_color_test_pattern | 31 | Confirme la sortie d’image en couleur unie et la programmabilité des couleurs de l’image. |
Les mires de test de couleur unie doivent être activées pour prendre en charge le mode de confidentialité de la caméra. Le test test_solid_color_test_pattern
confirme la sortie d'image YUV en couleur unie avec la couleur définie par le motif sélectionné et la couleur de l'image change selon les spécifications.
Paramètres
-
cameraPrivacyModeSupport
: Détermine si la caméra prend en charge le mode confidentialité. -
android.sensor.testPatternMode
: Définit le mode du modèle de test. Ce test utiliseSOLID_COLOR
. -
android.sensor.testPatternData
: définit les valeurs du modèle de test R, Gr, Gb, G pour le mode modèle de test.
Pour une description du motif de test de couleur unie, voir SENSOR_TEST_PATTERN_MODE_SOLID_COLOR
.
Méthode
Les images YUV sont capturées pour les paramètres définis et le contenu de l'image est validé. La mire de test est directement émise par le capteur d’image, aucune scène particulière n’est donc requise. Si PER_FRAME_CONTROL
est pris en charge, une seule image YUV est capturée pour chaque paramètre testé. Si PER_FRAME_CONTROL
n'est pas pris en charge, quatre images sont capturées avec uniquement la dernière image analysée pour maximiser la couverture de test dans les caméras LIMITED
.
Les captures YUV sont définies sur des mires de test BLACK
, WHITE
, RED
, GREEN
et BLUE
entièrement saturées. Comme la définition du motif de test correspond au motif Bayer du capteur, les canaux de couleur doivent être définis pour chaque couleur, comme indiqué dans le tableau suivant.
Couleur | testPatternData (RGGB) |
---|---|
NOIR | (0, 0, 0, 0) |
BLANC | (1, 1, 1, 1) |
ROUGE | (1, 0, 0, 0) |
VERT | (0, 1, 1, 0) |
BLEU | (0, 0, 0, 1) |
Tableau d'assertions
Le tableau suivant décrit les assertions de test pour test_solid_color_test_pattern.py
.
Caméra Premier niveau API | Type de caméra | Des couleurs affirmées |
---|---|---|
31 | Bayer | NOIR, BLANC, ROUGE, VERT, BLEU |
31 | MONO | NOIR BLANC |
< 31 | Bayer/MONO | NOIR |
Tests de classe de performance
scene2_c/test_camera_launch_perf_class.py
Vérifie que le démarrage de la caméra est inférieur à 500 ms pour les caméras principales avant et arrière avec la scène de visage scene2_c.
scene2_c/test_jpeg_capture_perf_class.py
Vérifie que la latence de capture JPEG 1080p est inférieure à 1 seconde pour les caméras principales avant et arrière avec la scène de visage scene2_c.