[Перевод] Рекомендации по проектированию пользовательского интерфейса RealSense-приложений
Технология Intel® RealSense™ поддерживает две разновидности камер глубины: камера переднего обзора, малой дальности (F200) предназначена для установки на ноутбуки, ультрабуки, трансформеры и моноблоки; камера заднего обзора, большой дальности (R200) предназначена для установки на планшеты и в виде отдельного съемного устройства. Обе камеры как выпускаются в виде автономных периферийных устройств, так и встраиваются в компьютерные устройства, доступные на рынке в настоящее время. При использовании технологии Intel RealSense для разработки приложений для таких устройств следует помнить, что принцип взаимодействия с трехмерными приложениями без тактильной обратной связи существенно отличается от модели работы, к которой привыкли разработчики, создающие приложения для сенсорного управления.
В этой статье мы описываем некоторые распространенные принципы и проблемы пользовательских интерфейсов для камер F200 и R200 и показываем, как можно встраивать в приложения визуальную обратную связь с помощью API Intel® RealSense™ SDK.
Результат 1. Понимание объемного пространства съемки и зон взаимодействия для ноутбуков и моноблоков
Сценарий использования пользовательского интерфейса
Рассмотрим сценарии использования, показанные на рис. 1.
Рисунок 1. Объемное пространство съемки
Пирамида, исходящая из камеры на этом рисунке, представляет собой то, что называется объемным пространством съемки или полем зрения камеры. Для камеры F200 объемное пространство съемки определяется отклонениями от горизонтальной и вертикальной осей камеры, а также эффективным расстоянием между пользователем и камерой. Если пользователь сдвинется за пределы этой пирамиды, камера не сможет отслеживать режим взаимодействия. Ниже для справки приведена таблица с параметрами поля зрения.
| Параметр | Диапазон |
|---|---|
| Эффективная дальность распознавания жестов | 0,2–0,6 м |
| Эффективная дальность распознавания лица | 0,35–1,2 м |
| Поле зрения камеры цветного изображения, градусы | 77×43 x 70 (конус) |
| Поле зрения инфракрасной (ИК) камеры, градусы | 90×59 x 73 (конус) Поле зрения ИК-прожектора = н/д x 56×72 (пирамида) |
| Разрешение цветного изображения | До 1080p при кадровой скорости 30 кадров в секунду (кадр/с) |
| Разрешение карты глубины | До 640×480 при 60 кадр/с |
Камера съемки цветного изображения и камера глубины в составе устройства F200 обладают разной разрешающей способностью, поэтому разработчикам следует учитывать объемное пространство съемки для предполагаемых режимов работы с приложением. Как показано в приведенной выше таблице, эффективная дальность распознавания жестов невелика, тогда как отслеживание лица работает на большем расстоянии.
Почему это важно с точки зрения пользовательского интерфейса? Конечные пользователи понятия не имеют о том, как именно их «видит» камера. Поскольку они знают о зонах взаимодействия, это может привести к раздражению при работе с приложением, поскольку невозможно определить, в чем именно возникла проблема. На изображении слева на рис. 1 рука пользователя находится в поле зрения камера, а на изображении справа — вне поля зрения; в этом случае отслеживание может быть потеряно. Проблема дополнительно осложняется, если в приложении используется управление с помощью обеих рук или сразу несколько режимов управления, например одновременно с помощью лица и рук. Также учитывайте изменение поля зрения камеры при развертывании приложения на устройствах разных типоразмеров, например на ноутбуках и моноблоках: в последнем случае зона взаимодействия будет расположена выше, чем на ноутбуках. На рис. 2 показаны различные сценарии, в которых пользователи находятся перед разными устройствами.
Рисунок 2. Поле зрения камеры и типоразмер устройства
Информация об этих параметрах поможет встроить в приложение эффективный механизм обратной связи, чтобы предоставлять пользователям четкие указания о правильном способе использования устройства и камеры. Теперь посмотрим, как получить некоторые из этих параметров поля зрения в приложении через SDK.
Техническая реализация
Пакет Intel RealSense SDK предоставляет API, позволяющие получать данные поля зрения и дальности камеры. API QueryColorFieldOfView и QueryDepthFieldOfView работают в интерфейсе device вне зависимости от типа устройства. Вот как реализуется код.
Хотя возвращаемая структура данных имеет формат PXCPointF32, возвращаемые значения указывают углы X (обзора по горизонтали) и Y (обзора по вертикали) в градусах. Это — заданные производителем значения для данной модели камеры, а не настроенные программно на устройстве.
Следующим параметром объемного пространства съемки является дальность. API QueryDepthSensorRange возвращает значение дальности в миллиметрах. Это значение также задано производителем по умолчанию для данной модели, а не настроено программно на конкретном устройстве.
Знание этих API и способов их реализации в коде поможет создать эффективную систему обратной связи для пользователей. На рис. 3 и 4 показаны примеры визуальной обратной связи для объемного пространства съемки.
Рисунок 3. Подсказки о расстоянии до камеры
Рисунок 4. Схематическое изображение окружающего мира
Простые подсказки обозначают ближнюю и дальнюю границы зоны взаимодействия. Без подсказок пользователь просто не будет понимать, что нужно делать, если система перестанет реагировать на его действия. Применяйте фильтрацию данных расстояния и показывайте подсказку после короткой задержки. Кроме того, используйте указания и подсказки вместо оповещений об ошибках. Схематическое изображение окружающего мира поможет пользователям сориентироваться и ознакомиться с понятиями зоны взаимодействия камеры глубины.
Рекомендуется использовать такие схематические изображения на экранах справки и в учебных заставках, а также в играх, пользователи которых могут впервые работать с камерой. Для наибольшей эффективности следует показывать схематическое изображение окружающего мира только при обучении пользователей и на экранах справки. Инструкции должны быть простыми и удобопонятными, при их составлении необходимо ориентироваться на предполагаемую аудиторию приложения.
Вместо перечисленных выше API можно использовать оповещения, предоставляемые в каждом SDK для записи определенных действий пользователей. Рассмотрим, к примеру, следующее решение для распознавания лиц. В следующей таблице перечислены оповещения модуля PXC[M]FaceData.
Как вы уже знаете, SDK поддерживает обнаружение до 4 лиц в поле зрения. С помощью идентификатора лица можно получать оповещения, относящиеся к каждому лицу, в зависимости от потребностей приложения. Также отслеживание может быть полностью потеряно (например, если лицо переместилось в поле зрения камеры, а затем вышло из поля зрения со слишком высокой для отслеживания скоростью). В таком сценарии можно использовать данные объемного пространства съемки вместе с оповещениями, чтобы создать надежный механизм обратной связи для пользователей.
| Тип оповещения | Описание |
|---|---|
| ALERT_NEW_FACE_DETECTED | Обнаружено новое лицо. |
| ALERT_FACE_NOT_DETECTED | В сцене отсутствует лицо. |
| ALERT_FACE_OUT_OF_FOV | Лицо вне поля зрения камеры. |
| ALERT_FACE_BACK_TO_FOV | Лицо вернулось в поле зрения камеры. |
| ALERT_FACE_LOST | Потеряно отслеживание лица. |
SDK также позволяет обнаруживать наложение, т. е. случаи, когда снимаемый объект загорожен посторонним предметом. Описание неподдерживаемых и частично поддерживаемых сценариев см. в документе Руководство по созданию пользовательских интерфейсов для камеры F200. Вне зависимости от того, какой тип наложения вы пытаетесь отслеживать, следующий набор оповещений окажется весьма полезным.
| Тип оповещения | Описание |
|---|---|
| ALERT_FACE_OCCLUDED | Лицо загорожено. |
| ALERT_FACE_NO_LONGER_OCCLUDED | Лицо больше не загорожено. |
| ALERT_FACE_ATTACHED_OBJECT | Лицо загорожено каким-либо объектом, например рукой. |
| ALERT_FACE_OBJECT_NO_LONGER_ATTACHED | Лицо больше не загорожено каким-либо объектом. |
Теперь перейдем к оповещениям в модуле отслеживания рук. Они доступны в модуле PXC[M]HandData в составе SDK. Как видите, некоторые из этих оповещений также неявно задействуют определение дальности (помните о разной дальности действия у модулей распознавания лиц и модулей распознавания рук).
| Имя оповещения | Описание |
|---|---|
| ALERT_HAND_OUT_OF_BORDERS | Отслеживаемая рука находится вне двухмерной ограничительной рамки или трехмерного ограничительного куба, заданного пользователем. |
| ALERT_HAND_INSIDE_BORDERS | Отслеживаемая рука вернулась внутрь двухмерной ограничительной рамки или трехмерного ограничительного куба, заданного пользователем. |
| ALERT_HAND_TOO_FAR | Отслеживаемая рука находится слишком далеко от камеры. |
| ALERT_HAND_TOO_CLOSE | Отслеживаемая рука находится слишком близко к камере. |
| ALERT_HAND_DETECTED | Отслеживаемая рука распознана, доступна ее отметка. |
| ALERT_HAND_NOTE_DETECTED | Ранее обнаруженная рука потеряна, поскольку она либо вышла из поля зрения, либо загорожена. |
| И многие другие… | См. документацию. |
Теперь вы знаете, какие возможности предоставляет SDK, и можете без особых усилий применить их в коде приложения. Пример показан в следующем фрагменте кода.
Замените инструкции wprintf_s на логику реализации визуальной обратной связи. Можно включать не все оповещения, а только некоторые из них, как показано ниже.
На рис. 5 и 6 показаны примеры эффективной визуальной обратной связи с помощью оповещений.
Рисунок 5. Изображение пользователя в поле зрения камеры
Рисунок 6. Наложение изображения пользователя
Ссылки на API в документации SDK
Результат 2. Снижение утомляемости пользователей
Сценарий использования пользовательского интерфейса: выбор подходящего метода ввода для требуемой точности.
При создании приложений с помощью Intel RealSense SDK важно помнить об особенностях режимов ввода. Выбор подходящих режимов ввода для различных сценариев играет важнейшую роль в работе приложения. Ввод с помощью клавиатуры, мыши и сенсорного экрана отличается высокой точностью, тогда как ввод с помощью жестов — низкой точностью. К примеру, для работы с приложениями, где требуется много работать с данными, предпочтительно использовать ввод с помощью клавиатуры и мыши, а не жестов. Попробуйте представить, каково будет пытаться выбрать определенную ячейку в Excel пальцем вместо мыши (см. рис. 7). Такие действия не вызовут ничего, кроме крайнего раздражения и усталости пользователя. При попытке выполнения точных действий пользователи естественным образом напрягают мышцы, что, в свою очередь, приводит к повышению утомляемости.
Рисунок 7. Выбор правильного способа ввода
Для выбора элементов в меню можно использовать сенсорное управление или мышь. Режимы ввода, поддерживаемые пакетом Intel RealSense SDK, реализуют непосредственный, естественный механизм взаимодействия без касаний и позволяют создавать увлекательные приложения. Используйте эти режимы таким образом, чтобы не требовалось множества повторяющихся жестов. Для использования жестов лучше всего подходят постоянные действия, в которых ошибки не приведут к нежелательному риску.
Выбор направления движения жестов
Рекомендуется использовать жесты, направленные по горизонтали или по дуге. Если доступен выбор, то для удобства пользователей старайтесь использовать движения по горизонтали вместо движений по вертикали. Помимо этого, не используйте действия, вынуждающие пользователей поднимать руки выше уровня плеч. Помните про эффект «рук гориллы»?
Рисунок 8. Выбор направления движения жестов
Выбор относительного или абсолютного движения
Допускайте относительное движение вместо абсолютного во всех целесообразных случаях. При относительном движении пользователь может «сбрасывать» расположение виртуальной руки на экране, чтобы добиться более удобного положения своей собственной руки перед камерой. Это приблизительно то же самое, что поднять мышь и переставить ее с края коврика на середину, если нужно передвинуть указатель дальше. При абсолютном движении взаимосвязь между положением указателя на экране и положением руки на экране всегда сохраняется. В приложениях следует использовать такую модель движения, которая наиболее целесообразна для каждого конкретного контекста.
Понимание скорости движения
Составной частью проблемы точности является фактор скорости. Если пользователи слишком быстро двигают руками перед камерой, то возникает риск полной потери отслеживания, поскольку при этом руки могут оказаться вне объемного пространства съемки. При использовании в приложениях жестов с быстрыми движениями повышается утомляемость пользователей и увеличивается риск ошибок. Поэтому очень важно учитывать фактор скорости и ее влияние как на эффективную дальностью (вблизи от камеры, на расстоянии от 20 до 55 см, можно обнаруживать быстрое движение со скоростью до 2 м/с), так и на пространство съемки (при небольшом расстоянии от камеры в поле зрения может находиться только одна рука).
Понимание действий пользователя и взаимодействия с объектами
Естественные движения человека не всегда являются плавными: человеческое тело часто двигается неравномерно и рывками, что интерпретируется камерой как несколько разных взаимодействий. При создании приложений для Intel RealSense SDK следует помнить о взаимосвязи между действиями и объектами. Например, если существуют объекты, которые можно «взять» рукой с помощью жестов, следует учитывать размер таких объектов и их расположение, нужно принимать во внимание расстояние до краев экрана и места, куда можно «перетащить» такие объекты, а также способы обнаружения сбоев отслеживания.
Вот несколько рекомендаций, помогающих преодолеть такие проблемы.
- Объекты должны быть достаточно крупными, чтобы на них не влияла дрожь или неравномерное движение руки. Расстояние между объектами должно быть достаточно большим, чтобы пользователи не могли случайно взять не тот объект, который нужно.
- Не располагайте элементы взаимодействия слишком близко к краям экрана, поскольку в этом случае возрастает риск выхода руки пользователя за пределы поля зрения и потери отслеживания, что вызовет у пользователя неминуемое и праведное раздражение.
- Если в интерфейсе важно перетаскивание объектов, то должно быть очевидно, куда именно можно перетащить взятый объект и куда его можно отпустить.
- Если при перемещении пользователем объекта происходит сбой отслеживания, перемещаемый объект должен возвращаться на исходное место, а пользователь должен получить уведомление о сбое отслеживания.
Техническая реализация: скорость и точность
Если для приложения не требуются данные о суставах кисти, а чаще используются быстрые движения руки, имеет смысл использовать модуль Blob. В следующей таблице перечислены различные возможные сценарии и предполагаемая точность в каждом из них. При отслеживании всей руки с данными о суставах движение должно быть более медленным, но это ограничение можно обойти, использовав либо отслеживание оконечностей, либо режим Blob. Кроме того, благодаря режиму Blob вы получите целый ряд преимуществ, если приложение предназначается для детей.
| Режим отслеживания | Только руки? | Выходные данные | Нагрузка на вычислительные ресурсы | Ограничения |
|---|---|---|---|---|
| Full Hand | Да | Сегментированное изображение, точки конечностей, боковая сторона руки, оповещения, данные о суставах, данные о пальцах, данные об открытой или сжатой ладони, жесты | Наивысшая, несколько потоков | 2 руки, дальность 60 см, малая скорость движения рук |
| Extremities | Да | Сегментированное изображение, точки конечностей, боковая сторона руки, оповещения | Средняя, один поток | 2 руки, дальность 60 см, средняя скорость движения рук |
| Blob | Нет | Сегментированное изображение, точки конечностей, контурная линия | Низкая, один поток | 4 объекта, дальность 100 см, высокая скорость |
Если же в приложении требуется более полный контроль и нужно управлять скоростью движения, то можно получить данные скорости на уровне суставов руки с помощью PXCMHandConfiguration.EnableJointSpeed. Это позволяет получить либо абсолютное значение скорости, вычисляемое на основе текущего и предыдущего положений руки, либо среднюю скорость за определенный период времени. Тем не менее при таком подходе значительно возрастает нагрузка на ЦП и оперативную память, поэтому применять этот способ следует, лишь когда это совершенно необходимо.
Поскольку нельзя заставить пользователей двигаться плавно, без рывков, в состав SDK также включена программа Smoother (PXC[M]Smoother), сглаживающая рывки при движении рук перед камерой. Эта программа использует различные линейные и квадратные алгоритмы. Можно поэкспериментировать с ними и выбрать наиболее подходящий. На рис. 9 ниже видно, что неравномерное движение руки в значительной степени сглаживается этой программой.
Рисунок 9. Данные со сглаживанием и без сглаживания
Еще один способ обнаружить слишком быстрое движение руки — перечисление TRACKINGSTATUS_HIGH_SPEED в свойстве PXCMHandData.TrackingStatusType. При обнаружении лица быстрые движения могут привести к потере отслеживания. Используйте PXCMFaceData.AlertData.AlertType — ALERT_FACE_LOST, чтобы определять утраченное отслеживание. Если же вы используете жесты рук для управления операционной системой с помощью Touchless Controller, используйте функции SetPointerSensitivity и SetScrollSensitivity в PXC[M]TouchlessController для настройки чувствительности указателя и прокрутки.
Ограничительные рамки
Эффективный механизм, позволяющий добиться плавности действий и взаимодействия с объектами, — применение ограничительных рамок. Они предоставляют пользователям четкие визуальные указания об исходном месте и месте назначения объекта, с которым взаимодействует пользователь.
Модули отслеживания лица и рук в SDK поддерживают API PXCMHandData.IHand.QueryBoundingBoxImage, который возвращает расположение и размеры отслеживаемой руки (двухмерную ограничительную рамку), на карте глубины. API PXCMFaceData.DetectionData.QueryBoundingRect возвращает ограничительную рамку обнаруженного лица. Также можно использовать PXCMHandData.AlertType — ALERT_HAND_OUT_OF_BORDERS, чтобы обнаруживать выход руки за пределы ограничительной рамки.
Ссылки на API в документации SDK
Камера R200 встраивается в планшеты и выпускается в виде съемного устройства. Она предназначена для съемки пространства вокруг пользователя. Среди возможных сценариев использования камеры R200 следует отметить такие решения, как дополненная реальность и съемка всего тела человека. В поле зрения этой камеры попадает окружающий мир, поэтому сущность и набор проблем проектирования пользовательских интерфейсов отличаются от описанных выше для камеры F200. В этом разделе описываются некоторые известные проблемы пользовательских интерфейсов, связанные с модулем Scene Perception (который будет использоваться разработчиками в приложениях дополненной реальности) и с модулем 3D Scanning.
Результат 1. Понимание объемного пространства съемки и зон взаимодействия для планшетов
Сценарий использования пользовательского интерфейса
Как видно на рис. 10, углы обзора камеры R200 по вертикали и по горизонтали, а также дальность ее действия значительно отличаются от аналогичных характеристик камеры F200. Камеру R200 можно использовать в двух разных режимах: в активном режиме (когда пользователь передвигается, снимая сцену) и в пассивном режиме (когда пользователь работает с неподвижным изображением). При съемке объекта или сцены убедитесь, что объект находится в поле зрения камеры, пока пользователь снимает его в активном режиме. Также учтите, что дальность действия этой камеры (в зависимости от того, где она используется: в помещении или на улице) отличается от дальности камеры F200. Как получить эти точки данных во время выполнения, чтобы предоставить пользователю визуальную обратную связь?
Рисунок 10. Объемное пространство съемки камеры R200
Техническая реализация
Мы уже обсудили API QueryColorFieldOfView () и QueryDepthFieldOfView () выше в разделе, посвященном камере F200. Эти функции не зависят от устройства, с их помощью можно производить объемную съемку и камерой R200. Тем не менее для обнаружения дальности действия камеры R200 нужно использовать специализированный API, предназначенный только для этого устройства. Чтобы получить такие данные для камеры R200, необходимо использовать API QueryDSMinMaxZ, доступный в составе интерфейса PXCCapture. Он возвращает минимальную и максимальную дальность камеры в миллиметрах.
Ссылки на API в документации SDK
Результат 2. Понимание действий пользователя и взаимодействия со сценой
Сценарий использования пользовательского интерфейса: планирование с учетом особенностей сцены и возможностей камеры
При работе с камерой в активном режиме следует помнить об ограничениях камеры. Данные глубины будут менее точными при съемке сцены с очень яркими областями, с отражающими и с черными поверхностями. Информация о том, в каких случаях возможен сбой отслеживания, поможет встроить в приложение эффективный механизм обратной связи, чтобы мягко напоминать пользователю о необходимых действиях, а не завершать работу с ошибкой.
Техническая реализация
Модули Scene Perception и 3D Scanning обладают разными требованиями, а поэтому в них используются разные механизмы для обнаружения минимальных требований.
Scene Perception. Всегда используйте API CheckSceneQuality в модуле PXCScenePerception, чтобы определить, пригодна ли сцена для отслеживания. API возвращает значение между 0 и 1. Чем выше возвращенное значение, тем лучше сцена для отслеживания. Вот как реализуется код.
После того как качество сцены будет сочтено удовлетворительным и начнется отслеживание, следует динамически проверять состояние отслеживания с помощью API TrackingAccuracy в модуле PXCScenePerception. Этот API выдает точность отслеживания.
| Имя | Описание |
|---|---|
| HIGH | Высокая точность отслеживания |
| LOW | Низкая точность отслеживания |
| MED | Средняя точность отслеживания |
| FAILED | Сбой отслеживания |
Чтобы добиться максимального качества данных сцены, можно также настроить разрешение вокселей (воксель — это единица разрешения объемного изображения). В зависимости от того, что именно отслеживает камера (пространство размером с комнату, поверхность стола или расположенный близко объект), настраивайте разрешение вокселей согласно приведенной ниже таблице для получения наилучших результатов.
| Имя | Описание |
|---|---|
| LOW_RESOLUTION | Низкое разрешение вокселей. Используйте это разрешение для отслеживания пространства размером с комнату (4/256 м). |
| MED_RESOLUTION | Среднее разрешение вокселей. Используйте это разрешение для отслеживания поверхности стола (2/256 м). |
| HIGH_RESOLUTION | Высокое разрешение вокселей. Используйте это разрешение для отслеживания небольших объектов (1/256 м). |
3D Scanning Алгоритм 3D Scanning предоставляет оповещения, показанные в приведенной ниже таблице. Для получения этих данных используйте PXC3DScan: AlertEvent.
| Имя | Описание |
|---|---|
| ALERT_IN_RANGE | Снимаемый объект находится на подходящем расстоянии. |
| ALERT_TOO_CLOSE | Снимаемый объект находится слишком близко к камере. Предложите пользователю отодвинуть объект от камеры. |
| ALERT_TOO_FAR | Снимаемый объект находится слишком далеко от камеры. Предложите пользователю придвинуть объект к камере. |
| ALERT_TRACKING | Снимаемый объект правильно отслеживается. |
| ALERT_LOST_TRACKING | Отслеживание снимаемого объекта потеряно. |
Если в приложении доступны данные об отслеживании камеры и об ограничениях используемого модуля, эти данные можно использовать для предоставления визуальной обратной связи, четко указывая пользователям, каким образом их действия были интерпретированы камерой. В случае потери отслеживания можно показать, как правильнее работать с камерой. Примеры визуальной обратной связи показаны здесь исключительно для примера, их необходимо адаптировать в соответствии с требованиями приложения и с устройством пользовательского интерфейса.
Образец учебной программы при запуске.
Рисунок 11. Обучение
Предварительный просмотр снятой области или предмета.
Рисунок 12. Предварительный просмотр
Подсказки для пользователя.
Рисунок 13. Подсказки для пользователя
Снижение утомляемости в случае, когда пользователь держит устройство в руках
Большинство приложений будет использовать устройство и при активном, и при неактивном режимах работы камеры. (Эти два режима отличаются следующим образом: камера работает в активном режиме, когда пользователь держит в руках планшет для просмотра сцены через камеру или для съемки; камера работает в неактивном режиме, когда пользователь положил планшет и работает с содержимым на экране, в то время как камера выключена). Для снижения утомляемости пользователей необходимо понимать, каким образом пользователь держит и использует устройство в каждом из указанных режимов, и соответственным образом выбирать зоны взаимодействия. При использовании камеры в активном режиме пользователь устает быстрее, поскольку держит устройство на весу, как показано на рис. 14.
Рисунок 14. Использование устройства в активном и в неактивном режимах
Выбор подходящего режима для действия
Режим использования также напрямую определяет природу взаимодействия с приложением через пользовательский интерфейс. В активном режиме пользователь держит устройство обеими руками. Поэтому любые визуальные элементы приложения, например кнопки, должны находиться в легкодоступных местах на экране. Исследования показывают, что в таких случаях лучше всего использовать края экрана. Рекомендуемые зоны касаний показаны на рис. 15. Кроме того, в активом режиме снижается точность касаний, поэтому активный режим лучше всего подходит для краткосрочной съемки.
Напротив, в неактивном режиме пользователю удобнее работать с устройством, пользователь точнее взаимодействует с элементами интерфейса и может пользоваться приложением в течение продолжительного времени.
Рисунок 15. Зоны касаний в активном и в неактивном режимах
Ссылки на API в документации SDK
При разработке приложений с использованием технологии Intel® RealSense™ разработчики должны с самых ранних этапов принимать во внимание потребности и особенности работы конечных пользователей. Рекомендации, приведенные в этой статье, послужат основой для решения некоторых важных проблем пользовательских интерфейсов и для реализации необходимых компонентов в коде с помощью SDK.
