|
[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
|
