Un certain nombre de modifications apportées à Camera ITS sont incluses dans la version d'Android 12. Cette page résume les modifications qui se répartissent en quatre grandes catégories:
- Refactoring vers Python 3
- Adoption du framework de test Mobly
- Tester les modifications
- Nouveaux tests
Refactoring vers Python 3
En raison de l'abandon de Python 2.7 en janvier 2020, l'ensemble du codebase ITS de Camera a été refactorisé 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
- pySerial 3.5
- Pillow 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 antérieures et est refactorisé en Python 3.
Tous les tests individuels sont refactorisés et utilisent la nouvelle classe de configuration des tests définie dans tests/its_base_test.py. La plupart des noms et des fonctionnalités des tests restent inchangés.
Dans Android 12, tous les tests individuels chargent désormais leurs scènes. Bien que le chargement de la scène pour chaque test augmente la durée globale du test, il permet de déboguer des tests individuels.
Pour en savoir plus sur les modifications de test individuelles, consultez la section Modifications de test.
Les modules Python suivants sont refactorisés et leur nom est modifié:
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
Adoption du framework de test Mobly
Mobly est un framework de test basé sur Python qui prend en charge les scénarios de test nécessitant plusieurs appareils avec des configurations matérielles personnalisées. La solution ITS de la caméra utilise l'infrastructure de test Mobly pour un meilleur contrôle et une meilleure journalisation des tests.
La solution ITS de la caméra utilise l'infrastructure de test Mobly pour un meilleur contrôle et journalisation des tests. Mobly est un framework de test basé sur Python qui prend en charge les cas de test nécessitant plusieurs appareils avec des configurations matérielles personnalisées. Pour en savoir plus sur Mobly, consultez google/mobly.
Fichiers config.yml
Avec le framework Mobly, vous pouvez configurer un appareil testé (DUT) et une tablette de graphique dans la classe its_base_test. Un fichier config.yml (YAML) permet de créer un banc d'essais Mobly. Plusieurs plates-formes de test peuvent être configurées dans ce fichier de configuration, par exemple une tablette et une plate-forme de fusion de capteurs. Dans la section du contrôleur de chaque banc d'essai, vous pouvez spécifier device_ids pour identifier les appareils Android appropriés au lanceur de test. En plus des ID d'appareil, d'autres paramètres tels que brightness, chart_distance, debug_mode, camera_id et scene_id de tablette sont transmis dans la classe de test. Voici les valeurs de paramètre de test courantes:
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 d'essai. Lors de l'initialisation, le lanceur de test 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 d'essais peut être appelé à l'aide de tools/run_all_tests.py. Si aucune valeur de ligne de commande n'est présente, les tests sont exécutés avec les valeurs du fichier config.yml.
Vous pouvez également remplacer les valeurs des fichiers de configuration camera et scene au niveau de la ligne de commande à l'aide de commandes semblables à Android 11 ou version antérieure.
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'essais doit inclure le mot clé SENSOR_FUSION. Le testbed correct est déterminé par les scènes testées. Android 12 est compatible avec les contrôleurs Arduino et Canakit pour la fusion de capteurs.
Voici 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 montage de test 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 plates-formes de test
Plusieurs plates-formes de test peuvent être incluses dans le fichier de configuration. La combinaison la plus courante consiste à disposer à la fois d'un banc d'essai pour tablette et d'un banc d'essai pour la fusion de capteurs.
Voici un exemple de fichier config.yml avec des plates-formes de test de fusion de capteurs et de 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
- 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 restent compatibles avec Android 12.
Toutefois, le banc d'essais doit identifier les tests en tant que tels avec le mot clé MANUAL dans le nom du banc d'essais. De plus, le testbed ne peut pas inclure d'ID de tablette.
Voici 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 tablette
Les tests de la scène 0 et de la scène 5 peuvent être effectués avec TEST_BED_TABLET_SCENES ou TEST_BED_MANUAL. Toutefois, si les tests sont effectués avec TEST_BED_TABLET_SCENES, la tablette doit être connectée et son numéro de série doit être valide, même si elle n'est pas utilisée, car la configuration de la classe de test attribue la valeur du numéro de série à la tablette.
Exécuter des tests individuels
Des tests individuels ne peuvent être exécutés qu'à 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. En outre, si le fichier de configuration contient plusieurs plates-formes de test, vous devez spécifier la plate-forme de test avec l'indicateur --test_bed. Exemple :
python tests/scene1_1/test_black_white.py --config config.yml --test_bed TEST_BED_TABLET_SCENES
Artefacts de test
Sous Android 12, les artefacts de test pour l'ITS de l'appareil photo sont stockés de manière similaire à Android 11 ou version antérieure, mais avec les modifications suivantes:
- Pour plus de clarté, le répertoire
/tmpde l'artefact de test est précédé deCameraITS_dans la chaîne aléatoire de 8 caractères. - La sortie et les erreurs des tests sont stockées dans
test_log.DEBUGpour chaque test au lieu detest_name_stdout.txtettest_name_stderr.txt. - Les logcats de l'appareil de test 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 pour 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.
scene0/test_jitter.py
Le test test_jitter s'exécute sur les caméras cachées physiques dans Android 12.
scène1_1/test_noir_blanc.py
Pour Android 12, test_black_white possède les fonctionnalités de test_black_white et de test_channel_saturation.
Le tableau suivant décrit les deux tests individuels d'Android 11.
| Nom du test | Premier niveau d'API | Assertions |
|---|---|---|
| scene1_1/test_black_white.py | TOUT | Exposition courte, valeurs RVB à faible gain : ~[0, 0, 0] Exposition longue, valeurs RVB à gain élevé : ~[255, 255, 255] |
| scene1_1/test_channel_saturation.py | 29 | Tolérance réduite pour les différences [255, 255, 255] afin d'é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 d'API | Assertions |
|---|---|---|
| scene1_1/test_black_white.py | TOUT | 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. |
scène1_1/test_intensive_sameness_manual.py
Le test test_burst_sameness_manual s'exécute sur les caméras cachées physiques dans Android 12.
scene1_2/test_tonemap_sequence.py
Le test test_tonemap_sequence s'exécute sur les appareils photo LIMITED sous Android 12.
scene1_2/test_yuv_plus_raw.py
Le test test_yuv_plus_raw s'exécute sur les caméras cachées physiques dans Android 12.
scene2_a/test_format_combos.py
Le test test_format_combos s'exécute sur un nombre limité d'appareils photo dans Android 12.
scene3/test_flip_mirror.py
Le test test_flip_mirror s'exécute sur les appareils photo 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 impliquait de trouver 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 à trouver tous les contours, puis à filtrer en fonction des caractéristiques les plus circlisses. Pour masquer les cercles parasites à l'écran, vous devez spécifier une zone de contour minimale. Le contour du cercle doit être noir.
Les contours et leurs critères de sélection sont illustrés dans l'image suivante.
Figure 1 : Dessin conceptuel de contours et de critères de sélection
La méthode Android 12 est plus simple et permet de résoudre le problème de découpe de la zone de délimitation sur certaines tablettes d'affichage. Tous les cercles candidats sont consignés à des fins de débogage.
Dans Android 12, le test de recadrage est exécuté pour les appareils FULL et LEVEL3. Les versions d'Android 11 ou 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 au premier niveau d'API.
| Au niveau de l'appareil | Premier niveau d'API | Assertions |
|---|---|---|
| LIMITÉE | TOUT | Format Champ de vision pour les formats 4:3, 16:9 et 2:1 |
| COMPLET | < 31 | Format Format 4:3, 16:9 et 2:1 |
| COMPLET | ≥ 31 | Recadrer Format FoV pour les formats 4:3, 16:9 et 2:1 |
| LEVEL3 | TOUT | Recadrer Format Champ de vision pour les formats 4:3, 16:9 et 2:1 |
scene4/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 format 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 d'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 permettant de détecter des caractéristiques dans les images est ajoutée pour le test de fusion de capteurs.
Dans les versions antérieures à Android 12, l'image entière est utilisée pour trouver les 240 meilleures fonctionnalités, qui sont ensuite masquées à 20% au centre afin d'éviter les effets de l'obturateur glissant (30 fonctionnalités minimales requises).
Si les éléments détectés par cette méthode sont insuffisants, Android 12 masque d'abord la zone de détection des éléments au centre de 20% et limite le nombre maximal d'éléments à deux fois la limite minimale requise.
L'image suivante montre la différence entre la détection de fonctionnalités d'Android 11 et d'Android 12. Augmenter le seuil de fonctionnalité minimale requise permet de détecter les fonctionnalités de mauvaise qualité et a un impact négatif sur les mesures.
Figure 2. Différences de détection de fonctionnalités entre Android 11 et Android 12
Nouveaux tests
scene0/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 décrit dans le tableau suivant.
| Scène | Nom du test | Premier niveau d'API | Description |
|---|---|---|---|
| 0 | test_solid_color_test_pattern | 31 | Confirme la sortie d'images en couleur unie et la programmabilité des couleurs des images. |
Les motifs de test des couleurs unies doivent être activés pour prendre en charge le mode Confidentialité de l'appareil photo.
Le test test_solid_color_test_pattern confirme la sortie de l'image YUV en couleur unie avec la couleur définie par le motif sélectionné. La couleur de l'image change selon la spécification.
Paramètres
cameraPrivacyModeSupport: détermine si l'appareil photo est compatible avec le mode de confidentialité.android.sensor.testPatternMode: définit le mode du motif de test. Ce test utiliseSOLID_COLOR.android.sensor.testPatternData: définit les valeurs du modèle de test R, Gr, Gb et G pour le mode de modèle de test.
Pour obtenir une description du modèle de test de couleur unie, consultez la section 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é. Le motif de test est généré directement à partir du capteur d'image. Aucune scène particulière n'est donc requise. Si PER_FRAME_CONTROL est compatible, 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, et seule la dernière est analysée pour maximiser la couverture des tests dans les caméras LIMITED.
Les captures YUV sont définies sur des modèles de test BLACK, WHITE, RED, GREEN et BLUE entièrement saturés. Comme la définition du motif de test est basée sur le 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 des assertions
Le tableau suivant décrit les assertions de test pour test_solid_color_test_pattern.py.
| Appareil photo Premier niveau d'API |
Type d'appareil photo | Couleurs appliquées |
|---|---|---|
| 31 | Bayer | NOIR, BLANC, ROUGE, VERT, BLEU |
| 31 | MONO | NOIR, BLANC |
| < 31 | Bayer/MONO | NOIR |
Tests de classe de performances
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 à une seconde pour les caméras principales avant et arrière avec la scène de visage scene2_c.