In this chapter, we will cover:
- Creating a project in Visual Studio 2010
- OpenNI class and error handling
- Enumerating a list of connected devices
- Accessing video streams (depth/IR/RGB) and configuring them
- Retrieving a list of supported video modes for depth stream
- Selecting a specific device for accessing depth stream
- Listening to the device connect and disconnect events
- Opening an already recorded file (ONI file) instead of a device
In this chapter, we will introduce primary datatypes of the OpenNI and the NiTE along with some basic information about how to access and select a data stream. Then we will try to show you some examples of events triggered by devices such as connecting or disconnecting an OpenNI supported device from computer.
But first, let's get some background about the whole OpenNI's principle first.
OpenNI object is the starting point of everything in the framework. Using the OpenNI class we can access a list of connected devices as well as the version of OpenNI itself. Then using this information we can access a device object and read data.
This class uses the singleton pattern, which means there is only one instance of this class and all of its methods are static.
Also in OpenNI 2 we have the ability to register two callback functions by OpenNI object for capturing device connected and device disconnected events.
Device object is representing the actual physical device where each device supports a number of sensors (for example, depth, color, and IR) that can be accessed using Device object. We need to ask for access to a device before using its sensor's output. Also using this object, we can access some device-wide settings. Read more in Chapter 4, More about Low-level Outputs.
Using the VideoStream object we can access the output data of color, IR, and depth sensors. VideoStream in the new version of OpenNI supports event-based reading that gives us the ability to register a callback function to execute when a new frame of data becomes available.
Unlike OpenNI 1.x, where we could share a device between two or more applications at the same time, we can't share a sensor's output at all with OpenNI 2.x. In the new design, the first application always locks the device; not only is there no way for the second app to change settings of sensors, there is no way to even use the output of locked sensors in any way as well.