Table of Contents

Requisitos de datos de fotograma de entrada para la fuente de datos de fotograma externa

Para que la fuente de datos de fotograma externa funcione correctamente, la parte más importante y complicada es garantizar la exactitud de los datos. Este documento describe los requisitos de datos de fotograma de entrada para la fuente de datos de fotograma externa.

Antes de comenzar

Tipos de datos de fotograma de entrada

En Unity, la fuente de datos de fotograma externa generalmente necesita recibir diferentes datos en dos momentos distintos. Según el momento de entrada de datos externos y las características de los datos, denominamos estos dos conjuntos de datos como:

  1. Datos de fotograma de cámara (camera frame data)
  2. Datos de fotograma de renderizado (rendering frame data)

Diferentes tipos de fuentes de datos de fotograma externa tienen diferentes requisitos para estos dos conjuntos de datos:

  • Extensión de entrada de datos de imagen y movimiento del dispositivo: requiere tanto datos de fotograma de cámara como de renderizado
  • Extensión de entrada de imagen: solo requiere datos de fotograma de cámara

Datos de fotograma de cámara

Requisitos de datos:

  1. Marca de tiempo (timestamp)
  2. Datos de imagen de cámara física sin procesar (raw camera image data)
  3. Parámetros intrínsecos (intrinsics, incluyendo tamaño de imagen, distancia focal, punto principal. Si hay distorsión, también se necesitan el modelo de distorsión y los parámetros de distorsión)
  4. Parámetros extrínsecos (extrinsics, Tcw o Twc, matriz calibrada que expresa el desplazamiento físico de la cámara física en relación con el origen de pose del dispositivo/cabeza)
  5. Estado de seguimiento (tracking status)
  6. Pose del dispositivo (device pose)

Momento de los datos:

  • Punto medio de exposición de la cámara física

Uso de los datos:

  • Momento de llamada API: puede variar según el diseño del código externo. Un método común para la mayoría de dispositivos es consultar durante la actualización de renderizado del motor 3D, luego juzgar según la marca de tiempo de los datos del dispositivo si se necesita más procesamiento de datos
  • Hilo de llamada API: game thread del motor 3D o cualquier otro hilo (si todas las API externas utilizadas son seguras para hilos)

Ejemplo de llamada API en 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);
    }
}

Datos de frame de renderizado

Requisitos de datos:

  1. Marca de tiempo (timestamp)
  2. Estado de seguimiento (tracking status)
  3. Pose del dispositivo (device pose)

Momento de los datos:

  • Momento de presentación en pantalla. TimeWarp no se tiene en cuenta. Los datos de pose del dispositivo en el mismo momento serán utilizados por el exterior (por ejemplo, el SDK del dispositivo) para establecer el transform de la cámara virtual y renderizar el fotograma actual.
Nota

TimeWarp (a veces llamado Reprojection o ATW/PTW) es una técnica común en cascos VR/AR para reducir la latencia. Distorsiona la imagen nuevamente después del renderizado según la última pose de la cabeza para compensar el movimiento durante el renderizado. EasyAR necesita el momento correspondiente a la pose utilizada para establecer la cámara virtual al inicio del renderizado, no el momento real de presentación después de TimeWarp.

Uso de los datos:

  • Momento de llamada API: cada fotograma de renderizado del motor 3D
  • Hilo de llamada API: game thread del motor 3D

Ejemplo de llamada a API en Unity:

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

Detalles de los requisitos de datos

Datos de imagen de cámara física:

  • Sistema de coordenadas de imagen: los datos capturados con el sensor horizontal también deben estar horizontales. Los datos deben almacenarse con origen en la esquina superior izquierda, priorizando filas. La imagen no debe voltearse o invertirse.
  • FPS de imagen: datos normales a 30 o 60 fps son aceptables. Si fps alto tiene impacto especial, para lograr efectos algorítmicos razonables, la tasa mínima aceptable es 2. Se recomienda usar fps superior a 2; normalmente se puede usar la tasa de fotogramas de datos original.
  • Tamaño de imagen: para mejores resultados de cálculo, el lado más largo debe ser 960 o mayor. Normalmente se desaconseja el escalado de imagen que consume tiempo en la cadena de datos; se recomienda usar datos originales directamente, a menos que la copia de datos a tamaño completo sea inaceptablemente lenta. La resolución de imagen no puede ser menor a 640*480.
  • Formato de píxel: priorizando efecto de seguimiento y considerando rendimiento, el orden de preferencia suele ser YUV > RGB > RGBA > Gray (componente Y en YUV). Al usar datos YUV, se necesita definición completa de datos, incluyendo detalles de empaquetamiento y relleno. Las imágenes en color mejoran más el efecto Mega que las monocromáticas, pero otros efectos son menores.
  • Acceso a datos: puntero de datos o implementación equivalente. Idealmente eliminar todas las copias innecesarias posibles en la cadena de datos. En HandleRenderFrameData, EasyAR copia los datos una vez, luego los usa asincrónicamente; después de completar esta llamada sincrónica, ya no usa los datos de imagen. Notar la propiedad de los datos.

Timestamp:

  • Todos los timestamps deben estar sincronizados por reloj, preferiblemente por hardware. Las unidades de datos son segundos, pero la precisión debe ser nanosegundos o lo más alta posible.

Estado de seguimiento:

  • El estado de seguimiento lo define el dispositivo y debe incluir el estado de pérdida de seguimiento (VIO no disponible). Si hay más niveles, mejor.

Pose del dispositivo:

  • Todas las poses (incluida la transform de la cámara virtual en el motor 3D) deben usar el mismo origen.
  • Todas las poses y los parámetros extrínsecos deben usar el mismo sistema de ejes de coordenadas.
  • En Unity, el tipo de sistema de ejes de coordenadas para los datos de pose debe ser el sistema de coordenadas de Unity o el de EasyAR. Si la extensión de entrada es implementada por EasyAR y utiliza otras definiciones de sistemas de ejes de coordenadas, debe proporcionar una definición clara del sistema de ejes o un método para convertirlo al sistema de coordenadas de Unity o EasyAR.
  • En Unity, si se usa el marco XR de Unity, solo es necesario ser compatible con el modo XROrigin.TrackingOriginMode.Device.

Parámetros intrínsecos:

  • Todos los valores deben coincidir con los datos de la imagen. Si es necesario, los parámetros intrínsecos deben escalarse antes de ingresar a EasyAR.
  • Si la extensión de entrada es implementada por EasyAR, debe indicarse si los parámetros intrínsecos cambian cada fotograma (la diferencia es si la API correspondiente debe llamarse una vez o por fotograma).

Parámetros extrínsecos:

  • Debe proporcionarse datos reales en dispositivos head-mounted.
  • Es una matriz de calibración que expresa el desplazamiento físico de la cámara física relativo al origen de la pose del dispositivo/cabeza. Si la pose del dispositivo y la pose de la cámara física son iguales, debe ser la matriz identidad.
  • La interfaz correspondiente para Apple Vision Pro es: CameraFrame.Sample.Parameters.extrinsics. Tenga en cuenta que la definición de sus datos difiere de la requerida por la interfaz; EasyAR realiza una conversión internamente antes de usarlos.
  • En Unity, el tipo de sistema de ejes de coordenadas para los parámetros extrínsecos debe ser el sistema de coordenadas de Unity o el de EasyAR. Si la extensión de entrada es implementada por EasyAR y utiliza otras definiciones de sistemas de ejes de coordenadas, debe proporcionar una definición clara del sistema de ejes o un método para convertirlo al sistema de coordenadas de Unity o EasyAR.
  • En dispositivos head-mounted, generalmente existen múltiples sistemas de coordenadas con diferentes definiciones. Estas diferencias pueden incluir el origen de los ejes, la orientación, la representación de mano izquierda/derecha, etc. Los parámetros extrínsecos deben calcularse en el mismo sistema de coordenadas. Esta interfaz de datos requiere una transformación de coordenadas dentro del mismo sistema, no una matriz de transformación entre dos sistemas de coordenadas con definiciones diferentes.

Rendimiento:

  • Los datos deben proporcionarse con la máxima eficiencia. En la mayoría de las implementaciones, las llamadas API ocurren durante el proceso de renderizado, por lo que se recomienda no bloquear las llamadas API incluso si las operaciones subyacentes requieren tiempo, o utilizar estas API de manera razonable.
  • Si la extensión de entrada es implementada por EasyAR, se deben documentar todas las llamadas API que consumen tiempo.

Múltiples cámaras:

  • Se necesitan datos de al menos una cámara. Esta cámara puede ser cualquiera entre una cámara RGB, una cámara VST, una cámara de seguimiento, etc. En dispositivos head-mounted, si solo se ingresa una cámara, generalmente se recomienda usar una cámara RGB o VST ubicada en el centro o cerca de los ojos.
  • El uso de múltiples cámaras puede mejorar el rendimiento de los algoritmos de EasyAR. Los datos de fotograma de todas las cámaras disponibles en un momento dado deben ingresarse simultáneamente en el mismo punto en el tiempo.

El soporte para múltiples cámaras aún no está completamente implementado. Puede contactar a EasyAR para obtener más detalles.

Próximos pasos

Temas relacionados