|
[DPRG] EmbedCV
Subject: [DPRG] EmbedCV
From: Chris Jang
cjang at ix.netcom.com
Date: Tue Oct 17 19:33:05 CDT 2006
Hello Everyone,
Many thanks to all who have provided feedback about EmbedCV. I'll try to
summarize everything just as Dave has in his email. I apologize for not
replying directly to everyone.
> If you're serious about targeting the embedded platform, then I would
> give serious consideration to dropping C++, or adding it as a wrapper
> layer. I've always been a string proponant for C++, but it has a few
> downsides.
Yes, EmbedCV will be a C library for three reasons, in order of
importance.
1. Market acceptance - it is what people want to use
2. C++ usually does not optimize as well as C
3. No conceptual need for higher level data and algorithm abstractions
Today, I tried compiling, linking, stripping some simple code with an
inlined function call and nested for loop in both languages. The test
platforms were a Sun UltraSPARC 3 v440 server with cc/CC and a Via C3
mini-ITX PC with gcc/g++.
On Solaris, cc and CC generated identical assembly code. On Linux, g++ and
gcc were very different - full loop unrolling with C but not with C++. For
both Solaris and GNU/Linux, C++ binaries were somewhat larger and stack
usage greater. So on a purely objective performance level - yes, C wins.
For large systems (several million LOCs), the higher level abstractions
are a good trade against performance due to very high complexity. But in a
deeply embedded and memory constrained system, performance matters more
and systems are smaller.
> My first comment is pro-C++. Most of the performance issues relate to
> exception handling, and have nothing to do with constructors (unless
> they're misused).
Before C++ was standardized, I believe there was a philosophical
disagreement over exception handling and RTTI overhead. The ANSI/ISO
standard now mandates exceptions so everything runs a few percent slower.
But every compiler I have encountered allows disabling exceptions.
However, the system and third party libraries may require exceptions. So
yes, in practice you are stuck.
The two main issues with C++ that I see are about portability and
maintainability rather than performance.
1. No link compatibility, uneven translation between compiler versions
2. The language confuses people
Number one is bad. It means that upgrading the compiler often forces
upgrades to libraries at the same time. Number two is also bad and one of
the major reasons why most of the software market shifted to Java.
> My real "issue" with C++ is how crappy the run-time libraries are. I'm
> using a gumstix running linux, and turning on C++ pulls in a 500K
> library. I am especially disgusted by stuff like cout << 1; winding up
> calling sprintf( "%d", 1 ) internally.
I know ... and how technology exists in practice matters most if you are
trying to get something to work. Languages and APIs do not specify how
they are to be implemented.
> I'm also in favor of fixed-point math, or as Clem points out, a
> mixture where fxed point is used in the performance sensitive stuff.
This is one of those areas where C++ templates are so nice.
template <typename PIXEL, size_t WIDTH, size_t HEIGHT>
class Image
{
std::vector< PIXEL > _pixels;
...etc...
So you can write
Image< uint16_t, 320, 240 > anImg;
or
Image< float, 320, 240 > anotherImg;
The entire library is neutral to floating or fixed point yet still has
type safety with compile time optimization. You can do neat stuff like
templatized functions with parameterized convolution kernel size so that
loop unrolling can occur. It's like having C macros except with type
safety.
template <size_t RADIUS,
typename PIXEL, size_t WIDTH, size_t HEIGHT,
typename OTHERPIXEL>
void corner (Image< PIXEL, WIDTH, HEIGHT >& destImage,
const Image< OTHERPIXEL, WIDTH, HEIGHT >& gradX,
const Image< OTHERPIXEL, WIDTH, HEIGHT >& gradY)
So you can write
corner< 3 >(anImg, anImgSobelX, anImgSobelY);
for a 3 x 3 box window or
corner< 5 >(anImg, anImgSobelX, anImgSobelY);
for a 5 x 5.
There is flexibility yet all loop extents are known at compile time and so
amenable to optimization. However, from the little experimentation done
today, my confidence in C++ compiler optimization is shaken.
> If you feel tempted to optimize anything using assembler, make sure
> that you also have a C version of the algorithim so people who have a
> different processor can at least get started using the C version and
> then hand-optimize as needed.
Don't worry about that. I have to get it working first. It would be very
nice to have processor architecture specific optimization (e.g. x86 MMX).
But that's later.
About my robot, there are four things I have in mind for computer vision.
1. image segmentation - easy, I know this works in chroma/luma
2. other histogram based techniques such as edge orientation - not tried
3. line detection for roads - uh oh, Hough transform may be too expensive
4. keypoint detection and correlation for object tracking - expensive
This is somewhat ambitious. And I can't say what will work and what will
not. I still do not have an autonomous driving robot. Unfortunately, my
experience is that I am unable to predict what works and does not until
I've tried doing it. A lot of computer vision seems to be this way?
I was playing with corner detection using Foerstner's operator last
Thursday.
http://golem5.org/robot1/images/corner20061012.png
The red is the luminance image. The cyan dots are corners. I know, they
are not very stable - I'm not sure how this will turn out.
I'd like to be able to walk around and have my robot "follow me". So if it
can lock onto a person in front of it and then approach, that would be
great. It would make for a cute demo. I saw Asimo at SMU in 2004. One of
the demos shown on video was Asimo following people.
Chris
More information about the DPRG mailing list
|
