This is a first trial to see how the SSTT library performs on various and random user hardware. Please give it a spin and tell me about your experiences. You find the download down here.

Somebody should have told them that just slapping some content which itself doesn’t represent anything spatial doesn’t work with AR. And heavy Kalman filters there anyway: what a whobble in more than one meaning.

Just by fixing an allocation error in SSTT I gained a four-fold speed increase. The memory lost was a few bytes but it was hitting the caching mechanism. The result: on a Atom based netbook it runs 10ms with a VGA (640x480) sized image.
This subsequently made enough room for proper framerates near the screen refresh rate on those low-powered devices

Download ARToolKit 2.74 RC1 for usage with CMake. It will work with various version of Visual Studio, Xcode and plain old Makefiles

What is it that drives Microsoft to treat DirectShow developers like they do. Capturing from a webcam with high speed is only possible with DirectShow. In the documentation for the Media Foundation they explicitly state to use DirectShow. However, all current SDKs are somehow broken. Visual Studio 2003 has an internal copy of the Platform SDK which is halfway usable for DirectShow capture. However, in Visual Studio 2005 and 2008 the internal SDK is missing important headers.

With sstt due to be released in the next few weeks some more optimizations have to be done. A major part has nothing really to do with the actual tracking: video capture. There are various methods and on Windows I am still relying on VfW which is the default method in OpenCV. Currently I am working on replacing this with a DirectShow capture which apparently doesn’t rely on the usual qedit.h header rather than being pure COM. Keep fingers crossed …

Congratulations Phil!

Again a severe problem with SWIG

Article on CNN

This video hopefully shows a few more features of SSTT. There is another one coming soon, demonstrating the performance with multiple markers.