Table of Contents

Exigences relatives aux données de trame d'entrée pour les sources de données de trame externes

Pour que les sources de données de trame externes fonctionnent correctement, la tâche la plus importante et la plus délicate consiste à garantir l'exactitude des données. Ce document décrit les exigences relatives aux données de trame d'entrée pour les sources de données de trame externes.

Avant de commencer

Types de données de trame d'entrée

Dans Unity, une source de données de trame externe nécessite généralement la réception de données différentes à deux moments distincts. En fonction du moment d'entrée des données externes et de leurs caractéristiques, nous regroupons ces données en deux ensembles appelés :

  1. Données de trame de caméra (camera frame data)
  2. Données de trame de rendu (rendering frame data)

Les différents types de sources de données de trame externes ont des besoins différents pour ces deux ensembles de données :

  • Extension d'entrée d'image et de mouvement de l'appareil : nécessite à la fois les données de trame de caméra et les données de trame de rendu
  • Extension d'entrée d'image : nécessite uniquement les données de trame de caméra

Données de trame de caméra

Exigences de données :

  1. Horodatage (timestamp)
  2. Données d'image brutes de la caméra physique (raw camera image data)
  3. Paramètres intrinsèques (intrinsics, incluant la taille de l'image, la focale, le point principal. Si une distorsion est présente, le modèle de distorsion et les paramètres de distorsion sont également requis)
  4. Paramètres extrinsèques (extrinsics, Tcw ou Twc, matrice d'étalonnage exprimant le décalage physique de la caméra physique par rapport à l'origine de la pose de l'appareil/casque)
  5. État du suivi (tracking status)
  6. Pose de l'appareil (device pose)

Moment des données :

  • Milieu d'exposition de la caméra physique

Utilisation des données :

  • Moment de l'appel API : Peut varier selon la conception du code externe. Une méthode courante utilisée par la plupart des appareils consiste à interroger lors de la mise à jour du rendu du moteur 3D, puis à décider d'un traitement ultérieur des données en fonction de l'horodatage des données de l'appareil.
  • Thread d'appel API : Game thread du moteur 3D ou tout autre thread (si toutes les API externes utilisées sont thread-safe).

Exemple d'appel d'API dans Unity :

void TryInputCameraFrameData()
{
    double timestamp;

    if (timestamp == curTimestamp) { return; }
    curTimestamp = timestamp;

    PixelFormat format;
    Vector2Int size;
    Vector2Int pixelSize;
    int bufferSize;

    var bufferO = TryAcquireBuffer(bufferSize);
    if (bufferO.OnNone) { return; }
    var buffer = bufferO.Value;

    IntPtr imageData;
    buffer.tryCopyFrom(imageData, 0, 0, bufferSize);

    var historicalHeadPose = new Pose();
    MotionTrackingStatus trackingStatus = (MotionTrackingStatus)(-1);

    using (buffer)
    using (var image = Image.create(buffer, format, size.x, size.y, pixelSize.x, pixelSize.y))
    {
        HandleCameraFrameData(deviceCamera, timestamp, image, cameraParameters, historicalHeadPose, trackingStatus);
    }
}

Rendu des données de trame

Exigences de données :

  1. Horodatage (timestamp)
  2. État de suivi (tracking status)
  3. Pose de l'appareil (device pose)

Moment des données :

  • Moment de l'affichage. Le TimeWarp n'est pas pris en compte. Les données de pose de l'appareil (device pose) du même moment seront utilisées par des sources externes (par exemple, le SDK de l'appareil) pour définir la transformation (transform) de la caméra virtuelle afin de rendre la trame actuelle.
Note

Le TimeWarp (parfois appelé Reprojection ou ATW/PTW) est une technique couramment utilisée dans les casques VR/AR pour réduire la latence. Il déforme à nouveau l'image après le rendu en fonction de la dernière pose de la tête pour compenser les mouvements de tête survenus pendant le rendu. EasyAR a besoin du moment correspondant à la pose utilisée pour configurer la caméra virtuelle au début du rendu, et non du moment réel de l'affichage après le TimeWarp.

Utilisation des données :

  • Moment de l'appel API : Chaque trame de rendu du moteur 3D
  • Thread d'appel API : Game thread du moteur 3D

Exemple d'appel d'api dans unity：

private void InputRenderFrameMotionData()
{
    double timestamp = 0e-9;
    var headPose = new Pose();
    MotionTrackingStatus trackingStatus = (MotionTrackingStatus)(-1);
    HandleRenderFrameData(timestamp, headPose, trackingStatus);
}

Détails des exigences de données

Données d'image de la caméra physique :

  • Système de coordonnées de l'image : Les données acquises lorsque le capteur est horizontal doivent également être horizontales. Les données doivent être stockées avec l'origine dans le coin supérieur gauche, par ligne (row-major). L'image ne doit pas être retournée ou inversée.
  • FPS de l'image : Des données à 30 ou 60 fps normaux sont acceptables. Si un FPS élevé a un impact particulier, un débit d'images minimal acceptable de 2 est requis pour des résultats algorithmiques raisonnables. Il est recommandé d'utiliser un FPS supérieur à 2, en utilisant généralement le débit d'images des données brutes.
  • Taille de l'image : Pour de meilleurs résultats de calcul, le côté le plus long doit être de 960 pixels ou plus. Il est généralement déconseillé d'effectuer une mise à l'échelle d'image chronophage dans le flux de données. Il est recommandé d'utiliser directement les données brutes, sauf si le temps de copie des données en taille réelle devient inacceptable. La résolution de l'image ne peut pas être inférieure à 640*480.
  • Format de pixel : Prioriser l'efficacité du suivi et les performances globales. L'ordre de préférence des formats est généralement : YUV > RGB > RGBA > Gray (composante Y du YUV). Lors de l'utilisation de données YUV, une définition complète des données est nécessaire, y compris les détails d'encapsulation et de remplissage (padding). Par rapport aux images monocanal, les images couleur améliorent généralement l'effet Mega, mais ont moins d'impact sur d'autres fonctionnalités.
  • Accès aux données : Pointeur de données ou implémentation équivalente. Il est préférable d'éliminer toutes les copies non nécessaires possibles dans le flux de données. Dans HandleRenderFrameData, EasyAR copie les données une fois pour une utilisation asynchrone ultérieure et n'utilise plus les données d'image après la fin de cet appel synchrone. Attention à la propriété (ownership) des données.

Horodatage :

  • Tous les horodatages doivent être synchronisés par horloge, de préférence par synchronisation matérielle. L'unité de données est la seconde, mais la précision doit atteindre la nanoseconde ou être aussi élevée que possible.

État de suivi :

  • L'état de suivi est défini par l'appareil et doit inclure un état de perte de suivi (VIO non disponible). Plus il y a de niveaux, mieux c'est.

Pose de l'appareil :

  • Toutes les poses (y compris la transformation de la caméra virtuelle dans le moteur 3D) doivent utiliser la même origine.
  • Toutes les poses et les paramètres extrinsèques doivent utiliser le même système d'axes.
  • Dans Unity, le type de système d'axes pour les données de pose doit être le système d'axes Unity ou le système d'axes EasyAR. Si l'extension d'entrée est implémentée par EasyAR et utilise une autre définition de système d'axes, une définition claire du système d'axes doit être fournie ou une méthode de conversion vers le système d'axes Unity ou EasyAR doit être donnée.
  • Dans Unity, si le framework XR Unity est utilisé, seule la compatibilité avec le mode XROrigin.TrackingOriginMode.Device est nécessaire.

Paramètres intrinsèques :

  • Toutes les valeurs doivent correspondre aux données d'image. Si nécessaire, les paramètres intrinsèques doivent être mis à l'échelle avant d'être fournis à EasyAR.
  • Si l'extension d'entrée est implémentée par EasyAR, il doit être précisé si les paramètres intrinsèques changent à chaque image (la différence étant si l'API correspondante doit être appelée une fois ou à chaque image).

Paramètres extrinsèques :

  • Des données réelles doivent être fournies sur les casques.
  • C'est une matrice d'étalonnage exprimant le décalage physique de la caméra physique par rapport à l'origine de la pose de l'appareil/de la tête. Si la pose de l'appareil et la pose de la caméra physique sont identiques, ce devrait être une matrice identité.
  • L'interface correspondante pour Apple Vision Pro est : CameraFrame.Sample.Parameters.extrinsics. Notez que sa définition des données diffère de celle requise par l'interface. EasyAR effectue une conversion en interne avant utilisation.
  • Dans Unity, le type de système d'axes pour les paramètres extrinsèques doit être le système d'axes Unity ou le système d'axes EasyAR. Si l'extension d'entrée est implémentée par EasyAR et utilise une autre définition de système d'axes, une définition claire du système d'axes doit être fournie ou une méthode de conversion vers le système d'axes Unity ou EasyAR doit être donnée.
  • Sur les appareils de type casque, il existe généralement plusieurs systèmes de coordonnées avec des définitions différentes. Ces différences peuvent inclure l'origine des axes, l'orientation, la représentation main gauche/main droite, etc. Les paramètres extrinsèques doivent être calculés dans le même système de coordonnées. Cette interface nécessite une transformation de coordonnées dans le même système, et non une matrice de transformation entre deux systèmes de coordonnées de définitions différentes.

Performances :

  • Les données doivent être fournies de manière optimale. Dans la plupart des implémentations, les appels d'API se produisent pendant le processus de rendu. Il est donc recommandé, même si des opérations longues sont nécessaires en bas niveau, de ne pas bloquer les appels d'API, ou d'utiliser ces API de manière raisonnable.
  • Si l'extension d'entrée est implémentée par EasyAR, tous les appels d'API potentiellement longs doivent être documentés.

Caméras multiples :

  • Les données d'au moins une caméra sont nécessaires. Cette caméra peut être une caméra RGB, une caméra VST, une caméra de localisation, etc. Sur un casque, si une seule caméra est fournie, il est généralement recommandé d'utiliser une caméra RGB ou VST centrale ou située près des yeux.
  • L'utilisation de caméras multiples peut améliorer les résultats des algorithmes EasyAR. Toutes les données d'image des caméras disponibles à un instant donné doivent être fournies simultanément au même point dans le temps.

Les caméras multiples ne sont pas encore entièrement prises en charge. Contactez EasyAR pour plus de détails.

Étapes suivantes

Sujets connexes