Table of Contents

Anforderungen an Eingangs-Framedaten für externe Frame-Datenquellen

Damit externe Frame-Datenquellen ordnungsgemäß funktionieren, ist die wichtigste und gleichzeitig kniffligste Aufgabe die Sicherstellung der Datenkorrektheit. Dieser Artikel beschreibt die Anforderungen an Eingangs-Framedaten für externe Frame-Datenquellen.

Voraussetzungen

Typen von Eingangs-Framedaten

In Unity müssen externe Frame-Datenquellen typischerweise zu zwei verschiedenen Zeitpunkten unterschiedliche Daten empfangen. Basierend auf dem Zeitpunkt der externen Dateneingabe und den Datenmerkmalen werden diese beiden Datensätze bezeichnet als:

  1. Kamera-Framedaten (camera frame data)
  2. Render-Framedaten (rendering frame data)

Verschiedene Typen externer Frame-Datenquellen haben unterschiedliche Anforderungen an diese beiden Datensätze:

  • Erweiterung für Bild- und Gerätebewegungsdaten: Benötigt sowohl Kamera-Framedaten als auch Render-Framedaten
  • Erweiterung für Bildeingang: Benötigt nur Kamera-Framedaten

Kamera-Framedaten

Datenanforderungen:

  1. Zeitstempel (timestamp)
  2. Rohdaten des physikalischen Kamerabilds (raw camera image data)
  3. Intrinsikparameter (intrinsics, einschließlich Bildgröße, Brennweite, Hauptpunkt. Bei Verzerrung zusätzlich Verzerrungsmodell und -parameter)
  4. Extrinsikparameter (extrinsics, Tcw oder Twc, kalibrierte Matrix, die die physikalische Verschiebung der physikalischen Kamera relativ zum Pose-Ursprung des Geräts/Kopfs ausdrückt)
  5. Tracking-Status (tracking status)
  6. Gerätepose (device pose)

Datenzeitpunkt:

  • Mittelpunkt der physikalischen Kamerabelichtung

Datenverwendung:

  • API-Aufrufzeit: Kann basierend auf dem Design des externen Codes variieren. Eine gängige Methode für die meisten Geräte ist die Abfrage im Render-Update der 3D-Engine, gefolgt von einer Entscheidung zur weiteren Datenverarbeitung basierend auf dem Zeitstempel der Gerätedaten
  • API-Aufrufthread: Game-Thread der 3D-Engine oder jeder andere Thread (falls alle verwendeten externen APIs threadsicher sind)

Unity-API-Aufrufbeispiel:

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

Rendering von framendaten

Datenanforderungen:

  1. Zeitstempel (timestamp)
  2. Tracking-Status (tracking status)
  3. Gerätepose (device pose)

Datenzeitpunkt:

  • Zeitpunkt der Bildschirmausgabe. TimeWarp wird nicht berücksichtigt. Die Gerätepose-Daten zum gleichen Zeitpunkt werden von externen Quellen (z.B. Geräte-SDK) verwendet, um die Transformation der virtuellen Kamera für das Rendern des aktuellen Frames festzulegen.
Anmerkung

TimeWarp (manchmal auch als Reprojektion oder ATW/PTW bezeichnet) ist eine in VR/AR-Headsets häufig verwendete Technik zur Reduzierung der Latenz. Dabei wird das Bild nach Abschluss des Renderings basierend auf der neuesten Kopfpose erneut verzerrt, um Kopfbewegungen während des Renderings auszugleichen. EasyAR benötigt den Zeitpunkt, der der Pose entspricht, die zum Start des Renderings für das Setzen der virtuellen Kamera verwendet wird, nicht den Zeitpunkt nach TimeWarp, zu dem das Bild tatsächlich auf dem Bildschirm erscheint.

Datenverwendung:

  • API-Aufrufzeit: Jeder Render-Frame der 3D-Engine
  • API-Aufrufthread: Game-Thread der 3D-Engine

Unity-API-Aufrufbeispiel in Unity:

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

Details der Datenanforderungen

Daten des physikalischen Kamerabilds:

  • Bildkoordinatensystem: Bei horizontaler Sensorausrichtung sollten auch die Daten horizontal sein. Daten sollten den Ursprung in der oberen linken Ecke haben und zeilenweise gespeichert sein. Bilder sollten nicht gespiegelt oder invertiert sein.
  • Bild-FPS: Normale 30 oder 60 fps sind akzeptabel. Wenn hohe fps spezielle Auswirkungen haben, ist eine minimale akzeptable Bildrate von 2 für akzeptable Algorithmusergebnisse möglich. Es wird empfohlen, fps über 2 zu verwenden, typischerweise ist die Rohdaten-Bildrate ausreichend.
  • Bildgröße: Für bessere Berechnungsergebnisse sollte die längere Seite 960 oder größer sein. Eine aufwändige Bildskalierung in der Datenpipeline wird generell nicht empfohlen; Rohdaten sollten direkt verwendet werden, es sei denn, das Kopieren der vollständigen Daten dauert inakzeptabel lange. Die Bildauflösung darf nicht kleiner als 640*480 sein.
  • Pixelformat: Priorisierung basierend auf Tracking-Qualität und Leistung, typische Prioritätsreihenfolge ist YUV > RGB > RGBA > Grau (Y-Kanal in YUV). Bei Verwendung von YUV-Daten ist eine vollständige Datendefinition erforderlich, einschließlich Datenpackung und Fülldetails. Farbbilder verbessern die Mega-Funktion im Vergleich zu Einzelkanalbildern, andere Funktionen sind weniger betroffen.
  • Datenzugriff: Datenzeiger oder äquivalente Implementierung. Unnötige Kopien sollten in der Datenpipeline möglichst vermieden werden. In HandleRenderFrameData kopiert EasyAR die Daten einmal und verwendet sie asynchron; nach Abschluss dieses synchronen Aufrufs werden die Bilddaten nicht mehr verwendet. Beachten Sie die Datenbesitzverhältnisse.

Zeitstempel:

  • Alle Zeitstempel sollten zeitsynchron sein, vorzugsweise hardware-synchronisiert. Die Dateneinheit ist Sekunden, aber die Genauigkeit sollte Nanosekunden oder so hoch wie möglich erreichen.

Tracking-Zustand:

  • Der Tracking-Zustand wird vom Gerät definiert und muss einen Zustand für Tracking-Verlust (VIO nicht verfügbar) enthalten. Weitere Abstufungen sind wünschenswert.

Geräte-Pose:

  • Alle Posen (einschließlich der Transformation der virtuellen Kamera in der 3D-Engine) sollten denselben Ursprung verwenden.
  • Alle Posen und extrinsische Parameter sollten dasselbe Koordinatensystem verwenden.
  • In Unity sollte der Koordinatensystem-Typ für Posendaten das Unity-Koordinatensystem oder das EasyAR-Koordinatensystem sein. Wenn die Eingabeerweiterung von EasyAR implementiert ist und eine andere Koordinatensystemdefinition verwendet, sollte eine klare Koordinatensystemdefinition bereitgestellt oder eine Methode zur Umrechnung in das Unity- oder EasyAR-Koordinatensystem angegeben werden.
  • In Unity, wenn das Unity XR-Framework verwendet wird, ist nur die Kompatibilität mit dem XROrigin.TrackingOriginMode.Device-Modus erforderlich.

Intrinsische Parameter:

  • Alle Werte sollten mit den Bilddaten übereinstimmen. Bei Bedarf sollten intrinsische Parameter vor der Eingabe in EasyAR skaliert werden.
  • Wenn die Eingabeerweiterung von EasyAR implementiert ist, sollte angegeben werden, ob sich die intrinsischen Parameter pro Frame ändern (Unterscheidung, ob die entsprechende API einmal oder pro Frame aufgerufen werden sollte).

Extrinsische Parameter:

  • Auf Head-Mounted-Displays müssen echte Daten bereitgestellt werden.
  • Es ist eine Kalibriermatrix, die die physikalische Verschiebung der physischen Kamera relativ zum Ursprung der Geräte-/Kopf-Pose ausdrückt. Wenn die Pose des Geräts und die Pose der physischen Kamera gleich sind, sollte es die Einheitsmatrix sein.
  • Die entsprechende Schnittstelle für Apple Vision Pro ist: CameraFrame.Sample.Parameters.extrinsics. Es ist zu beachten, dass deren Datendefinition sich von der für die Schnittstelle benötigten unterscheidet; EasyAR verwendet die Daten intern nach einer Konvertierung.
  • In Unity sollte der Koordinatensystem-Typ für extrinsische Parameter das Unity-Koordinatensystem oder das EasyAR-Koordinatensystem sein. Wenn die Eingabeerweiterung von EasyAR implementiert ist und eine andere Koordinatensystemdefinition verwendet, sollte eine klare Koordinatensystemdefinition bereitgestellt oder eine Methode zur Umrechnung in das Unity- oder EasyAR-Koordinatensystem angegeben werden.
  • In Head-Mounted-Displays gibt es typischerweise mehrere Koordinatensysteme mit unterschiedlichen Definitionen. Diese Unterschiede können Ursprung, Ausrichtung, Links-/Rechtshändigkeit usw. umfassen. Extrinsische Parameter sollten im selben Koordinatensystem berechnet werden. Diese 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 Rendering-Prozesses. Daher wird empfohlen, API-Aufrufe auch dann nicht zu blockieren, wenn auf niedriger Ebene zeitaufwändige Operationen erforderlich sind, oder diese APIs auf angemessene Weise zu nutzen.
  • Wenn die Eingabeerweiterung von EasyAR implementiert ist, müssen alle zeitaufwändigen API-Aufrufe dokumentiert werden.

Mehrkamerasysteme:

  • Daten von mindestens einer Kamera sind erforderlich. Diese Kamera kann eine RGB-Kamera, eine VST-Kamera, eine Tracking-Kamera usw. sein. Auf einem Head-Mounted-Display wird, wenn nur Daten einer Kamera eingegeben werden, normalerweise die RGB- oder VST-Kamera in der Mitte oder in der Nähe der Augen empfohlen.
  • Die Verwendung mehrerer Kameras kann die Leistung der EasyAR-Algorithmen verbessern. Die Kameraframedaten aller verfügbaren Kameras zu einem bestimmten Zeitpunkt sollten gleichzeitig und für denselben Zeitpunkt eingegeben werden.

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

Nächste Schritte

Verwandte Themen