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

Cette page récapitule les modifications apportées à la suite de tests d'image de l'appareil photo (ITS) dans Android 11. Les modifications se répartissent dans les catégories suivantes :

• Modifications apportées au matériel
• Premiers tests OBLIGATOIRES au niveau de l'API
• Éclairage testé et validé
• Changement de nom des scènes
• Tester les modifications et les ajouts
• Augmentation des tests de caméras LIMITED

Modifications matérielles

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

• Fabricant supplémentaire
• Méthodes de fabrication unifiées
• Plus d'options pour les tablettes
• Ouverture de la tablette réduite
• Nouveau contrôleur de fusion de capteurs

Fabricant supplémentaire

Rahi Systems est qualifié pour produire des enceintes de test ITS en plus de notre fournisseur actuel, MYWAY design. Voici les informations sur l'entreprise pour les fournisseurs qualifiés :

• Rahi Systems Inc.
  48303 Fremont Blvd, Fremont CA 94538, États-Unis
  rahisystems.com/products/android-device-testing-equipment/
  androidpartner@rahisystems.com
  +1-510-319-3802

• MYWAY design
  4F., N° 163, Fu-Ying Road, XinZhuang District, New Taipei City, Taïwan
  twmyway.com
  sales@myway.tw
  +886-2-29089060

Méthodes de fabrication unifiées

L'enceinte de test ITS-in-a-box à champ de vision normal (RFoV) rev1 a été repensée pour utiliser les méthodes de fabrication utilisées par les enceintes de test à champ de vision large (WFoV) et à fusion de capteurs. La fonctionnalité est identique et, pour plus de simplicité, la conception est appelée rev1a. La nouvelle conception permet aux fabricants de stocker un seul type de plastique pour fabriquer tous les boîtiers de test. De plus, les supports de tablette et de lampe ont été repensés pour s'adapter à une plus grande variété de tablettes et de barres lumineuses LED.

Pour télécharger les dernières descriptions et les derniers plans mécaniques, consultez Boîtier RFoV (rev1a) et Boîtier WFoV (rev2.9).

Plus d'options pour les tablettes

Les tablettes, y compris la Samsung Galaxy Tab A 10.1 et la Chuwi Hi9 Air 10.1, ont été ajoutées à la liste des tablettes recommandées. Il est important que la tablette ne dispose pas de la 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 Configuration requise pour les tablettes.

Ouverture de la tablette réduite

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 modifications sont rev1a.1 et rev2.9. Pour ces schémas, consultez Cadre du champ de vision à distance (rév. 1a) et Cadre du champ de vision large (rév. 2.9).

Nouveau contrôleur de fusion de capteurs

Le matériel du contrôleur de fusion de capteurs est repensé pour améliorer la fabricabilité. Le nouveau contrôleur est basé sur Arduino, avec une carte de routage personnalisée shield qui se monte sur Arduino. La figure 1 montre le blindage et la figure 2 montre le plan 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 par le connecteur USB. L'alimentation séparée permet une isolation complète entre l'électronique de contrôle et le servomoteur. De plus, un seul contrôleur peut contrôler jusqu'à six servomoteurs.

Figure 1 : Vue de dessus d'un shield Arduino

Figure 2. Conception d'enceintes

Android 11 est rétrocompatible avec les manettes existantes. Pour appeler les 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 d'API

Dans Android 10, les tests ITS sont désignés par MANDATED et NOT_YET_MANDATED. Pour être lancé en tant qu'appareil Android 10, tous les tests MANDATED doivent réussir. Les tests NOT_YET_MANDATED peuvent échouer, mais sont classés comme PASS pour les rapports CTS Verifier. L'exigence relative aux 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 retardé la conversion des tests en tests MANDATED, car les anciens appareils doivent également réussir les tests.

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

Exemple :

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

Valider l'éclairage de la scène

Dans 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 basées sur une tablette sont validées pour les caméras à champ de vision réduit (RFoV) dans le banc d'essai RFoV et pour les caméras à champ de vision large (WFoV) dans le banc d'essai WFoV. Si les niveaux de luminosité sont insuffisants, une erreur est signalée et le test échoue.

Changement de nom des scènes

Dans Android 10, la scène 1 représente la majorité des tests et un pourcentage important de la durée totale des tests. Si un test de la scène 1 échoue, l'ensemble de la scène doit être relancé. Par conception, la réexécution de l'ensemble de la scène réduit le nombre de tests marginaux réussis. 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 pour la caméra arrière du Pixel 4 pour différentes scènes. Le nombre de tests est réparti pour égaliser la durée des tests, et non le nombre de tests.

De plus, les noms sont nettoyés. La scène 2 est divisée avec des lettres et la scène 1 avec des chiffres. La nomenclature des différentes extensions est la suivante :

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

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 d'API. Tous ces tests utilisent un premier niveau d'API de 29, à l'exception du test test_tonemap_curve, qui utilise un premier niveau d'API de 30.

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.

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.

scene0/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 enceintes de test ITS-in-a-box.

Assertions

• 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 deux octets. Pour en savoir plus, consultez JPEG.

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

Les valeurs 0 pour le marqueur de matrice de luminance et 1 pour le marqueur de chrominance semblent cohérentes 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 à présenter 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 d'essai ITS. Les valeurs de la matrice augmentent considérablement (ce qui indique une compression accrue) pour le paramètre de qualité inférieure. Ces matrices ne sont imprimées avec le script que si l'option debug=True est appliquée. 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 moyennes de la matrice pour l'appareil photo 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 de luminance/chrominance) diminue.

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

Assertions

• Pour [25, 45, 65, 86], la qualité +20 correspond à une réduction de 20 % des moyennes de la matrice de quantification.
• 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. Notez 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 d'échec du test

scene2_d/e test_num_faces

Deux nouvelles scènes de détection de visages ont été ajoutées pour accroître la diversité des visages dans les vérifications de l'algorithme de détection de visages. Après avoir testé plusieurs caméras, le visage le plus difficile à détecter devrait être celui le plus à gauche dans scene2_d. En particulier, le modèle porte un chapeau et une barbe, ce qui est nouveau dans les scènes de visage. Les nouvelles scènes sont présentées dans les figures 5 et 6.

Figure 5 : scene2_d

Figure 6 : scene2_e

Assertions

• 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 visages. Dans ce test, 50 images de résolution VGA sont capturées avec la requête de capture définissant d'abord android.control.afMode = 4 (CONTINUOUS_PICTURE).

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

Assertions

• Le 3A est dans un état convergent à la fin de la capture.

scene_change/test_scene_change

Méthode

Un nouveau test est activé pour vérifier si l'indicateur android.control.afSceneChange est défini lors d'un changement de scène. Le changement de scène utilise la tablette qui affiche une scène de visage, puis l'allume et l'éteint 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 de la commande de tablette requise.

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 diagramme de timing du test. Le délai 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. Diagramme chronologique pour test_scene_change

Conditions de changement de vitesse :

• En cas de changement de scène et de afSceneChange == 1, le test renvoie PASS.
• Si la scène change et que afSceneChange == 0, le changement de scène est décalé de cinq images plus tôt pour laisser plus de temps à afSceneChange pour s'affirmer.
• S'il n'y a pas de changement de scène et que 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 est décalé de 30 images plus tôt pour obtenir le changement de scène dans la capture.

Assertions

• Boutons bascule de l'écran (scène).
• L'indicateur afSceneChange est compris entre 0 et 1.
• Si la scène ne change pas, la 3A converge (fonctionnellement identique à test_continuous_picture).
• Si la valeur est afSceneChange == 1, la luminosité doit changer dans la scène.
• PASS en six tentatives, avec un timing modifié en fonction des résultats précédents.

scene6/test_zoom

Méthode

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

La figure 8 montre la nouvelle scène avec un tableau de cercles régulier. Le tableau de cercles assouplit les exigences concernant le centrage du DUT/graphique et permet d'avoir un cercle toujours près du centre de l'image capturée. Dans cette scène, une grille de cercles 9x5 avec une bordure noire recouvre toute la tablette. Un cercle est remplacé par un carré dans l'angle supérieur droit pour indiquer l'orientation. La taille des cercles correspond à une zone d'environ 7 500 pixels (radius=50pixels) pour un capteur de 4 000 x 3 000 pixels capturé avec un champ de vision d'environ 80 degrés.

Figure 8 : scène test_zoom

Figure 9. Zoom de la caméra Pixel 4[0] = [1, 3.33, 5.67, 8] images avec le cercle trouvé

La figure 9 montre les images capturées par 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 prendre de précautions particulières pour le centrage, sauf pour utiliser l'ouverture de test du téléphone avec deux ouvertures pour permettre de tester les caméras avant et arrière. Un décalage par rapport au centre est attendu et observé, car la tablette graphique est légèrement à gauche du centre. De plus, le graphique semble suffisant pour effectuer des tests avec des rapports de zoom supérieurs à x8.

Rechercher des cercles

Le test inclut une méthode find_circle() utilisant findContours qui trouve tous les contours et réduit 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 un centre noir.
• Les contours doivent ressembler à un cercle, c'est-à-dire que leur aire doit être proche de l'aire pi*r2 du contour.

Plage de test

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

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

Le zoom s'arrête si le cercle trouvé touche les limites de l'image. Un contrôle permet de s'assurer qu'un niveau de zoom suffisant est atteint lors du test (x10).

Assertions

• Au moins un cercle est visible à chaque niveau de zoom.
• 10x ou le maximum de android.control.zoomRatioRange est testé.
• Le rayon du cercle est mis à l'échelle en fonction du zoom (RTOL à 10 % de la valeur attendue).
• Le décalage du centre du cercle par rapport au centre est proportionnel au zoom (RTOL de 10 % par rapport à la valeur attendue).
• Le niveau de zoom suffisant est atteint (x2).

Augmentation des tests de caméras LIMITED

Dans 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.

La figure 10 montre l'anneau de décodage secret ITS d'Android 11. L'anneau de décodage secret indique les paramètres de test dont dépendent les tests individuels. Le gating est codé par couleur pour faciliter la visualisation. Voici les principaux éléments de gating :

• MANUAL_SENSOR
• READ_3A *MANUAL SENSOR requis
• COMPUTE_TARGET_EXPOSURES *MANUAL SENSOR requis
• 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 mis en évidence en vert clair.

Figure 10. Bague de décodage secrète Android 11