Tests ITS de l'appareil photo

Cette page fournit une liste complète des tests de la suite de tests d'image de l'appareil photo (ITS, Camera Image Test Suite), qui fait partie de l'outil de vérification de la suite de tests de compatibilité (CTS, Compatibility Test Suite) Android. Les tests ITS sont des tests fonctionnels, ce qui signifie qu'ils ne mesurent pas la qualité de l'image, mais que toutes les fonctions de l'appareil photo annoncées fonctionnent comme prévu. Ce document permet aux développeurs et aux testeurs de comprendre ce que font les tests individuels et comment déboguer les échecs de test.

Camera ITS sélectionne les tests en fonction des propriétés requises de l'appareil photo, du niveau d'API et du niveau de classe de performances multimédias (MPC). Pour le niveau d'API, ITS utilise ro.product.first_api_level pour contrôler les tests ajoutés à un niveau d'API spécifique qui testent les expériences utilisateur négatives pour les fonctionnalités des niveaux d'API inférieurs. ITS utilise ro.vendor.api_level pour contrôler les tests des fonctionnalités ajoutées à un niveau d'API spécifique qui nécessitent de nouvelles capacités matérielles. Si ro.odm.build.media_performance_class est défini pour un appareil, ITS exige l'exécution de tests spécifiques en fonction du niveau MPC.

Les tests sont regroupés par scène comme suit :

  • scene0 : capture les métadonnées, le jitter, le gyroscope et les vibrations
  • scene1 : compensation de l'exposition, de la sensibilité et de la valeur d'exposition (EV), YUV par rapport à JPEG et RAW
  • scene2 : détection de visages, tests nécessitant des scènes en couleur
  • scene3 : amélioration des contours, mouvement de l'objectif
  • scene4 : format, recadrage, champ de vision
  • scene5 : ombrage d'objectif
  • scene6 : Zoom
  • scene7 : bouton de sélection multicaméra
  • scene8 : mesure de l'exposition automatique (AE) et de la balance des blancs automatique (AWB)
  • scene9 : compression JPEG
  • scene_extensions : extensions pour l'appareil photo
  • scene_tele : commutation du téléobjectif
  • scene_flash : Autoflash, fréquence d'images minimale
  • scene_video : pertes de fréquence d'images
  • sensor_fusion : décalage temporel de la caméra et du gyroscope
  • feature_combination : combinaisons de caractéristiques
  • scene_ip : parité des images entre l'application d'appareil photo par défaut et l'application Jetpack Camera (JCA)

Pour obtenir la description de chaque scène, consultez les sections correspondantes.

scene0

Les tests ne nécessitent aucune information spécifique sur la scène. Toutefois, le téléphone doit être immobile pour les tests du gyroscope et des vibrations.

test_jitter

Mesure la gigue dans les codes temporels de la caméra.

API testées :

Réussite : il existe un delta d'au moins 30 ms entre les frames.

Dans la figure suivante, notez la petite plage de l'axe Y. Le jitter est en fait faible dans ce graphique.

test_jitter plot

Figure 1 : graphique test_jitter.

test_metadata

Teste la validité des entrées de métadonnées en examinant les résultats de capture et les objets de caractéristiques de la caméra. Ce test utilise des valeurs d'exposition et de gain auto_capture_request, car le contenu de l'image n'a pas d'importance.

API testées :

Réussite : les balises de niveau matériel rollingShutterSkew, frameDuration, timestampSource, croppingType, blackLevelPattern et pixel_pitch, ainsi que le champ de vision (FoV) et la distance hyperfocale sont présents et ont des valeurs valides.

test_request_capture_match

Test qui vérifie que l'appareil écrit les valeurs d'exposition et de gain correctes en relisant les métadonnées de capture.

API testées :

Réussite : les valeurs de métadonnées de la requête et de la capture correspondent pour tous les plans.

test_sensor_events

Pour les appareils qui annoncent la prise en charge de la fusion de capteurs, ce test vérifie si l'appareil interroge et imprime les événements de capteur. Les capteurs attendus sont l'accéléromètre, le gyroscope et le magnétomètre. Ce test ne fonctionne que si l'écran est allumé, c'est-à-dire si l'appareil n'est pas en mode veille.

API testées :

Réussite : les événements de chaque capteur sont reçus.

test_solid_color_test_pattern

Tests permettant de vérifier que les mires de couleur unie sont générées correctement lorsque la caméra est désactivée. Si la désactivation du micro de la caméra est prise en charge, les mires de test de couleur unie doivent l'être également. Si la désactivation du micro de la caméra n'est pas prise en charge, les mires de couleur unie ne sont testées que si la fonctionnalité est annoncée.

Si les images brutes sont acceptées, l'attribution des couleurs est également testée. Les couleurs testées sont le noir, le blanc, le rouge, le bleu et le vert. Pour les caméras qui ne prennent pas en charge les images brutes, seule la couleur noire est testée.

API testées :

Réussite : les mires fixes compatibles sont de la bonne couleur et la variance de l'image est faible.

test_test_pattern

Teste le paramètre android.sensor.testPatternMode pour capturer des frames pour chaque mire de test valide et vérifie que les frames sont générées correctement pour les couleurs unies et les barres de couleur. Ce test comprend les étapes suivantes :

  1. Capture des images pour tous les schémas de test compatibles.
  2. Effectue un contrôle d'exactitude pour le motif de test de couleur unie et les barres de couleur.

API testées :

Réussite : les schémas de test compatibles sont générés correctement.

Exemple de test_test_patterns

Figure 2 : exemple de test_test_patterns.

test_tonemap_curve

Teste la conversion du modèle de test du format brut au format YUV avec une cartographie tonale linéaire. Ce test nécessite android.sensor.testPatternMode = 2 (COLOR_BARS) pour générer un motif d'image parfait pour la conversion de la cartographie des tons. Vérifie que le pipeline dispose de sorties de couleur appropriées avec une cartographie tonale linéaire et une entrée d'image idéale (repose sur test_test_patterns).

API testées :

Réussite : les formats YUV et RAW se ressemblent.

Exemple brut de test_tonemap_curve

Figure 3 : Exemple brut de test_tonemap_curve.

Exemple test_tonemap_curve YUV

Figure 4 : exemple de test_tonemap_curve YUV.

test_unified_timestamp

Teste si les événements du capteur d'image et de mouvement se trouvent dans le même domaine temporel.

API testées :

Réussite : les codes temporels de mouvement se situent entre les codes temporels des deux images.

test_vibration_restriction

Teste si la vibration de l'appareil fonctionne comme prévu.

API testées :

Réussite : l'appareil ne vibre pas lorsque le son de la caméra est coupé par l'API de restriction audio de la caméra.

scene1_1

scene1 est un graphique gris. La charte grise doit couvrir les 30 % centraux du champ de vision de la caméra. Le graphique gris devrait présenter une difficulté modérée pour la catégorie 3A (AE, AWB et AF), car la région centrale ne comporte aucune caractéristique. Toutefois, la requête de capture spécifie l'intégralité de la scène, qui inclut suffisamment de caractéristiques pour que 3A converge.

Les caméras à champ de vision réduit peuvent être testées dans le banc d'essai à champ de vision large ou à champ de vision réduit. Si une caméra à champ de vision réduit est testée dans le banc d'essai à champ de vision large, le graphique est mis à l'échelle 2/3 pour spécifier certaines limites pour le graphique gris dans le champ de vision afin d'aider le 3A à converger. Pour obtenir des descriptions plus détaillées des bancs d'essai de caméras, consultez Camera ITS-in-a-box.

scene1 example

Figure 5. Graphique de la scène 1 en taille réelle (à gauche) et graphique à l'échelle 2/3 (à droite).

test_ae_precapture_trigger

Teste la machine à états AE lors de l'utilisation du déclencheur de précapture. Capture cinq demandes manuelles avec l'AE désactivé. La dernière requête comporte un déclencheur de précapture AE, qui doit être ignoré, car AE est désactivé.

API testées :

Réussite : l'AE converge.

test_auto_vs_manual

Les tests qui ont capturé des photos automatiques et manuelles se ressemblent.

API testées :

Réussite : les gains et la transformation de la balance des blancs manuelle indiqués dans chaque résultat de capture correspondent à la balance des blancs automatique estimate de l'algorithme 3A de l'appareil photo.

Exemple automatique test_auto_vs_manual

Figure 6 : Exemple automatique de test_auto_vs_manual.

Exemple de balance des blancs test_auto_vs_manual

Figure 7 : Exemple de test de la balance des blancs automatique par rapport à la balance des blancs manuelle.

Exemple de transformation de la balance des blancs manuelle test_auto_vs_manual

Figure 8 : Exemple de transformation de la balance des blancs manuelle test_auto_vs_manual.

test_black_white

Tests permettant de vérifier que l'appareil produit des images en noir et blanc. Prend deux photos : la première avec un gain extrêmement faible et une exposition courte, ce qui donne une photo noire, et la seconde avec un gain extrêmement élevé et une exposition longue, ce qui donne une photo blanche.

API testées :

Pass : produit des images en noir et blanc. Les canaux saturés des images blanches ont des valeurs RVB de [255, 255, 255] avec une marge d'erreur inférieure à 1 %.

test_black_white, exemple noir

Figure 9.test_black_white, exemple noir.

Exemple de transformation de la balance des blancs manuelle test_auto_vs_manual

Figure 10 : test_black_white, exemple blanc.

test_black_white plot means example

Figure 11 : test_black_white, exemple de tracé des moyennes.

test_burst_capture

Vérifie que l'ensemble du pipeline de capture peut suivre la vitesse de capture en taille réelle et le temps processeur.

API testées :

Réussite : capture une rafale d'images en taille réelle, vérifie les pertes d'images et la luminosité des images.

test_burst_sameness_manual

Prend cinq rafales de 50 images avec le paramètre de capture manuelle et vérifie qu'elles sont toutes identiques. Utilisez ce test pour identifier les éventuels artefacts ou images sporadiques traitées différemment.

API testées :

Réussite : les images sont identiques visuellement et en valeurs RVB.

Échec : le graphique de la moyenne RVB affiche un pic ou une baisse au début de chaque rafale.

  • La tolérance est de 3 % pour first_API_level < 30
  • La tolérance est de 2 % pour first_API_level >= 30

test_burst_sameness_manual_mean

Figure 12 : exemple de moyenne test_burst_sameness_manual.

test_burst_sameness_manual_plot_means

Figure 13 : test_burst_sameness_manual_plot_means

test_crop_region_raw

Teste si les flux RAW ne sont pas recadrables.

API testées :

Réussite : les images YUV sont recadrées au centre, mais pas les images RAW.

Exemple de recadrage brut test_crop_region_raw

Figure 14 : Exemple de recadrage brut de la composition brute test_crop_region_raw.

Exemple complet de test_crop_region_raw comp

Figure 15.Exemple complet de test_crop_region_raw comp raw.

Exemple de recadrage YUV du composant test_crop_region_raw

Figure 16.Exemple de recadrage YUV du composant test_crop_region_raw.

Exemple test_crop_region_raw_yuv_full

Figure 17 : Exemple complet de test_crop_region_raw YUV.

test_crop_regions

Tests de fonctionnement des régions de recadrage. Prend une image complète et crée des zones de cinq régions différentes (coins et centre). Prend des images avec un recadrage défini pour les cinq régions. Compare les valeurs de l'image du patch et de l'image recadrée.

API testées :

Réussite : l'image de la région recadrée correspond à la zone correspondant à l'image recadrée.

test_ev_compensation

Teste si la compensation de la valeur d'exposition (EV) est appliquée. Le test se compose d'une section de base et d'une section avancée.

La section de base teste l'application de la compensation de l'exposition à l'aide d'une plage créée avec CONTROL_AE_COMPENSATION_STEP. Huit images sont capturées pour chaque valeur de compensation.

La section avancée augmente l'exposition en huit étapes et vérifie la luminosité mesurée par rapport à la luminosité attendue. Les valeurs attendues sont calculées à partir de la luminosité de l'image sans compensation de l'EV appliquée. La valeur attendue est saturée si les valeurs calculées dépassent la plage de valeurs de l'image réelle. Le test échoue si les valeurs attendues et mesurées ne correspondent pas ou si les images sont surexposées en cinq étapes.

API testées :

Section de base réussie : les images montrent une exposition croissante sans surexposition en cinq étapes.

test_ev_compensation_basic

Figure 18 : test_ev_compensation_basic.

Passage de section avancé : capture une augmentation de la luminance à mesure que le paramètre de compensation de l'EV augmente. Les huit images capturées pour chaque paramètre de compensation de l'exposition ont des valeurs de luminosité stables.

test_ev_compensation_advanced_plot_means

Figure 19.test_ev_compensation_advanced_plot_means.

test_exposure_x_iso

Tests permettant d'obtenir une exposition constante lorsque l'ISO et le temps d'exposition varient. Prend une série de photos dont l'ISO et le temps d'exposition sont choisis pour s'équilibrer mutuellement. Les résultats doivent avoir la même luminosité, mais l'image doit devenir plus bruitée au fil de la séquence. Vérifie que les valeurs moyennes des pixels de l'échantillon sont proches les unes des autres. Vérifie que les images ne sont pas bloquées à 0 ou 1 (ce qui les ferait ressembler à des lignes plates). Le test peut également être exécuté avec des images RAW en définissant l'indicateur debug dans votre fichier de configuration.

API testées :

Réussite : les images ont la même luminosité, mais deviennent plus bruitées avec un ISO plus élevé. Les plans RVB sont plats lorsque la valeur de ISO*exposure est constante sur l'espace de gain testé.

Mécanisme d'échec : dans la figure ci-dessous, à mesure que les valeurs du multiplicateur de gain (axe x) augmentent, les valeurs moyennes normalisées du plan RVB (axe y) commencent à s'écarter des valeurs du multiplicateur de gain faible.

test_exposure_plot_means

Figure 20.test_exposure_plot_means.

test_exposure_mult=1.00.jpg

Figure 21 : test_exposure_mult=1.00.

test_exposure_mult=64.00

Figure 22 : test_exposure_mult=64.00.

test_latching

Tests qui vérifient que les paramètres (exposition et gain) sont appliqués au bon frame pour les caméras FULL et LEVEL_3. Prend une série de photos à l'aide de requêtes consécutives, en faisant varier les paramètres de la requête de capture entre les photos. Vérifie que les images possèdent les propriétés attendues.

API testées :

Réussite : les images [2, 3, 6, 8, 10, 12, 13] ont une sensibilité ISO ou une exposition plus élevées et présentent des moyennes RVB plus élevées dans le graphique de la figure suivante.

test_latching plot means example

Figure 23 : Exemple de graphique test_latching.

test_latching i=00

Figure 24.test_latching i=00.

test_latching i=01

Figure 25.test_latching i=01.

test_latching i=02

Figure 26.test_latching i=02.

test_latching i=03

Figure 27.test_latching i=03.

test_latching i=04

Figure 28.test_latching i=04.

test_latching i=05

Figure 29 : test_latching i=05.

test_latching i=06

Figure 30. test_latching i=06.

test_latching i=07

Figure 31.test_latching i=07.

test_latching i=08

Figure 32.test_latching i=08.

test_latching i=09

Figure 33.test_latching i=09.

test_latching i=10

Figure 34 : test_latching i=10.

test_latching i=11

Figure 35 : test_latching i=11.

test_latching i=12

Figure 36.test_latching i=12.

test_linearity

Tests permettant de vérifier que le traitement de l'appareil peut être inversé en pixels linéaires. Capture une séquence de prises de vue avec l'appareil pointé sur une cible uniforme.

API testées :

Réussite : les valeurs R, G et B doivent augmenter de manière linéaire avec la sensibilité.

Exemple de signification du graphique test_linearity

Figure 37 : exemple de tracé test_linearity.

test_locked_burst

Teste le verrouillage 3A et la rafale YUV (avec le paramètre automatique). Ce test est conçu pour réussir même sur les appareils limités qui ne disposent pas de MANUAL_SENSOR ni de PER_FRAME_CONTROLS. Le test vérifie la cohérence des images YUV tandis que la vérification de la fréquence d'images se trouve dans CTS.

API testées :

Réussite : les captures semblent cohérentes.

Exemple de test_locked_burst frame0

Figure 38 : Exemple de frame0 test_locked_burst.

test_locked_burst frame1 example

Figure 39 : Exemple de frame1 test_locked_burst.

test_locked_burst_frame2

Figure 40 : Exemple de frame2 test_locked_burst.

scene1_2

scene 1_2 est une copie fonctionnellement identique de scene 1_1, qui implémente une structure de sous-scène pour atténuer la durée étendue de scene 1.

test_param_color_correction

Teste si les paramètres android.colorCorrection.* sont appliqués lorsqu'ils sont définis. Prend des photos avec différentes valeurs de transformation et de gain, et vérifie qu'elles sont différentes. La transformation et les gains sont choisis pour rendre la sortie de plus en plus rouge ou bleue. Utilise un mappage de ton linéaire.

Le mappage de ton est une technique utilisée dans le traitement d'images pour mapper un ensemble de couleurs à un autre afin d'approximer l'apparence des images à plage dynamique élevée dans un support dont la plage dynamique est plus limitée.

API testées :

Réussite : les valeurs R et B sont boostées en fonction de la transformation.

Exemple de signification du graphique test_param_color_correction

Figure 41.Exemple de graphique test_param_color_correction.

Dans les figures suivantes, l'axe x correspond aux requêtes de capture : 0 = unité, 1 = amélioration du rouge et 2 = amélioration du bleu.

test_param_color_correction req=0 unity example

Figure 42 : exemple Unity de test_param_color_correction avec req=0.

test_param_color_correctness req=1 red boost example

Figure 43 : Exemple de test_param_color_correctness req=1 red boost.

test_param_color_correction req=2 blue boost example

Figure 44.Exemple de test_param_color_correction avec req=2 et boost de bleu.

test_param_flash_mode

Teste si le paramètre android.flash.mode est appliqué. Définit manuellement l'exposition sur le côté sombre, de sorte qu'il soit évident de savoir si le flash s'est déclenché ou non, et utilise une cartographie tonale linéaire. Vérifie le centre avec l'image de la vignette pour voir s'il existe un grand dégradé créé pour vérifier si le flash s'est déclenché.

API testées :

Réussite : le centre de l'image de la vignette présente un grand dégradé, ce qui signifie que le flash s'est déclenché.

test_param_flash_mode 1 example

Figure 45 : exemple de test_param_flash_mode 1.

Exemple de bloc test_param_flash_mode 1

Figure 46 : Exemple de vignette test_param_flash_mode.

Exemple test_param_flash_mode_2

Figure 47 : exemple de test_param_flash_mode 2.

Exemple de bloc test_param_flash_mode 2

Figure 48 : Exemple de deux tuiles test_param_flash_mode.

test_param_noise_reduction

Teste si le paramètre android.noiseReduction.mode est correctement appliqué lorsqu'il est défini. Prend des photos avec la caméra faiblement éclairée. Utilise un gain analogique élevé pour s'assurer que l'image capturée est bruitée. Capture trois images : une avec la réduction du bruit désactivée, une avec la réduction du bruit rapide et une avec la réduction du bruit de haute qualité. Capture également une image avec un gain faible et la réduction du bruit désactivée, et utilise la variance de celle-ci comme référence. Plus le rapport signal/bruit est élevé, meilleure est la qualité de l'image.

API testées :

Réussite : le SNR varie en fonction des différents modes de réduction du bruit et se comporte de manière similaire au graphique suivant :

Exemple de tracé des SNR test_param_noise_reduction

Figure 49 : exemple de graphique SNR test_param_noise_reduction.

0 : OFF (DÉSACTIVÉ), 1 : FAST (RAPIDE), 2 : HQ (HAUTE QUALITÉ), 3 : MIN (MINIMALE), 4 : ZSL (ZERO SHUTTER LAG)

test_param_noise_reduction high gain nr=0 example

Figure 50 : Exemple de test_param_noise_reduction avec un gain élevé et nr=0.

Exemple de test_param_noise_reduction avec un gain élevé (nr=1)

Figure 51 : Exemple de test_param_noise_reduction avec un gain élevé et nr=1.

Exemple de test_param_noise_reduction avec un gain élevé (nr=2)

Figure 52 : Exemple de test_param_noise_reduction avec un gain élevé (nr=2).

test_param_noise_reduction high gain nr=3 example

Figure 53 : Exemple de test_param_noise_reduction avec un gain élevé (nr=3).

Exemple de gain faible pour test_param_noise_reduction

Figure 54 : Exemple de test_param_noise_reduction avec un gain faible.

test_param_shading_mode

Teste si le paramètre android.shading.mode est appliqué.

API testées :

Réussite : les modes d'ombrage sont inversés et les cartes d'ombrage de l'objectif sont modifiées comme prévu.

test_param_shading_mode lens shading map, mode 0 loop 0 example

Figure 55 : Exemple de carte de shading d'objectif test_param_shading_mode, boucle 0 du mode 0.

Exemple de boucle 0 du mode 1 de la carte de nuance de l&#39;objectif test_param_shading_mode

Figure 56 : Exemple de carte de shading de l'objectif test_param_shading_mode, boucle 0 du mode 1.

Exemple de boucle 0 du mode 2 de la carte de shading de l&#39;objectif test_param_shading_mode

Figure 57 : Exemple de carte de shading de l'objectif test_param_shading_mode, boucle 0 du mode 2.

test_param_tonemap_mode

Teste si le paramètre android.tonemap.mode est appliqué. Applique différentes courbes de mappage de ton à chaque canal R, G et B, et vérifie que les images de sortie sont modifiées comme prévu. Ce test se compose de deux tests, test1 et test2.

API testées :

Pass (Réussite) :

  • test1 : les deux images ont une cartographie tonale linéaire, mais n=1 a un gradient plus élevé. Le canal G (vert) est plus lumineux pour l'image n=1.
  • test2 : même mappage de ton, mais longueur différente. Les images sont identiques.

test_param_tonemap_mode avec n=0

Figure 58 : test_param_tonemap_mode avec n=0.

test_param_tonemap_mode avec n=1

Figure 59 : test_param_tonemap_mode avec n=1.

test_post_raw_sensitivity_boost

Vérifie l'augmentation de la sensibilité brute après la publication. Capture un ensemble d'images brutes et YUV avec différentes sensibilités, publie la combinaison d'augmentation de sensibilité brute et vérifie si la moyenne des pixels de sortie correspond aux paramètres de la requête.

API testées :

Réussite : les images brutes s'assombrissent à mesure que le boost augmente, tandis que la luminosité des images YUV reste constante.

test_post_raw_sensitivity_boost raw s=3583 boost=0100 example

Figure 60 : exemple de test_post_raw_sensitivity_boost avec s=3583 et boost=0100.

test_post_raw_sensitivity_boost raw s=1792 boost=0200 example

Figure 61 : Exemple de test_post_raw_sensitivity_boost brut s=1792 boost=0200.

test_post_raw_sensitivity_boost raw s=0896 boost=0400 example

Figure 62 : Exemple de test_post_raw_sensitivity_boost avec s=0896 et boost=0400.

test_post_raw_sensitivity_boost raw s=0448 boost=0800 example

Figure 63 : Exemple de test_post_raw_sensitivity_boost brut s=0448 boost=0800.

test_post_raw_sensitivity_boost raw s=0224 boost=1600 example

Figure 64.Exemple de test_post_raw_sensitivity_boost avec s=0224 et boost=1600.

test_post_raw_sensitivity_boost raw s=0112 boost=3199 example

Figure 65 : exemple de test_post_raw_sensitivity_boost avec s=0112 et boost=3199.

test_post_raw_sensitivity_boost raw plot means example

Figure 66 : Exemple de graphique brut des moyennes de test_post_raw_sensitivity_boost.

test_post_raw_sensitivity_boost YUV s=0112 boost=3199 example

Figure 67 : exemple de test_post_raw_sensitivity_boost YUV s=0112 boost=3199.

test_post_raw_sensitivity_boost YUV s=0448 boost=0800 example

Figure 68 : Exemple de test_post_raw_sensitivity_boost YUV s=0448 boost=0800.

test_post_raw_sensitivity_boost YUV s=0896 boost=0400 example

Figure 69 : exemple de test_post_raw_sensitivity_boost YUV s=0896 boost=0400.

test_post_raw_sensitivity_boost YUV s=1792 boost=0200 example

Figure 70.Exemple de test_post_raw_sensitivity_boost YUV s=1792 boost=0200.

test_post_raw_sensitivity_boost YUV s=3585 boost=0100 example

Figure 71 : Exemple de test_post_raw_sensitivity_boost YUV s=3585 boost=0100.

test_post_raw_sensitivity_boost_yuv_plot_means

Figure 72 : test_post_raw_sensitivity_boost_yuv_plot_means

test_raw_exposure

Capture un ensemble d'images brutes avec un temps d'exposition croissant et mesure les valeurs de pixels.

API testées :

Réussite : l'augmentation de l'ISO (gain) rend les pixels plus sensibles à la lumière, de sorte que le graphique se déplace vers la gauche.

Exemple test_raw_exposure ISO=55

Figure 73 : exemple de test_raw_exposure ISO=55.

10⁰ = 1 ms, 10¹ = 10 ms et 10⁻¹ = 0, 1 ms.

Exemple test_raw_exposure ISO=132

Figure 74 : Exemple de test_raw_exposure ISO=132.

Exemple test_raw_exposure ISO=209

Figure 75 : Exemple de test_raw_exposure ISO=209.

Exemple de test_raw_exposure ISO=286

Figure 76 : Exemple de test_raw_exposure ISOs=286.

Exemple test_raw_exposure ISO=363

Figure 77 : Exemple de test_raw_exposure ISO=363.

test_raw_exposure_s=440

Figure 78 : Exemple de test_raw_exposure ISO=440.

test_reprocess_noise_reduction

Tests auxquels android.noiseReduction.mode est appliqué pour les demandes de retraitement. Capture des images retraitées avec la caméra faiblement éclairée. Utilise un gain analogique élevé pour vérifier que l'image capturée est bruyante. Capture trois images retraitées, pour la réduction du bruit désactivée, rapide et de haute qualité. Capture une image retraitée avec un gain faible et la réduction du bruit désactivée, et utilise la variance de cette image comme référence.

API testées :

Pass : FAST >= OFF, HQ >= FAST et HQ >> OFF.

Graphique typique du SNR par rapport au mode NR

Figure 79. Exemple de graphique typique du SNR par rapport au mode NR.

test_tonemap_sequence

Teste une séquence de prises de vue avec différentes courbes de tonemap. Capture trois photos manuelles avec une cartographie tonale linéaire. Capture trois photos manuelles avec la cartographie de ton par défaut. Calcule le delta entre chaque paire d'images consécutives.

API testées :

Réussite : trois images identiques sont suivies d'un autre ensemble de trois images identiques.

Exemple de test_tonemap_sequence i=0

Figure 80 : exemple de test_tonemap_sequence i=0.

test_tonemap_sequence i=1 example

Figure 81 : exemple de test_tonemap_sequence i=1.

Exemple test_tonemap_sequence i=2

Figure 82 : exemple test_tonemap_sequence i=2.

test_tonemap_sequence i=3 example

Figure 83 : exemple de test_tonemap_sequence i=3.

Exemple test_tonemap_sequence_i=4

Figure 84 : exemple de test_tonemap_sequence i=4.

test_tonemap_sequence i=5 example

Figure 85 : exemple de test_tonemap_sequence i=5.

test_yuv_jpeg_all

Tests qui vérifient que toutes les tailles et tous les formats signalés pour la capture d'images fonctionnent. Utilise une requête manuelle avec une table de tonalités linéaire afin que les formats YUV et JPEG se ressemblent lorsqu'ils sont convertis par le module image_processing_utils. Les images ne sont pas enregistrées par défaut, mais vous pouvez les enregistrer en activant debug_mode.

API testées :

Réussite : tous les centres d'images présentent une différence maximale de racine carrée moyenne (RMS, Root Mean Square) (valeur d'un signal) dans les images converties au format RVB avec 3 % de l'image YUV à la résolution la plus élevée.

Exemple test_yuv_jpeg_all

Exemple Figure 86 test_yuv_jpeg_all.

test_yuv_plus_dng

Teste le bon fonctionnement des tailles et formats signalés pour la capture d'images.

API testées :

Réussite : le test se termine et renvoie les images demandées.

Exemple test_yuv_plus_dng

Figure 87 : Exemple test_yuv_plus_dng.

scene1_3

scene 1_3 est une copie fonctionnellement identique de scene 1_1, qui implémente une structure de sous-scène pour atténuer la durée étendue de scene 1.

test_capture_result

Teste que des données valides sont renvoyées dans les objets CaptureResult. Le test se compose d'une capture automatique, d'une capture manuelle et d'une deuxième capture automatique.

API testées :

Réussite : les métadonnées sont valides pour toutes les captures et les paramètres manuels ne sont pas répercutés dans la deuxième capture automatique. Trace la correction de l'ombrage de l'objectif pour les captures.

test_capture_result_plot_lsc_auto_ch0

Figure 88 : test_capture_result_plot_lsc_auto_ch0.

test_dng_noise_model

Vérifie que les paramètres du modèle brut DNG sont corrects. Le graphique représente la variance mesurée d'un patch central de la carte grise dans les clichés bruts capturés sur une plage de sensibilités, et compare ces valeurs à la variance attendue à chaque sensibilité par le modèle de bruit DNG dans le HAL de l'appareil photo (basé sur les paramètres O et S renvoyés dans les objets de résultat de capture). Pour en savoir plus sur le modèle de bruit DNG, téléchargez le document suivant sur le modèle de bruit DNG.

API testées :

Réussite : les paramètres du modèle brut DNG sont corrects. Les valeurs RVB attendues correspondent aux valeurs RVB réelles mesurées.

test_dng_noise_model_plog

Figure 89.test_dng_noise_model_plog.

test_jpeg

Les tests qui ont converti les images YUV et les images JPEG de l'appareil ont la même apparence. Le test prend les 10 % du centre de l'image, calcule la valeur RVB et vérifie qu'elle correspond.

API testées :

Réussite : la différence RGB moyenne entre chaque image est inférieure à 3 %.

test_jpeg_fmt=jpg.jpg

Figure 90.test_jpeg_fmt=jpg.jpg.

test_jpeg=fmt=yuv.jpg

Figure 91.test_jpeg=fmt=yuv.jpg.

test_raw_burst_sensitivity

Capture un ensemble d'images brutes avec des gains croissants et mesure le bruit. Capture des images brutes uniquement, en rafale.

API testées :

Réussite : chaque prise est plus bruyante que la précédente, car le gain augmente.

Utilise la variance de la cellule de la grille de statistiques du centre.

test_raw_burst_sensitivity_variance

Figure 92 : test_raw_burst_sensitivity_variance.

test_raw_sensitivity

Capture un ensemble d'images brutes avec des sensibilités croissantes et mesure le bruit (variance) dans les 10 % centraux de l'image. Tests visant à vérifier que chaque prise est plus bruyante que la précédente.

API testées :

Passe : la variance augmente à chaque tir.

test_raw_sensitivity_variance

Figure 93.test_raw_sensitivity_variance.

test_yuv_plus_jpeg

Tests de capture d'un seul frame en tant que sorties YUV et JPEG. Utilise une requête manuelle avec une table de tonalités linéaire afin que les formats YUV et JPEG se ressemblent lorsqu'ils sont convertis par le module image_processing_utils.

API testées :

Réussite : les images YUV et JPEG sont similaires et présentent une différence RMS (valeur d'un signal) inférieure à 1 %.

test_yuv_plus_jpeg avec le format JPEG

Figure 94.test_yuv_plus_jpeg avec le format JPEG.

test_yuv_plus_jpeg avec le format YUV

Figure 95.test_yuv_plus_jpeg avec le format YUV.

test_yuv_plus_raw

Tests capturant un seul frame en tant que sorties brutes (brutes 10 bits et 12 bits) et YUV, si pris en charge. Utilise une requête manuelle avec une cartographie tonale linéaire, de sorte que les formats Raw et YUV devraient être identiques. Compare les 10 % de valeurs RVB au centre des images converties en RVB. Journauxandroid.shading.mode.

API testées :

Réussite : les images YUV et brutes sont similaires et présentent une différence RMS (valeur quadratique moyenne d'un signal) inférieure à 3,5 %.

test_yuv_plus_raw_shading=1_raw.jpg

Figure 96.test_yuv_plus_raw_shading=1_raw.jpg.

test_yuv_plus_raw_shading=1_yuv.jpg

Figure 97. test_yuv_plus_raw_shading=1_yuv.jpg.

test_sensitivity_priority

Tests CONTROL_AE_PRIORITY_MODE_SENSOR_SENSITIVITY_PRIORITY avec différents paramètres ISO pour confirmer la corrélation entre un ISO élevé et des niveaux de bruit accrus.

API testées :

Réussite : un ISO plus élevé entraîne une augmentation du niveau de bruit.

Critères de désactivation des tests

Le test test_sensitivity_priority.py est ignoré si l'un des critères suivants est rempli :

test_exposure_time_priority

Tests CONTROL_AE_PRIORITY_MODE_SENSOR_EXPOSURE_TIME_PRIORITY avec différents temps d'exposition, en vérifiant la luminosité stable dans la plage où l'ISO peut compenser.

API testées :

Réussite : la luminosité est stable (dans les limites de tolérance) pour toutes les durées d'exposition si l'ISO se situe dans sa plage de compensation.

Critères de désactivation des tests

Le test test_exposure_time_priority est ignoré si l'un des critères suivants est rempli :

scene2_a

scene2_a : trois visages sur fond gris, avec des vêtements neutres. Les visages sont choisis pour représenter un large éventail de couleurs de peau. Le graphique doit être orienté correctement pour que la détection des visages fonctionne de manière optimale.

Exemple de scene2_a

Figure 98 : exemple de scene2_a.

test_autoframing

Teste le comportement de cadrage automatique de la caméra. Effectue un zoom arrière important pour que plus aucun visage de la scène ne soit visible, active le mode de recadrage automatique en définissant AUTOFRAMING dans CaptureRequest sur True, puis vérifie si tous les visages de la scène d'origine peuvent être détectés lorsque l'état converge (c'est-à-dire lorsque AUTOFRAMING_STATE dans CaptureResult est défini sur AUTOFRAMING_STATE_CONVERGED).

API testées :

Réussite : les trois visages sont détectés.

test_display_p3

Tests de capture Display P3 au format JPEG à l'aide de l'API ColorSpaceProfiles. Teste si le fichier JPEG capturé comporte un profil ICC approprié dans son en-tête et si l'image contient des couleurs en dehors de la gamme sRGB.

API testées :

Réussite : le fichier JPEG contient un profil ICC Display P3 et des couleurs en dehors de la gamme sRGB.

test_effects

Capture une image pour les effets de caméra compatibles et vérifie s'ils sont générés correctement. Le test ne vérifie que les effets OFF et MONO, mais enregistre les images pour tous les effets compatibles.

API testées :

Pass : capture l'image de la scène avec les effets OFF et une image monochrome avec les effets définis sur MONO.

test_effects_MONO

Figure 99.test_effects_MONO.

test_exposure_keys_consistent

Ce test compare la luma moyenne d'une capture avec AE activé à celle d'une capture avec AE désactivé qui applique manuellement les paramètres d'exposition (sensibilité, durée d'exposition, durée de la frame, augmentation de la sensibilité post-RAW) reçus dans CaptureResult de la capture avec AE activé.

API testées :

Réussite : la différence relative de luminosité entre les deux captures est inférieure à 4 %.

test_format_combos

Teste différentes combinaisons de formats de sortie.

API testées :

Réussite : toutes les combinaisons ont été capturées avec succès.

test_num_faces

Teste la détection des visages.

API testées :

Réussite : trois visages sont trouvés.

Exemple de test_num_faces en mode de détection des visages 1

Figure 100 : Exemple du mode 1 de détection des visages test_num_faces.

test_reprocess_uv_swap

Teste que le retraitement YUV n'inverse pas les plans U et V. Cela est détecté en calculant la somme des différences absolues (SAD) entre l'image retraitée et une capture non retraitée. Si l'échange des plans U et V de la capture retraitée entraîne une augmentation de la SAD, on suppose que la sortie comporte les plans U et V corrects.

API testées :

Réussite : les plans U et V ne sont pas inversés.

test_reprocess_uv_swap

Figure 101 : exemple de test_reprocess_uv_swap.

scene2_b

test_preview_num_faces

Test de la détection des visages dans l'aperçu avec une plus grande diversité de carnations dans les scènes de visages.

API testées :

Réussite : trois visages avec des points de repère faciaux sont trouvés dans les cadres de délimitation des visages.

test_num_faces_fd_mode_1

Figure 102 : exemple du mode 1 de détection des visages test_num_faces.

test_yuv_jpeg_capture_sameness

Capture deux images en utilisant les formats YUV et JPEG communs les plus grands, avec le même format que le plus grand format JPEG ne dépassant pas une résolution de 1920x1440. Définit jpeg.quality sur 100 et capture une requête double surface. Convertit les deux images en tableaux RGB et calcule la différence RMS (Root Mean Square) 3D entre les deux images.

Ce test vérifie également que les sorties YUV pour tous les cas d'utilisation de flux compatibles sont raisonnablement similaires à celles de l'utilisation de STILL_CAPTURE.

API testées :

Réussite : les images YUV et JPEG pour le cas d'utilisation STILL_CAPTURE présentent une différence RMS (valeur quadratique moyenne d'un signal) inférieure à 3 %. Les images YUV pour tous les cas d'utilisation compatibles présentent une différence RMS inférieure à 10 % par rapport aux images YUV avec le cas d'utilisation STILL_CAPTURE.

scene2_c

test_num_faces

Teste la détection des visages avec une diversité accrue des carnations dans les scènes de visages.

API testées :

Réussite : trois visages sont trouvés.

test_num_faces_fd_mode_1

Figure 103 : exemple du mode de détection des visages test_num_faces.

test_jpeg_capture_perf_class

Teste la latence de capture JPEG pour la classe de performances S, comme spécifié dans la section 2.2.7.2 Caméra du CDD.

Réussite : la latence de capture JPEG camera2 DOIT être inférieure à 1 000 ms pour une résolution de 1080p, telle que mesurée par le test CTS camera PerformanceTest dans des conditions d'éclairage ITS (3 000 K) pour les deux caméras principales.

test_camera_launch_perf_class

Teste la latence de lancement de l'appareil photo pour la classe de performances S, comme spécifié dans la section 2.2.7.2 Appareil photo du CDD.

Réussite : la latence de démarrage de camera2 (ouverture de l'appareil photo à la première image d'aperçu) DOIT être inférieure à 600 ms, mesurée par le test de performances de l'appareil photo CTS dans les conditions d'éclairage ITS (3 000 K) pour les deux caméras principales.

test_default_camera_hdr

Tests permettant de vérifier que la capture par défaut de l'appareil photo est en Ultra HDR pour la classe de performances 15, comme indiqué dans la section 2.2.7.2 Appareil photo du CDD.

Réussite : la capture du package de caméras par défaut DOIT être en Ultra HDR pour un appareil de classe de performances 15.

scene2_d

test_preview_num_faces

Test de la détection des visages dans l'aperçu avec une plus grande diversité de carnations dans les scènes de visages.

API testées :

Réussite : trois visages avec des points de repère faciaux sont trouvés dans les cadres de délimitation des visages.

scene2_e

test_continuous_picture

50 images de résolution VGA sont capturées avec le premier paramètre de requête de capture défini sur android.control.afMode = 4 (CONTINUOUS_PICTURE).

API testées :

Réussite : le système 3A se stabilise à la fin d'une capture de 50 images.

test_num_faces

Teste la détection des visages avec une diversité accrue des carnations dans les scènes de visages.

API testées :

Succès : trois visages sont détectés.

scene2_f

scene2_f comporte trois visages avec un arrière-plan et des vêtements blancs. Les visages ont une large gamme de carnations et un contraste élevé avec l'arrière-plan.

scene2_f example

Exemple Figure 104 de scene2_f.

test_preview_num_faces

Teste la détection des visages avec une diversité accrue des carnations dans les scènes de visages.

API testées :

Réussite : trois visages avec des points de repère faciaux sont trouvés dans les cadres de délimitation des visages.

test_num_faces_fd_mode_1

Exemple Figure 105 de test_num_faces_fd_mode_1.

scene2_g

scene2_g : trois visages de profil sur un arrière-plan blanc et avec des vêtements blancs. Les visages ont une large gamme de teintes de peau et un contraste élevé avec l'arrière-plan.

scene2_g.png

Figure 106 : exemple scene2_g.

test_preview_num_faces

Teste la détection des visages avec une diversité accrue des carnations dans les scènes de visages.

API testées :

Réussite : trois visages avec des points de repère faciaux sont trouvés dans les cadres de délimitation des visages.

test_preview_num_faces

Figure 107 : exemple de test_preview_num_faces.

scene3

scene3 utilise le graphique ISO12233, et la plupart des tests utilisent une méthode d'extraction de graphique pour trouver le graphique dans la scène. C'est pourquoi la plupart des images enregistrées n'ont pas de bordures comme celles des scènes 1, 2 ou 4, mais uniquement le graphique. Pour que l'outil de recherche de graphiques fonctionne de manière optimale, le graphique doit être orienté correctement.

test_edge_enhancement

Teste si le paramètre android.edge.mode est appliqué correctement. Capture des images non retraitées pour chaque mode Edge et renvoie la netteté de l'image de sortie et les métadonnées du résultat de la capture. Traite une demande de capture avec un mode Edge, une sensibilité, un temps d'exposition, une distance de mise au point et un paramètre de surface de sortie donnés.

Réussite : le mode HQ (2) est plus net que le mode OFF (0). Le mode FAST est (1) plus net que le mode OFF. Mode HQ ou mode plus net que FAST.

API testées :

Paramètres de caméra concernés :

  • EDGE_MODE

test_edge_enhancement_edge=0

Figure 108 : exemple de test_edge_enhancement avec edge=0.

test_edge_enhancement edge=1 example

Figure 109 : Exemple de test_edge_enhancement edge=1 (mode rapide).

Exemple test_edge_enhancement edge=2

Figure 110 : exemple de test_edge_enhancement edge=2 (mode haute qualité).

test_flip_mirror

Teste si l'image est correctement orientée conformément à la section 7.5.2 Caméra frontale du CDD.

Les images en miroir, inversées ou pivotées peuvent être identifiées par le losange situé près du centre.

Acceptée : l'image n'est pas inversée, mise en miroir ni pivotée.

Exemple de patch de scène test_flip_mirror

Figure 111.Exemple de correctif de scène test_flip_mirror.

test_imu_drift

Teste si l'unité de mesure inertielle (IMU) a une sortie stable pendant 30 secondes lorsque l'appareil est immobile et capture un aperçu haute définition.

API testées :

Pass (Réussite) :

  • La dérive du gyroscope est inférieure à 0,01 rad pendant la durée du test.
  • La variance de la lecture du gyroscope est inférieure à 1E-7 rad2/s2/Hz pendant la durée du test.
  • La dérive du vecteur de rotation est inférieure à 0,01 rad pendant la durée du test.
  • (Non encore obligatoire) La dérive du gyroscope est inférieure à 1 degré par seconde.

Exemple de dérive du gyroscope test_imu_drift

Figure 112 : exemple de dérive du gyroscope test_imu_drift.

Exemple de dérive du vecteur de rotation test_imu_drift

Figure 113 : exemple de dérive du vecteur de rotation test_imu_drift.

test_landscape_to_portrait

Teste si le remplacement du mode Paysage par le mode Portrait fonctionne correctement pour les capteurs orientés Paysage.

API testées :

Réussite : le test localise un graphique avec la rotation attendue (0 degré lorsque le remplacement du mode Paysage par le mode Portrait est désactivé, 90 degrés lorsqu'il est activé).

Exemple test_landscape_to_portrait

Figure 114 : exemple de test_landscape_to_portrait.

test_lens_movement_reporting

Teste si l'indicateur de mouvement de l'objectif est correctement signalé. Capture une rafale de 24 images, les 12 premières à la distance de mise au point optimale (déterminée par 3A) et les 12 dernières à la distance de mise au point minimale. Vers la 12e image, l'objectif se déplace, ce qui entraîne une baisse de la netteté. La netteté se stabilise finalement lorsque l'objectif atteint sa position finale.

L'indicateur de mouvement de l'objectif doit être activé dans toutes les images où la netteté est intermédiaire entre la netteté des premières images avec l'objectif immobile à la distance focale optimale et celle des dernières images avec l'objectif immobile à la distance focale minimale. Le nombre exact d'images pendant lesquelles l'objectif se déplace n'est pas important. Ce qui compte, c'est que l'indicateur de mouvement soit activé lorsque l'objectif se déplace.

API testées :

Réussite : le drapeau de mouvement de l'objectif est défini sur True dans le frame avec changement de netteté.

Mécanismes d'échec :

  • lens_moving: True (android.hardware.camera2.CaptureResult#LENS_STATE = 1) dans test_log.DEBUG n'est affirmé que dans les frames où la netteté ne change pas.
  • Les images avec lens_moving: False (android.hardware.camera2.CaptureResult#LENS_STATE = 0) dans test_log.DEBUG présentent une différence de netteté par rapport aux premières images à la distance focale optimale ou aux dernières images à la distance de mise au point minimale.

test_reprocess_edge_enhancement

Teste si les méthodes de retraitement compatibles pour l'amélioration des contours fonctionnent correctement. Traite une demande de capture avec un mode Edge de retraitement donné et compare différents modes de capture avec les modes Edge de retraitement désactivés.

API testées :

Réussite : la netteté des différents modes de contour est correcte. HQ (mode 2) est plus net que OFF (mode 0), et l'amélioration entre les différents modes est similaire.

Exemple de graphique test_reprocess_edge_enhancement

Figure 115 : exemple de graphique test_reprocess_edge_enhancement.

scene4

scene4 : un cercle noir sur un fond blanc à l'intérieur d'un carré.

Les tests dans scene4 peuvent être sensibles à l'alignement. Ainsi, à partir d'Android 15, vous pouvez utiliser check_alignment.py dans le répertoire des outils pour activer une vérification de l'alignement de l'appareil sous test et du graphique.

scene4 example

Figure 116 : exemple de scène4.

test_30_60fps_preview_fov_match

Tests permettant de vérifier que les vidéos d'aperçu à 30 FPS et 60 FPS ont le même champ de vision. Le test capture deux vidéos, l'une à 30 FPS et l'autre à 60 FPS. Une image représentative est sélectionnée dans chaque vidéo et analysée pour vérifier que les changements de champ de vision dans les deux vidéos sont conformes aux spécifications. Tests permettant de vérifier que les proportions du cercle restent constantes, que le centre du cercle reste stable et que le rayon du cercle reste constant.

API testées :

Réussite : les images ne sont pas étirées, le centre des images ne diffère pas de plus de 3 % et le changement maximal du format entre les vidéos à 30 FPS et à 60 FPS ne dépasse pas 7,5 %.

Mécanismes d'échec :

  • Le cercle de la vidéo à 30 FPS est de taille très différente de celui de la vidéo à 60 FPS.
  • Le cercle de l'image capturée est déformé par le pipeline de traitement.
  • Le cercle de l'image capturée est recadré en raison d'une demande de capture avec un rapport hauteur/largeur extrême, ce qui réduit la hauteur ou la largeur de l'image.
  • Le cercle de l'image capturée présente un reflet au centre et ne semble pas entièrement rempli.

test_aspect_ratio_and_crop

Teste si les images sont déformées ou recadrées de manière inattendue dans le pipeline d'images. Prend en photo un cercle dans tous les formats. Vérifiez que le cercle n'est pas déformé, qu'il ne se déplace pas du centre de l'image et que sa taille ne change pas de manière incorrecte avec différents formats ou résolutions.

API testées :

Réussite : les images ne sont pas étirées, le centre des images ne diffère pas de plus de 3 % et le champ de vision maximal possible est conservé.

Mécanismes d'échec :

  • La caméra n'est pas alignée sur le cercle affiché sur la tablette au centre de la scène capturée.
  • Le cercle de l'image capturée est déformé par le pipeline de traitement.
  • L'image basse résolution est doublement recadrée dans le pipeline d'images, ce qui crée un champ de vision différent entre les images haute et basse résolution.
  • Le cercle de l'image capturée est recadré en raison d'une demande de capture avec un rapport hauteur/largeur extrême, ce qui réduit la hauteur ou la largeur de l'image.
  • Le cercle de l'image capturée présente un reflet au centre et ne semble pas entièrement rempli.

test_multi_camera_alignment

Teste les paramètres de calibration de la caméra liés à son positionnement pour les systèmes multicaméras. Prend une photo avec l'une des caméras physiques à l'aide des sous-caméras physiques multicaméras. Trouve le centre du cercle. Projete le centre du cercle dans les coordonnées du monde pour chaque caméra. Compare la différence entre les centres des cercles des caméras dans les coordonnées du monde. Reprojette les coordonnées mondiales en coordonnées de pixels et les compare aux coordonnées d'origine pour vérifier leur validité. Compare les tailles des cercles pour vérifier si les focales des caméras sont différentes.

API testées :

Réussite : les centres et les tailles des cercles sont conformes aux attentes dans les images projetées par rapport aux images capturées à l'aide des données de calibration de la caméra et des distances focales.

Mécanismes d'échec :

  • LENS_INTRINSIC_CALIBRATION, LENS_POSE_TRANSLATION et LENS_POSE_ROTATION sont des valeurs de conception et non des données de calibration réelles.
  • Le système de caméras n'est pas adapté à la configuration du test, par exemple, tester un système de caméras grand-angle et ultra grand-angle avec le banc de test RFoV. Pour en savoir plus, consultez les questions fréquentes sur Camera ITS-in-a-box Q1.

test_preview_aspect_ratio_and_crop

Semblable au test test_aspect_ratio_and_crop pour les captures fixes, il vérifie les formats d'aperçu compatibles pour s'assurer que les frames d'aperçu ne sont pas étirées ni recadrées de manière inappropriée. Vérifie que le format du cercle ne change pas, que les images recadrées conservent le cercle au centre du cadre et que la taille du cercle ne change pas pour un format constant ou avec différentes résolutions (vérification du champ de vision).

API testées :

Réussite : les images ne sont pas étirées, le centre des images ne diffère pas de plus de 3 % et le champ de vision maximal possible est conservé.

test_preview_stabilization_fov

Vérifie les tailles d'aperçu compatibles pour s'assurer que le champ de vision est recadré correctement. Le test capture deux vidéos : l'une avec la stabilisation de l'aperçu ON et l'autre avec la stabilisation de l'aperçu OFF. Une image représentative est sélectionnée dans chaque vidéo et analysée pour vérifier que les changements de champ de vision dans les deux vidéos sont conformes aux spécifications.

API testées :

Réussite : le format du cercle reste à peu près constant, l'emplacement du centre du cercle reste stable et la taille du cercle ne change pas de plus de 20 %.

test_video_aspect_ratio_and_crop

Prend des vidéos d'un cercle à l'intérieur d'un carré dans tous les formats vidéo. Extrait les images clés et vérifie que les proportions du cercle ne changent pas, que les images recadrées conservent le cercle au centre et que la taille du cercle ne change pas pour un format constant ou avec une résolution différente (vérification du champ de vision).

API testées :

Réussite : les images vidéo ne sont pas étirées, le centre des images ne diffère pas de plus de 3 % et le champ de vision maximal possible est conservé.

scene5

scene5 nécessite une scène grise uniformément éclairée. Pour cela, un diffuseur est placé sur l'objectif de la caméra. Nous vous recommandons le diffuseur suivant : www.edmundoptics.com/optics/window-diffusers/optical-diffusers/opal-diffusing-glass/46168.

Pour préparer la scène, fixez un diffuseur devant la caméra et pointez-la vers une source de lumière d'environ 2 000 lux. Les images capturées pour scene5 doivent être prises avec une lumière diffuse, sans aucun élément visible. Voici un exemple d'image :

scene5 example

Figure 117 : exemple de capture scene5.

test_lens_shading_and_color_uniformity

Teste si la correction de l'ombrage de l'objectif est appliquée correctement et si la couleur d'une scène monochrome uniforme est répartie de manière égale. Effectue ce test sur un frame YUV avec 3A automatique. L'ombrage de l'objectif est évalué en fonction du canal Y. Mesure la valeur y moyenne pour chaque bloc d'échantillon spécifié et détermine la réussite ou l'échec en comparant avec la valeur y centrale. Le test d'uniformité des couleurs est évalué dans l'espace rouge-vert et bleu-vert.

API testées :

Réussite : dans le rayon spécifié de l'image, la variance de la valeur rouge-vert et bleu-vert doit être inférieure à 20 % pour que le test soit réussi.

scene6

scene6 est une grille de marqueurs ArUco identifiables de manière unique. Les tests dans scene6 peuvent être sensibles à l'alignement. Par conséquent, à partir de la version 15, vous pouvez utiliser check_alignment.py dans le répertoire des outils pour activer une vérification de l'alignement du DUT et du graphique.

scene6

Figure 118 : exemple de scene6.

test_in_sensor_zoom

Teste le comportement de la fonctionnalité de zoom du capteur de la caméra, qui produit des images brutes recadrées.

Lorsque le cas d'utilisation du flux est défini sur CROPPED_RAW, le test effectue deux captures sur la plage de zoom : une image brute avec un champ de vision complet et une image brute recadrée. Le test convertit les images en tableaux RVB, réduit l'image brute recadrée en taille réelle à la taille indiquée par SCALER_RAW_CROP_REGION et calcule la différence RMS 3D entre les deux images.

API testées :

Réussite : la différence RMS 3D entre l'image brute recadrée et réduite et l'image brute avec champ de vision complet est inférieure au seuil défini dans le test.

test_zoom

Teste le comportement du zoom de la caméra, de l'objectif ultra grand-angle à l'objectif grand-angle. Prend des photos sur la plage de zoom et vérifie si les marqueurs ArUco grossissent lorsque la caméra effectue un zoom avant. Le test vérifie également si la position du repère central change de manière prévisible à chaque capture. La distance entre le centre du repère central et le centre de l'image peut changer à un rythme constant par rapport au facteur de zoom jusqu'à ce qu'un changement de caméra physique se produise, ou elle peut changer de manière monotone vers l'emplacement du même repère après un changement de caméra physique. L'application Jetpack Camera (JCA) doit être installée sur l'appareil avant le test.

API testées :

Réussite : la taille relative du marqueur ArUco capturé est précise par rapport au facteur de zoom demandé pour vérifier que la caméra effectue correctement le zoom, et la distance du marqueur par rapport au centre de l'image change selon les critères indiqués dans la description du test.

test_zoom pour trouver le contour du marqueur ArUco le plus proche du centre

Figure 119 : test_zoom pour trouver le contour du marqueur ArUco le plus proche du centre.

test_low_latency_zoom

Teste le comportement du zoom à faible latence de la caméra. Prend des photos sur la plage de zoom avec android.control.settingsOverride = 1 (SETTINGS_OVERRIDE_ZOOM) et vérifie si les repères dans les images de sortie correspondent aux rapports de zoom dans les métadonnées de capture. La même session de capture de caméra est utilisée pour la convergence 3A et la prise de photos.

API testées :

Réussite : la taille relative du repère capturé est précise par rapport aux métadonnées du résultat du facteur de zoom.

test_preview_video_zoom_match

Tests qui, lors de l'enregistrement et du zoom, affichent et enregistrent la même sortie pour l'aperçu vidéo et la sortie vidéo. Calcule la taille du repère le plus proche du centre à différents niveaux de zoom et vérifie si la taille du repère augmente à mesure que le niveau de zoom augmente.

API testées :

Réussite : la taille relative du repère capturé est précise par rapport au niveau de zoom demandé dans la vidéo et l'aperçu.

HD_1280x720_key_frame.png

Figure 120 : HD_1280x720_key_frame.png (avant le zoom).

preview_1280x720_key_frame.png

Figure 121.preview_1280x720_key_frame.png (avant le zoom).

HD_1280x720_key_frame_zoomed.png

Figure 122. HD_1280x720_key_frame.png (après zoom).

preview_1280x720_key_frame_zoomed.png

Figure 123.preview_1280x720_key_frame.png (après zoom).

test_preview_zoom

Tests visant à vérifier que le rapport de zoom de chaque frame d'aperçu correspond aux métadonnées de capture correspondantes de l'objectif ultra grand-angle à l'objectif grand-angle. Le test prend des aperçus d'images sur la plage de zoom et trouve le marqueur ArUco le plus proche du centre. Le test vérifie ensuite si la position du repère central change de manière prévisible à chaque capture. La distance entre le centre du repère central et le centre de l'image peut changer à un rythme constant par rapport au facteur de zoom jusqu'à ce qu'un changement de caméra physique se produise, ou elle peut changer de manière monotone vers l'emplacement du même repère après un changement de caméra physique.

API testées :

Réussite : la taille relative du marqueur ArUco sélectionné est précise pour le rapport de zoom indiqué du résultat de capture correspondant pour toutes les images de l'aperçu. La distance relative du repère sélectionné par rapport au centre de l'image est précise pour le rapport de zoom indiqué du résultat de capture correspondant de toutes les images d'aperçu.

test_preview_zoom images showing selected marker closest to the center

Figure 124 : Images de prévisualisation du test test_preview_zoom montrant le repère sélectionné le plus proche du centre

test_session_characteristics_zoom

Teste la plage de rapport de zoom pour toutes les configurations de session compatibles listées dans CameraCharacteristics#INFO_SESSION_CONFIGURATION_QUERY_VERSION. Pour chacune de ces configurations, si CameraDeviceSetup#isSessionConfigurationSupported renvoie true, le test vérifie que la plage de rapport de zoom renvoyée dans CameraDeviceSetup#getSessionCharacteristics peut être atteinte.

API testées :

Réussite : les rapports de zoom minimal et maximal peuvent être atteints pour chaque SessionConfiguration compatible listé dans CameraCharacteristics#INFO_SESSION_CONFIGURATION_QUERY_VERSION.

scene7

scene7 est un cadre rectangulaire divisé en quatre quadrants égaux, chacun rempli d'une couleur différente. Au centre du rectangle se trouve un graphique à bord incliné pour vérifier la netteté. Quatre marqueurs ArUco sont alignés sur les quatre coins extérieurs du rectangle pour vous aider à obtenir des coordonnées précises du cadre principal du rectangle à différents niveaux de zoom.

scene7

Figure 125 : scene7.

test_multi_camera_switch

Ce test vérifie que, lors de l'enregistrement de l'aperçu à différents niveaux de zoom, le passage de l'objectif ultra grand-angle (UW) à l'objectif grand-angle (W) entraîne des valeurs RVB similaires.

Le test utilise différents rapports de zoom dans la plage prédéfinie pour effectuer un enregistrement d'aperçu dynamique et identifier le point auquel la caméra physique change. Ce point marque la transition entre l'objectif UW et l'objectif W.

Les frames capturées au point de croisement et avant sont analysées pour l'exposition automatique (AE), la balance des blancs automatique (AWB) et la mise au point automatique (AF).

La vérification de l'AE permet de s'assurer que la variation de luminosité se situe dans la plage attendue pour les images des objectifs UW et W. Le contrôle de la balance des blancs vérifie que les rapports rouge/vert et bleu/vert sont compris dans les seuils pour les images prises avec l'objectif ultra grand-angle et l'objectif grand-angle. Le contrôle AF évalue la valeur d'estimation de la netteté en fonction de l'amplitude moyenne du gradient entre les images de l'objectif UW et W.

Si l'effet de moiré interfère avec les résultats lors de l'exécution de ce test, utilisez une tablette à résolution plus élevée de la liste des tablettes approuvées par Camera ITS.

API testées :

Réussite : pour que le test soit réussi, les vérifications AE et AWB doivent être réussies. Les résultats de la vérification de la FA ne sont utilisés qu'à des fins de journalisation. Voici les critères pour chaque vérification :

  • Vérification de l'AE : la variation de luminance (valeur Y) entre les images des objectifs UW et W doit être inférieure à 4 % pour tous les patchs de couleur si l'appareil est compatible avec ae_regions et awb_regions. Si seul ae_regions est accepté, seules les valeurs du patch gris doivent répondre aux critères.
  • Vérification de la balance des blancs automatique : la différence entre les valeurs rouge-vert et bleu-vert pour les images des objectifs UW et W doit être inférieure à 3 % pour le patch de couleur grise et inférieure à 10 % pour les autres patchs de couleur si l'appareil est compatible avec ae_regions et awb_regions.
  • Vérification de la mise au point automatique : la netteté de l'image capturée avec l'objectif W doit être supérieure à celle de l'image capturée avec l'objectif UW.

test_multi_camera_switch_gray_uw_y

Figure 126. Patch gris pris avec un objectif ultra grand-angle.

test_multi_camera_switch_gray_w_y

Figure 127. Patch gris pris avec l'objectif W.

scene8

scene8 est un cadre rectangulaire divisé en quatre régions égales, chacune contenant un portrait pris avec une exposition différente ou superposé avec une nuance de couleur différente (nuance bleue, exposition augmentée, exposition diminuée, nuance jaune). Quatre marqueurs ArUco sont alignés sur les quatre coins extérieurs du rectangle pour obtenir des coordonnées précises du cadre principal du rectangle.

Exemple de scène 8

Figure 128 : exemple de scene8.

test_ae_awb_regions

Testez si les valeurs RVB et de luminance diffèrent lorsque l'enregistrement de l'aperçu est effectué dans différentes régions AE et AWB.

Le test enregistre un aperçu de huit secondes, en effectuant une mesure de l'exposition automatique et de la balance des blancs automatique sur chaque quadrant pendant deux secondes. Le test extrait ensuite un frame de l'enregistrement de l'aperçu de chaque région et utilise les frames extraits pour effectuer les vérifications AE et AWB suivantes :

  • Vérification de l'AE : vérifie que la mesure de l'exposition du frame dans la région où l'exposition a diminué présente une valeur de luminance supérieure de plus de 1 % à celle de la mesure de l'exposition du frame dans la région où l'exposition a augmenté. Cela permet de vérifier que les images sont éclaircies lors de la mesure d'une région sombre.
  • Vérification de la balance des blancs automatique : vérifie que le rapport entre le rouge et le bleu (des valeurs RVB moyennes de l'image) dans le frame avec la région de mesure bleue est supérieur de plus de 2 % à celui du frame avec la région de mesure jaune. Cela permet de vérifier que les images ont une valeur RVB équilibrée lors de la mesure d'une région jaune (chaude) ou bleue (froide).

API testées :

Réussite : les vérifications AE et AWB sont réussies.

test_ae_awb_regions_dark_region

Figure 129 : Région sombre de la photo avec une exposition accrue.

test_ae_awb_regions_light_region

Figure 130. Région plus claire avec une exposition réduite.

Mécanismes d'échec :

  • La détection précise des quatre marqueurs ArUco est essentielle pour ce test. Si la détection initiale échoue, le système tente une deuxième détection à l'aide d'une version en noir et blanc de l'image. L'image en niveaux de gris suivante représente l'étape de traitement secondaire :

    Désalignement des marqueurs ArUco

    Figure 131 : Désalignement des marqueurs ArUco.

test_color_correction_mode_cct

Tests COLOR_CORRECTION_MODE sur différentes températures et teintes de couleur, vérifiant les changements dans les rapports RVB par rapport à la scène de capture, scene8.

API testées :

Réussite : les ratios RVB présentent les augmentations ou diminutions attendues par rapport aux températures de couleur et aux teintes sélectionnées.

Critères de désactivation des tests

Le test test_color_correction_mode_cct est ignoré si l'un des critères suivants est rempli :

scene9

scene9 se compose de milliers de cercles de tailles et de couleurs aléatoires pour créer une scène avec une très faible répétabilité afin de tester les algorithmes de compression JPEG.

Exemple de scène 9

Figure 132 : exemple de scène9.

test_jpeg_high_entropy

Tests de fonctionnement de la compression JPEG de l'appareil photo sur scene9 avec une entropie élevée et le facteur de qualité JPEG défini sur 100 %. Le facteur de zoom est augmenté pour vérifier que la scène affichée sur la tablette remplit le champ de vision de la caméra.

API testées :

Réussite : le fichier JPEG est correctement compressé, écrit et relu à partir du disque.

test_jpeg_quality

Teste la qualité de compression JPEG de la caméra. Parcourez les qualités JPEG via android.jpeg.quality et vérifiez que les tables de quantification changent correctement.

API testées :

Réussite : la matrice de quantification diminue lorsque la qualité augmente. (La matrice représente le facteur de division.)

Moyennes des matrices DQT de luma et de chroma de la caméra arrière du Pixel 4 par rapport à la qualité JPEG

Figure 133 : Moyennes des matrices DQT de luma et de chroma de la caméra arrière du Pixel 4 par rapport à la qualité JPEG.

Exemple de test test_jpeg_quality ayant échoué

Figure 134. Exemple de test ayant échoué.

scene_video

scene_video est une scène vidéo composée de quatre cercles de couleurs différentes qui se déplacent d'avant en arrière à différentes fréquences d'images sur un fond blanc.

Exemple de Figure 135.scene_video.

test_preview_frame_drop

Test permettant de vérifier que la fréquence d'images de l'aperçu demandée est maintenue avec une scène dynamique. Ce test s'exécute sur toutes les caméras exposées aux applications tierces.

API testées :

Réussite : la fréquence d'images de l'aperçu est au maximum de la plage de fréquences d'images demandée, et la variation moyenne entre les images consécutives est inférieure à la tolérance relative définie dans le test.

scene_extensions

Les tests scene_extensions sont destinés aux extensions de caméras et doivent utiliser Camera ITS-in-a-Box, car ils nécessitent un contrôle précis de l'environnement de test. De plus, toute fuite de lumière doit être contrôlée. Pour cela, vous devrez peut-être recouvrir le banc d'essai, le DUT et la tablette avec une housse de protection, et éliminer toute fuite de lumière provenant de l'écran avant du DUT.

scene_hdr

La scène scene_hdr se compose d'un portrait à gauche et d'un code QR à faible contraste à droite.

scene_hdr

Figure 136 : exemple de scene_hdr.

test_hdr_extension

Teste l'extension HDR. Prend des captures avec et sans l'extension activée, et vérifie si l'extension rend le code QR plus détectable.

API testées :

Réussite : l'extension HDR réduit le nombre de changements de contraste nécessaires pour détecter le code QR ou réduit le dégradé sur le code QR.

scene_low_light

La scène scene_low_light se compose d'une grille de carrés de différentes nuances de gris sur un fond noir. La grille de carrés est délimitée par un contour rouge. Les carrés sont disposés selon une courbe de Hilbert.

scene_low_light example

Figure 137. Exemple de scene_low_light.

test_night_extension

Teste l'extension Night. Prend des captures avec l'extension activée et effectue les opérations suivantes :

  • Détecte la présence de 20 carrés
  • Calcule la luma limitée par chaque carré
  • Calcule la valeur de luma moyenne des six premiers carrés selon l'orientation de la grille de la courbe de Hilbert.
  • Calcule la différence de valeur de luminance entre les carrés consécutifs (par exemple, carré 2 - carré 1) jusqu'aux carrés 5 et 6 (carré 6 - carré 5), puis calcule la moyenne des cinq différences obtenues.

Pour les appareils équipés d'Android 16 ou version ultérieure, la requête de capture inclut une région mesurée correspondant au rectangle délimitant la grille de carrés. Cette modification change les critères de réussite du seuil.

API testées :

Pass (Réussite) :

  • Pour les appareils équipés d'Android 16 ou version ultérieure, la valeur de luma moyenne des six premiers carrés doit être d'au moins 80, et la différence moyenne de valeur de luma des carrés consécutifs jusqu'aux carrés 5 et 6 doit être d'au moins 18,75.
  • Pour les appareils équipés d'Android 15 ou d'une version antérieure, la valeur de luma moyenne des six premiers carrés doit être d'au moins 85, et la différence moyenne de valeur de luma des carrés consécutifs jusqu'aux carrés 5 et 6 doit être d'au moins 17.

Le graphique de luminance suivant montre à quoi ressemble un résultat de test réussi.

Exemple de test réussi pour une scène de nuit en basse luminosité

Figure 138. Exemple de test réussi pour une scène de nuit à faible luminosité.

test_low_light_boost_extension

Teste le mode AE d'amplification luminosité faible. Si Camera2 est compatible avec le mode AE d'amplification de la luminosité, ce test est effectué pour Camera2. Si l'extension de l'appareil photo en mode Nuit est prise en charge et que l'extension prend en charge le mode AE d'amplification de la luminosité, ce test est également effectué pour l'extension de l'appareil photo en mode Nuit. Ce test définit le mode AE sur "Low light boost" (Amplification en basse luminosité), prend un frame de l'aperçu et effectue les opérations suivantes :

  • Détecte la présence de 20 boîtes
  • Calcule la luma limitée par chaque boîte
  • Calcule la valeur de luma moyenne des six premiers carrés selon l'orientation de la grille de la courbe de Hilbert.
  • Calcule la différence de valeur de luminance entre les carrés consécutifs (par exemple, carré 2 - carré 1) jusqu'aux carrés 5 et 6 (carré 6 - carré 5), puis calcule la moyenne des cinq différences obtenues.

Pour les appareils équipés d'Android 16 ou version ultérieure, la requête de capture inclut une région mesurée correspondant au rectangle délimitant la grille de carrés. Cette modification change les critères de réussite du seuil.

API testées :

Pass (Réussite) :

  • Pour les appareils exécutant Android 16 ou version ultérieure, la valeur de luma moyenne des six premiers carrés doit être d'au moins 54, et la différence moyenne de valeur de luma des carrés consécutifs jusqu'aux carrés 5 et 6 doit être d'au moins 17.

  • Pour les appareils équipés d'Android 15 ou version antérieure, la valeur de luma moyenne des six premiers carrés doit être d'au moins 70, et la différence moyenne de valeur de luma des carrés consécutifs jusqu'aux carrés 5 et 6 doit être d'au moins 18.

scene_tele

Pour les tests scene_tele, il est essentiel que la distance du graphique soit au moins égale à la distance focale minimale du téléobjectif. Étant donné que cette distance de mise au point minimale peut varier d'un appareil à l'autre, vous devez configurer votre installation en fonction de la caméra téléobjectif spécifique.

Configuration de scene_tele basée sur la distance focale des caméras grand-angle et téléobjectif

Figure 139 : configuration de scene_tele basée sur la distance de mise au point des caméras grand angle et téléobjectif.

Pour en savoir plus sur la configuration du matériel de test, consultez Configuration du banc de test de l'extension télé.

scene6_tele

La scène scene6_tele se compose d'une grille de marqueurs ArUco sur un fond blanc.

Si les captures scene6_tele semblent surexposées dans le support modulaire, retirez la plaque avant du support modulaire.

Débranchez le banc de test du champ de vision grand-angle de l'extension et retirez le support du téléphone.

Déconnectez le banc de test du champ de vision grand angle de l&#39;extension et retirez le support de téléphone.

Figure 140 : Débranchez le banc de test du champ de vision grand-angle de l'extension et retirez le support du téléphone.

remove_front_plate

Figure 141. Retirez la plaque avant.

test_zoom_tele

Teste le comportement du zoom de l'appareil photo, de l'objectif grand-angle à l'objectif téléphoto. Le test est identique à test_zoom, mais il teste le comportement du zoom de l'appareil photo, de l'objectif grand-angle au téléobjectif.

API testées :

Réussite : la taille relative du marqueur ArUco capturé est précise par rapport au facteur de zoom demandé pour vérifier que la caméra effectue correctement le zoom, et la distance du marqueur par rapport au centre de l'image change selon les critères listés dans test_zoom.

test_preview_zoom_tele

Teste le comportement du zoom de la caméra pour les aperçus du grand-angle au téléobjectif. Le test est identique à test_preview_zoom, mais il teste le comportement du zoom de la caméra pour les aperçus du grand-angle au téléobjectif.

API testées :

Réussite : la taille relative du marqueur ArUco capturé est précise par rapport au rapport de zoom demandé pour vérifier que la caméra effectue un zoom correct, et la distance du marqueur par rapport au centre de l'image change en fonction des critères listés dans test_preview_zoom.

scene7_tele

scene7_tele est identique à scene7, mais configuré pour les tests de téléobjectif. Il s'agit d'un cadre rectangulaire divisé en quatre quadrants égaux, chacun rempli d'une couleur différente. Au centre du rectangle se trouve un graphique à bord incliné pour vérifier la netteté. Quatre marqueurs ArUco sont alignés sur les quatre coins extérieurs du rectangle pour vous aider à obtenir des coordonnées précises du cadre principal du rectangle à différents niveaux de zoom.

test_multi_camera_switch_tele

Ce test vérifie que, lors de l'enregistrement de l'aperçu à différents niveaux de zoom, le passage de l'objectif grand-angle (W) à l'objectif téléphoto (tele) entraîne des valeurs RVB similaires.

Le test utilise différents rapports de zoom dans la plage prédéfinie pour effectuer un enregistrement d'aperçu dynamique et identifier le point auquel la caméra physique change. Ce point marque le passage de l'objectif grand-angle au téléobjectif.

Les frames capturées au point de croisement et avant sont analysées pour l'AE, la balance des blancs et l'AF.

La vérification de l'AE permet de s'assurer que la variation de luminosité se situe dans la plage attendue pour les images prises avec l'objectif grand-angle et le téléobjectif. Le contrôle de la balance des blancs vérifie que les rapports rouge/vert et bleu/vert sont compris dans les seuils pour les images grand-angle et celles prises avec le téléobjectif. Le contrôle AF évalue la valeur d'estimation de la netteté en fonction de l'amplitude moyenne du dégradé entre les images des objectifs grand-angle et téléobjectif.

API testées :

Réussite : pour que le test réussisse, les vérifications de l'AE, de la balance des blancs et de la mise au point automatique doivent toutes réussir. Voici les critères pour chaque vérification :

  • Vérification de l'AE : la variation de luminance entre les images des objectifs grand-angle et téléobjectif doit être inférieure à 4 %.
  • Vérification de la balance des blancs automatique : dans l'espace colorimétrique LAB, le delta C entre le rouge-vert et le bleu-vert pour les objectifs grand-angle et téléobjectif ne doit pas dépasser 10.
  • Vérification de la mise au point automatique : la netteté de l'image du téléobjectif doit être supérieure à celle de l'objectif grand-angle.

scene_flash

Les tests scene_flash nécessitent une scène sombre dans la boîte de fusion des capteurs.

test_auto_flash

Tests qui déclenchent automatiquement le flash dans une scène sombre pour les caméras arrière et avant. Pour les caméras avant, le flash automatique utilise l'écran pour éclairer la scène, et non un flash physique. Le test vérifie que le flash automatique est déclenché en vérifiant que le centre de l'image de la vignette est plus lumineux lorsque le flash automatique est activé. Pour déclencher le flash automatique, les lumières du banc d'essai doivent être éteintes. Elles peuvent être éteintes automatiquement avec le contrôleur Arduino. La scène doit être complètement sombre pour que le test fonctionne correctement. L'application Jetpack Camera (JCA) doit être installée sur l'appareil avant le test. Le flash automatique des caméras arrière repose sur l'état AE pour se déclencher, mais le flash automatique des caméras avant ne repose pas sur l'AE et se déclenche toujours.

API testées :

Réussite : le centre de l'image de la vignette avec le flash automatique activé est plus lumineux que l'image de la scène d'origine pour toutes les caméras.

test_flash_strength

Tests permettant de vérifier que le contrôle de l'intensité du flash en mode SINGLE est correctement implémenté.

Vérifie que si l'appareil prend en charge le contrôle de l'intensité du flash lors de l'utilisation de l'appareil photo en mode SINGLE, l'intensité du flash change en fonction des différents niveaux d'intensité demandés. Vérifie que le contrôle de l'intensité du flash fonctionne avec différents AE_MODES. Par exemple, si le mode d'exposition automatique est ON ou OFF, le niveau d'intensité du flash a un impact sur la luminosité. Si le mode est ON_AUTO_FLASH, le niveau d'intensité du flash n'a aucun impact sur la luminosité.

Pour effectuer le test, les lumières du banc d'essai doivent être éteintes. Elles peuvent être éteintes automatiquement avec le contrôleur Arduino. La scène doit être complètement sombre pour que le test fonctionne correctement.

API testées :

Pass (Réussite) :

Lorsque le mode d'exposition automatique est défini sur ON ou OFF, la luminosité des zones de l'image augmente à mesure que l'intensité du flash augmente, de l'absence de flash à FLASH_SINGLE_STRENGTH_MAX_LEVEL. Lorsque le mode d'exposition automatique est défini sur ON_AUTO_FLASH, la différence de luminosité des zones de l'image est dans les limites de tolérance lorsque le niveau d'intensité du flash passe de "aucun flash" à FLASH_SINGLE_STRENGTH_MAX_LEVEL.

test_led_snapshot

Teste si les instantanés LED saturent ou teintent l'image.

Ce test ajoute un contrôleur d'éclairage à la Sensor Fusion Box pour contrôler les lumières. Lorsque les lumières sont réglées sur OFF, le test prend une photo avec le mode AUTO_FLASH défini sur ON. Lors de cette capture, le test exécute une séquence de précapture avec le déclencheur aePrecapture défini sur START et définit l'intention de capture sur Preview pour effectuer la capture avec le flash.

Étant donné que la capture présente un point chaud distinctif en raison du flash, le test calcule la moyenne de l'image du flash pour l'ensemble de la capture et vérifie si la valeur se situe dans la plage (68, 102). Pour vérifier si la balance des blancs de l'image est raisonnable, le test calcule les rapports rouge/vert et bleu/vert, et vérifie si ces rapports sont compris entre 0,95 et 1,05.

API testées :

Réussite : les ratios rouge/vert et bleu/vert sont compris entre 0,95 et 1,05. La moyenne de l'image du flash se situe dans la plage (68, 102).

test_night_mode_indicator

Teste la fonctionnalité de l'indicateur du mode Nuit, une fonctionnalité qui indique si la caméra fonctionne dans des conditions de faible luminosité et si elle bénéficiera d'une extension de caméra en mode Nuit pour la capture d'images. Cette fonctionnalité n'est disponible que sur les appareils compatibles avec les extensions de caméra en mode Nuit.

Ce test vérifie que l'indicateur du mode Nuit reflète correctement les conditions d'éclairage pendant l'aperçu de la caméra. Le test effectue les étapes suivantes :

  1. Initialisation : le test initialise un ItsSession et récupère les propriétés de la caméra. Il établit également une connexion avec le contrôleur d'éclairage.
  2. Conditions d'exclusion : le test est ignoré si l'appareil n'est pas compatible avec le niveau d'API requis ou la fonctionnalité d'indicateur du mode Nuit.
  3. Session Camera2 :
    • Le test démarre une session de capture d'aperçu à l'aide d'une session Camera2.
    • La lumière s'allume et une image d'aperçu est capturée.
    • Le test vérifie que l'indicateur du mode Nuit est à l'état OFF.
    • La lumière s'éteint et une image d'aperçu est capturée.
    • Le test vérifie que l'indicateur du mode Nuit est à l'état ON.
  4. Session d'extension de l'appareil photo :
    • Le test répète la même procédure que pour la session Camera2, mais en utilisant une session CameraExtension avec l'extension EXTENSION_NIGHT.
  5. Nettoyage : le test se termine ItsSession et libère le contrôleur d'éclairage.

API testées :

Pass (Réussite) :

  • Lorsque la lumière est allumée, l'indicateur du mode Nuit doit être à l'état OFF.
  • Lorsque le voyant est éteint, l'indicateur du mode Nuit doit être à l'état ON.
  • S'applique aux sessions Camera2 et CameraExtension.

test_preview_min_frame_rate

Teste si la fréquence d'images de l'aperçu diminue correctement dans une scène sombre. Pour que ce test fonctionne correctement, les lumières du banc d'essai doivent être éteintes par le contrôleur ou manuellement par l'opérateur de test.

API testées :

Réussite : la fréquence d'images de l'aperçu est au minimum de la plage de fréquences d'images demandée, et la variation entre les images est inférieure à la tolérance absolue définie dans le test.

test_torch_strength

Tests permettant de vérifier que le contrôle de l'intensité du flash en mode TORCH est correctement implémenté.

Vérifie que si l'appareil prend en charge le contrôle de l'intensité du flash lors de l'utilisation de l'appareil photo en mode TORCH, l'intensité de la lampe torche change en fonction des différents niveaux d'intensité demandés. Vérifie que le contrôle de l'intensité du flash fonctionne avec différents AE_MODES. Par exemple, si le mode d'exposition automatique est ON ou OFF, le niveau d'intensité du flash a un impact sur la luminosité. Si le mode est ON_AUTO_FLASH, le niveau d'intensité du flash n'a aucun impact sur la luminosité. Vérifie que l'intensité de la torche reste la même pendant toute la durée d'une rafale, en simulant une session de capture vidéo. Pour effectuer le test, les lumières du banc d'essai doivent être éteintes. Elles peuvent être éteintes automatiquement avec le contrôleur Arduino. La scène doit être complètement sombre pour que le test fonctionne correctement.

API testées :

Pass (Réussite) :

Lorsque le mode d'exposition automatique est défini sur ON ou OFF, la luminosité des zones de la rafale d'images augmente à mesure que le niveau d'intensité du flash passe de "Sans flash" à FLASH_TORCH_STRENGTH_MAX_LEVEL. Lorsque le mode d'exposition automatique est défini sur ON_AUTO_FLASH, la différence de luminosité des zones de la rafale d'images se situe dans les limites de tolérance lorsque le niveau d'intensité du flash passe de "aucun flash" à FLASH_TORCH_STRENGTH_MAX_LEVEL.

sensor_fusion

Les tests de fusion de capteurs nécessitent un mouvement spécifique du téléphone devant un motif en damier et des marqueurs ArUco. Pour obtenir des résultats optimaux, vérifiez que le tableau de test est monté à plat. Les graphiques non plats affectent les calculs de rotation pour de nombreux tests. Le graphique doit remplir l'arrière de la boîte de fusion des capteurs en l'imprimant au format 43 x 43 cm. (43 x 43 cm). Les tests sensor_fusion peuvent être automatisés avec la Sensor Fusion Box.

Graphique de fusion des capteurs

Figure 142. Graphique de fusion des capteurs.

Graphique de fusion des capteurs dans Rig

Figure 143. Graphique de fusion des capteurs qui remplit l'arrière de la boîte de fusion des capteurs.

test_lens_intrinsic_calibration

Teste les changements intrinsèques du centre optique de l'objectif lorsque celui-ci se déplace en raison de la stabilisation optique de l'image (OIS). Si les échantillons intrinsèques de l'objectif sont pris en charge, les tests vérifient que le centre optique des échantillons intrinsèques de l'objectif change lorsque l'objectif se déplace en raison de l'OIS.

API testées :

Réussite : le centre optique des caractéristiques intrinsèques de l'objectif change d'un pixel ou plus. Si les exemples intrinsèques de l'objectif sont acceptés, les centres optiques des exemples intrinsèques de l'objectif changent d'un pixel ou plus.

La figure suivante est un exemple de graphique test_lens_intrinsic_calibration montrant les variations des points principaux en pixels pour chaque frame :

test_lens_intrinsic_calibration_example.png

Figure 144 : Exemple de graphique test_lens_intrinsic_calibration montrant les variations des points principaux en pixels pour chaque frame.

test_multi_camera_frame_sync

Les tests qui encadrent les codes temporels capturés par la caméra logique sont à moins de 10 ms en calculant les angles des carrés du damier pour déterminer le code temporel.

API testées :

Réussite : l'angle entre les images de chaque caméra ne change pas de manière significative lorsque le téléphone est pivoté.

test_preview_distortion

Tests visant à vérifier que la distorsion est corrigée dans chaque frame d'aperçu pris à différents niveaux de zoom. Pour chaque frame d'aperçu, le test calcule les points idéaux en fonction des caractéristiques intrinsèques et extrinsèques de la caméra.

Dans l'exemple d'image, les points idéaux sont indiqués en vert et les points réels en rouge. L'erreur de distorsion est calculée en fonction de la distance RMS en pixels entre les points réels et les points idéaux. Les zones vertes et rouges sur l'image permettent de détecter visuellement la zone d'erreur de distorsion.

test_preview_distortion_example.jpg

Figure 145. Image d'un damier avec des points idéaux en vert et des points réels en rouge.

API testées :

Réussite : l'erreur de distorsion normalisée de chaque frame d'aperçu est inférieure au seuil défini dans le test.

test_preview_stabilization

Les tests qui stabilisent l'aperçu vidéo effectuent une rotation inférieure à celle du gyroscope.

API testées :

Réussite : la rotation angulaire maximale sur les frames est inférieure à 70 % de la rotation du gyroscope.

Voici des exemples de vidéos avec et sans stabilisation :

Figure 146. Exemple de vidéo avec stabilisation.

Figure 147. Exemple de vidéo sans stabilisation.

test_sensor_fusion

Teste la différence de code temporel entre la caméra et le gyroscope pour les applications de RA et de RV. Le téléphone est pivoté de 90 degrés 10 fois devant le motif en damier. Le mouvement dure environ 2 s aller-retour. Ce test est ignoré si aucun gyroscope n'est inclus ou si le paramètre de source d'horodatage REALTIME n'est pas activé.

Le test test_sensor_fusion génère un certain nombre de graphiques. Les deux graphiques les plus importants pour le débogage sont les suivants :

  • test_sensor_fusion_gyro_events : affiche les événements du gyroscope du téléphone pendant le test. Un mouvement dans les directions x et y implique que le téléphone n'est pas solidement fixé sur la plaque de fixation, ce qui réduit la probabilité de réussite du test. Le nombre de cycles dans le graphique dépend de la vitesse d'écriture pour l'enregistrement des frames.

    Exemple d&#39;événements de gyroscope test_sensor_fusion

    Figure 148 : exemple d'événements de gyroscope test_sensor_fusion.

  • test_sensor_fusion_plot_rotations : affiche l'alignement des événements du gyroscope et de la caméra. Ce graphique doit montrer un mouvement correspondant entre la caméra et le gyroscope à +/-1 ms.

    Exemple de rotations du graphique test_sensor_fusion

    Figure 149 : exemple de rotations du graphique test_sensor_fusion.

API testées :

Réussite : le décalage des codes temporels de la caméra et du gyroscope est inférieur à 1 ms, conformément à la section 7.3.9 Capteurs haute fidélité du CDD.

Mécanismes d'échec :

  • Erreur de décalage : le décalage entre la caméra et le gyroscope n'est pas correctement calibré à +/-1 ms.
  • Perte d'images : le pipeline n'est pas assez rapide pour capturer 200 images consécutives.
  • Erreurs de socket : adb ne peut pas se connecter de manière fiable au DUT assez longtemps pour exécuter le test.
  • Le graphique n'est pas monté à plat. Le graphique test_sensor_fusion_plot_rotations comporte des frames où la rotation du gyroscope et de la caméra varie considérablement lorsque la caméra pivote dans les parties non plates du graphique.
  • La caméra n'est pas installée à plat. Le graphique test_sensor_fusion_gyro_events montre le mouvement dans les plans X et Y. Ce problème est plus fréquent avec les caméras avant, car la caméra arrière est souvent surélevée par rapport au reste du boîtier du téléphone, ce qui crée une inclinaison lors de la fixation de l'arrière du téléphone sur la plaque de fixation.

test_video_stabilization

Les tests qui ont stabilisé la vidéo montrent une rotation inférieure à celle du gyroscope.

API testées :

Réussite : la rotation angulaire maximale sur les frames est inférieure à 60 % de la rotation du gyroscope.

Voici des exemples de vidéos avec et sans stabilisation.

Figure 150. Exemple de vidéo avec stabilisation.

Figure 151. Exemple de vidéo sans stabilisation.

test_video_stabilization_jca

Les tests de stabilisation vidéo capturée à l'aide de la JCA montrent une rotation inférieure à celle du gyroscope. Le JCA doit être installé sur l'appareil avant le test.

API testées :

Réussite : l'angle de rotation maximal des images extraites de la vidéo capturée à l'aide de la JCA est inférieur à 70 % de la rotation du gyroscope.

feature_combination

Les tests feature_combination permettent de vérifier que les fonctionnalités fonctionnent correctement lorsque plusieurs fonctionnalités de caméras sont activées en même temps. Ces tests utilisent la même image en damier que celle utilisée dans la scène de fusion des capteurs.

test_feature_combination

Teste toutes les combinaisons de différents flux, du mode de stabilisation vidéo, de la plage de FPS cible, de la vidéo HDR 10 bits et de l'Ultra HDR compatibles avec l'appareil photo.

Pour Android 16 et versions ultérieures, le test exécute toutes les combinaisons de fonctionnalités compatibles et consigne les résultats dans un fichier proto. Les assertions d'échec ne sont appelées que pour les combinaisons de caractéristiques pour lesquelles isSessionConfigurationSupported renvoie True.

API testées :

Réussite : pour chaque combinaison de fonctionnalités acceptée :

  • L'aperçu de la diffusion est stabilisé si la stabilisation de l'aperçu est activée.
  • La fréquence d'images de l'aperçu se situe dans la plage AE_TARGET_FPS_RANGE configurée.
  • L'espace colorimétrique du flux d'aperçu enregistré correspond à celui défini.
  • La capture Ultra HDR comporte une carte de gain valide.

scene_ip

Dans Android 16 et versions ultérieures, la scène scene_ip permet de vérifier la parité des images entre l'application d'appareil photo par défaut et l'application d'appareil photo Jetpack (JCA, Jetpack Camera App) afin d'identifier les différences majeures entre les images capturées. La JCA réplique les captures d'applications de réseaux sociaux et fournit une image de base que les applications de réseaux sociaux traitent et affinent ensuite.

Configuration matérielle requise

La configuration matérielle suivante est requise pour les tests scene_ip :

  • Les tests sont exécutés dans la caméra Gen2 ITS-in-a-box.
  • Les contrôleurs de servo et d'éclairage qui font partie du système Gen2 sont utilisés pour contrôler l'environnement de test.
  • Un tableau des fonctionnalités de test est placé à l'intérieur du rig Gen2.

test_chart_gen2

Figure 152. Exemple Gen2chart_sample.

Critères de désactivation des tests

Les tests scene_ip sont ignorés si l'un des critères suivants est rempli :

  • Le premier niveau d'API (first_api_level) de l'appareil est de 35 ou inférieur.
  • L'appareil n'est pas un téléphone doté d'une caméra principale avant et arrière (par exemple, une tablette ou un téléviseur).

test_default_jca_ip

Prend des photos du graphique de la fonctionnalité de test dans des conditions d'éclairage contrôlées à l'aide de l'application de caméras par défaut et de la JCA, et effectue les vérifications suivantes :

  • Champ de vision : vérifie que l'application de caméras par défaut et les captures JCA ont le même champ de vision. Cette vérification utilise la fonctionnalité de code QR central extraite de l'image du graphique des captures.

  • Luminosité : vérifie que la différence de luminosité mesurée entre l'application de caméras par défaut et JCA ne dépasse pas 10. Cette vérification utilise le correctif de plage dynamique pour la mesure de la luminosité.

  • Balance des blancs : vérifie que la différence de balance des blancs entre l'application d'appareil photo par défaut et JCA ne dépasse pas 4. Cette vérification utilise le correctif de plage dynamique pour la mesure de la luminosité.

Section de base réussie : le test réussit les vérifications du champ de vision, de la luminosité et de la balance des blancs. Dans Android 16, ce test n'est pas obligatoire (NOT_YET_MANDATED).