I just finished the first alpha of MishraReader, a tool written with WPF 4.0 (so you need to install .NET framework 4.0) which allows you to read your feeds (using a Google reader account).

You can download it here : https://www.catuhe.com/files/MishraReader.zip

This version is an early alpha with a lot of missing features (such as notifications for instance).

In a near future, I will write a blog on some key points of the code used in MishraReader.

As a user interface fan, I could not miss the development with HTML 5.

So the goal of this post is to walk through a graphic application that uses JavaScript and HTML 5. We will see through examples one way (among others) to develop this kind of project.

Application overview  
Tools 
The HTML 5 page
Data gathering 
Cards loading & cache handling
Cards display
Mouse management  
State storage
Animations
Handling multi-devices
Conclusion
To go further

Application overview

We will produce an application that will let us display a Magic the Gathering ©(courtesy of www.wizards.com/Magic) cards collection. Users will be able to scroll and zoom using the mouse (like Bing Maps, for example).

You can see the final result here: https://bolaslenses.catuhe.com

The project source files can be downloaded here: https://www.catuhe.com/msdn/bolaslenses.zip

Cards are stored on Windows Azure Storage and use the Azure Content Distribution Network (CDN : a service that deploys data near the final users) in order to achieve maximum performances. An ASP.NET service is used to return cards list (using JSON format). 

Tools

To write our application, we will use Visual Studio 2010 SP1 with Web Standards Update. This extension adds IntelliSense support in HTML 5 page (which is a really important thing ).

So, our solution will contain an HTML 5 page side by side with .js files (these files will contain JavaScript scripts). About debug, it is possible to set a breakpoint directly in the .js files under Visual Studio. It is also possible to use the developer bar of Internet Explorer 9 (use F12 key to display it).

Debug with Visual Studio 2010

Debug with Internet Explorer 9 (F12/Developer bar)

So, we have a modern developer environment with IntelliSense and debug support. Therefore, we are ready to start and first of all, we will write the HTML 5 page.

The HTML 5 page

Our page will be built around an HTML 5 canvas which will be used to draw the cards:

If we dissect this page, we can note that it is divided into two parts:

• The header part with the title, the logo and the special mentions
• The main part (section) holds the canvas and the tooltips that will display the status of the application. There is also a hidden image (backImage) used as source for not yet loaded cards.

To build the layout of the page, a style sheet (full.css) is applied. Style sheets are a mechanism used to change the tags styles (in HTML, a style defines the entire display options for a tag):

Thus, this sheet is responsible for setting up the following display:

Style sheets are powerful tools that allow an infinite number of displays. However, they are sometimes complicated to setup (for example if a tag is affected by a class, an identifier and its container). To simplify this setup, the development bar of Internet Explorer 9 is particularly useful because we can use it to see styles hierarchy that is applied to a tag.
For example let’s take a look at the waitText tooltip with the development bar. To do this, you must press F12 in Internet Explorer and use the selector to choose the tooltip:

Once the selection is done, we can see the styles hierarchy:

Thus, we can see that our div received its styles from the body tag  and the .tooltip entry of the style sheet.

With this tool, it becomes possible to see the effect of each style (which can be disabled). It is also possible to add new style on the fly.

Another important point of this window is the ability to change the rendering mode of Internet Explorer 9. Indeed, we can test how, for example, Internet Explorer 8 will handle the same page. To do this, go to the [Browser mode] menu and select the engine of Internet Explorer 8. This change will especially impact our tooltip as it uses border-radius (rounded edge) and box-shadow that are features of CSS 3:

Our page provides a graceful degradation  as it still works (with no annoying visual difference) when the browser does not support all the required technologies.

Now that our interface is ready, we will take a look at the data source to retrieve the cards to display.

Data gathering

The server provides the cards list using JSON format on this URL:

https://bolaslenses.catuhe.com/Home/ListOfCards/?colorString=0

It takes one parameter (colorString) to select a specific color (0 = all).

When developing with JavaScript, there is a good reflex to have (reflex also good in other languages too, but really important in JavaScript): one must ask whether what we want to develop has not been already done in an existing framework.

Indeed, there is a multitude of open source projects around JavaScript. One of them is jQuery which provides a plethora of convenient services.

Thus, in our case to connect to the URL of our server and get the cards list, we could go through a XmlHttpRequest and have fun to parse the returned JSON. Or we can use jQuery .

So we will use the getJSON function which will take care of everything for us:

As we can see, our function stores the cards list in the listOfCards variable and calls two jQuery functions:

• text that change the text of a tag
• slideToggle that hides (or shows) a tag by animating its height

The listOfCards list contains objects whose format is:

• _ID_: unique identifier of the card
• Path: relative path of the card (without the extension)

It should be noted that the URL of the server is called with the “?jsoncallback=?” suffix. Indeed, Ajax calls are constrained in terms of security to connect only to the same address as the calling script. However, there is a solution called JSONP that will allow us to make a concerted call to the server (which of course must be aware of the operation). And fortunately, jQuery can handle it all alone by just adding the right suffix.

Once we have our cards list, we can set up the pictures loading and caching.

Cards loading & cache handling

The main trick of our application is to draw only the cards effectively visible on the screen. The display window is defined by a zoom level and an offset (x, y) in the overall system.

The overall system is defined by 14819 cards that are spread over 200 columns and 75 rows.

Also, we must be aware that each card is available in three versions:

• High definition: 480×680 without compression (.jpg suffix)
• Medium definition: 240×340 with standard compression (.50.jpg suffix)
• Low definition: 120×170 with strong compression (.25.jpg suffix)

Thus, depending on the zoom level, we will load the correct version to optimize networks transfer.

To do this we will develop a function that will give an image for a given card. This function will be configured to download a certain level of quality. In addition it will be linked with lower quality level to return it if the card for the current level is not yet uploaded:

An ImageCache is built by giving the associated suffix and the underlying cache.

Here you can see two important functions:

• load: this function will load the right picture and will store it in a cache (the msecnd.net url is the Azure CDN address of the cards)
• getImageForCard: this function returns the card picture from the cache if already loaded. Otherwise it requests the underlying cache to return its version (and so on)

So to handle our 3 levels of caches, we have to declare three variables:

Selecting the right cover is only depending on zoom:

To give a feedback to the user, we will add a timer that will manage a tooltip that indicates the number of images currently loaded:

Again we note the use of jQuery to simplify animations.

We will now discuss the display of cards.

Cards display

To draw our cards, we need to actually fill the canvas using its 2D context (which exists only if the browser supports HTML 5 canvas):

The drawing will be made by processListOfCards function (called 60 times per second):

This function is built around many key points:

• If the cards list is not yet loaded, we display a tooltip indicating that download is in progress::

• Subsequently, we define the position of the display window (in terms of cards and coordinates), then we proceed to clean the canvas:

• Then we browse the cards list and call the drawImage function of the canvas context. The current image is provided by the active cache (depending on the zoom):

• We also have to draw the scroll bar with the RoundedRectangle function that uses quadratic curves:

• And finally, we need to compute the number of frames per second:

Drawing cards relies heavily on the browser’s ability to speed up canvas rendering. For the record, here are the performances on my machine with the minimum zoom level (0.05):

The site even works on mobile phones and tablets as long as they support HTML 5.

Here we can see the inner power of HTML 5 browsers that can handle a full screen of cards more than 30 times per second!

Mouse management

To browse our cards collection, we have to manage the mouse (including its wheel).

For the scrolling, we’ll just handle the onmouvemove, onmouseup and onmousedown events.

Onmouseup and onmousedown events will be used to detect if the mouse is clicked or not:

The onmousemove event is connected to the canvas and used to move the view:

This function (onMouseMove) calculates the current position and provides also the previous value in order to move the offset of the display window:

Note that jQuery also provides tools to manage mouse events.

For the management of the wheel, we will have to adapt to different browsers that do not behave the same way on this point:

We can see that everyone does what he wants .

The function to register with this event is:

And we will use this function to change the zoom with the wheel:

Finally we will add a bit of inertia when moving the mouse (and the zoom) to give some kind of smoothness:

This kind of small function does not cost a lot to implement, but adds a lot to the quality of user experience.

State storage

Also to provide a better user experience, we will save the display window’s position and zoom. To do this, we will use the service of localStorage (which saves pairs of keys / values ​​for the long term (the data is retained after the browser is closed) and only accessible by the current window object):

Animations

To add even more dynamism to our application we will allow our users to double-click on a card to zoom and focus on it.

Our system should animate three values: the two offsets (X, Y) and the zoom. To do this, we will use a function that will be responsible of animating a variable from a source value to a destination value with a given duration:

The use of this function is:

The advantage of the AnimationHelper function is that it is able to animate as many parameters as you wish (and that only with the setTimer function!)

Handling multi-devices

Finally we will ensure that our page can also be seen on tablets PC and even on phones.

To do this, we will use a feature of CSS 3: The media-queries. With this technology, we can apply style sheets according to some queries such as a specific display size:

Here we see that if the screen width is less than 480 pixels, the following style sheet will be added:

This sheet will reduce the size of the header to keep the site viewable even when the browser width is less than 480 pixels (for example, on a Windows Phone):

Conclusion

HTML 5 / CSS 3 / JavaScript and Visual Studio 2010 allow to develop portable and efficient solutions (within the limits of browsers that support HTML 5 of course) with some great features such as hardware accelerated rendering.

This kind of development is also simplified by the use of frameworks like jQuery.

Also, I am especially fan of JavaScript that turns out to be a very powerful dynamic language. Of course, C# or VB.NET developers have to change theirs reflexes but for the development of web pages it’s worth.

In conclusion, I think that the best to be convinced is to try!

To go further

• Internet Explorer test drive: https://ie.microsoft.com/testdrive/
• Internet Explorer 9  guide for developer : https://msdn.microsoft.com/en-us/ie/ff468705
• W3C site for HTML 5 : https://dev.w3.org/html5/spec/Overview.html
• Internet Explorer site : https://msdn.microsoft.com/en-us/ie/aa740469

You have certainly not missed (as a regular reader of this blog ) that the Kinect for Windows SDK is out!

For now, however, no gestures recognition services are available. So throughout this paper we will create our own library that will automatically detect simple movements such as swipe but also movements more complex such as drawing a circle with your hand.

The detection of such gestures enable Powerpoint control the Jedi way ! (similar to the Kinect Keyboard Simulator demo).

If you are not familiar with the Kinect for Windows SDK, you should read a previous post that addressed the topic: https://blogs.msdn.com/b/eternalcoding/archive/2011/06/13/unleash-the-power-of-kinect-for-windows-sdk.aspx

How to detect gestures ?

There is an infinite number of solutions for detecting a gesture. In this article I will explorer two of them:

• Algorithmic search
• Template based search

Note that these two techniques have many variants and refinements.

You can find the code used in this article just here: **[https://kinecttoolbox.codeplex.com**](https://kinecttoolbox.codeplex.com)

GestureDetector class

To standardize the use of our gestures system, we will therefore propose an abstract class GestureDetector inherited by all gesture classes:

This class provides the Add method used to record the different positions of the skeleton’s joints.

It also provides the abstract method LookForGesture implemented by the children.

It stores a list of Entry in the property Entries whose role is to save the properties and timing of each recorded position.

Drawing stored positions

The Entry class also stores an WPF ellipse that will be used to draw the stored position:

Via the TraceTo method of the GestureDetector class, we will indicate which canvas will be used to draw the stored positions.

In the end, all the work is done in the Add method:

Note the use of the SkeletonToDepthImage method which converts a 3D coordinate to a 2D coordinate between 0 and 1 on each axis.

So in addition to saving the position of the joints, the GestureDetector class can draw them to give visual feedback that greatly simplifies the development and debug phases:

As we can see above, the positions being analyzed are shown in red above the Kinect image. To activate this service, the developer just needs to put a canvas over the image that shows the stream of the Kinect camera and pass this canvas to the GestureDetector.TraceTo method:

The Viewbox is used to keep the image and the canvas at the same size. The second canvas (kinectCanvas) is used to display the green skeleton (using a class available in the sample : SkeletonDisplayManager).

Event-based approach

GestureDetector class provides one last service to his children: the RaiseGestureDetected method that reports the detection of a new gesture via an OnGestureDetected event. The SupportedGesture argument of this event contains the following values:

• SwipeToLeft
• SwipeToRight
• Circle

Obviously the solution is extensible and I encourage you to add new gestures to the system.

The RaiseGestureDetected method (with MinimalPeriodBetweenGestures property) also guarantee that a certain time will elapse between two gestures (in order to remove badly executed gestures).

Now that our foundations are laid, we can develop our algorithms.

Algorithmic search

The algorithmic search browses the list of positions and checks that predefined constraints are always valid.

The SwipeGestureDetector class is responsible for this search:

For the SwipeToRight gesture, we will use the following constraints:

• Each new position should be to the right of the previous one
• Each position must not exceed in height the first by more than a given distance (20 cm)
• The time between the first and last position must be between 250ms and 1500ms
• The gesture must be at least 40 cm long

The SwipeToLeft gesture is based on the same constraints except for the direction of the movement of course.

To effectively manage these two gestures, we use a generic algorithm that checks the four constraints mentioned above:

To use this method, we must provide three functions and a time-delay to check.

So to manage the two gestures, simply call the following code:

With this class it is really simple to add gestures that are detectable with constraints.

Skeleton stability

To ensure the proper operation for our detection, we must validate that the skeleton is actually static so as not to generate wrong gestures (i.e. detection of movement associated with a swipe of the whole body) .

To do that, we will use the BarycenterHelper class:

By providing to this class the successive positions of the skeleton, it will tell us (via the IsStable method) if the skeleton is moving or static.

Thus, we can use this information to send the positions of the joints to the detection systems only when the skeleton is not in motion:

Replay & Recording tools

Another important point when developing with the Kinect for Windows SDK is the ability to efficiently test. It may sound silly, but to test you must get up, come in front of the sensor and make the appropriate gesture. And unless you have an assistant, this can quickly become painful.

So we’ll have a record and replay service for the information sent by Kinect.

Recording

The recording part is pretty simple because we only have to take a SkeletonFrame and browse each skeleton to serialize its contents:

Replay

The main problem with the replay mechanism is about data reconstruction. Indeed, Kinect classes are sealed and do not expose their constructor. To work around this problem, we will replicate and mimic the Kinect class hierarchy adding implicit cast operators to Kinect classes:

The SkeletonReplay class is responsible of the replay with its Start method:

Finally, we can record and replay gestures to debug our application:

You can download a replay sample here: https://www.catuhe.com/msdn/davca.replay.zip

Know when to start

The last remaining problem to resolve is deciding when to begin the analysis of gestures. We already know that we must do so when the body is stable but it is not enough.

Even if I stay static, I use my hands a lot when I speak and I can inadvertently trigger a gesture.

To protect ourselves from this, it is possible to complete the detection by adding a posture condition.

That’s why we are going to use the PostureDetector class:

The PostureDetector class is based on a comparative analysis of the positions of each joint. For example, to trigger the Hello posture, we have to know if the hand is at the same height as the head and if it is at least 25cm on the side.

In addition, the system use an accumulator to ensure that the posture is stable during a given number of frames.

Once again this class is highly extensible.

Template-based search

The main drawback of the algorithmic search is that all gestures are not easily describable with constraints. We will therefore consider another more general approach.

We will assume that a gesture can be recorded and subsequently, the system will determine if the current gesture is one that is already known.

Finally, our goal will be to efficiently compare two gestures.

Compare the comparable

Before we start to write a comparison algorithm, we have to standardize our data.

Indeed, a gesture is a sequence of points (for this article we will simply compare 2D gestures such as circles). However, the coordinates of these points define a distance to the sensor and we will have to bring them together to a common reference. To do this we will do the following;

1. Generate a new gesture with a defined number of points
2. Rotate the gesture so the first point is at 0 degree
3. Rescale the gesture to a 1×1 reference graduation
4. Center the gesture to origin

With these changes, we will be able to compare points array of the same size centered on a common graduation with a common direction.

To pack points array using this technique, we use the following code:

Methods and extension methods are available in the GoldenSectionExtensions static class:

Golden Section

The comparison between our data could be done via a simple average distance function between each point. However, this solution is not accurate enough.

So I used a much more powerful algorithm called Golden Section Search. He comes from a paper available here: https://www.math.uic.edu/~jan/mcs471/Lec9/gss.pdf

A JavaScript implementation is available here: https://depts.washington.edu/aimgroup/proj/dollar/

The implementation in C#:

With this algorithm, we can simply compare a template with the current gesture and get a score (between 0 and 1).

Learning Machine

To improve our success rate, we need to have multiple templates. For this, we will work with the LearningMachine class whose role is precisely to store our templates (i.e. to learn new models) and to compare with the current gesture:

Each RecordedPath implements the Match method and therefore call the Golden Section Search:

Thus, thanks to our detection algorithm and to our learning machine, we are dealing with a system that is both reliable and very little dependent on the quality of information supplied by Kinect.

You will find below an example of a knowledge base used to recognize a circle: https://www.catuhe.com/msdn/circleKB.zip.

Conclusion

So we have at our disposal a set of tools for working with Kinect. In addition we have two systems to detect a large number of gestures.

It’s now your turn to use these services in your Kinect applications!

To go further

• Kinect on Channel9
• Coding4Fun Kinect
• Microsoft Research site

This post is a translation of https://blogs.msdn.com/b/eternalcoding/archive/2011/06/14/fr-prenez-le-contr-244-le-avec-kinect-pour-windows-sdk.aspx

Introduction

Microsoft Research has released the first beta of Kinect for Windows SDK. You can find resources and download the SDK at:

https://research.microsoft.com/kinectsdk

This SDK also install drivers for the Kinect sensors. However, be aware that the SDK will only install on Windows 7 (x86 and x64).
The first point worth noting is that the latter is actually available in two versions: one for C++ developers and one for managed developers.

So there is no jealousy. As I prefer managed environment, my samples will be presented in C # (matter of taste only).

Regarding the licensing mode, this version released by Microsoft Research, is free for private use (basically, anything that is not commercial).

Architecture

Basically, the Kinect sensors will send a set of three streams:

Image stream can be displayed like with any other camera (for example to do augmented reality). The Kinect video sensor can return a stream with 2 resolutions: one at 640×480 (at 30 frames per second) and one at 1280×1024 (but at 15 frames per second).

The depth stream is the determining factor in our case. It will indeed add to each pixel a depth defined by the sensor. So in addition to the 2D position of each pixel (and color) we now have depth. This will greatly simplify the writing of shapes detection algorithms.

A third stream is sent from the sensor: it is the audio stream from the four microphones (more on this subject at the end of the article).

Therefore, the key point here concerns the ability of Kinect to give us three-dimensional data. Using the NUI library (which comes with the SDK and stand for Natural User Interfaces) you will be able to detect the presence of humans in front of the sensor. Kinect can “see” up to 4 peoples and accurately track both of them.

When Kinect precisely follows a person, it can provide a skeleton made ​​up of key points detected on the user:

As shown in this diagram of the Vitruvian Man, there are 20 key points (which we call joints) that are detected and tracked by the NUI library.

For best results, it is necessary to stand between 4 and 11 feet from the sensor. Beyond these limits, the sensors accuracy decreases quickly. It is also not possible (yet) to follow a user sitting in front of his computer.

Getting started

To use Kinect for Windows SDK in your .Net application, you only have to reference Microsoft.Research.Kinect.dll.

Then you have two new namespaces, one for accessing video streams and skeletons and one for audio.

To initialize the NUI library, you must instantiate an object from the Runtime class and configure the streams you want to receive:

In our example, we initialize the library with the support of depth stream, video stream and tracking of skeletons.

Video buffer

To use the video stream, you must first define the awaited format, To do so, we’ll ask the library to retrieve the data in a given resolution with a defined pixel format:

Here, we ask for a resolution of 640×480 with a RGB pixel format. It is also possible to request a resolution of 1280×1024 (with lower performances) and pixel can be in YUV format. Resolution as mentioned earlier has an impact on performances. This is not the case of pixel format so it can be chosen according to what suits better for your application.

Subsequently, to be informed of the availability of each image, you must subscribe to an event of the library:

In the handler of this event, we can simply produce a BitmapSource to display it in a WPF application:

Depth buffer

Besides the video stream, Kinect can send a stream coming from the infrared sensor that gives depth data.

The initialization is similar to that of the video stream:

The depth data are stored as arrays of 16 bits integers. The depth stream can be retrieved at 320×240 or 80×60.

• The 13 high-order bits of each pixel represent the distance from the depth sensor to the closest object, in millimeters.
• The 3 low-order bits of each pixel represent the index of the tracked user who is visible at the pixel’s x and y coordinates.

So if you want to view the depth stream while coloring the areas occupied by humans, it is possible to use this code:

This stream can be extremely useful to detect shapes. Thus, it is possible to monitor and detect hands or fingers movements to produce new ways to interact with the PC.

Skeleton tracking

One of the big strengths of Kinect for Windows SDK is its ability to discover the skeleton of joints of an human standing in front of the sensor. And unlike the hacks that have sprung up on Internet (like OpenNI), the Kinect for Windows SDK incorporates a very fast recognition system and requires no training to use. This is the result of a long training of a learning machine. Microsoft Research has given many examples to the recognition system to serve its apprenticeship.

So once you pass behind the sensor (at the right distance of course), the NUI library will discover your skeleton and will raise an event with useful data about it.

To enable skeleton tracking system, you must activate the depth stream and handle the appropriate event:

In the handler for this event, we can loop through all the skeletons found by the system:

Several points are noteworthy here:

• The NUI library cannot track more than 2 skeletons. It is the property TrackingState == SkeletntrackingState.Tracked that defines whether a skeleton is ‘tracked’ or not. The untracked skeletons only give their position.
• Each joint has a Position property that is defined by a Vector4: (x, y, z, w). The first three attributes define the position in camera space. The last attribute (w) gives the quality level (between 0 and 1) of the position. This allows you to filter and take only the data that the library is almost certain.

• Each skeleton has a property TrackingID which remains the same on every frame. This allows us to uniquely identify the skeletons between each call.
• Each joint is identified by an enum which define its reference position (hands, head, etc.).

It is also possible to pool the current skeletons with the SkeletonEngine.GetNextFrame() method.

Finally, the NUI library provides an algorithm for filtering and smoothing incoming data from the sensor. Indeed, by default, the skeletons data are sent without smoothing or filtering. However, the Kinect depth sensor has not sufficient resolution to ensure consistent accuracy over time. Thus, the data seem to vibrate around their positions. To correct this problem, you can call this code:

As we can see, it is possible to smooth and correct data. Depending on what you need, you should manipulate these parameters to provide the best experience possible.

It is now your imagination’s turn to propose future applications. Thus, it is possible to look for gestures to control applications (the famous PowerPoint Jedi control) or even to make fun with augmented reality…

Kinect and sound

Kinect comes with a group of four microphones (microphone array) that capture sound at very high quality. Indeed, directly on the sensor, a signal processor (DSP) is used to remove background noise and cancel echo effects.

Moreover, thanks to its group of microphones, Kinect can provide the direction of the recorded sound source (beamforming). Then it becomes possible to know who is speaking in a meeting for example.

The Kinect for Windows SDK is also able to be a source for Microsoft.Speech API and thus it becomes possible to do voice recognition using Kinect.

So to use all of these services, simply instantiate an object of class KinectAudioSource:

This instantiation can select microphone array mode or single microphone mode with or without echo cancellation (Audio Echo Cancellation: AEC).

To start capturing, we’ll just ask our KinectAudioSource to start providing us the audio stream:

The audio is in 16-kHz, 16-bit mono pulse code modulation (PCM).

To use the beamforming services, use this code:

There are several ways to detect the sound beam. Here, we let the system itself selects the appropriate beam. It would also be possible to make the selection manually, or take only the central beam or use the average of all beams.

Then, the system can raise an event when the beam moves:

The returned angle is in radians and is relative to the center of your Kinect. If you are in front of it: an angle of 0 indicates that the sound comes across the sensor, an angle <0 indicates="" that="" the="" sound="" comes="" from="" left="" and="" an="" angle=""> 0 indicates that the sound comes from the right.

At any time, it is also possible to request the current value of the angle by calling source.SoundSourcePosition:

Like the positions of the skeletons joints, we can get a data level of quality to decide if we want to use it.

Regarding filters (anti-echo and noise reduction) the KinectAudioSource class provides updatable parameters to achieve the expected results.

Conclusion

So we could see that the Kinect for Windows SDK provides many tools to play with. We are about to discover a lot of new kinds of interaction between man and machine. Of course it lacks some high level tools (like a library of gestures), but it’s an easy bet that the next few weeks will show up many projects from the community and Microsoft (for example the Coding4Fun Kinect Toolkit on CodePlex).

To go further

• Demonstrations : https://msdn.microsoft.com/fr-fr/windows/sdk-kinect-demo
• Microsoft Research : https://research.microsoft.com/en-us/
• Kinect on Channel9 : https://channel9.msdn.com/coding4fun/kinect/
• Demonstration of the Light Saber on Channel9 :
  https://channel9.msdn.com/coding4fun/kinect/Of-course-our-first-Kinect-for-Windows-SDK-Project-has-to-involve-a-Light-Saber