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

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

• Modifications matérielles
• Premier niveau d'API : tests OBLIGATOIRES
• Éclairage de test validé
• Changement de nom de scène
• Tester les modifications et les ajouts
• Augmentation de la LIMITE des tests de l'appareil photo

Modifications matérielles

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

• Autres fabricants
• Méthodes de fabrication unifiées
• Augmentation du nombre d'options des tablettes
• Réduction de l'ouverture de la tablette
• Nouveau contrôleur de fusion de capteurs

Autre fabricant

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:

• 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., No. 163, Fu-Ying Road, XinZhuang District, New Taipei City, Taiwan
  twmyway.com
  sales@myway.tw
  +886-2-29089060

Méthodes de fabrication unifiées

La boîte ITS-in-a-box à champ de vision régulier (RFoV) rev1 a été repensée pour utiliser les méthodes de fabrication utilisées par les boîtiers de test de la boîte à champ de vision large (WFoV) et de la boîte de fusion de capteurs. La fonctionnalité est identique, et pour simplifier, la conception est appelée rev1a. La nouvelle conception permet aux fabricants de stocker un seul type de plastique pour fabriquer toutes les enceintes de test. De plus, le support de tablette et les supports de lumière 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 les derniers dessins mécaniques, consultez les documents Boîte RFoV (rev1a) et Boîte 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, 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 connaître les dernières informations sur les tablettes recommandées, consultez la section Configuration requise pour les tablettes.

Ouverture de la tablette réduite

Pour permettre l'utilisation de la Galaxy Tab A 10.1, la hauteur de l'ouverture de la tablette est légèrement réduite 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 dessins, consultez les sections Cadre de champ de vision du radar (rev1a) et Cadre de champ de vision du radar (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 shield de carte de routage personnalisé qui se monte sur l'Arduino. La figure 1 montre le bouclier et la figure 2 le dessin mécanique du boîtier. Le nouveau contrôleur est alimenté par une seule alimentation 5 V qui alimente directement le moteur. L'électronique est entièrement contrôlée via le connecteur USB. L'alimentation séparée permet une isolation complète entre les composants électroniques de contrôle et le servomoteur. De plus, un seul contrôleur peut contrôler jusqu'à six servomoteurs.

Figure 1 : Vue de dessus de la carte Arduino

Figure 2. Conception de l'enveloppe

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

Dans Android 10, les tests ITS sont désignés par MANDATED et NOT_YET_MANDATED. Pour lancer l'application en tant qu'appareil Android 10, tous les tests MANDATED doivent réussir. Les tests NOT_YET_MANDATED peuvent échouer, mais ils sont présentés sous la forme PASS pour les rapports de vérificateur CTS. L'exigence de tests MANDATED s'applique également aux appareils mis à niveau. Cette exigence pour que les appareils mis à niveau réussissent tous les tests MANDATED a retardé les tests pour 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 d'API des propriétés du téléphone. Pour les appareils qui passent à Android 11, les tests s'exécutent 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 RFoV dans le banc d'essai RFoV et les caméras WFoV dans le banc d'essai WFoV. Si les niveaux d'éclairage sont insuffisants, une erreur est signalée et les tests échouent.

Modification du nom de la scène

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 l'un des tests de la scène 1 échoue, l'intégralité de la scène doit être recalculée. Par conception, la réexécution de l'ensemble de la scène réduit le passage des tests marginaux. Dans Android 11, les temps de relecture 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 pour égaliser le nombre de tests.

De plus, un nettoyage des noms est effectué. La scène 2 est divisée par des lettres et la scène 1 par 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 des graphiques différents, mais mêmes tests: *_a,b,c

Tester les modifications

Mise à jour des tests pour utiliser le premier niveau d'API

Dans Android 11, les tests du tableau suivant sont mis à jour pour utiliser l'indicateur de premier 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 sous 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.

Déclarations

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

scene2_a/test_jpeg_quality

Méthode

Les différentes parties du fichier JPEG sont définies par des repères de 2 octets. Pour en savoir plus, consultez JPEG.

Le test extrait les matrices de quantification de la capture JPEG. Le repère des matrices de quantification dans la capture JPEG est la séquence [255, 219]. Lorsque le repère est trouvé, les deux éléments de liste suivants correspondent à la taille. Le repère 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 sont au format : [255, 219, 0, 132, 0 (repère luma), matrice luma 8x8, 1 (repère chroma), matrice chroma 8x8].

Le 0 du repère de la matrice de luma et le 1 du repère de chroma 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 luma ont tendance à présenter une plus grande variété de valeurs que les matrices chroma, car l'œil humain est plus sensible à la luma qu'au chroma, et les images JPEG en tiennent compte.

Des exemples de matrices luma et chroma 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 qui capture 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é le plus bas. 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 luminosité 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 de matrice moyennes 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 luma/chroma) diminue.

Figure 3. Moyennes de la matrice DQT luma/chroma de l'appareil photo arrière du Pixel 4 par rapport à la qualité JPEG

Affirmations

• Pour [25, 45, 65, 86], une qualité de +20 % entraîne une réduction de 20 % de la moyenne 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 basse qualité (jpeg.quality < 50), la compression n'est pas augmentée dans la matrice de quantification.

Figure 4. Exemple de test ayant échoué

scène2_d/e test_num_faces

Deux nouvelles scènes de détection de visages sont ajoutées pour augmenter la diversité des visages dans les vérifications de l'algorithme. 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 comporte à la fois un chapeau et une barbe, ce qui est nouveau dans les scènes de visage. Les nouvelles scènes sont illustrées dans les figures 5 et 6.

Figure 5 : scene2_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 le premier paramètre de requête de capture android.control.afMode = 4 (CONTINUOUS_PICTURE).

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

Affirmations

• 3A est à l'état convergé à 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 affirmé avec un changement de scène. Le changement de scène utilise la tablette qui affiche une scène de visage, puis allume et éteint 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 de la commande de la tablette requise.

En outre, pour les tests manuels, vous pouvez changer de scène en agitant la main devant la caméra.

La figure 7 présente un diagramme temporel du test. Le délai entre l'arrêt de l'écran et la capture est ajusté en fonction des résultats d'événements des captures précédentes.

Figure 7. Schéma temporel de test_scene_change

Conditions du changement:

• En cas de changement de scène et de afSceneChange == 1, le test renvoie PASS.
• En cas de changement de scène et de afSceneChange == 0, le changement de scène est décalé de cinq images plus tôt pour laisser plus de temps à afSceneChange de s'affirmer.
• S'il n'y a pas de changement de scène et de afSceneChange == 1, le test renvoie FAIL.
• S'il n'y a pas de changement de scène et de afSceneChange == 0, le changement de scène est décalé de 30 images plus tôt pour obtenir un changement de scène lors de la capture.

Affirmations

• Boutons d'activation/de désactivation de l'écran (scène).
• L'indicateur afSceneChange se trouve entre [0, 1].
• En l'absence de changement de scène, 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, le temps étant modifié en fonction des résultats précédents.

scène6/test_zoom

Méthode

Une nouvelle scène est requise pour tester android.control.zoomRatioRange, car les scènes établies n'ont pas de caractéristique suffisamment petite pour être agrandie (scènes [1, 2, 4]) ou la scène comporte de nombreux objets difficilement identifiés, ce qui complique l'extraction de caractéristiques (scène 3).

La figure 8 montre la nouvelle scène avec un tableau régulier de cercles. La matrice de cercles réduit les exigences concernant le centrage du DUT/du graphique et permet d'obtenir un cercle toujours près du centre de l'image capturée. Dans cette scène, un tableau de 9 x 5 cercles avec une bordure noire couvre l'ensemble de la tablette. Un cercle est remplacé par un carré dans l'angle supérieur droit pour indiquer l'orientation. Les tailles de cercles ont une fonctionnalité d'une surface 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 de la caméra Pixel 4 [0] = [1, 3,33, 5,67, 8] images avec 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 à 8 fois en quatre étapes. Cet ensemble d'images est capturé sans aucun soin particulier pour le centrage, sauf pour utiliser l'ouverture de test du téléphone avec deux ouvertures afin de permettre de tester à la fois les caméras avant et arrière. Un décalage par rapport au centre est attendu et observé, car la tablette du graphique est légèrement à gauche du centre. De plus, le graphique semble suffisant pour tester avec des taux de zoom supérieurs à 8 x.

Rechercher des cercles

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

• La surface des contours doit être 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 surface est proche de la surface pi*r2 du contour.

Plage de test

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

• [1, 7] tests [1, 1,67, 2,33, 3, 3,67, 4,33, 5, 5,67, 6,33, 7]

Le zoom s'arrête si le cercle détecté touche les limites de l'image. Une vérification est effectuée pour s'assurer qu'un niveau de zoom suffisant est atteint lors du test (10 x).

Affirmations

• Au moins un cercle est détecté à chaque paramètre de zoom.
• 10 fois ou un maximum de android.control.zoomRatioRange est testé.
• Le rayon du cercle évolue avec le zoom (RTOL de 10% par rapport à la valeur attendue).
• Le centre du cercle est décalé par rapport aux échelles du centre avec le zoom (RTOL de 10% par rapport à la valeur attendue).
• Vous avez atteint le niveau de zoom suffisant (2x).

Amélioration des tests de caméra 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 le test des appareils LIMITED avec un premier niveau d'API supérieur ou égal à 30.

La figure 10 montre le cercle de décodeur secret de l'ITS Android 11. L'anneau de déchiffrement secret indique les paramètres de test par lesquels les tests individuels sont contrôlés. La limitation est codée par couleur pour faciliter la visualisation. Les principaux éléments de filtrage sont les suivants:

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

Figure 10. Anneau de déchiffrement secret Android 11