AR data flow

Cet article présente le data flow dans EasyAR Sense. EasyAR Sense utilise des API composées de composants, et les composants sont reliés par data flow.

Données d'entrée et de sortie

InputFrame : Input frame. Contient l'image, les camera parameters, le timestamp, le camera transform relatif au world coordinate system et le tracking status. Parmi eux, camera parameters, timestamp, camera transform relatif au world coordinate system et tracking status sont optional, mais certains algorithm components ont des exigences spécifiques pour l'input.

OutputFrame : Output frame. Contient l'input frame et les output results des synchronous processing components.

FeedbackFrame : Feedback frame. Contient un input frame et un historical output frame, et est utilisé par les feedback-style synchronous processing components comme ImageTracker.

Camera components

CameraDevice : Default camera sur Windows, Mac, iOS et Android.

ARKitCameraDevice : Implémentation default d'ARKit sur iOS.

ARCoreCameraDevice : Implémentation default d'ARCore sur Android.

MotionTrackerCameraDevice : Implémente motion tracking et calcule les 6DoF coordinates de l'appareil par multi-sensor fusion. (Android uniquement)

ThreeDofCameraDevice : Ajoute 3DoF orientation à la default camera.

InertialCameraDevice : Ajoute 3DoF orientation et une plane translation basée sur inertial estimation à la default camera.

custom camera device : Implémentation de custom camera.

Algorithm components

Feedback-style synchronous processing component : doit produire des results pour chaque camera image frame et nécessite le processing result du frame précédent pour éviter les interférences mutuelles.

• ImageTracker: implémente la détection et le suivi des images planes.

• ObjectTracker: implémente la détection et le suivi des objets 3D.

Composants de traitement synchrone: ils doivent produire des résultats en suivant l'image de la caméra à chaque frame.

• SurfaceTracker: implémente le suivi des surfaces de l'environnement.

• SparseSpatialMap: implémente sparse spatial maps, avec la capacité de scanner l'espace physique tout en générant des cartes de nuages de points et en effectuant une localisation en temps réel.

• MegaTracker: implémente la localisation spatiale Mega.

Composants de traitement asynchrone: ils n'ont pas besoin de produire des résultats en suivant l'image de la caméra à chaque frame.

• CloudRecognizer: implémente cloud recognition.

• DenseSpatialMap: implémente dense spatial maps, qui peuvent être utilisées pour réaliser des effets tels que collision et occlusion.

Vérification de disponibilité des composants

Tous les composants disposent d'une fonction isAvailable, qui permet de déterminer si le composant est disponible.

Un composant peut être indisponible dans les cas suivants :

• Il n'est pas implémenté sur l'operating system actuel.

• Les dependencies requises par le composant n'existent pas, par exemple ARKit ou ARCore.

• Le composant n'existe pas dans la version (variant) actuelle, par exemple lorsque certaines fonctionnalités n'existent pas dans certaines versions allégées.

• Le composant n'est pas disponible sous la License actuelle.

Avant d'utiliser un composant, vérifiez toujours s'il est disponible et effectuez le fallback ou le prompt correspondant.

Data flow

La manière de connecter les composants est illustrée ci-dessous.

Il existe une utilisation spéciale où l'input est un feedback frame, comme illustré ci-dessous.

Data flow helper classes

Ports d'envoi et de réception du data flow. Chaque composant doit inclure ces ports.

• SignalSink / SignalSource : reçoit/envoie un signal sans données.

• InputFrameSink / InputFrameSource : reçoit/envoie un InputFrame.

• OutputFrameSink / OutputFrameSource : reçoit/envoie un OutputFrame.

• FeedbackFrameSink / FeedbackFrameSource : reçoit/envoie un FeedbackFrame.

Branchement et fusion du data flow

• InputFrameFork : divise un InputFrame en plusieurs sorties parallèles.

• OutputFrameFork : divise un OutputFrame en plusieurs sorties parallèles.

• OutputFrameJoin : fusionne plusieurs OutputFrame en un seul et fusionne tous les résultats dans Results. Notez que ses multiples connexions d'entrée ne doivent pas être connectées pendant l'arrivée des données, sinon il peut entrer dans un état où aucune sortie ne peut être produite. Il est recommandé de terminer les connexions data flow avant le démarrage de Camera.

• FeedbackFrameFork : divise un FeedbackFrame en plusieurs sorties parallèles.

Limitation et mise en cache du data flow

• InputFrameThrottler : reçoit et envoie InputFrame, mais n'en envoie qu'un à la fois. Il n'envoie le prochain InputFrame qu'après avoir reçu un signal de déclenchement. Lorsque plusieurs InputFrame sont reçus, les InputFrame suivants peuvent écraser les précédents.

• OutputFrameBuffer : reçoit et met en cache OutputFrame, attend le polling utilisateur et peut envoyer un signal lorsqu'un OutputFrame est reçu.

• Connectez le signal envoyé par OutputFrameBuffer à InputFrameThrottler pour terminer tout le processus de throttling.

Conversion du data flow

• InputFrameToOutputFrameAdapter : peut envelopper directement un InputFrame en OutputFrame pour l'affichage du rendu.

• InputFrameToFeedbackFrameAdapter : peut envelopper un InputFrame et un FeedbackFrame en FeedbackFrame pour les composants de traitement synchronisé par feedback.

Limite du nombre d'InputFrame

CameraDevice peut définir bufferCapacity, c'est-à-dire le nombre maximal de InputFrame qu'il émet. La valeur default actuelle est 8.

Les custom cameras peuvent utiliser BufferPool pour l'implémentation.

Pour le nombre de InputFrame requis par chaque composant, consultez l'API documentation de chaque composant.

Si le nombre de InputFrame est insuffisant, le data flow peut se bloquer et entraîner le blocage du rendering.

Si le nombre de InputFrame est insuffisant, il peut également arriver que le rendering ne se bloque pas au premier démarrage, mais se bloque après un passage en background ou après pause/start des composants. Veillez à couvrir cette situation lors des tests.

Connexion et déconnexion

Il n'est pas recommandé de connecter et déconnecter pendant l'exécution du data flow.

Si vous devez connecter ou déconnecter pendant runtime, notez que cela ne peut être fait que sur un cut edge (après suppression de cet edge, le data flow est divisé en deux parties). Cela ne peut pas être fait sur un edge dans un cycle (ici, cycle désigne un cycle formé par les edges lorsque le data flow est considéré comme un undirected graph), sur l'input de OutputFrameJoin ou sur le sideInput de InputFrameThrottler. Sinon, le data flow peut rester bloqué sur des nodes comme OutputFrameJoin et InputFrameThrottler, empêchant toute sortie.

Tous les algorithm components disposent de fonctions start/stop. En stop, les frames ne sont pas traités, mais ils continuent de sortir du composant, simplement sans results.

Utilisation typique

Voici l'utilisation d'un seul ImageTracker, qui peut servir à reconnaître et tracking des planar image targets non répétées.

Voici l'utilisation d'un seul ImageTracker, qui peut servir à reconnaître et tracking des planar image targets répétées.

Voici l'utilisation de SparseSpatialMap, qui peut servir à implémenter sparse spatial map building, localization et tracking.

Voici l'utilisation simultanée de SparseSpatialMap et DenseSpatialMap, qui peut servir à implémenter sparse spatial map building, localization, tracking et dense spatial map generation.