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

Cette page résume les modifications apportées à Camera Image Test Suite (ITS) dans Android 11. Les modifications appartiennent aux catégories suivantes :

• Modifications matérielles
• Premiers tests MANDATÉS au niveau API
• Test d'éclairage validé
• Changements de nom de scène
• Tester les modifications et les ajouts
• Augmentation des tests de caméra LIMITÉS

Modifications matérielles

Android 11 introduit plusieurs modifications matérielles pour réduire les coûts et augmenter la disponibilité. Ces changements entrent dans les catégories suivantes :

• Fabricant supplémentaire
• Méthodes de fabrication unifiées
• Options de tablette accrues
• Ouverture réduite pour la tablette
• Nouveau contrôleur de fusion de capteurs

Fabricant supplémentaire

Rahi Systems est qualifié pour produire des boîtiers de test ITS en plus de notre fournisseur existant, MYWAY design. Les informations sur l'entreprise pour les fournisseurs qualifiés sont les suivantes :

• Systèmes Rahi Inc.
  48303 Fremont Blvd, Fremont CA 94538, États-Unis
  rahisystems.com/products/android-device-testing-equipment/
  [e-mail]
  [phone]

• Conception MYWAY
  4F., n° 163, Fu-Ying Road, district de XinZhuang, ville de New Taipei, Taiwan
  twmyway.com
  [e-mail]
  [phone]

Méthodes de fabrication unifiées

Le boîtier de test ITS-in-a-box rev1 à champ de vision régulier (RFoV) est repensé pour utiliser les méthodes de fabrication utilisées par le boîtier de test à large champ de vision (WFoV) et le boîtier de fusion de capteurs . La fonctionnalité est identique et, par souci de simplicité, la conception est appelée rev1a . La refonte permet aux fabricants de stocker un seul type de plastique pour fabriquer tous les boîtiers de test. De plus, le support de tablette et les supports d'éclairage ont été repensés pour gérer une plus grande variation de tablettes et de barres lumineuses LED.

Pour télécharger les dernières descriptions et dessins mécaniques, voir l'encadré RFoV (rev1a) et l'encadré WFoV (rev2.9) .

Options de tablette accrues

Des tablettes dont la Samsung Galaxy Tab A 10.1 et la Chuwi Hi9 Air 10.1 sont ajoutées à la liste des tablettes recommandées. Il est important que la tablette ne dispose pas de modulation de largeur d'impulsion (PWM) pour ajuster la luminosité de l'écran afin d'éliminer les bandes dans les images capturées.

Pour obtenir les dernières informations sur les tablettes recommandées, consultez Exigences relatives aux tablettes .

Ouverture réduite pour la tablette

Pour permettre l'utilisation de la Galaxy Tab A 10.1, l'ouverture de la tablette est légèrement réduite en hauteur pour les boîtiers de test RFoV (rev1a) et WFoV (rev2). Les révisions qui reflètent ces changements sont rev1a.1 et rev2.9. Pour ces dessins, voir la boîte RFoV (rev1a) et la boîte WFoV (rev2.9) .

Nouveau contrôleur de fusion de capteurs

Le matériel du contrôleur de fusion de capteurs a été repensé pour améliorer la fabricabilité. Le nouveau contrôleur est basé sur Arduino , avec un blindage de carte de routage personnalisé qui se monte sur l'Arduino. La figure 1 montre le bouclier et la figure 2 montre le dessin mécanique du boîtier. Le nouveau contrôleur est alimenté par une seule alimentation de 5 V qui alimente directement le moteur. L'électronique est entièrement contrôlée via le connecteur USB. L'alimentation électrique séparée permet une isolation complète entre l'électronique de commande et le servomoteur. De plus, un seul contrôleur peut contrôler jusqu'à six servomoteurs.

Figure 1. Vue de dessus du blindage Arduino

Figure 2. Conception du boîtier

Android 11 est rétrocompatible avec les contrôleurs existants. Pour appeler des tests avec le contrôleur basé sur Arduino, utilisez :

python tools/run_all_tests.py device=# camera=# rot_rig=arduino:1 scenes=sensor_fusion

Premier niveau API

Dans Android 10, les tests ITS sont désignés comme MANDATED et NOT_YET_MANDATED . Pour lancer en tant qu'appareil Android 10, tous les tests MANDATED doivent réussir. Les tests NOT_YET_MANDATED peuvent échouer mais sont comptabilisés comme PASS pour les rapports du vérificateur CTS. L’exigence de tests MANDATED s’applique également aux appareils mis à niveau. Cette exigence selon laquelle les appareils mis à niveau doivent réussir tous les tests MANDATED a entraîné le retard des tests avant de devenir des tests MANDATED , car les appareils plus anciens doivent également réussir les tests.

Dans Android 11, les tests MANDATED sont contrôlés par le premier indicateur de niveau API des propriétés du téléphone. Pour les appareils mis à niveau vers Android 11, les tests s'exécutent en tant que tests NOT_YET_MANDATED , ce qui signifie qu'un test peut échouer mais être tabulé comme PASS dans CtsVerifier.apk .

Par exemple:

• Sous Android 11, le test test_channel_saturation est MANDATED pour les appareils dont le premier niveau d'API est supérieur à 29.
• Sous Android 10, le test test_channel_saturation est MANDATED pour tous les appareils.

Validation de l'éclairage de la scène

Sous Android 11, l'éclairage de la scène est validé en analysant la luminosité dans les coins de la scène. Toutes les scènes manuelles sont validées pour l'éclairage, et les scènes sur tablette sont validées pour les caméras RFoV dans le banc de test RFoV et les caméras WFoV dans le banc de test WFoV. Si les niveaux d'éclairage sont inadéquats, une erreur est signalée et le test échoue.

Changements de nom de scène

Dans Android 10, la scène 1 représente la majorité des tests et un pourcentage important de la durée totale du test. Si un test de la scène 1 échoue, la scène entière doit être réexécutée. De par sa conception, la réexécution de la scène entière réduit le nombre de tests marginaux. Dans Android 11, les temps de réexécution sont réduits en divisant la scène 1 en deux scènes, scene1_1 et scene1_2.

Le tableau suivant présente les temps de test tabulés pour la caméra arrière du Pixel 4 pour différentes scènes. Le nombre de tests est divisé pour égaliser la durée du test, et non pour égaliser le nombre de tests.

De plus, il y a un nettoyage de nom. La scène 2 est divisée en lettres et la scène 1 est divisée en chiffres. La nomenclature des différentes extensions est la suivante :

• Scènes avec même grille, mais tests différents : *_1,2,3
• Scènes avec des grilles différentes, mais mêmes tests : *_a,b,c

Scène	Nombre d'essais	Durée d'exécution du Pixel 4 (min : s)
0	11	1:12
1_1	22	17h12
1_2	13	17h20
2_a	5	3:22
2_b	1	0:24
2_c	1	0:24
3	6	2:04
4	2	2:46

Tester les modifications

Tests mis à jour pour utiliser le premier niveau d'API

Dans Android 11, les tests du tableau suivant sont mis à jour pour utiliser le premier indicateur de niveau API. Tous ces tests utilisent un premier niveau API de 29 sauf le test test_tonemap_curve qui utilise un premier niveau API de 30.

Scène	Nom du test	Premier niveau API	Description
0	test_tonemap_curve	30	Assurez-vous que le pipeline a des sorties de couleurs appropriées avec une carte de tons linéaire et une entrée d'image idéale (s'appuie sur test_test_patterns ).
1	test_ae_precapture_trigger	29	Testez la machine à états AE lorsque vous utilisez le déclencheur de précapture. Assurez-vous que le déclencheur de précapture AE désactivé n’a aucun effet.
	test_channel_saturation	29	Assurez-vous que les canaux RVB saturent à des valeurs similaires pour éliminer la teinte dans les régions saturées.
2_a/b/c	test_num_faces	29	Augmentez la diversité d’âge dans les scènes de visage.

Tests avec modifications

Les tests du tableau suivant sont mis à jour dans Android 11. Les modifications sont décrites dans la colonne Description des modifications .

Scène	Nom du test	Premier niveau API	Description des changements
1	test_burst_sameness_manual	30	Réduire la tolérance à 2%.
4	test_aspect_ratio_and_crop	30	Modification pour fonctionner sur des appareils LIMITÉS.
	test_multi_camera_alignment	30	Parcourez les caméras individuellement si la capture multi-caméras n’est pas prise en charge. Retravaillez la logique de sélection des caméras pour tenir compte des systèmes à trois et quatre caméras, et ignorez les caméras mono, de profondeur uniquement et IR.

Nouveaux tests

Les tests du tableau suivant sont activés dans Android 11. Les tests sont résumés dans le tableau et des descriptions détaillées sont fournies dans les sections suivantes.

Scène	Nom du test	Premier niveau API	Description
0	test_vibration_restrictions	30	Assurez-vous que les alertes et les vibrations ne sont pas activées pendant les captures d'images.
2_a	test_jpeg_quality	30	Testez que les tables de quantification diminuent la compression pour une qualité JPEG accrue.
2_j/2_e	test_num_faces	30	Augmenter la diversité d’âge du visage.
2_e	test_continuous_picture	30	Assurez-vous que 3A s'installe dans android.control.afAvailableModes = CONTINUOUS_PICTURE.
changement	test_scene_change	31	android.control.afSceneChange affirmé lors du changement de scène.
6	test_zoom	30	Testez android.control.zoomRatioRange .

scène0/test_vibration_restriction

Ce test ne nécessite aucune scène spécifique, mais l'appareil testé (DUT) doit être placé ou monté sur une surface dure. Cela inclut le montage sur les boîtiers de test ITS-in-a-box.

Affirmations

• Aucune vibration lors de l'utilisation de l'appareil photo

scene2_a/test_jpeg_quality

Méthode

Différentes parties du fichier JPEG sont définies par des marqueurs de 2 octets. Pour plus d'informations, voir JPEG .

Le test extrait les matrices de quantification de la capture JPEG. Le marqueur des matrices de quantification dans la capture JPEG est la séquence [255, 219]. Lorsque le marqueur est trouvé, les deux éléments suivants de la liste correspondent à la taille. Le marqueur de taille JPEG DQT est généralement [0, 132] = 256*0+132 = 132, ce qui représente la taille des données DQT dans la capture JPEG. Les données intégrées sont de la forme : [255, 219, 0, 132, 0 (marqueur de luminance), matrice de luminance 8x8, 1 (marqueur de chrominance), matrice de chrominance 8x8].

Le 0 pour le marqueur de matrice luminance et 1 pour le marqueur de chrominance semblent cohérents pour un certain nombre d'appareils, y compris les téléphones qui séparent les deux matrices en sections DQT distinctes dans le fichier JPEG. Les matrices de luminance ont tendance à avoir une plus grande variété de valeurs que les matrices de chrominance, car l'œil humain est plus sensible à la luminance qu'à la chrominance et les images JPEG en tiennent compte.

Des exemples de matrices de luminance et de chrominance extraites sont présentés ci-dessous pour des facteurs de qualité de 85 et 25 pour la caméra arrière du Pixel 4 capturant la scène2_a avec le banc de test ITS. Les valeurs de la matrice augmentent considérablement (indiquant une compression accrue) pour le paramètre de qualité inférieure. Ces matrices ne sont imprimées avec le script que si l'indicateur debug=True est appliqué. Notez la plus grande variation des entrées dans les matrices de luminance par rapport aux matrices de chrominance.

    luma matrix (quality = 85)    chroma matrix (quality = 85)

    [[ 5  3  4  4  4  3  5  4]    [[ 5  5  5  7  6  7 14  8]
     [ 4  4  5  5  5  6  7 12]     [ 8 14 30 20 17 20 30 30]
     [ 8  7  7  7  7 15 11 11]     [30 30 30 30 30 30 30 30]
     [ 9 12 17 15 18 18 17 15]     [30 30 30 30 30 30 30 30]
     [17 17 19 22 28 23 19 20]     [30 30 30 30 30 30 30 30]
     [26 21 17 17 24 33 24 26]     [30 30 30 30 30 30 30 30]
     [29 29 31 31 31 19 23 34]     [30 30 30 30 30 30 30 30]
     [36 34 30 36 28 30 31 30]]     [30 30 30 30 30 30 30 30]]

    luma matrix (quality = 25)            chroma matrix (quality = 25)

    [[ 32  22  24  28  24  20  32  28]    [[ 34  36  36  48  42  48  94  52]
     [ 26  28  36  34  32  38  48  80]     [ 52  94 198 132 112 132 198 198]
     [ 52  48  44  44  48  98  70  74]     [198 198 198 198 198 198 198 198]
     [ 58  80 116 102 122 120 114 102]     [198 198 198 198 198 198 198 198]
     [112 110 128 144 184 156 128 136]     [198 198 198 198 198 198 198 198]
     [174 138 110 112 160 218 162 174]     [198 198 198 198 198 198 198 198]
     [190 196 206 208 206 124 154 226]     [198 198 198 198 198 198 198 198]
     [242 224 200 240 184 202 206 198]]     [198 198 198 198 198 198 198 198]]

La figure 3 montre les valeurs matricielles moyennes de la caméra arrière du Pixel 4 par rapport à la qualité JPEG. À mesure que la qualité JPEG augmente, le niveau de compression (moyenne de la matrice DQT luma/chroma) diminue.

Figure 3. Moyennes de la matrice DQT luma/chroma de la caméra arrière du Pixel 4 par rapport à la qualité JPEG

Affirmations

• Pour [25, 45, 65, 86], +20 en qualité a des moyennes de matrice de quantification de réduction de 20 %.
• Les charges utiles de la matrice DQT sont des nombres carrés.

La figure 4 montre un exemple de téléphone qui échoue au test. A noter que pour les images de très mauvaise qualité ( jpeg.quality < 50 ), il n'y a pas d'augmentation de la compression dans la matrice de quantification.

Figure 4. Exemple de test échoué

scene2_d/e test_num_faces

Deux nouvelles scènes de détection de visage sont ajoutées pour augmenter la diversité faciale des contrôles de l'algorithme de détection de visage. Avec des tests répétés sur un certain nombre de caméras, le visage le plus difficile devrait être le visage le plus à gauche de la scène2_d. On retrouve notamment à la fois un chapeau et une barbe sur le modèle, chose de nouveau dans les scènes de visage. Les nouvelles scènes sont présentées dans les figures 5 et 6.

Figure 5. scène2_d

Figure 6. scène2_e

Affirmations

• num_faces == 3

scene2_e/test_continuous_picture

Méthode

Le test test_continuous_picture utilise scene2_e mais il peut être activé avec n'importe quelle scène de visage. Dans ce test, 50 images de résolution VGA sont capturées avec la demande de capture définissant d'abord android.control.afMode = 4 (CONTINUOUS_PICTURE) .

Le système 3A devrait s'être installé à la fin d'une capture de 50 images.

Affirmations

• 3A est dans un état convergé en fin de capture.

changement_scène/test_scene_change

Méthode

Un nouveau test est activé pour tester si l'indicateur android.control.afSceneChange est activé lors d'un changement de scène. Le changement de scène utilise la tablette pour afficher une scène de visage, puis allumer et éteindre la tablette pour créer un changement de scène. La scène réutilise scene2_e mais se trouve dans une scène distincte en raison du contrôle de tablette requis.

De plus, pour les tests manuels, le changement de scène peut être effectué en agitant la main devant la caméra.

La figure 7 montre un chronogramme du test. Le temps entre l'extinction de l'écran et la capture est ajusté en fonction des résultats des événements des captures précédentes.

Figure 7. Chronogramme pour test_scene_change

Conditions de quart de travail :

• S'il y a un changement de scène et afSceneChange == 1 , le test renvoie PASS .
• S'il y a un changement de scène et afSceneChange == 0 , le changement de scène se décale de 5 images plus tôt pour donner plus de temps à afSceneChange pour s'affirmer.
• S'il n'y a pas de changement de scène et afSceneChange == 1 , le test renvoie FAIL .
• S'il n'y a pas de changement de scène et que afSceneChange == 0 , le changement de scène se décale 30 images plus tôt pour obtenir un changement de scène lors de la capture.

Affirmations

• L’écran (scène) bascule.
• L'indicateur afSceneChange est dans [0, 1].
• Si aucun changement de scène, 3A converge (fonctionnellement identique à test_continuous_picture ).
• Si afSceneChange == 1 , la luminosité doit changer dans la scène.
• PASS dans les six essais avec un timing modifié en fonction des résultats précédents.

scène6/test_zoom

Méthode

Une nouvelle scène est nécessaire pour tester android.control.zoomRatioRange car les scènes établies n'ont pas de fonctionnalité suffisamment petite pour être agrandies (scènes [1, 2, 4]) ou la scène comporte de nombreux objets qui ne sont pas facilement identifiés. , compliquant l'extraction des fonctionnalités (scène 3).

La figure 8 montre la nouvelle scène avec un réseau régulier de cercles. Le réseau de cercles assouplit les exigences en matière de centrage du DUT/graphique et permet d'avoir un cercle toujours proche du centre de l'image capturée. Dans cette scène, un ensemble de cercles de 9 x 5 avec une bordure noire recouvre la totalité de la tablette. Un cercle est remplacé par un carré dans le coin supérieur droit pour indiquer l'orientation. Les tailles de cercle ont une caractéristique d'une superficie d'environ 7 500 pixels ( radius=50pixels ) pour un capteur 4 000 x 3 000 capturé avec un champ de vision (FoV) d'environ 80 degrés.

Figure 8. Scène test_zoom

Figure 9. Zoom Pixel 4 cam[0] = [1, 3,33, 5,67, 8] images avec cercle trouvé

La figure 9 montre les images capturées pour la caméra arrière d'un Pixel 4 lorsque le zoom passe de 1 à 8x en quatre étapes. Cet ensemble d'images est capturé sans aucun soin particulier apporté au centrage, à l'exception de l'utilisation de l'ouverture de test du téléphone à deux ouvertures pour permettre le test des caméras avant et arrière. Un décalage par rapport au centre est attendu et est observé lorsque la tablette graphique est légèrement à gauche du centre. De plus, le graphique semble suffisant pour tester avec des taux de zoom supérieurs à 8x.

Trouver des cercles

Le test inclut une méthode find_circle() utilisant findContours qui trouve tous les contours et restreint la recherche de contours aux cercles souhaités en testant les éléments suivants :

• Les contours doivent avoir une superficie supérieure à 10 pixels.
• Les contours doivent avoir NUM_PTS >= 15 .
• Les contours doivent avoir des centres noirs.
• Les contours doivent ressembler à un cercle, c'est-à-dire que leur aire est proche de l'aire pi*r2 du contour.

Plage de test

android.control.zoomRatioRange est divisé en 10 étapes.

• [1, 7] essais [1, 1.67, 2.33, 3, 3.67, 4.33, 5, 5.67, 6.33, 7]

Le zoom est interrompu si le cercle trouvé touche les limites de l'image. Il y a une vérification pour s'assurer qu'un niveau de zoom suffisant est atteint lors du test (10x).

Affirmations

• Au moins un cercle est trouvé à chaque réglage de zoom.
• 10x ou maximum de android.control.zoomRatioRange est testé.
• Échelles de rayon de cercle avec zoom (RTOL 10 % par rapport à prévu).
• Décalage du centre du cercle par rapport aux échelles centrales avec zoom (RTOL 10 % par rapport à prévu).
• Un niveau de zoom suffisant est atteint (2x).

Augmentation des tests de caméra LIMITÉS

Sous Android 11, les tests du tableau suivant testent les caméras LIMITED . En plus des nouveaux tests , le test scene4/test_aspect_ratio_and_crop est mis à jour pour permettre de tester les appareils LIMITED avec un premier niveau d'API de 30 ou supérieur.

Scène	Nom du test
0	test_vibration_restrictions
2_a	test_jpeg_quality
2_j/2_e	test_num_faces
4	test_aspect_ratio_and_crop
6	test_zoom

La figure 10 montre l' anneau de décodeur secret Android 11 ITS. L'anneau de décodeur secret montre par quels paramètres de test les tests individuels sont contrôlés. Le portail est codé par couleur pour faciliter la visualisation. Les principaux éléments de contrôle sont :

• MANUAL_SENSOR
• READ_3A *nécessite MANUAL SENSOR
• COMPUTE_TARGET_EXPOSURES *nécessite MANUAL SENSOR
• PER_FRAME_CONTROL
• RAW
• SENSORS * REALTIME
• MULTI_CAMERA

MANUAL SENSOR , READ_3A , COMPUTE_TARGET_EXPOSURES et PER_FRAME_CONTROL contrôlent la majorité des tests. De plus, les tests activés pour les appareils LIMITED sont surlignés en vert clair.

Figure 10. Anneau de décodeur secret Android 11