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/
androidpartner@rahisystems.com
+1-510-319-3802Conception MYWAY
4F., n° 163, Fu-Ying Road, district de XinZhuang, ville de New Taipei, Taiwan
twmyway.com
sales@myway.tw
+886-2-29089060
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
estMANDATED
pour les appareils dont le premier niveau d'API est supérieur à 29. - Sous Android 10, le test
test_channel_saturation
estMANDATED
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 renvoiePASS
. - 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 renvoieFAIL
. - 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écessiteMANUAL SENSOR
-
COMPUTE_TARGET_EXPOSURES
*nécessiteMANUAL 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