Got the following question via email:
I am trying to understand the differences between the depth stream and the IR stream. Both can see in the dark. What can the depth stream do that the IR stream can’t and vice versa?
The docs says that I can also use IR data to capture an IR image in darkness as long as I provide my own IR source. In the demo app I darkened the room (not pitch black but dark) and put my hand in view of the sensor and could see it quite well. What was providing the IR in that scenario?
First, some background:
We added the ability in Kinect for Windows 1.6 to get an infrared stream, on top of the depth stream that was enabled since v1. The depth stream is created by processing the dots in the infrared stream. One of the goals of our v1.6 release was to unlock more of the data that the sensor could provide (accelerometer, infrared, extended depth) and to provide more control over the data it captures (color camera settings, infrared emitter control).
Some additional pointers with more detail
- Kinect for Windows team blog post: “Inside the Newest Kinect for Windows SDK — Infrared Control“
- See my discussion of infrared during my “Build 2012 Kinect for Windows Programming Deep Dive” (Watch video from 29m 5s until 32m 30s). (if you want the demo code from that talk, it is located here “KinectMagicMirror demo“.
What other clarifications would people like?
So when a pet peeve of mine struck again, I took action.
1) I attempted to fix the instance of the problem:
1a) emailed feedback to fidelity via a reply to the email they originally sent me (added a suffix to subject line — another pet peeve of mine – good email subject lines)
From: Rob Relyea
Sent: Saturday, January 26, 2013 6:29 AM
To: ‘Fidelity Investments’
Subject: RE: Important 2012 tax information – feedback on file downloads
Please pass this feedback to your web site designers…who own creating the tax form download page.
Wrote a short blog post with my feedback: https://robrelyea.wordpress.com/2013/01/26/designing-file-names-improving-user-experience-for-file-downloads/
Thanks, Rob Relyea
A Fidelity customer
A program manager at Microsoft with passion for great filenames
1b) got an automated reply from Fidelity. Impressed so far! We’ll see how they route the feedback.
From: Fidelity Customer Service [mailto:firstname.lastname@example.org]
Sent: Saturday, January 26, 2013 6:40 AM
To: Rob Relyea
Subject: RE: Important 2012 tax information – feedback on file downloads
This email is automatically generated to confirm that your email to Fidelity Investments was received.
Your email is very important to us and you will receive a personalized response within 48 hours.
2) When I spend my energy to improve something, I try to fix instances of problems in a way that can have a bigger impact.
2b) tweeted it.
We’ll see how this goes…
Electronic statements from financial institutions and application setup files are two types of file downloads that happen often on the internet. More design needs to go into the file names that web sites choose to provide for downloadable files.
When web site builders design a file name, they should:
Design it with the perspective of the user, not the site!
Consider what your users want to do with it and where they will store it.
In the example above, I’m going to store that file in: documents\financial\taxes\2012\. I downloaded this file from Fidelity.com, shouldn’t the file name include the word Fidelity?
Pick a name that will make sense in the future (include context in name)
If they saved it in their downloads or documents folder, and came back 1 month later, would they know what it was and where it came from?
Clearly, TaxForm2012.pdf doesn’t tell me enough. Fidelity-TaxForm-2012.pdf, but might be improved on. Read on…
Avoid Duplicate Names
Consider how to provide unique names of documents to users. If they might download several files, they shouldn’t be forced to rename them. Your suggested name should be good enough to save all of them into the same folder.
In the case of tax statements from fidelity, you might get tax statements from different accounts, a normal brokerage account, retirement accounts, etc… Perhaps Fidelity-Investments-Tax Form-2012.pdf and Fidelity-401k-Tax Form-2012.pdf would be a good pattern.
Imagine the lifecycle of the files you provide for download.
If they want to download more than one version (over time), consider putting a version number or date in the filename.
Fidelity did a good job of this by having the year.
Application setup files – NO MORE SETUP.EXE!
Application setup programs shouldn’t be named “Setup.exe”. Perhaps MyCoolAppName-1.5-Setup.exe would be a better pattern.
Driver setup files – V220.127.116.11_VT_DRIVERS.zip???
An example, Windows “Problem Reports and Solutions” once pointed me towards a new network driver from Intel to improve stability. When I follow a link or two and begin downloading the file, the filename was: V18.104.22.168_VT_DRIVERS.zip. When I save that file locally, the file name makes it very tough to understand what the file is.
Shouldn’t driver downloads be named with the idea that they will be stored in a directory with other drivers and need to be distinguishable?
Perhaps something more like: IntelPro-Wireless-3945ABG_V22.214.171.124_Drivers.zip
Filenames for files that won’t be downloaded by end users also need design
Computers are complex system. Picking good names for application components and data files is good practice that improves the system and the user experience.
[This blog post was a rewrite of similar May 22, 2007 post I did. Perhaps my first blog post wasn’t effective enough. Maybe twitter will help this time? Perhaps you could spread the word to a site that has badly designed file names?]
Had a great time during //build/2012 on October 30th-November 2nd here on campus.
Kinect for Windows Team Talks
1) Jay Kapur talked about “Kinect UI Design Considerations“. We are investing in more work improving user interactions via Kinect. He foreshadows some of that work in this talk. Discusses some details of our button press and scrolling interaction models.
2) In my session (Kinect for Windows Programming Deep Dive), I did a demo which tried to walk through much of the API. Built a cool app that I called Magic Mirror (will post soon). Chris White, another Program Manager on our team, came up and announced/demoed Kinect Fusion (happens at about 47:30 in the video).
Andy Wilson, of Microsoft Research, also presented a great session called Super-Natural Interaction. The session detailed a bunch of UI research and experimentation that Andy and his colleagues have done over the past few years. Many interesting uses of Kinect in this session.
Beyond that, Ben Lower organized a great booth where we had devs, testers and program managers from our team talking directly with devs. We demoed sample apps and even showed off Kinect Fusion – doing a few scans! We had another room where developers could bring their laptop, use our Kinect for Windows sensors and code away…with assistance where needed.
[Ok, I’m getting to this blog post a few months late. Been busy! Trying to do a few catch up posts today…]
We released v1.6 of the Runtime/SDK and v1.6.0 of the Developer Toolkit for Kinect for Windows in October. I did a bunch of work on v1.6, helping to drive many of the features and the release overall — so I’m very happy to see it ship.
Our team blog post. (Kinect for Windows releases SDK update and launches in China) goes into details about:
- Extended Sensor Access (accelerometer data, depth data beyond 4m, color camera settings, infrared data, toggling ir emitter, etc..)
- Improved Dev Tools (German speech language pack, skeletal tracking works on multiple sensors per process now, great new Basic Interactions sample)
- Support for Windows 8 wave (Windows 8 desktop app support, you can use VS2010 or VS2012, you can target managed apps at .NET 4.0 or 4.5)
Download Details. As always, this Kinect for Windows SDK download page is where you can download the latest versions of the SDK/Toolkit.
See you on the Forums. Please engage with our team, and the rest of the Kinect developer community, on the Kinect Forums – http://bit.ly/KinectSDKForums
-Rob Relyea, @rrelyea
Program Manager, Kinect for Windows team
Microsoft.Research.Kinect.dll was the DLL name for our early beta releases (beta 1, beta 1 refresh and beta 2) from 2011.
In our final version 1.0 release (Feb 1, 2012), we changed the DLL name to Microsoft.Kinect.dll and did a major refactoring of the API surface of the Kinect for Windows SDK.
This means that you are probably looking at an old article or source code. Our recommendation is that you should migrate your code/projects to our latest version. Details of how to migrate your Beta 2 code forward to v1.0 and later is here: https://robrelyea.wordpress.com/2012/02/01/k4w-details-of-api-changes-from-beta2-to-v1-managed/
The VAST MAJORITY OF PEOPLE should be using the latest versions of Kinect for Windows SDK – See http://kinectforwindows.com for the download location of the SDK.
[As of May 2012, Beta 2 is still downloadable…for those that absolutely need it…from http://www.microsoft.com/en-us/download/details.aspx?id=27876]
No, Kinect for Windows SDK doesn’t support Windows Embedded Compact version 7 (or other versions of Windows Embedded Compact).
This is true as of May 2012 (including version 1.0 and 1.5 of Kinect for Windows SDK).