Archived source · macOS · 2010
cocoaKinect.app
A native macOS viewer for the Microsoft Kinect, built straight onto libfreenect. It turns the depth stream into a point cloud or a triangle mesh in real time, and writes the result out as PLY or STL.
The depth colormap
2048 depth values, one colour ramp
The Kinect reports depth as an 11-bit number. The app builds a 2048-entry lookup texture at startup and shades every sample through it. This is that exact ramp, regenerated from the code that builds it:
Notice that it runs out. The ramp applies a cubic gamma, so the whole visible spectrum is spent by roughly value 1150 and everything beyond it clips to black. That is why the app carries near and far clipping controls: without them, most of the sensor's range renders as nothing at all.
What it does
Capabilities
- StreamsLive depth, RGB and infrared, straight from the device
- Draw modes2D image, point cloud, or triangle mesh
- ShadingGLSL shaders: depth colormap, or the RGB camera projected onto the geometry
- ControlsNear and far clipping, detail, mirror, surface normals, background removal
- HardwareMotor tilt and LED colour
- ExportPLY, ASCII STL and binary STL, with a delayed snapshot timer
Provenance
Whose work this is
cocoaKinect was written in November 2010 by Robert Pointon (fernlightning) as a demo for the OpenKinect community. It is not the work of the person maintaining this archive. All credit for the application code goes to the original author, whose own notes are preserved in the repository verbatim.
The application code carries no formal licence: main.m says "All
rights reserved", while the author's notes grant permission informally — "frankly
I don't care what you do with this code, hopefully you'll be nice and add me to
your credits". That is a statement of intent, not a licence, so no
LICENSE file has been added here. The maintainer is not the copyright
holder and cannot license someone else's work.
The vendored dependencies do carry formal licences. libfreenect is Apache-2.0 or GPL-2.0 at your option; libusb is LGPL-2.1. Their terms and obligations are set out in THIRD-PARTY-LICENSES.md, which is worth reading before redistributing any of it.
Since 2010
What was fixed
The first commit is the source as received, reorganised and nothing more. Work applied on top of it falls into two piles.
Speed
The per-pixel depth clamp was making up to seven Objective-C message sends and
two fmod() calls on each of 307200 pixels, every frame. Hoisting
the accessors and replacing the modulo with the loop's own column index:
| Per frame | Before | After | |
|---|---|---|---|
| Depth clamp | 4.69 ms | 0.71 ms | 6.6× |
| Mesh indices | 0.087 ms | 0.019 ms | 4.6× |
| Allocator | 1.5 MB | none | reused |
Both rewritten loops were checked against the originals across 960 randomised parameter combinations, and produce byte-identical output.
Defects
The export actions waited for a frame in a loop with no exit. With no device streaming, that pinned a CPU core on the main thread and froze the interface permanently — and nothing disabled the menu items, so it was two clicks away.
The binary STL writer counted facets in a pointer variable, so the arithmetic advanced in units of eight bytes and the file header announced eight times as many facets as it wrote.
Shader compile failures were logged by passing an NSString * to a
%s format, which reads the object pointer as a C string: garbage
or a crash, on the one code path whose job is to report shader errors.
Building
It still compiles
Open src/cocoaKinect.xcodeproj and build the cocoaKinect
target. On an Intel Mac it builds and runs.
On Apple Silicon it will not link as it stands. The vendored libusb binaries are x86_64 only:
$ lipo -info src/libusb-1.0/lib/libusb-1.0.0.dylib
Non-fat file: ... is architecture: x86_64
They have to be rebuilt or replaced with a universal build first. Continuous integration on the repository parses and type-checks the sources against the current macOS SDK on every change, which catches anything that stops them being valid Objective-C — but it does not build the app, and nothing here has been run against Kinect hardware.