Заархивировано - Создание приложений для технологии Intel® RealSense™. Рекомендации по проектированию пользовательского интерфейса с примерами для Windows*

Выпуск комплекта Intel® RealSense™ SDK прекращен. Его поддержка и обновления более недоступны.

Введение

Технология Intel® RealSense™ поддерживает две разновидности камер глубины: камера переднего обзора, малой дальности (F200) предназначена для установки на ноутбуки, ультрабуки, трансформеры и моноблоки; камера заднего обзора, большой дальности (R200) предназначена для установки на планшеты и в виде отдельного съемного устройства. Обе камеры как выпускаются в виде автономных периферийных устройств, так и встраиваются в компьютерные устройства, доступные на рынке в настоящее время. При использовании технологии Intel RealSense для разработки приложений для таких устройств следует помнить, что принцип взаимодействия с трехмерными приложениями без тактильной обратной связи существенно отличается от модели работы, к которой привыкли разработчики, создающие приложения для сенсорного управления.

В этой статье мы описываем некоторые распространенные принципы и проблемы пользовательских интерфейсов для камер F200 и R200 и показываем, как можно встраивать в приложения визуальную обратную связь с помощью API Intel® RealSense™ SDK.

Рекомендации по созданию пользовательских интерфейсов и использованию API для камеры F200

Результат 1. Понимание объемного пространства съемки и зон взаимодействия для ноутбуков и моноблоков.

Сценарий использования пользовательского интерфейса

Рассмотрим сценарии использования, показанные на рис. 1.

 Capture volumes.

Рисунок 1. Объемное пространство съемки

Пирамида, исходящая из камеры на этом рисунке, представляет собой то, что называется объемным пространством съемки или полем зрения камеры. Для камеры F200 объемное пространство съемки определяется отклонениями от горизонтальной и вертикальной осей камеры, а также эффективным расстоянием между пользователем и камерой. Если пользователь сдвинется за пределы этой пирамиды, камера не сможет отслеживать режим взаимодействия. Ниже для справки приведена таблица с параметрами поля зрения.

ПараметрДиапазон
Эффективная дальность распознавания жестов0.2–0.6 m
Эффективная дальность распознавания лица0.35–1.2 m
Поле зрения камеры цветного изображения (глубина х по вертикали х по горизонтали), градусы77 x 43 x 70 (конус)
Поле зрения инфракрасной (ИК) камеры, градусы

90x59x73 (конус)

Поле зрения ИК-прожектора = н/д x 56 x 72 (пирамида)
Разрешение цветного изображенияДо 1080p при кадровой скорости 30 кадров в секунду (кадр/с)
Разрешение карты глубиныДо 640 х 480 при 60 кадр/с

Камера съемки цветного изображения и камера глубины в составе устройства F200 обладают разной разрешающей способностью, поэтому разработчикам следует учитывать объемное пространство съемки для предполагаемых режимов работы с приложением. Как показано в приведенной выше таблице, эффективная дальность распознавания жестов невелика, тогда как отслеживание лица работает на большем расстоянии.

Почему это важно с точки зрения пользовательского интерфейса? Конечные пользователи понятия не имеют о том, как именно их «видит» камера. Поскольку они знают о зонах взаимодействия, это может привести к раздражению при работе с приложением, поскольку невозможно определить, в чем именно возникла проблема. На изображении слева на рис. 1 рука пользователя находится в поле зрения камера, а на изображении справа — вне поля зрения; в этом случае отслеживание может быть потеряно. Проблема дополнительно осложняется, если в приложении используется управление с помощью обеих рук или сразу несколько режимов управления, например одновременно с помощью лица и рук. Также учитывайте изменение поля зрения камеры при развертывании приложения на устройствах разных типоразмеров, например на ноутбуках и моноблоках: в последнем случае зона взаимодействия будет расположена выше, чем на ноутбуках. На рис. 2 показаны различные сценарии, в которых пользователи находятся перед разными устройствами.

Figure 2. FOV and form factor considerations.
Рисунок 2. Поле зрения камеры и типоразмер устройства

Информация об этих параметрах поможет встроить в приложение эффективный механизм обратной связи, чтобы предоставлять пользователям четкие указания о правильном способе использования устройства и камеры. Теперь посмотрим, как получить некоторые из этих параметров поля зрения в приложении через SDK.

Техническая реализация

Пакет Intel RealSense SDK предоставляет API, позволяющие получать данные поля зрения и дальности камеры. API QueryColorFieldOfView и QueryDepthFieldOfView работают в интерфейсе device вне зависимости от типа устройства. Вот как реализуется код.

Хотя возвращаемая структура данных имеет формат PXCPointF32, возвращаемые значения указывают углы X (обзора по горизонтали) и Y (обзора по вертикали) в градусах. Это — заданные производителем значения для данной модели камеры, а не настроенные программно на устройстве.

Следующим параметром объемного пространства съемки является дальность. API QueryDepthSensorRange возвращает значение дальности в миллиметрах. Это значение также задано производителем по умолчанию для данной модели, а не настроено программно на конкретном устройстве.

Знание этих API и способов их реализации в коде поможет создать эффективную систему обратной связи для пользователей. На рис. 3 и 4 показаны примеры визуальной обратной связи для объемного пространства съемки.
Figure 3. Distance prompts.
Рисунок 3. Подсказки о расстоянии до камеры.
Figure 4. World diagrams.
Рисунок 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Ранее обнаруженная рука потеряна, поскольку она либо вышла из поля зрения, либо загорожена.
And more...См. документацию.

Теперь вы знаете, какие возможности предоставляет SDK, и можете без особых усилий применить их в коде приложения. Пример показан в следующем фрагменте кода:



Замените инструкции wprintf_s на логику реализации визуальной обратной связи. Можно включать не все оповещения, а только некоторые из них, как показано ниже.


На рис. 5 и 6 показаны примеры эффективной визуальной обратной связи с помощью оповещений.

Figure 5. User viewport.
На рис. 5 и 6 показаны примеры эффективной визуальной обратной связи с помощью оповещений.

Figure 6. User overlay.
Рисунок 6. Наложение изображения пользователя

Ссылки на API в документации SDK

QueryColorFieldOfView: https://software.intel.com/sites/landingpage/realsense/camera-sdk/v1.1/documentation/html/index.html?querycolorfieldofview_device_pxccapture.html

QueryDepthFieldOfView: https://software.intel.com/sites/landingpage/realsense/camera-sdk/v1.1/documentation/html/index.html?querydepthfieldofview_device_pxccapture.html

QueryDepthSensorRange: https://software.intel.com/sites/landingpage/realsense/camera-sdk/v1.1/documentation/html/index.html?querydepthsensorrange_device_pxccapture.html

Оповещения о поле зрения модуля распознавания лиц:https://software.intel.com/sites/landingpage/realsense/camera-sdk/v1.1/documentation/html/index.html?alerttype_alertdata_pxcfacedata.html

Оповещения о поле зрения модуля распознавания рук:https://software.intel.com/sites/landingpage/realsense/camera-sdk/v1.1/documentation/html/index.html?manuals_handling_alerts.html

Результат 2. Снижение утомляемости пользователей.

Сценарий использования пользовательского интерфейса: выбор подходящего метода ввода для требуемой точности.

При создании приложений с помощью Intel RealSense SDK важно помнить об особенностях режимов ввода. Выбор подходящих режимов ввода для различных сценариев играет важнейшую роль в работе приложения. Ввод с помощью клавиатуры, мыши и сенсорного экрана отличается высокой точностью, тогда как ввод с помощью жестов — низкой точностью. К примеру, для работы с приложениями, где требуется много работать с данными, предпочтительно использовать ввод с помощью клавиатуры и мыши, а не жестов. Попробуйте представить, каково будет пытаться выбрать определенную ячейку в Excel пальцем вместо мыши (см. рис. 7). Такие действия не вызовут ничего, кроме крайнего раздражения и усталости пользователя. При попытке выполнения точных действий пользователи естественным образом напрягают мышцы, что, в свою очередь, приводит к повышению утомляемости.  

 Choice of correct input.
Рисунок 7. Выбор правильного способа ввода  

Для выбора элементов в меню можно использовать сенсорное управление или мышь. Режимы ввода, поддерживаемые пакетом Intel RealSense SDK, реализуют непосредственный, естественный механизм взаимодействия без касаний и позволяют создавать увлекательные приложения. Используйте эти режимы таким образом, чтобы не требовалось множества повторяющихся жестов. Для использования жестов лучше всего подходят постоянные действия, в которых ошибки не приведут к нежелательному риску.

Выбор направления движения жестов

Рекомендуется использовать жесты, направленные по горизонтали или по дуге. Если доступен выбор, то для удобства пользователей старайтесь использовать движения по горизонтали вместо движений по вертикали. Помимо этого, не используйте действия, вынуждающие пользователей поднимать руки выше уровня плеч. Помните про эффект «рук гориллы»?

 Choice of direction for gesture movement.
Рисунок 8. Выбор направления движения жестов

Выбор относительного или абсолютного движения

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

Понимание скорости движения

Составной частью проблемы точности является фактор скорости. Если пользователи слишком быстро двигают руками перед камерой, то возникает риск полной потери отслеживания, поскольку при этом руки могут оказаться вне объемного пространства съемки. При использовании в приложениях жестов с быстрыми движениями повышается утомляемость пользователей и увеличивается риск ошибок. Поэтому очень важно учитывать фактор скорости и ее влияние как на эффективную дальностью (вблизи от камеры, на расстоянии от 20 до 55 см, можно обнаруживать быстрое движение со скоростью до 2 м/с), так и на пространство съемки (при небольшом расстоянии от камеры в поле зрения может находиться только одна рука).

Понимание действий пользователя и взаимодействия с объектами

Естественные движения человека не всегда являются плавными: человеческое тело часто двигается неравномерно и рывками, что интерпретируется камерой как несколько разных взаимодействий. При создании приложений для Intel RealSense SDK следует помнить о взаимосвязи между действиями и объектами. Например, если существуют объекты, которые можно «взять» рукой с помощью жестов, следует учитывать размер таких объектов и их расположение, нужно принимать во внимание расстояние до краев экрана и места, куда можно «перетащить» такие объекты, а также способы обнаружения сбоев отслеживания.

Вот несколько рекомендаций, помогающих преодолеть такие проблемы.

  • Объекты должны быть достаточно крупными, чтобы на них не влияла дрожь или неравномерное движение руки. Расстояние между объектами должно быть достаточно большим, чтобы пользователи не могли случайно взять не тот объект, который нужно.
  • Не располагайте элементы взаимодействия слишком близко к краям экрана, поскольку в этом случае возрастает риск выхода руки пользователя за пределы поля зрения и потери отслеживания, что вызовет у пользователя неминуемое и праведное раздражение.
  • Если в интерфейсе важно перетаскивание объектов, то должно быть очевидно, куда именно можно перетащить взятый объект и куда его можно отпустить.
  • Если при перемещении пользователем объекта происходит сбой отслеживания, перемещаемый объект должен возвращаться на исходное место, а пользователь должен получить уведомление о сбое отслеживания.

Техническая реализация: скорость и точность

Если для приложения не требуются данные о суставах кисти, а чаще используются быстрые движения руки, имеет смысл использовать модуль Blob. В следующей таблице перечислены различные возможные сценарии и предполагаемая точность в каждом из них. При отслеживании всей руки с данными о суставах движение должно быть более медленным, но это ограничение можно обойти, использовав либо отслеживание оконечностей, либо режим Blob. Кроме того, благодаря режиму Blob вы получите целый ряд преимуществ, если приложение предназначается для детей.

Если же в приложении требуется более полный контроль и нужно управлять скоростью движения, то можно получить данные скорости на уровне суставов руки с помощью PXCMHandConfiguration.EnableJointSpeed. Это позволяет получить либо абсолютное значение скорости, вычисляемое на основе текущего и предыдущего положений руки, либо среднюю скорость за определенный период времени. Тем не менее при таком подходе значительно возрастает нагрузка на ЦП и оперативную память, поэтому применять этот способ следует, лишь когда это совершенно необходимо.

Поскольку нельзя заставить пользователей двигаться плавно, без рывков, в состав SDK также включена программа Smoother (PXC[M]Smoother), сглаживающая рывки при движении рук перед камерой. Эта программа использует различные линейные и квадратные алгоритмы. Можно поэкспериментировать с ними и выбрать наиболее подходящий. На рис. 9 ниже видно, что неравномерное движение руки в значительной степени сглаживается этой программой.

 Smoothed and unsmoothed data.

Рисунок 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

Алгоритм отслеживания Blob:https://software.intel.com/sites/landingpage/realsense/camera-sdk/v1.1/documentation/html/index.html?manuals_blob_tracking.html

EnableJointSpeed:https://software.intel.com/sites/landingpage/realsense/camera-sdk/v1.1/documentation/html/index.html?enablejointspeed_pxchandconfiguration.html

Программа Smoother:https://software.intel.com/sites/landingpage/realsense/camera-sdk/v1.1/documentation/html/index.html?manuals_the_smoother_utility.html

TouchlessController:https://software.intel.com/sites/landingpage/realsense/camera-sdk/v1.1/documentation/html/index.html?pxctouchlesscontroller.html

SetPointerSensitivity и SetScrollSensitivity:https://software.intel.com/sites/landingpage/realsense/camera-sdk/v1.1/documentation/html/index.html?member_functions_pxctouchlesscontroller.html

Рекомендации по созданию пользовательских интерфейсов и использованию API для камеры R200

Камера R200 встраивается в планшеты и выпускается в виде съемного устройства. Она предназначена для съемки пространства вокруг пользователя. Среди возможных сценариев использования камеры R200 следует отметить такие решения, как дополненная реальность и съемка всего тела человека. В поле зрения этой камеры попадает окружающий мир, поэтому сущность и набор проблем проектирования пользовательских интерфейсов отличаются от описанных выше для камеры F200. В этом разделе описываются некоторые известные проблемы пользовательских интерфейсов, связанные с модулем Scene Perception (который будет использоваться разработчиками в приложениях дополненной реальности) и с модулем 3D Scanning.

Результат 1. Понимание объемного пространства съемки и зон взаимодействия для планшетов

Сценарий использования пользовательского интерфейса

Как видно на рис. 10, углы обзора камеры R200 по вертикали и по горизонтали, а также дальность ее действия значительно отличаются от аналогичных характеристик камеры F200. Камеру R200 можно использовать в двух разных режимах: в активном режиме (когда пользователь передвигается, снимая сцену) и в пассивном режиме (когда пользователь работает с неподвижным изображением). При съемке объекта или сцены убедитесь, что объект находится в поле зрения камеры, пока пользователь снимает его в активном режиме. Также учтите, что дальность действия этой камеры (в зависимости от того, где она используется: в помещении или на улице) отличается от дальности камеры F200. Как получить эти точки данных во время выполнения, чтобы предоставить пользователю визуальную обратную связь?

 R200 capture volumes.

Рисунок 10. Объемное пространство съемки камеры R200

Техническая реализация

Мы уже обсудили API QueryColorFieldOfView() и QueryDepthFieldOfView() выше в разделе, посвященном камере F200. Эти функции не зависят от устройства, с их помощью можно производить объемную съемку и камерой R200. Тем не менее для обнаружения дальности действия камеры R200 нужно использовать специализированный API, предназначенный только для этого устройства. Чтобы получить такие данные для камеры R200, необходимо использовать API QueryDSMinMaxZ, доступный в составе интерфейса PXCCapture. Он возвращает минимальную и максимальную дальность камеры в миллиметрах.

Ссылки на API в документации SDK

QueryDSMinMaxZ: https://software.intel.com/sites/landingpage/realsense/camera-sdk/v1.1/documentation/html/index.html?querydsminmaxz_device_pxccapture.html

Результат 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Отслеживание снимаемого объекта потеряно.

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

  • Образец учебной программы при запуске. Tutorials.
  • Рисунок 11. Обучение
  • Предварительный просмотр снятой области или предмета.
     Previews.
  • Рисунок 12. Предварительный просмотр
  • Подсказки для пользователя.
     User prompts.
  • Рисунок 13. Подсказки для пользователя

Снижение утомляемости в случае, когда пользователь держит устройство в руках

Большинство приложений будет использовать устройство и при активном, и при неактивном режимах работы камеры. (Эти два режима отличаются следующим образом: камера работает в активном режиме, когда пользователь держит в руках планшет для просмотра сцены через камеру или для съемки; камера работает в неактивном режиме, когда пользователь положил планшет и работает с содержимым на экране, в то время как камера выключена). Для снижения утомляемости пользователей необходимо понимать, каким образом пользователь держит и использует устройство в каждом из указанных режимов, и соответственным образом выбирать зоны взаимодействия. При использовании камеры в активном режиме пользователь устает быстрее, поскольку держит устройство на весу, как показано на рис. 14.

 Device usage in active and inactive modes.

Рисунок 14. Использование устройства в активном и в неактивном режимах

Выбор подходящего режима для действия

Режим использования также напрямую определяет природу взаимодействия с приложением через пользовательский интерфейс. В активном режиме пользователь держит устройство обеими руками. Поэтому любые визуальные элементы приложения, например кнопки, должны находиться в легкодоступных местах на экране. Исследования показывают, что в таких случаях лучше всего использовать края экрана. Рекомендуемые зоны касаний показаны на рис. 15. Кроме того, в активом режиме снижается точность касаний, поэтому активный режим лучше всего подходит для краткосрочной съемки.

Напротив, в неактивном режиме пользователю удобнее работать с устройством, пользователь точнее взаимодействует с элементами интерфейса и может пользоваться приложением в течение продолжительного времени.

 Touch zones in active and inactive modes.

Рисунок 15. Зоны касаний в активном и в неактивном режимах

Ссылки на API в документации SDK

Настройка API Scene Perception и данные отслеживания:https://software.intel.com/sites/landingpage/realsense/camera-sdk/v1.1/documentation/html/index.html?manuals_configuration_and_tra2.html

Оповещения API 3D Scanning:https://software.intel.com/sites/landingpage/realsense/camera-sdk/v1.1/documentation/html/index.html?alertevent_pxc3dscan.html

Заключение

При разработке приложений с использованием технологии Intel® RealSense™ разработчики должны с самых ранних этапов принимать во внимание потребности и особенности работы конечных пользователей. Рекомендации, приведенные в этой статье, послужат основой для решения некоторых важных проблем пользовательских интерфейсов и для реализации необходимых компонентов в коде с помощью SDK.

Дополнительные материалы

Рекомендации по созданию пользовательских интерфейсов для камеры F200: https://software.intel.com/sites/default/files/managed/27/50/Intel%20RealSense%20SDK%20Design%20Guidelines%20F200%20v2.pdf

Рекомендации по созданию пользовательских интерфейсов для камеры R200:

https://software.intel.com/sites/default/files/managed/d5/41/Intel%20RealSense%20SDK%20Design%20Guidelines%20R200%20v1_1.pdf

Лучшие методики создания пользовательских интерфейсов в приложениях для камеры F200:

https://software.intel.com/en-us/articles/best-ux-practices-for-intel-realsense-camera-f200-applications

Ссылка на презентацию и запись выступления на конференции IDF:

http://myeventagenda.com/sessions/0B9F4191-1C29-408A-8B61-65D7520025A8/7/5

Об авторах

Мегана Рао (Meghana Rao)

Мегана — разработчик-евангелист в отделе Software and Services корпорации Intel, она сотрудничает с разработчиками и независимыми производителями программного обеспечения, помогая им в использовании технологии Intel® RealSense™ и в разработке приложений для Windows* 8 на ультрабуках, трансформерах и планшетах с архитектурой Intel®. Кроме того, она регулярно выступает на семинарах Intel Application Labs, где рассказывает о проектировании и разработке приложений на платформах Intel. Мегана Рао является автором множества информационных документов, доступных на портале Intel® Developer Zone. Она обладает ученой степенью бакалавра в области компьютерных наук и ученой степенью магистра в области компьютерных наук и управления технологиями. До поступления на работу в корпорацию Intel в 2011 году она работала старшим инженером по программному обеспечению в компании Infineon Technologies India Pvt. Ltd.

Кевин Артур (Kevin Arthur)

Кевин Артур — старший исследователь взаимодействия с пользователями в отделе Perceptual Computing корпорации Intel. Он руководит исследованиями новых сценариев использования и рекомендаций по работе с трехмерными камерами RealSense, включая смешанные сценарии и дополненную реальность. Кевин получил ученую степень доктора компьютерных наук в Университете Северной Каролины в г. Чапел-Хилл, его специальность — взаимодействие человека и компьютера в системах виртуальной реальности. Ранее он занимался разработкой пользовательских интерфейсов и исследованиями программного обеспечения в компаниях Amazon Lab126, Synaptics и Industrial Light & Magic.

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