Markers, I will use them.

Feature detection has broken me & I have mostly decided that I will incorporate markers to a limited extent. Well, it hasn't broken me, but motion tracking is only but a part of my dissertation, and I need to do things on top of that. So, I cannot devote all my resources to solving problems that have not been solved in motion capture yet. Here's the current version (still markerless..):

So basically, I need to be able to distinguish between heads, so that it creates a new tracker for a new person. It obviously still loses where its tracking, non-trivially -- although it's better than before. It updates with face detection every 250 frames or so & also when its detecting too many zero pixels (this is after depth segmentation & only looking at the top 25% of blobs for heads -- yes, the kinect data is noisy).

Facial recognition is too CPU-intensive I think. I attempted to try tracking markers using some AR libraries (aruco, ARma) -- just as a prototype -- they were really light-weight & easy to implement -- but they were not meant for applications such as mine (nothing comes cheap in my case). I think I'm also ready to do better depth segmentation... & perhaps there is a way to disgard some of the Kinect noise.

I am worried about varied lighting conditions, etc. I am half-thinking about just turning the Kinect into a cheap IR sensor sans depth -- since the resolution of the depth information is fairly low & noisy for my purposes. Or just buying really high quality & fast webcams.

Another problem to solve: right now, the kinect is sucking up CPU -- like 120%... eek. I've traced the problem to the libfreenect-driver, but replacing the driver with an up-to-date version (the one on homebrew is 2 iterations behind) either crashes or runs once in debug mode, using even more CPU than before...

EXC_BAD_ACCESS in OSC + 64-bit Cinder with Xcode 4.6.2 in OS X 10.7

This was enough of a headache that it deserves a post.

I'm using cinder on OSX, 64-bit in order to run the OpenNI 2 block. The official release and everything of Cinder is still 32-bit, but most of the libraries will work in 64-bit -- but it is a pain. I am using the osc block that comes with the official 0.85 release of Cinder.

So I kept getting this weird EXC_BAD_ACCESS (code=13) error in OutboundPacketStream whenever I tried to use the osc::Sender object to send anything.

Unfortunately, I was convinced this was something weird I was doing myself... since all the examples worked & I have been using this library in 32-bit for a very long time...  But I wasn't thinking that about the fact they were in 32-bit & my code was compiling to 64-bit... in any case, it looks like it is fixed in the current version of the oscpack library (someone else had this problem, though not with the Cinder implementation in particular), so I replaced the /ip & /osc parts of the library. It solved my problem. Case closed!

Btw, I should probably move to OS X 10.9, I know. But you can see from the above mess that upgrading anything is generally a big hassle...

Cinder does not get as much curating as other libraries, like say Processing and has a much smaller user base. However, Cinder is leaner, meaner, and faster. And I've been coding in C++ for so long that I can just code in it -- unlike Java where I'm still occasionally looking up the syntax for something relatively basic or I'm doing something illegal since hey, you can do whatever I'm trying in C++... plus, its pretty easy to incorporate outside libraries.  I looked at OpenFrameworks for a little, too, but it looks messier to me....