Exigences relatives aux données de frame d'entrée pour les sources de données de frame externes
Pour qu'une source de données de frame externe fonctionne correctement, la tâche la plus importante, et aussi la plus délicate, consiste à garantir la justesse des données. Cet article décrit les exigences relatives aux données de frame d'entrée pour les sources de données de frame externes.
Avant de commencer
- Comprenez les concepts de base tels que caméra et frame d'entrée.
- Comprenez les concepts de base et les types courants de sources de données de frame externes.
Types de données de frame d'entrée
Dans Unity, une source de données de frame externe doit généralement recevoir des données différentes à deux moments différents. Selon le moment d'entrée des données externes et leurs caractéristiques, ces deux groupes de données sont appelés:
- données de frame caméra (camera frame data)
- données de frame de rendu (rendering frame data)
Les différents types de sources de données de frame externes ont des besoins différents pour ces deux groupes de données:
- Extension d'entrée de données d'image et de mouvement de l'appareil: nécessite à la fois les données de frame caméra et les données de frame de rendu
- Extension d'entrée d'image: nécessite uniquement les données de frame caméra
Données de frame caméra
Exigences de données:
- timestamp
- données d'image brutes de la caméra physique (raw camera image data)
- intrinsèques (intrinsics, y compris taille d'image, focale et point principal. S'il existe une distorsion, le modèle et les paramètres de distorsion sont également nécessaires)
- extrinsèques (extrinsics, Tcw ou Twc, matrice calibrée exprimant le décalage physique de la caméra physique par rapport au pose origin de l'appareil/de la tête)
- état de tracking (tracking status)
- pose de l'appareil (device pose)
Temps des données:
- Point médian de l'exposition de la caméra physique
Utilisation des données:
- Temps d'appel API: peut varier selon la conception du code externe. Une méthode courante utilisée par la plupart des appareils consiste à interroger pendant la mise à jour du rendu du 3D engine, puis à décider, selon le timestamp des données de l'appareil, s'il faut poursuivre le traitement des données
- Thread d'appel API: le game thread du 3D engine, ou tout autre thread si toutes les API externes utilisées sont thread-safe
L'exemple d'appel API dans Unity est le suivant :
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);
}
}
Rendre les frame data
Exigences de données :
- Timestamp
- Tracking status
- Device pose
Temps des données:
- Moment de présentation à l'écran. TimeWarp n'est pas inclus. Les données device pose au même moment seront utilisées par l'extérieur, par exemple par le device SDK, pour définir le transform de la caméra virtuelle lors du rendu de la frame actuelle.
Note
TimeWarp, parfois aussi appelé Reprojection ou ATW/PTW, est une technique courante de réduction de latence dans les casques VR/AR. Une fois le rendu terminé, elle déforme de nouveau l'image selon la pose de tête la plus récente afin de compenser le mouvement de tête produit pendant le rendu. EasyAR a besoin du moment correspondant à la pose utilisée pour définir la caméra virtuelle au début du rendu, et non du moment réel de présentation à l'écran après TimeWarp.
Utilisation des données:
- Temps d'appel API: chaque frame de rendu du 3D engine
- Thread d'appel API: le game thread du 3D engine
Un exemple d'appel d'API dans Unity est le suivant :
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 d'image: les données acquises lorsque le capteur est horizontal doivent également être horizontales. Les données doivent utiliser le coin supérieur gauche comme origin et être stockées en ordre row-major. L'image ne doit pas être retournée ni inversée.
- FPS de l'image: les données normales à 30 ou 60 fps sont acceptables. Si un fps élevé a un impact particulier, la fréquence d'images minimale acceptable pour obtenir un résultat d'algorithme raisonnable est 2. Il est recommandé d'utiliser un fps supérieur à 2; en général, la fréquence d'images d'origine des données peut être utilisée.
- Taille d'image: pour obtenir de meilleurs résultats de calcul, le côté le plus long doit être de 960 ou plus. Le redimensionnement d'image coûteux dans la chaîne de données n'est généralement pas recommandé. Il est recommandé d'utiliser directement les données d'origine, sauf si le temps de copie des données en taille complète est déjà inacceptable. La résolution de l'image ne doit pas être inférieure à 640*480.
- Format de pixel: en donnant la priorité à l'effet de tracking et en tenant compte des performances, l'ordre de préférence habituel est YUV > RGB > RGBA > Gray (le composant Y dans YUV). Lors de l'utilisation de données YUV, une définition complète des données est requise, y compris les détails de conditionnement et de padding. Par rapport aux images monocanal, les images couleur donnent de meilleurs résultats Mega, mais ont peu d'effet sur les autres fonctions.
- 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 la chaîne de données. Dans HandleRenderFrameData, EasyAR copie une copie des données puis l'utilise de manière asynchrone. Une fois l'appel synchrone terminé, les données d'image ne sont plus utilisées. Faites attention à la propriété des données.
Horodatages :
- Tous les horodatages doivent être synchronisés avec l'horloge, de préférence par matériel. L'unité des données est la seconde, mais la précision doit atteindre la nanoseconde ou être aussi élevée que possible.
État de tracking :
- L'état de tracking est défini par l'appareil et doit inclure l'état de perte de tracking, lorsque VIO est indisponible. S'il existe davantage de niveaux, c'est préférable.
Pose de l'appareil :
- Toutes les pose, y compris le transform de la caméra virtuelle dans le moteur 3D, doivent utiliser la même origine.
- Toutes les pose et extrinsics doivent utiliser le même système d'axes de coordonnées.
- Dans Unity, le type de système d'axes de coordonnées des données pose doit être le système d'axes Unity ou EasyAR. Si la input extension est implémentée par EasyAR et utilise une autre définition de système d'axes de coordonnées, fournissez une définition claire ou une méthode de conversion vers le système Unity ou EasyAR.
- Dans Unity, si le framework Unity XR est utilisé, il suffit d'être compatible avec le mode XROrigin.TrackingOriginMode.Device.
Intrinsics :
- Toutes les valeurs doivent correspondre aux données d'image. Si nécessaire, mettez les intrinsics à l'échelle avant de les entrer dans EasyAR.
- Si la input extension est implémentée par EasyAR, indiquez si les intrinsics changent à chaque frame, car cela détermine si l'API correspondante doit être appelée une seule fois ou à chaque frame.
Extrinsics :
- Sur les casques, des données réelles doivent être fournies.
- Il s'agit d'une matrice de calibration exprimant le décalage physique de la caméra physique par rapport à l'origine pose de l'appareil/de la tête. Si la pose de l'appareil et la pose de la caméra physique sont identiques, elle doit être une matrice identité.
- L'interface correspondante pour Apple Vision Pro est CameraFrame.Sample.Parameters.extrinsics. Notez que sa définition de données diffère des données requises par l'interface, et EasyAR l'utilise en interne après conversion.
- Dans Unity, le type de système d'axes de coordonnées des extrinsics doit être le système Unity ou EasyAR. Si la input extension est implémentée par EasyAR et utilise une autre définition de système d'axes, fournissez une définition claire ou une méthode de conversion vers le système Unity ou EasyAR.
- Dans les casques, il existe généralement plusieurs systèmes de coordonnées aux définitions différentes, incluant origine, orientation et représentation main gauche/main droite. Les extrinsics doivent être calculés dans le même système de coordonnées. Les données de cette interface nécessitent une transformation de coordonnées dans le même système, et non une matrice de transformation entre deux systèmes aux définitions différentes.
Performances :
- Les données doivent être fournies avec une efficacité optimale. Dans la plupart des implémentations, les appels API ont lieu pendant le rendu ; même si des opérations longues sont nécessaires au niveau inférieur, il est donc recommandé de ne pas bloquer les appels API, ou d'utiliser ces API de manière raisonnable.
- Si la input extension est implémentée par EasyAR, décrivez tous les appels API longs.
Multi-caméra :
- Les données d'au moins une caméra sont nécessaires. Cette caméra peut être une caméra RGB, VST, de localisation, etc. Sur les casques, si les données d'une seule caméra sont entrées, il est généralement recommandé d'utiliser une caméra RGB ou VST située au centre ou près des yeux.
- L'utilisation de plusieurs caméras peut améliorer le résultat de l'algorithme EasyAR. Les données de frame de toutes les caméras disponibles à un instant donné doivent être entrées simultanément au même point temporel.
Le multi-caméra n'est pas encore entièrement pris en charge. Contactez EasyAR pour plus de détails.
Étapes suivantes
- Créer une extension d'entrée de données d'image et de mouvement de l'appareil
- Créer une extension d'entrée d'image
- Créer un package d'extension de casque
Rubriques associées
- Systèmes de coordonnées EasyAR
- Exemple d'extension d'entrée d'image Workflow_FrameSource_ExternalImageStream