Table of Contents

Требования к данным входного кадра для внешних источников данных кадров

Для корректной работы внешнего источника данных кадров наиболее важной и сложной задачей является обеспечение правильности данных. В этом документе описаны требования к данным входного кадра для внешних источников данных кадров.

Перед началом работы

Типы данных входного кадра

В Unity внешнему источнику данных кадров обычно требуется получать разные данные в два различных момента времени. В зависимости от времени ввода внешних данных и их характеристик, мы называем эти два набора данных:

  1. Данные кадра камеры (camera frame data)
  2. Данные кадра рендеринга (rendering frame data)

Разные типы внешних источников данных кадров имеют различные требования к этим двум наборам данных:

  • Расширение ввода изображений и данных движения устройства: требует как данных кадра камеры, так и данных кадра рендеринга
  • Расширение ввода изображений: требует только данных кадра камеры

Данные кадра камеры

Требования к данным:

  1. Временная метка (timestamp)
  2. Необработанные данные изображения физической камеры (raw camera image data)
  3. Внутренние параметры (intrinsics, включая размер изображения, фокусное расстояние, главную точку. При наличии искажений также требуются модель искажений и параметры искажений)
  4. Внешние параметры (extrinsics, Tcw или Twc, калибровочная матрица, выражающая физическое смещение физической камеры относительно точки отсчета позы устройства/головы)
  5. Состояние отслеживания (tracking status)
  6. Поза устройства (device pose)

Время данных:

  • Средняя точка экспозиции физической камеры

Использование данных:

  • Время вызова API: может изменяться в зависимости от дизайна внешнего кода. Распространенный подход для большинства устройств — запрос в обновлении рендеринга 3D-движка с последующей обработкой данных на основе временной метки данных устройства.
  • Поток вызова API: игровой поток 3D-движка или любой другой поток (если все используемые внешние API потокобезопасны).

Примеры вызовов API в 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);
    }
}

Рендеринг данных кадра

Требуемые данные:

  1. Метка времени (timestamp)
  2. Статус отслеживания (tracking status)
  3. Поза устройства (device pose)

Время данных:

  • Момент вывода на экран. TimeWarp не учитывается. Данные позы устройства в тот же момент времени будут использоваться внешней стороной (например, SDK устройства) для установки transform виртуальной камеры при рендеринге текущего кадра.
Примечание

TimeWarp (иногда называемый Reprojection или ATW/PTW) — это распространенная технология в VR/AR-гарнитурах для снижения задержки. Она искажает изображение после завершения рендеринга на основе последней позы головы, компенсируя движение головы во время рендеринга. EasyAR требует момент времени, соответствующий позе, используемой для установки виртуальной камеры в начале рендеринга, а не фактический момент вывода на экран после TimeWarp.

Использование данных:

  • Время вызова API: каждый кадр рендеринга 3D-движка
  • Поток вызова API: игровой поток 3D-движка

Пример вызова API в Unity:

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

Детали требований к данным

Данные изображения физической камеры:

  • Система координат изображения: данные, полученные при горизонтальном положении сенсора, также должны быть горизонтальными. Данные должны храниться с началом координат в левом верхнем углу, построчно. Изображение не должно быть перевернутым или инвертированным.
  • Частота кадров изображения (FPS): подходят обычные 30 или 60 fps. Если высокая частота кадров имеет особое влияние, для достижения разумного алгоритмического эффекта минимально допустимая частота кадров составляет 2. Рекомендуется использовать частоту кадров выше 2, обычно можно использовать исходную частоту кадров данных.
  • Размер изображения: для лучших результатов вычислений самая длинная сторона должна быть 960 или больше. Не рекомендуется выполнять ресурсоемкое масштабирование изображения в потоке данных — лучше использовать исходные данные, если только копирование данных полного размера не занимает неприемлемо много времени. Разрешение изображения не может быть меньше 640*480.
  • Формат пикселей: приоритет — качество отслеживания с учетом производительности. Обычный порядок предпочтения форматов: YUV > RGB > RGBA > Gray (компонент Y в YUV). При использовании данных YUV требуется полное определение данных, включая детали упаковки и заполнения данных. По сравнению с одноканальным изображением, Mega дает лучшие результаты с цветными изображениями, но другие функции менее подвержены влиянию.
  • Доступ к данным: указатель данных или эквивалентная реализация. Желательно исключить все возможные ненужные копии в потоке данных. В HandleRenderFrameData EasyAR копирует данные один раз, затем использует их асинхронно; после завершения этого синхронного вызова данные изображения больше не используются. Важно учитывать владение данными.

Метки времени:

  • Все метки времени должны быть синхронизированы по часам, предпочтительно аппаратно-синхронизированы. Единица данных — секунды, но точность должна достигать наносекунд или быть максимально возможной.

Состояние отслеживания:

  • Состояние отслеживания определяется устройством и должно включать состояние потери отслеживания (VIO недоступно). Чем больше градаций, тем лучше.

Устройство позы:

  • Все позы (включая transform виртуальной камеры в 3D-движке) должны использовать одну и ту же точку отсчета.
  • Все позы и внешние параметры должны использовать одну и ту же систему координат.
  • В Unity тип системы координат для данных позы должен быть системой координат Unity или системой координат EasyAR. Если входное расширение реализовано EasyAR и использует другие определения систем координат, должно быть предоставлено четкое определение системы координат или способ преобразования в систему координат Unity или EasyAR.
  • В Unity, при использовании фреймворка Unity XR, требуется совместимость только с режимом XROrigin.TrackingOriginMode.Device.

Внутренние параметры:

  • Все значения должны соответствовать данным изображения. При необходимости внутренние параметры должны быть масштабированы перед вводом в EasyAR.
  • Если входное расширение реализовано EasyAR, должно быть указано, изменяются ли внутренние параметры в каждом кадре (разница в том, должен ли соответствующий API вызываться один раз или каждый кадр).

Внешние параметры:

  • На шлемах должны предоставляться реальные данные.
  • Это калибровочная матрица, выражающая физическое смещение физической камеры относительно точки отсчета позы устройства/головы. Если поза устройства и поза физической камеры совпадают, это должна быть единичная матрица.
  • Интерфейс для Apple Vision Pro: CameraFrame.Sample.Parameters.extrinsics. Обратите внимание, что определение его данных отличается от данных, требуемых интерфейсом. EasyAR внутренне преобразует их перед использованием.
  • В Unity тип системы координат для внешних параметров должен быть системой координат Unity или системой координат EasyAR. Если входное расширение реализовано EasyAR и использует другие определения систем координат, должно быть предоставлено четкое определение системы координат или способ преобразования в систему координат Unity или EasyAR.
  • В устройствах-шлемах обычно существует несколько систем координат с разными определениями. Эти различия могут включать точку отсчета, ориентацию, выражение правой/левой руки и т.д. Внешние параметры должны вычисляться в одной и той же системе координат. Данные этого интерфейса требуют преобразования координат в одной системе, а не матрицы преобразования между двумя системами координат с разными определениями.

Производительность:

  • Данные должны предоставляться с оптимальной эффективностью. В большинстве реализаций вызовы API происходят в процессе рендеринга, поэтому рекомендуется, даже если на низком уровне требуются трудоемкие операции, не блокировать вызовы API или использовать эти API разумным образом.
  • Если входное расширение реализовано EasyAR, должны быть описаны все вызовы API, требующие значительного времени.

Мультикамера:

  • Требуются данные как минимум с одной камеры. Эта камера может быть любой: RGB-камерой, VST-камерой, камерой для позиционирования и т.д. На шлеме, если вводится только одна камера, обычно рекомендуется использовать RGB-камеру или VST-камеру, расположенную по центру или рядом с глазами.
  • Использование нескольких камер может улучшить результаты алгоритмов EasyAR. Данные кадров всех доступных камер в определенный момент времени должны вводиться одновременно, в одну и ту же точку времени.

Мультикамера в настоящее время полностью не поддерживается. Для получения дополнительных деталей можно обратиться в EasyAR.

Дальнейшие шаги

Связанные темы