10/25/2008 14:07 by buza ()
I’ve been thinking a lot about software tools these days. As E15 continues to mature, and we start to consider it for installations, our OS X reliance has to be re-considered because of cost. The general trend in many open source projects, of course, is to be cross platform. At this point, I’m not particularly convinced that being strictly cross platform is the best approach. However, I’m definitely keeping it in mind as future E15 features get implemented and existing functionality upgraded. The determination of which features can remain cross platform and which ones should be platform specific is still in progress.
I’m currently working on a system that requires some simple realtime blob tracking from a webcam. The tracking results will be sent to E15 instances and iPhones. The easiest way to do simple blob tracking with the appropriate amount of programmatic flexibility is to use OpenCV, which doesn’t yet have a particularly stable home on OS X. As mentioned in my blog, my task was to find out how to use the most appropriate OS X technologies (in this case, CoreVideo) to grab the video, and then pass those pixels straight on into OpenCV. It turns out that a number of people have been trying to figure out how to do this, apparently without success. After getting the application to work, I was surprised to find that the performance was 7x faster than the cross platform approach using OpenFrameworks, a collection of utilities for making C++ programming more accessible to artists. In a sense, I see this as one example of what I call the cross platform tax, which exists because cross platform approaches tend to leverage only the most common set of functionality, which cuts down on implementation complexity and development time. The result is that the platform-specific and more cutting edge performance benefits offered by new OS features are lost. When I think about these kinds of tradeoffs, VVVV (Windows-only) comes to mind as a demonstration of the benefits of platform reliance.
October 25th, 2008 at 16:47
is it slow in frame rate or in cpu usage? in the blog you link to, you mention cpu usage, and what I wanted to mention is that since OF uses glut, it runs as fast as possible. that means that cpu usage is high, even if it is doing nothing. The better gauge of how slow or fast an operation is, is framerate, and I suspect there two might not be so different.
anyway I vote for cross-platformness, but understand your point.
take care!
zach
October 25th, 2008 at 19:21
Zach,
You bring up a good point, which underlies the two different approaches we’re discussing. On the OF side, its main focus is to provide a “one stop shop”, of sorts, for all of these types of tasks to reside. So, whereas I’m looking for a streamlined and elegant approach for a single task — grabbing the blob regions so that I may pass those results on to another application that may be perfectly suited and optimized for the next task, the OF model expects users to build everything they wish to do within the same general framework.
The OF approach also explains why my fan turns on nearly instantly when I run the OF version, which, as you point out, is built around the traditional graphics model of the single render loop, called as fast as possible, even though it may not have anything useful to do. The frames will be taken from the camera at the same (camera-dependent) rate in both applications.
The CoreVideo approach allows me to work with the pixels from the camera provided directly from the OS,
avoiding the additional performance hit due to the per-pixel transformations that OF needs to do for every video frame.