LIBCVD: http://mi.eng.cam.ac.uk/~er258/cvd/ Have you considered LIBCVD as an alternative to OpenCV? It is highly optimized for frame-rate real-time applications but also has a nice, succinct, simple (almost pythonic) syntax. For example, Image<float> img = img_load("lena.png") Image<float> out(img.size()); convolveGaussian(img, out, 3.0); loads an image from a file and convolves a Gaussian with it. LIBCVD's design is very simple: there are only three main classes and its interface is designed to be very functional so it translates from Python very nicely. Most of its dependencies are optional so it compiles very easily. You don't have to use pointers very much in LIBCVD, which eliminates many kinds of bugs--iteration is done with highly optimized and succinct iterators and index operators (e.g. image[y][x]). Best of all, it's very fast. Damian PS: I'm cc'ing Edward Rosten who's the author of LIBCVD. 2009/9/25 Stéfan van der Walt <stefan@sun.ac.za>:

Hi Mike

2009/9/25 Mike Sarahan <msarahan@gmail.com>:

...

Sorry if I missed this in discussions at the sprint, but is there any reason we're not taking advantage of OpenCV?  It may be a little more than what this scikit is aiming to offer, but it has some really nice, well-optimized routines.  It's BSD licensed.  I have been using the ctypes-opencv python wrapper, which is also BSD licensed.

I know there are two sets of wrappers, but I haven't used either.  Do you know their pros and cons?

OpenCV is a fairly heavy dependency, but if it adds good value I see little reason to avoid it.

Regards Stéfan

-- ----------------------------------------------------- Damian Eads Ph.D. Candidate University of California Computer Science 1156 High Street Machine Learning Lab, E2-489 Santa Cruz, CA 95064 http://www.soe.ucsc.edu/~eads

I actually started work on an OpenCV wrapper using Cython a couple of months ago. I got about 25% complete but then got busy with other things. I was real carefully about releasing the GIL whenever possible to make multi-core usage a reality. In some basic tests, the performance was on par with using opencv from pure C (more or less). I have since been wanting to get back to working on the wrapper, but I've been toying with the idea of instead of just wrapping the OpenCV array type and providing functions to convert to and from numpy arrays, to use a numpy array as the base data type (perhaps through subclassing or a hidden attribute; i havent yet decided) and dynamically creating/updating OpenCV array headers that point to the numpy data. I think this approach would be more natural and pythonic (at a small cost for speed). It would also eleminate the need to wrap the entire opencv library as simple manipulations can just be done with numpy or scipy.ndimage I have some free time now again, and I could ramp back up my work on this or perhaps merge the work into this project if the devs show interest. You can take a look at the current code here: http://code.google.com/p/cython-opencv/ Cheers! Chris On Sep 25, 11:21 am, Stéfan van der Walt <ste...@sun.ac.za> wrote:

2009/9/25 Damian Eads <e...@soe.ucsc.edu>:

...

Have you considered LIBCVD as an alternative to OpenCV? It is highly optimized for frame-rate real-time applications but also has a nice, succinct, simple (almost pythonic) syntax.

What is the feature scope of CVD compared to OpenCV?

Stéfan