|
[DPRG] EmbedCV
Subject: [DPRG] EmbedCV
From: Chris Jang
cjang at ix.netcom.com
Date: Mon Oct 16 03:39:20 CDT 2006
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
More information about the DPRG mailing list
|
