Notes de version de la suite de tests d'images de caméra Android 12

Un certain nombre de caméras ITS changements sont inclus dans la version Android 12. Cette page résume les changements qui se répartissent en quatre grandes catégories :

Refactorisation 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 principal lanceur de test, tools/run_all_tests.py , reste le même que les versions Android 11 ou moins et est refactorisé à Python 3.

Tous les tests individuels sont refactorisés et utiliser la nouvelle classe d'installation de test défini dans les tests/its_base_test.py . La plupart des noms de test et des fonctionnalités restent les mêmes. Dans Android 12, tous les tests individuels chargent désormais leurs scènes. Alors que le chargement de la scène pour chaque test augmente la durée globale du test, il permet le débogage de tests individuels.

Pour plus d' informations sur les changements de test individuels, voir les changements de test .

Les modules Python suivants sont remaniés avec un changement de nom :

  • pymodules/its/caps.pyutils/camera_properties_utils.py
  • pymodules/its/cv2image.pyutils/opencv_processing_utils.py
  • pymodules/its/device.pyutils/its_session_utils.py
  • pymodules/its/error.pyutils/error_util.py
  • pymodules/its/image.pyutils/image_processing_utils.py
  • pymodules/its/objects.pyutils/capture_request_utils.py
  • pymodules/its/target.pyutils/target_exposure_utils.py
  • tools/hw.pyutils/sensor_fusion_utils.py

Adoption du framework de test Mobly

Mobly est un cas de test framework de test en Python soutien qui nécessitent plusieurs périphériques 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, voir google / mobly .

fichiers config.yml

Avec le cadre Mobly, vous pouvez mettre en place un dispositif sous test (DUT) et une tablette graphique dans la its_base_test classe. Un config.yml fichier (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, une tablette et un banc d'essai de fusion de capteurs. Au sein de la section de commande 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 de dispositif, 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. 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 sous forme de comprimés, le mot - clé TABLET doit être présent au nom de banc d' essai. Lors de l' initialisation, le coureur de test Mobly initialise TestParams et les transmet aux tests individuels.

Ce qui suit est un échantillon config.yml fichier pour des courses sous forme de comprimé.

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 invoqué à l' aide des tools/run_all_tests.py . Si aucune valeur de ligne de commande sont présents, les tests obtenus avec les config.yml valeurs du fichier. En outre, vous pouvez remplacer les camera et scene valeurs du fichier de configuration sur la ligne de commande à l' aide des commandes similaires pour les applications 11 ou moins.

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

Test de fusion de capteurs

Pour les essais de fusion de capteurs , le nom de banc d' essai doit inclure le mot - clé SENSOR_FUSION . Le banc d'essai correct est déterminé par les scènes testées. Applications 12 supporte à la fois Arduino et Canakit contrôleurs de fusion de capteurs .

Ce qui suit est un échantillon config.yml fichier pour les cycles de fusion du capteur.

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 capteurs de fusion 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 de tablette et d'un banc d'essai de fusion de capteurs.

Ce qui suit est un exemple de config.yml fichier avec les deux bancs d' essai de fusion comprimé et le capteur.

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 manuel

Les tests manuels continue à être pris en charge dans Android 12. Cependant, le banc d' essai doit identifier le test en tant que tel avec le mot - clé MANUAL au nom de banc d' essai. De plus, le banc d'essai ne peut pas inclure d'ID de tablette.

Ce qui suit est un exemple config.yml fichier pour le test manuel.

TestBeds:
  - Name: TEST_BED_MANUAL
    Controllers:
        AndroidDevice:
          - serial: 8A9X0NS5Z
            label: dut

    TestParams:
      debug_mode: "False"
      camera: 0
      scene: scene1

Tester des scènes sans tablettes

Test de scène 0 et scène 5 peut être fait 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é et la tablette ID série doit être valide même si la tablette n'est pas utilisé parce que les cessionnaires de configuration de la classe de test la valeur de numéro de série pour la tablette.

Exécution de tests individuels

Des tests individuels peuvent être exécutés uniquement à des fins de débogage parce que leurs résultats ne sont pas à CTS Verifier . Parce que les config.yml fichiers ne peuvent être effacés à la ligne de commande pour la camera et la scene , ces paramètres doivent être corrects dans le config.yml fichier pour le test individuel en question. De plus, s'il y a plus d'un banc d' essai dans le fichier de configuration, vous devez spécifier le banc d' essai avec le --test_bed drapeau. 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 qu'Android 11 ou version antérieure, mais avec les modifications suivantes :

  • L'artefact Test /tmp répertoire a CameraITS_ ajouté au début de la chaîne aléatoire de 8 caractères pour plus de clarté.
  • Sortie de test et les erreurs sont stockées dans test_log.DEBUG pour chaque test au lieu de test_name_stdout.txt et test_name_stderr.txt .
  • Les logcats et de comprimés de sous test chaque test sont stockés dans les /tmp/CameraITS_######## répertoire qui simplifie le débogage que toutes les informations nécessaires pour débogage des problèmes de 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.

scene0/test_jitter.py

Le test_jitter test est exécuté sur des caméras cachées physiques dans Android 12.

scène1_1/test_black_white.py

Pour Android 12, test_black_white a la fonctionnalité des deux test_black_white et test_channel_saturation .

Le tableau suivant décrit les deux tests individuels dans Android 11.

Nom du test Premier niveau d'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]
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 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_burst_sameness_manual test est exécuté sur des caméras cachées physiques dans Android 12.

scene1_2/test_tonemap_sequence.py

Le test_tonemap_sequence test est exécuté sur les caméras LIMITED Android 12.

scene1_2/test_yuv_plus_raw.py

Les test_yuv_plus_raw séries de tests sur des caméras cachées physiques dans Android 12.

scene2_a/test_format_combos.py

Le test_format_combos test est exécuté sur les caméras LIMITED Android 12.

scene3/test_flip_mirror.py

Le test_flip_mirror test est exécuté sur les caméras LIMITED Android 12.

scene4/test_aspect_ratio_and_crop.py

Trouver des cercles dans scene4/test_aspect_ratio_and_crop.py est refactorisé dans Android 12.

Les versions antérieures d'Android utilisaient une méthode consistant à rechercher un contour enfant (le cercle) à l'intérieur du contour parent (le carré) avec des filtres de taille et de couleur. Applications 12 utilise un procédé qui consiste à trouver tous les contours et le filtrage en trouvant des caractéristiques qui sont les plus circlish. Pour éliminer 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 illustrés dans l'image suivante.

Dessin conceptuel des contours et 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 l'écrêtage de la zone de délimitation dans certaines tablettes d'affichage. Tous les candidats de cercle sont enregistrés à des fins de débogage.

Dans Android 12, le test de culture est exécutée pour FULL et LEVEL3 périphériques. Android 11 versions ou inférieure sauter les assertions de test de culture pour FULL appareils.

Le tableau ci - dessous les assertions de test_aspect_ratio_and_crop.py qui correspondent à un niveau de dispositif donné et le premier niveau de l' API.

Niveau de l'appareil Premier niveau d'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

scene4/test_multi_camera_alignment.py

La méthode undo_zoom() pour YUV captures dans scene4/test_multi_camera_alignment.py a été refondus pour compte avec plus de précision pour les cultures sur des capteurs qui ne correspondent pas le ratio d'aspect de la capture.

Code 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

Code 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

Dans Android 12, une méthode de détection des caractéristiques dans les 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 d'obturateur roulant avec une exigence minimale 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 les fonctionnalités minimales requises.

L'image suivante montre la différence entre la détection de fonctionnalités Android 11 et Android 12. L'augmentation du seuil d'exigence minimale des fonctionnalités entraîne la détection de fonctionnalités de mauvaise qualité et affecte négativement les mesures.

différence de détection de fonctionnalité entre Android 11 et Android 12 sensor_fusion détection de fonctionnalité

Figure 2. Différence de détection de caractéristiques entre Android 11 et Android 12

Nouveaux essais

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 ci - dessous.

Scène Nom du test Premier niveau d'API La description
0 test_solid_color_test_pattern 31 Confirme la sortie d'image en couleur unie et la programmabilité de la couleur de l'image.

Les motifs de test de couleur unie doivent être activés pour prendre en charge le mode de confidentialité de la caméra. Le test_solid_color_test_pattern test confirme sortie d'image YUV couleur unie avec la couleur définie par le motif sélectionné, et change de couleur d'image selon la spécification.

Paramètres

  • cameraPrivacyModeSupport : Détermine si les supports de l' appareil en mode de confidentialité.
  • android.sensor.testPatternMode : Définit le mode de motif de test. Ce test utilise SOLID_COLOR .
  • android.sensor.testPatternData : Réglage de la R, Gr, Gb, les valeurs de configuration de test G pour le mode de motif de test.

Pour une description du motif de test de couleur unie, voir SENSOR_TEST_PATTERN_MODE_SOLID_COLOR .

Méthode

Les trames YUV sont capturées pour les paramètres définis et le contenu de l'image est validé. Le motif de test est émis 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é pour chaque paramètre testé. Si PER_FRAME_CONTROL est pas pris en charge, quatre cadres sont capturés avec seulement la dernière trame analysée afin de maximiser la couverture des tests dans LIMITED caméras.

Captures YUV sont mis à complètement saturé BLACK , WHITE , RED , GREEN et BLUE modèles de test. Comme la définition du motif de test est conforme 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)
LE NOIR (0, 0, 0, 0)
BLANCHE (1, 1, 1, 1)
ROUGE (1, 0, 0, 0)
VERT (0, 1, 1, 0)
BLEU (0, 0, 0, 1)

Tableau d'assertion

Le tableau suivant décrit les assertions de test pour test_solid_color_test_pattern.py .

Caméra
Premier niveau d'API
Type de caméra Des couleurs affirmées
31 Bayer NOIR, BLANC, ROUGE, VERT, BLEU
31 MONO NOIR BLANC
< 31 Bayer/MONO LE 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.