DPRG mailing list archives: [DPRG] EmbedCV

Mon Oct 16 21:25:44 CDT 2006

Chris,

The answers to the question are as varied as the spanning set, so I'll
answer in a self-ish way.  I would really like to see integer optimized code
vs FP.  I would also really like to see code in vanilla 'C' rather than C++.
In the embedded systems I've been working on of late, one can of course
build and run C++ but the overhead of the constructors / destructors just
kills you.  Sure one can code around that, just seems easier not to...  As
for multiple DSPs I do not know anyone running multiple DSPs on an amateur
robot.   Multiple processors, yes, but not multiple DSPs....

-Kenneth

-----Original Message-----
From: dprglist-bounces at dprg.org [mailto:dprglist-bounces at dprg.org]On
Behalf Of Chris Jang
Sent: Monday, October 16, 2006 3:39 AM
To: dprglist at dprg.org
Subject: [DPRG] EmbedCV

Hello Everyone,

My background is as a software and math person, so electronics is a weak
point. Many of the people on the DPRG email list have either a background
in electronics design engineering or deep experience in this area. I have
some questions about C/C++ targeting DSPs and the practicalities involved.

I'm writing an open source C++ template library for computer vision. It is
named EmbedCV as in "Embedded Computer Vision". It's not rocket science
stuff but captures the basics in an efficient implementation.

Why write yet another library for image processing? I think that EmbedCV
does address a different set of requirements than typical image processing
and computer vision libraries.

1. floating point neutrality - can do everything with unsigned integers
    PRO: good for CPUs with crippled floating point or DSPs
    CON: accuracy can suffer

2. highly templatized - allow compiler to optimize as much as possible
    PRO: fast, especially with loop unrolling
    CON: less flexible for programming, a little harder to use

3. trades accuracy for speed - designed for low-end computers
    PRO: runs faster
    CON: less accurate

4. simple - only implement filters practical for low-end computers
    PRO: keeps it simple, not overwhelmed by huge API
    CON: none really, if computer is not fast enough for more

Most libraries I've seen have exactly the opposite requirements. They are
designed to a minimum system of the workstation with commensurate
tradeoffs - extensive coverage of image processing algorithms and a
flexible API. They are not so suitable for the limited computational
performance of a deeply embedded computer vision system in a small robot.

Does a highly templatized C++ library makes sense for DSPs? Or should it
be a C library? C++ is preferable for the higher abstraction level without
sacrificing performance. But perhaps C++ compilers for DSPs are uneven or
unavailable? Also, C++ is pretty much standard for performance oriented
software systems (large search engines, computer games). But maybe it is
not so standard for DSPs? I've spent my entire career as a C++ guy so am
biased towards it.

Perhaps floating point in hardware is now ubiquitous? So optimization for
integer arithmetic is superfluous and backwards looking?

Also, what are the practicalities of multi-core DSPs? Are these in common
use? If so, then does that imply multi-threadable library implementation
to balance across the cores? Or does a compiler do this work for you? I
have no experience in this area.

Thanks for any feedback on this.

As the library is developing, it should be a good fit for slow Pentium
class SBCs. My robot uses SBCs with 266 MHz Geode CPUs. I think the DPRG
tankbot uses a 1 GHz C3 mini-ITX mainboard. There must be some ARM based
robots out there. It will be nice to use processor architecture specific
optimization such as Pentium/MMX too. But that is not in scope right now.

Chris
_______________________________________________
DPRGlist mailing list
DPRGlist at dprg.org
http://list.dprg.org/mailman/listinfo/dprglist