Table of Contents

Requisiti dei dati del frame di input per sorgenti di dati frame esterne

Per far funzionare correttamente una sorgente di dati frame esterna, il lavoro più importante e anche la parte più delicata è garantire la correttezza dei dati. Questo articolo descrive i requisiti dei dati del frame di input per le sorgenti di dati frame esterne.

Prima di iniziare

Tipi di dati del frame di input

In Unity, una sorgente di dati frame esterna di solito deve ricevere dati diversi in due momenti diversi. In base al tempo di input dei dati esterni e alle caratteristiche dei dati, questi due gruppi di dati sono chiamati:

  1. dati del frame camera (camera frame data)
  2. dati del frame di rendering (rendering frame data)

Tipi diversi di sorgenti di dati frame esterne hanno requisiti diversi per questi due gruppi di dati:

  • Estensione di input di dati immagine e movimento del dispositivo: richiede sia dati del frame camera sia dati del frame di rendering
  • Estensione di input immagine: richiede solo dati del frame camera

Dati del frame camera

Requisiti dei dati:

  1. timestamp
  2. dati immagine grezzi della camera fisica (raw camera image data)
  3. intrinseci (intrinsics, inclusi dimensione immagine, lunghezza focale e punto principale. Se è presente distorsione, sono necessari anche modello e parametri di distorsione)
  4. estrinseci (extrinsics, Tcw o Twc, matrice calibrata che esprime l'offset fisico della camera fisica rispetto al pose origin del dispositivo/testa)
  5. stato di tracking (tracking status)
  6. pose del dispositivo (device pose)

Tempo dei dati:

  • Punto medio dell'esposizione della camera fisica

Uso dei dati:

  • Tempo di chiamata API: può cambiare in base al progetto del codice esterno. Un metodo comune usato dalla maggior parte dei dispositivi è interrogare durante l'aggiornamento di rendering del 3D engine, quindi decidere se elaborare ulteriormente i dati in base al timestamp dei dati del dispositivo
  • Thread di chiamata API: il game thread del 3D engine, o qualsiasi altro thread se tutte le API esterne utilizzate sono thread-safe

L'esempio di chiamata API in Unity e il seguente:

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

Renderizzare frame data

Requisiti dei dati:

  1. Timestamp
  2. Tracking status
  3. Device pose

Tempo dei dati:

  • Momento di presentazione sullo schermo. TimeWarp non è incluso. I dati device pose dello stesso momento saranno usati esternamente, per esempio dal device SDK, per impostare il transform della camera virtuale per il rendering del frame corrente.
Nota

TimeWarp, talvolta chiamato anche Reprojection o ATW/PTW, è una tecnica comune nei visori VR/AR per ridurre la latenza. Dopo il completamento del rendering, deforma nuovamente l'immagine in base alla pose della testa più recente per compensare il movimento della testa prodotto durante il rendering. EasyAR richiede il momento corrispondente alla pose usata per impostare la camera virtuale all'inizio del rendering, non il momento effettivo di presentazione sullo schermo dopo TimeWarp.

Uso dei dati:

  • Tempo di chiamata API: ogni frame di rendering del 3D engine
  • Thread di chiamata API: il game thread del 3D engine

Un esempio di chiamata API in Unity è il seguente:

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

Dettagli dei requisiti dei dati

Dati immagine della camera fisica:

  • Sistema di coordinate immagine: i dati acquisiti quando il sensore è orizzontale devono essere anch'essi orizzontali. I dati devono usare l'angolo in alto a sinistra come origin ed essere memorizzati in ordine row-major. L'immagine non deve essere specchiata o capovolta.
  • FPS immagine: sono accettabili dati normali a 30 o 60 fps. Se fps elevati hanno effetti particolari, il frame rate minimo accettabile per ottenere risultati ragionevoli dall'algoritmo è 2. Si consiglia di usare fps superiori a 2; normalmente si può usare il frame rate originale dei dati.
  • Dimensione immagine: per ottenere risultati di calcolo migliori, il lato più lungo deve essere 960 o maggiore. In genere non è consigliato eseguire scaling dell'immagine dispendioso nella catena dei dati. Si consiglia di usare direttamente i dati originali, a meno che il tempo di copia dei dati a dimensione completa sia già troppo lungo per essere accettabile. La risoluzione dell'immagine non deve essere inferiore a 640*480.
  • Formato pixel: dando priorità all'effetto di tracking e considerando anche le prestazioni, l'ordine di preferenza usuale è YUV > RGB > RGBA > Gray (il componente Y in YUV). Quando si usano dati YUV, è necessaria una definizione completa dei dati, inclusi dettagli di impacchettamento e padding. Rispetto alle immagini a canale singolo, le immagini a colori danno risultati Mega migliori, ma hanno scarso effetto su altre funzioni.
  • Accesso ai dati: puntatore ai dati o implementazione equivalente. È meglio eliminare tutte le possibili copie non necessarie nella catena dei dati. In HandleRenderFrameData, EasyAR copia una copia dei dati e poi la usa in modo asincrono. Dopo il completamento della chiamata sincrona, i dati immagine non vengono più usati. Prestare attenzione alla proprietà dei dati.

Timestamp:

  • Tutti i timestamp devono essere sincronizzati con l'orologio, preferibilmente tramite hardware. L'unità dei dati è il secondo, ma la precisione deve arrivare ai nanosecondi o essere la più alta possibile.

Stato di tracking:

  • Lo stato di tracking è definito dal dispositivo e deve includere lo stato di tracking perso, in cui VIO non è disponibile. Se sono presenti più livelli, è meglio.

Pose del dispositivo:

  • Tutte le pose, incluso il transform della camera virtuale nel motore 3D, devono usare la stessa origine.
  • Tutte le pose e gli extrinsics devono usare lo stesso sistema di assi di coordinate.
  • In Unity, il tipo di sistema di assi di coordinate dei dati pose deve essere il sistema di Unity o quello di EasyAR. Se la input extension è implementata da EasyAR e usa un'altra definizione del sistema di assi, fornire una definizione chiara o un metodo per convertirla nel sistema di Unity o EasyAR.
  • In Unity, se si usa il framework Unity XR, è sufficiente la compatibilità con la modalità XROrigin.TrackingOriginMode.Device.

Intrinsics:

  • Tutti i valori devono corrispondere ai dati immagine. Se necessario, scalare gli intrinsics prima di inserirli in EasyAR.
  • Se la input extension è implementata da EasyAR, specificare se gli intrinsics cambiano a ogni frame, perché questo determina se l'API corrispondente deve essere chiamata una sola volta o a ogni frame.

Extrinsics:

  • Sui visori devono essere forniti dati reali.
  • È una matrice di calibrazione che esprime l'offset fisico della camera fisica rispetto all'origine pose del dispositivo/testa. Se la pose del dispositivo e la pose della camera fisica sono uguali, deve essere una matrice identità.
  • L'interfaccia corrispondente per Apple Vision Pro è CameraFrame.Sample.Parameters.extrinsics. Notare che la sua definizione dei dati è diversa dai dati richiesti dall'interfaccia, ed EasyAR la usa internamente dopo la conversione.
  • In Unity, il tipo di sistema di assi di coordinate degli extrinsics deve essere il sistema di Unity o EasyAR. Se la input extension è implementata da EasyAR e usa un'altra definizione del sistema di assi, fornire una definizione chiara o un metodo per convertirla nel sistema di Unity o EasyAR.
  • Nei dispositivi headset esistono di solito più sistemi di coordinate con definizioni diverse, incluse differenze di origine, orientamento e rappresentazione sinistrorsa/destrorsa. Gli extrinsics devono essere calcolati nello stesso sistema di coordinate. I dati di questa interfaccia richiedono una trasformazione di coordinate nello stesso sistema, non una matrice di trasformazione tra due sistemi con definizioni diverse.

Prestazioni:

  • I dati devono essere forniti con efficienza ottimale. Nella maggior parte delle implementazioni, le chiamate API avvengono durante il rendering, quindi anche se sono necessarie operazioni dispendiose a livello inferiore, non bloccare le chiamate API oppure usare queste API in modo ragionevole.
  • Se la input extension è implementata da EasyAR, descrivere tutte le chiamate API dispendiose.

Multi-camera:

  • Sono necessari i dati di almeno una camera. Può essere una camera RGB, VST, di localizzazione e così via. Sui visori, se si inseriscono dati di una sola camera, di solito si consiglia di usare una camera RGB o VST al centro o vicino agli occhi.
  • L'uso di più camere può migliorare il risultato dell'algoritmo EasyAR. I dati dei frame di tutte le camere disponibili in un determinato momento devono essere inseriti simultaneamente nello stesso punto temporale.

Multi-camera non è ancora completamente supportato. Contattare EasyAR per maggiori dettagli.

Passaggi successivi

Argomenti correlati