Implémentation de la méthode de recalage avec l’API WebXR et ARKit

relation les différentes ressources impliquées dans un relevé d’art pariétal au sein d’un viewer unique compris dans une plateforme web. Pour cela, nous nous sommes basés sur l’API WebGL à partir de bibliothèques JavaScript. À ce stade, nous disposons donc d’un viewer hybride 2D/3D permettant de charger et manipuler les nuages de points issus de photogrammétrie, les photographies orientées accompagnées d’images auxiliaires, ainsi que les annotations 2D et 3D. Nous l’avons également doté d’outils de mesure et d’annotation 2D et 3D manuels ou semi-automatiques. À partir de cette preuve de concept, nous pouvons maintenant nous intéresser à l’implémentation de la méthode de recalage (section 5.3), afin de réconcilier les environnements réels et virtuels par le biais de modalités d’interactions en réalité augmentée.

7.3.1. Preuve de concept

L’objectif de cette implémentation est de valider l’approche propose en section 5.3 pour le recalage semi-automatique de la scène d’un projet sur la réalité au sein d’un environnement web.

7.3.1.1. Déroulement d’une session XR

Le déroulement de l’affichage d’une page web en XR comprend nécessairement les étapes suivantes : 1. Vérification de la prise en charge du mode XR (compatibilité du navigateur et du dispositif

d’affichage) ;

2. Si le support est compatible et disponible, la page annonce la disponibilité du mode XR à l’utilisateur ;

3. Si l’utilisateur active le mode XR, une session est initialisée ;

4. La session est utilisée pour exécuter une boucle de rendu qui produit en temps réel les images à afficher sur le dispositif XR ;

5. La production d’images de rendu se poursuit jusqu’à ce que l’utilisateur quitte le mode XR ; 6. La session est close.

Le processus global présenté précédemment pour le rendu du viewer en mode desktop comprend deux phases principales : l’initialisation, et la boucle de rendu. Globalement, l’implémentation d’un mode XR n’influence pas la phase d’initialisation car celle-ci concerne essentiellement la préparation des éléments minimaux du viewer. En revanche, d’après les étapes énoncées ci-dessus, elle impose l’intégration de deux phases intermédiaires de vérification de compatibilité et d’initialisation XR, ainsi que des modifications dans la boucle de rendu (Figure 153).

Relevé numérique d’art pariétal : définition d’une approche innovante combinant propriétés géométriques, visuelles et sémantiques au sein d’un environnement de réalité mixte

185

Figure 153 : Diagramme du processus de rendu permettant plusieurs modalités de visualisation (desktop ou XR). Illustration : auteur.

 Vérification de la compatibilité et initialisation XR

Pour étendre les capacités de notre viewer en lui fournissant un mode XR, nous devons dans un premier temps ajouter les étapes évoquées précédemment, destinées à vérifier la compatibilité du navigateur et du dispositif d’affichage. À l’issue de la phase d’initialisation, nous réalisons donc trois vérifications successives :

1. Le navigateur est-il compatible WebXR ?

2. Le mode XR du dispositif d’affichage est-il pris en charge ? 3. Le mode XR est-il demandé par l’utilisateur ?

186

Si la réponse à l’une de ces trois questions est négative, la boucle de rendu est inchangée, et l’utilisateur bénéficie d’un affichage desktop classique. Dans le cas contraire, la session XR est initialisée. Il est alors nécessaire de modifier la structure de la page pour l’adapter à la visualisation en réalité augmentée, en créant le canvas qui recevra les images provenant du flux vidéo du mobile, mais aussi en générant les éléments de GUI spécifiques, en particulier le bouton de sortie de mode XR. Il faut également mettre à jour les paramètres intrinsèques de la caméra virtuelle du viewer afin qu’ils correspondent à ceux de la caméra réelle. Sans cela, les images virtuelles issues du viewer et celles issues de la caméra mobile ne seront pas superposables.

 Boucle de rendu

Le mode XR étant initialisé, nous pouvons entrer dans la boucle de rendu. Lorsque le mode XR est actif, la boucle a deux objectifs principaux : assurer la synchronicité des mouvements de l’utilisateur dans son environnement réel et ceux de la caméra virtuelle de la scène afin que les contenus restent systématiquement superposables, et actualiser les contenus 3D du projet à afficher dans la scène en fonction des actions de l’utilisateur, comme dans la boucle de rendu desktop classique.

À chaque frame, les données du suivi fournies par le SDK XR utilisé sont fournies au client par le navigateur sous forme de chaînes de caractères encodées en base 64. Ce fonctionnement présente l’avantage de permettre le transfert de données complexes comme des images à travers des médias ne supportant que des données textuelles. Outre la nécessité de décoder à chaque frame les données qui nous intéressent, un inconvénient de cette approche est que les ressources encodées par ce biais pèsent 10% à 30% plus lourd que les données originales, selon la compression utilisée (Boudrias, 2012). Ainsi, pour des raisons d’optimisation les images du flux vidéo ne peuvent être communiquées en pleine résolution sans impacter sérieusement la fluidité de l’application.

Figure 154 : Diagramme du processus de rendu du flux vidéo dans le canvas. Illustration : auteur.

Nous devons dans un premier temps mettre à jour l’image du flux vidéo dans la page HTML (Figure154). Pour cela, les données de la frame sont décodées et converties en un tableau typé Uint8ClampedArray, c’est-à-dire un tableau d'entiers non signés de 8 bits, dont les valeurs sont comprises entre 0 et 255. Ce tableau est utilisé pour générer une image en attribuant pour chaque pixel des valeurs RGB. Enfin, le contenu du canvas est supprimé (frame précédente), afin d’y placer la nouvelle image. Dans un second temps, nous devons mettre à jour les paramètres extrinsèques de la caméra virtuelle en fonction des poses calculées lors du suivi, afin que ses déplacements soient

Relevé numérique d’art pariétal : définition d’une approche innovante combinant propriétés géométriques, visuelles et sémantiques au sein d’un environnement de réalité mixte

187

synchrones avec ceux du dispositif d’affichage. Pour cela, nous appliquons directement la matrice calculée par ARKit à la caméra virtuelle.

Enfin, nous devons mettre à jour les ancres de l’environnement réel. Il s’agit d’actualiser les positions des ancres existantes, constamment affinées par la procédure de suivi, mais aussi d’ajouter les nouvelles ancres, créées par la prise en compte d’images-clés. Lorsque cette étape est achevée, nous poursuivons la boucle avec les processus présents dans le rendu desktop, c’est-à-dire la prise en compte des actions de l’utilisateur et des modifications opérées dans la scène.

Cette boucle est répétée à chaque frame, jusqu’à ce que l’utilisateur manifeste l’envie de quitter le mode XR. Dans ce cas, après confirmation de l’utilisateur, la session XR est close, les éléments HTML dédiés sont supprimés de la page (canvas de rendu vidéo et éventuellement éléments du GUI spécifiques à l’usage XR), et la boucle de rendu repasse en mode desktop (Figure 155).

Figure 155 : Diagramme de processus de sortie du mode XR. Illustration : auteur.

Ce processus, résumé sur le schéma (Figure 153) permet d’obtenir une visualisation en réalité augmentée stable. La scène virtuelle est placée dans l’environnement de l’utilisateur et reste en place, comme si elle faisait partie du décor. L’utilisateur peut évoluer avec sa tablette dans le monde réel et visualiser son environnement augmenté. Cependant à ce stade, rien n’est fait pour que la scène soit positionnée de manière cohérente par rapport à l’objet physique étudié (Figure 156).

Figure 156 : Capture d’écran de l’application en mode XR. À ce stade, la scène apparaît de manière stable d’en l’environnement réel, mais n’est pas positionnée de manière cohérente.

7.3.1.2. Spatialisation de la frame référence

Maintenant que nous avons assuré le rendu de la scène 3D en mode XR, il reste à implémenter la méthode de recalage afin de calculer la position réelle des objets affichés à l’écran. Nous avons proposé une méthode de recalage basée sur la spatialisation d’une frame de référence. Nous avions alors identifié deux méthodes possibles (section 5.3.3).

188

Généralement, la méthode par ajustement de faisceaux est considérée comme plus précise, du fait de l’utilisation des paramètres intrinsèques et de l’optimisation itérative. Cependant, elle est aussi plus lente ce qui peut s’avérer très problématique dans notre cas, en partie pour l’utilisateur qui doit attendre la fin du processus de recalage pour visualiser son projet en AR, en partie parce que le SLAM peut provoquer une dérive progressive, ce qui nous conduit plutôt à limiter le temps de calcul pour favoriser le temps d’utilisation effective. Par ailleurs, nous avons vu qu’en l’état actuel le flux de la caméra est communiqué frame par frame au client sous forme d’une chaîne de caractères, encodée en base64 et rendu en arrière-plan. Les images ne sont pas fournies avec des métadonnées EXIF, bien que nous puissions tout à fait en ajouter à la volée, connaissant la calibration interne de la caméra utilisée. La méthode par résection spatiale est quant à elle plus polyvalente puisqu’elle ne nécessite pas de métadonnées, mais aussi plus rapide. Elle est globalement moins précise : si cette méthode de calcul fournit une orientation globalement cohérente, le manque de métadonnées concernant la distance focale peut parfois causer une incohérence concernant la profondeur par rapport à la position réelle.

Figure 157 : Diagramme du processus de recalage basé sur un calcul de résection spatiale. Illustration : auteur.

Après évaluation des atouts et limites des deux méthodes, nous avons opté pour la méthode basée sur la résection spatiale en raison de sa flexibilité. Une fois que la frame est orientée par rapport à l’acquisition maîtresse, elle est indexée dans un conteneur dédié pour pouvoir bénéficier des annotations préexistantes et devenir à son tour support d’annotation. Enfin, les données de la nouvelle image sont stockées dans la base de données.

Relevé numérique d’art pariétal : définition d’une approche innovante combinant propriétés géométriques, visuelles et sémantiques au sein d’un environnement de réalité mixte

189

Lorsque l’application reçoit le signal de la fin du processus de calcul, nous pouvons charger la frame dans la scène en tant que nouvelle image, et calculer Tscene →AR, la matrice de passage entre la pose

exprimée dans Rscene et la pose dans RAR sauvée lors de l’extraction. Enfin, cette matrice de passage est

appliquée à la scène 3D, qui contient toutes les données du projet, et le recalage est terminé (Figure 157). En cas de besoin, des éléments de GUI permettent à l’utilisateur d’ajuster manuellement la position et l’orientation de la scène selon les trois axes.

7.3.2. Résultats préliminaires

Les tests ont été menés sur des projets réalisés à partir de six prises de vues convergentes du facsimilé du panneau des chevaux de la grotte Chauvet-Pont d’Arc. Des projets ont été créés à partir de ces photographies, et des annotations ont été réalisées en amont dans la version desktop de la plateforme. Une fois le projet créé et annoté, nous passons à la version mobile pour activer le mode XR. Tout le contenu de la scène 3D du projet est rendu sur le flux vidéo de la caméra, et les contrôles utilisateur sont initialisés pour synchroniser les mouvements de la caméra virtuelle avec ceux de l’appareil. À ce stade, la position de la scène n’est pas cohérente avec la réalité. Lorsque nous démarrons la procédure de recalage, une frame est extraite, et envoyée au serveur de traitement pour les calculs nécessaires à l’alignement.

Entre l’envoi de l’image au serveur et l’alignement subséquent, le temps de calcul varie entre 2 à 5 minutes environ selon le contexte. Plusieurs facteurs peuvent influencer cette durée, principalement la définition de l’image candidate, sa proximité avec celles de l’acquisition maîtresse, et les variations environnementales notamment lumineuses. Évidemment, ce temps de calcul est trop conséquent pour envisager une utilisation confortable, mais néanmoins raisonnable pour une preuve de concept. Par ailleurs, nous verrons par la suite que des solutions existent pour le réduire considérablement. La précision du calcul de résection spatiale dépend beaucoup de l’image de référence, qui doit, dans la mesure du possible, partager de nombreux points homologues avec les images de l’acquisition maîtresse. Ainsi, la qualité de la procédure d’alignement n’est pas constante d’un recalage à l’autre.

Figure 158 : Résultat. Capture d’écran d’un projet visualisé en réalité augmentée après un recalage réussi.

Visuellement, les résultats du recalage semblent satisfaisants, les nuages de points du projet et des annotations sont positionnés de manière cohérente par rapport à la réalité (Figure 158). Nous pouvons observer par transparence la proximité entre les figures pariétales du facsimilé et celles du nuage de points (Annexe 15). Nous pouvons constater un léger décalage, qui peut être lié à la précision du calcul de résection spatiale ou à celle de la mise à l’échelle du projet.