Notes de version de la suite Camera Image Test d'Android 12

La version Android 12 inclut un certain nombre de modifications apportées à Camera ITS. Cette page récapitule les modifications, qui se répartissent en quatre grandes catégories :

Refactoriser vers Python 3

En raison de l'abandon de Python 2.7 en janvier 2020, l'ensemble de la base de code Camera ITS a été refactorisé en Python 3. Les versions et bibliothèques Python suivantes sont requises dans Android 12 :

Le lanceur de test principal, tools/run_all_tests.py, reste le même que pour 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 de test définie dans tests/its_base_test.py. La plupart des noms et des 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è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 apportées aux tests individuels, consultez Modifications apportées aux tests.

Les modules Python suivants ont été refactorisés et leur nom a été modifié :

  • 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 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. Camera ITS utilise l'infrastructure de test Mobly pour améliorer le contrôle et la journalisation des tests.

Camera ITS utilise l'infrastructure de test Mobly pour améliorer le contrôle et la 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 graphique dans la classe its_base_test. Un fichier config.yml (YAML) est utilisé pour créer un banc d'essai Mobly. Plusieurs bancs d'essai peuvent être configurés dans ce fichier de configuration, par exemple, un banc d'essai pour tablette et un banc d'essai pour la 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 pour le programme d'exécution des tests. En plus des ID d'appareil, d'autres paramètres tels que la tablette brightness, chart_distance, debug_mode, camera_id et scene_id sont transmis dans la classe de test. Voici quelques valeurs de paramètres 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 figurer dans le nom du banc d'essai. Lors de l'initialisation, le testeur 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'essai peut être appelé à l'aide de 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 des fichiers de configuration camera et scene au niveau de la ligne de commande à l'aide de commandes semblables à celles d'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'essai doit inclure le mot clé SENSOR_FUSION. Le banc d'essai approprié 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 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 d'essai 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.

Voici un exemple de fichier config.yml avec des bancs d'essai pour tablette et fusion 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 restent compatibles avec Android 12. Toutefois, le banc d'essai doit identifier les tests en tant que tels avec le mot clé MANUAL dans son nom. De plus, le module 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 tablettes

Les scènes 0 et 5 peuvent être testées avec TEST_BED_TABLET_SCENES ou TEST_BED_MANUAL. Toutefois, si le test est effectué 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

Les 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. De plus, si le fichier de configuration contient plusieurs bancs d'essai, vous devez spécifier le banc d'essai avec l'option --test_bed. Exemple :

python tests/scene1_1/test_black_white.py --config config.yml --test_bed TEST_BED_TABLET_SCENES

Artefacts de test

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 :

  • Pour plus de clarté, le répertoire de l'artefact de test /tmp est précédé de CameraITS_ avant la chaîne aléatoire de huit caractères.
  • Les sorties et les erreurs de test sont stockées dans test_log.DEBUG pour chaque test au lieu de test_name_stdout.txt et test_name_stderr.txt.
  • Les logcats de la tablette et du DUT de chaque test individuel sont stockés dans le répertoire /tmp/CameraITS_########, ce qui simplifie le débogage, car toutes les informations nécessaires au débogage des problèmes 3A sont enregistrées.

Tester les modifications

Dans Android 12, les scènes de 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 des caméras physiques cachées dans Android 12.

scene1_1/test_black_white.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 dans Android 11.

Nom du test Premier niveau d'API Assertions
scene1_1/test_black_white.py TOUS Valeurs RVB à faible gain et courte exposition : ~[0, 0, 0]
Valeurs RVB à gain élevé et longue exposition : ~[255, 255, 255]
scene1_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 d'API Assertions
scene1_1/test_black_white.py TOUS Valeurs RVB à faible exposition et gain faible : ~[0, 0, 0]
Valeurs RVB à exposition longue et 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 dans Android 12.

scene1_2/test_tonemap_sequence.py

Le test test_tonemap_sequence s'exécute sur des CAMÉRAS LIMITÉES dans Android 12.

scene1_2/test_yuv_plus_raw.py

Le test test_yuv_plus_raw s'exécute sur des caméras physiques cachées dans Android 12.

scene2_a/test_format_combos.py

Le test test_format_combos s'exécute sur des CAMÉRAS LIMITÉES dans Android 12.

scene3/test_flip_mirror.py

Le test test_flip_mirror s'exécute sur des CAMÉRAS LIMITÉES dans Android 12.

scene4/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 anciennes versions d'Android utilisaient une méthode qui consistait à trouver un contour enfant (le cercle) à l'intérieur du contour parent (le carré) avec des filtres pour la taille et la couleur. Android 12 utilise une méthode qui consiste à trouver tous les contours, puis à filtrer en recherchant les caractéristiques les plus circulaires. Pour éliminer les cercles parasites sur l'écran, une aire de contour minimale est requise et le contour du cercle doit être noir.

Les contours et leurs critères de sélection sont illustrés dans l'image ci-dessous.

Dessin conceptuel des contours et des critères de sélection

Figure 1 : Dessin conceptuel des contours et des critères de sélection

La méthode Android 12 est plus simple et permet de résoudre le problème de rognage des cadres de sélection sur certaines tablettes d'affichage. Tous les candidats aux cercles sont consignés à des fins de débogage.

Dans 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 liste les assertions pour test_aspect_ratio_and_crop.py qui correspondent à un niveau d'appareil et à un premier niveau d'API donnés.

Au niveau de l'appareil Premier niveau d'API Assertions
LIMITED TOUS Proportions
Champ de vision pour les formats 4:3, 16:9 et 2:1
COMPLET < 31 Proportions
Champ de vision pour les formats 4:3, 16:9 et 2:1
COMPLET ≥ 31 Recadrer
Proportions
Champ de vision pour les formats 4:3, 16:9 et 2:1
LEVEL3 TOUS Recadrer
Proportions
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 dont le format ne correspond pas à celui de la capture.

Code Python 2 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 des capteurs.

Dans les versions antérieures à Android 12, l'image entière est utilisée pour trouver les 240 meilleures caractéristiques, qui sont ensuite masquées au centre à 20 % pour éviter les effets d'obturateur roulant. Le nombre minimal de caractéristiques est de 30.

Si les caractéristiques trouvées par cette méthode sont insuffisantes, Android 12 masque d'abord la zone de détection des caractéristiques sur les 20 % centraux et limite le nombre maximal de caractéristiques à deux fois le nombre minimal requis.

L'image suivante montre la différence entre la détection de fonctionnalités d'Android 11 et d'Android 12. Si vous augmentez le seuil minimal requis pour les caractéristiques, vous détecterez des caractéristiques de mauvaise qualité, ce qui aura un impact négatif sur les mesures.

Différence de détection des fonctionnalités entre Android 11 et Android 12 sensor_fusion

Figure 2. Différence de détection des 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 est 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'une image en couleur unie et la programmabilité de la couleur de l'image.

Les mires de couleur unie doivent être activées pour que le mode Confidentialité de la caméra fonctionne. Le test test_solid_color_test_pattern confirme la sortie d'une image YUV en couleur unie, avec la couleur définie par le motif sélectionné, et les changements de couleur de l'image conformément aux spécifications.

Paramètres

  • cameraPrivacyModeSupport : détermine si la caméra est compatible avec le mode Confidentialité.
  • android.sensor.testPatternMode : définit le mode du signal de test. Ce test utilise SOLID_COLOR.
  • android.sensor.testPatternData : définit les valeurs de la mire de test R, Gr, Gb et G pour le mode Mire de test.

Pour obtenir une description du modèle de test de couleur unie, consultez SENSOR_TEST_PATTERN_MODE_SOLID_COLOR.

Méthode

Les frames YUV sont capturées pour les paramètres définis et le contenu de l'image est validé. La mire est générée directement 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 frames sont capturés, mais seul le dernier est analysé pour maximiser la couverture des tests dans les caméras LIMITED.

Les captures YUV sont définies sur des mires BLACK, WHITE, RED, GREEN et BLUE entièrement saturées. Étant donné que 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 de caméra Couleurs affirmé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 à 1 seconde pour les caméras avant et arrière principales avec la scène de visage scene2_c.