Table of Contents

Anforderungen an Eingabeframedaten für externe Framedatenquellen

Damit eine externe Framedatenquelle korrekt funktioniert, besteht die wichtigste und zugleich schwierigste Aufgabe darin, die Korrektheit der Daten sicherzustellen. Dieser Artikel beschreibt die Anforderungen an Eingabeframedaten für externe Framedatenquellen.

Bevor Sie beginnen

Typen von Eingabeframedaten

In Unity muss eine externe Framedatenquelle normalerweise zu zwei unterschiedlichen Zeitpunkten unterschiedliche Daten empfangen. Nach Eingabezeitpunkt und Datenmerkmalen der externen Daten werden diese beiden Datengruppen bezeichnet als:

  1. Kameraframedaten (camera frame data)
  2. Renderingframedaten (rendering frame data)

Verschiedene Typen externer Framedatenquellen benötigen diese beiden Datengruppen in unterschiedlichem Umfang:

  • Eingabeerweiterung für Bild- und Gerätebewegungsdaten: benötigt sowohl Kameraframedaten als auch Renderingframedaten
  • Bildeingabeerweiterung: benötigt nur Kameraframedaten

Kameraframedaten

Datenanforderungen:

  1. timestamp
  2. rohe Bilddaten der physischen Kamera (raw camera image data)
  3. Intrinsics (intrinsics, einschließlich Bildgröße, Brennweite und Hauptpunkt. Bei Verzeichnung werden außerdem Verzeichnungsmodell und Verzeichnungsparameter benötigt)
  4. Extrinsics (extrinsics, Tcw oder Twc, kalibrierte Matrix, die den physischen Offset der physischen Kamera relativ zum pose origin des Geräts/Kopfes ausdrückt)
  5. Trackingstatus (tracking status)
  6. Gerätepose (device pose)

Datenzeit:

  • Mittelpunkt der Belichtung der physischen Kamera

Datennutzung:

  • API-Aufrufzeit: kann sich je nach Entwurf des externen Codes ändern. Eine von den meisten Geräten verwendete übliche Methode besteht darin, während des Rendering-Updates der 3D engine abzufragen und dann anhand des timestamp der Gerätedaten zu entscheiden, ob eine weitere Datenverarbeitung erfolgt
  • API-Aufrufthread: der game thread der 3D engine oder ein beliebiger anderer Thread, sofern alle verwendeten externen APIs thread-safe sind

Das Beispiel für den API-Aufruf in Unity ist wie folgt:

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);
    }
}

Frame data rendern

Datenanforderungen:

  1. Timestamp
  2. Tracking status
  3. Device pose

Datenzeit:

  • Zeitpunkt der Bildschirmausgabe. TimeWarp wird nicht berücksichtigt. Device pose-Daten zum gleichen Zeitpunkt werden extern, zum Beispiel durch das device SDK, verwendet, um den transform der virtuellen Kamera für das Rendern des aktuellen Frames zu setzen.
Anmerkung

TimeWarp, manchmal auch Reprojection oder ATW/PTW genannt, ist eine in VR/AR-Headsets gängige Technik zur Verringerung der Latenz. Nach Abschluss des Renderings wird das Bild anhand der neuesten Kopfpose erneut verzerrt, um während des Renderings entstandene Kopfbewegungen zu kompensieren. EasyAR benötigt den Zeitpunkt, der der pose entspricht, die beim Beginn des Renderings zum Setzen der virtuellen Kamera verwendet wurde, nicht den tatsächlichen Zeitpunkt der Bildschirmausgabe nach TimeWarp.

Datennutzung:

  • API-Aufrufzeit: jeder Renderingframe der 3D engine
  • API-Aufrufthread: der game thread der 3D engine

Ein Beispiel für einen API-Aufruf in Unity sieht wie folgt aus:

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

Details der Datenanforderungen

Bilddaten der physischen Kamera:

  • Bildkoordinatensystem: Daten, die bei horizontalem Sensor erfasst werden, sollten ebenfalls horizontal sein. Die Daten sollten die linke obere Ecke als origin verwenden und in row-major-Reihenfolge gespeichert werden. Das Bild darf nicht gespiegelt oder umgedreht sein.
  • Bild-FPS: normale Daten mit 30 oder 60 fps sind geeignet. Wenn hohe fps besondere Auswirkungen haben, beträgt die minimal akzeptable Framerate für sinnvolle Algorithmusergebnisse 2. Es wird empfohlen, fps über 2 zu verwenden; normalerweise kann die ursprüngliche Framerate der Daten verwendet werden.
  • Bildgröße: Für bessere Berechnungsergebnisse sollte die längste Seite 960 oder größer sein. Zeitaufwendiges Bildskalieren in der Datenkette wird normalerweise nicht empfohlen. Es wird empfohlen, direkt die Originaldaten zu verwenden, sofern die Kopierzeit der vollständigen Daten nicht bereits unakzeptabel lang ist. Die Bildauflösung darf nicht kleiner als 640*480 sein.
  • Pixelformat: Wenn Trackingwirkung priorisiert und Leistung mit berücksichtigt wird, lautet die übliche Präferenzreihenfolge YUV > RGB > RGBA > Gray (die Y-Komponente in YUV). Bei Verwendung von YUV-Daten ist eine vollständige Datendefinition erforderlich, einschließlich Details zu Datenpackung und Padding. Im Vergleich zu Einkanalbildern liefern Farbbilder bessere Mega-Ergebnisse, haben aber wenig Einfluss auf andere Funktionen.
  • Datenzugriff: Datenzeiger oder äquivalente Implementierung. Es ist am besten, alle möglichen nicht erforderlichen Kopien in der Datenkette zu vermeiden. In HandleRenderFrameData kopiert EasyAR eine Kopie der Daten und verwendet sie anschließend asynchron. Nach Abschluss des synchronen Aufrufs werden die Bilddaten nicht mehr verwendet. Achten Sie auf die Dateneigentümerschaft.

Zeitstempel:

  • Alle Zeitstempel sollten taktsynchron sein, vorzugsweise hardwaresynchron. Die Dateneinheit ist Sekunden, die Genauigkeit sollte jedoch Nanosekunden erreichen oder so hoch wie möglich sein.

Tracking-Status:

  • Der Tracking-Status wird vom Gerät definiert und muss den Status Tracking verloren enthalten, bei dem VIO nicht verfügbar ist. Mehr Stufen sind besser, falls vorhanden.

Geräte-Pose:

  • Alle pose, einschließlich transform der virtuellen Kamera in der 3D-Engine, sollten denselben Ursprung verwenden.
  • Alle pose und extrinsics sollten dasselbe Koordinatenachsensystem verwenden.
  • In Unity sollte der Typ des Koordinatenachsensystems der pose-Daten entweder das Unity-Koordinatenachsensystem oder das EasyAR-Koordinatenachsensystem sein. Wenn die input extension von EasyAR implementiert wird und eine andere Definition des Koordinatenachsensystems verwendet, geben Sie eine klare Definition oder eine Methode zur Umwandlung in das Unity- oder EasyAR-Koordinatenachsensystem an.
  • In Unity reicht bei Verwendung des Unity XR framework die Kompatibilität mit dem Modus XROrigin.TrackingOriginMode.Device.

Intrinsics:

  • Alle Werte sollten zu den Bilddaten passen. Skalieren Sie intrinsics bei Bedarf vor der Eingabe in EasyAR.
  • Wenn die input extension von EasyAR implementiert wird, geben Sie an, ob sich intrinsics in jedem Frame ändern. Davon hängt ab, ob die entsprechende API einmal oder in jedem Frame aufgerufen werden sollte.

Extrinsics:

  • Auf Headsets müssen echte Daten bereitgestellt werden.
  • Dies ist eine Kalibrierungsmatrix, die den physischen Versatz der physischen Kamera relativ zum pose-Ursprung des Geräts/Kopfs ausdrückt. Wenn Geräte-pose und physische Kamera-pose gleich sind, sollte sie eine Einheitsmatrix sein.
  • Die entsprechende Schnittstelle für Apple Vision Pro ist CameraFrame.Sample.Parameters.extrinsics. Beachten Sie, dass deren Datendefinition von den für die Schnittstelle benötigten Daten abweicht; EasyAR verwendet sie intern erst nach einer Konvertierung.
  • In Unity sollte der Typ des Koordinatenachsensystems von extrinsics entweder das Unity- oder das EasyAR-Koordinatenachsensystem sein. Wenn die input extension von EasyAR implementiert wird und eine andere Definition des Koordinatenachsensystems verwendet, geben Sie eine klare Definition oder eine Methode zur Umwandlung in das Unity- oder EasyAR-Koordinatenachsensystem an.
  • In Headset-Geräten gibt es normalerweise mehrere unterschiedlich definierte Koordinatensysteme, etwa Unterschiede bei Ursprung, Ausrichtung und Links-/Rechtshändigkeit. Extrinsics sollten im selben Koordinatensystem berechnet werden. Die Schnittstellendaten benötigen eine Koordinatentransformation innerhalb desselben Koordinatensystems, nicht eine Transformationsmatrix zwischen zwei unterschiedlich definierten Koordinatensystemen.

Leistung:

  • Daten sollten mit optimaler Effizienz bereitgestellt werden. In den meisten Implementierungen erfolgen API-Aufrufe während des Renderings. Daher sollten API-Aufrufe auch dann nicht blockiert werden, wenn auf niedrigerer Ebene zeitaufwendige Operationen nötig sind, oder diese APIs sollten auf angemessene Weise verwendet werden.
  • Wenn die input extension von EasyAR implementiert wird, beschreiben Sie alle zeitaufwendigen API-Aufrufe.

Mehrere Kameras:

  • Daten von mindestens einer Kamera sind erforderlich. Diese Kamera kann eine RGB-Kamera, VST-Kamera, Lokalisierungskamera usw. sein. Auf Headsets wird bei Eingabe von nur einer Kamera normalerweise empfohlen, eine RGB- oder VST-Kamera in der Mitte oder in Augennähe zu verwenden.
  • Die Verwendung mehrerer Kameras kann die Ergebnisse des EasyAR-Algorithmus verbessern. Kameraframedaten aller verfügbaren Kameras zu einem bestimmten Zeitpunkt sollten gleichzeitig zum selben Zeitpunkt eingegeben werden.

Mehrere Kameras werden derzeit noch nicht vollständig unterstützt. Kontaktieren Sie EasyAR für weitere Details.

Nächste Schritte

Verwandte Themen