DPRG
DPRG List  



[DPRG] request for comments about EmbedCV direction

Subject: [DPRG] request for comments about EmbedCV direction
From: Chris Jang cjang at ix.netcom.com
Date: Mon Nov 6 03:38:58 CST 2006

Hello,

There is a code drop of the computer vision library I am writing at:

http://golem5.org/embedcv/download/embedcv-0.1.zip

It is still small so now is a good time to solicit feedback. The last 
time, everyone told me to write a C library. This opinion was unanimous. 
So...I dropped C++ (my first love!) and went over to C. I guess I'm trying 
to say that I do listen! Thanks for the advice, it was very helpful. C is 
more appropriate and natural for this kind of work.

Note that I do not consider EmbedCV ready at this time. It is a snapshot 
(although it does build and the sample code works). However, a deal of 
care has gone into it so far. And it is under active development. I need 
this library for my robot.

Right now, the four features I plan for EmbedCV are:

1. histogram based image segmentation (most of the core stuff is there)
2. rectified stereo vision (haven't started yet)
3. floating point free, only integer arithmetic (yes, no floating point)
4. MMX acceleration (haven't started yet)

The reason for these four features is that they should work well with my 
robot. I think they are also more useful generally. Image segmentation is 
linear time and fast. Stereo vision is slow but outputs a depth map which 
has clear physical interpretation. I know that stereo, without fast 
hardware, is not real time. But I think it can be useful for periodic 
"stop and stare" strategies even on small robots.

Transform and feature based approaches are interesting and where most of 
the sexy research is. But these techniques also tend to be computationally 
expensive. However, I'm open to anything that works (and I guess until you 
try, you don't know one way or the other).

If you are interested in this library then I invite you to take a look. 
Right now, my toolchain is entirely GNU/Linux using GCC. I've tried to 
avoid platform dependencies or cross toolchain unfriendliness. But 
ultimately, testing is the only way to know for sure. It would be nice to 
know what platforms and toolchains people are using.

Also, don't get the wrong idea. I'm not an expert at this. I'm not a DSP 
or old fixed point game programmer who has years of experience in image 
processing. I never studied signal processing or computer science in 
school. I'm learning as I go. So if you see something that could be made 
faster or more efficient, please let me know.

Chris

More information about the DPRG mailing list