|
[DPRG] EmbedCV
Subject: [DPRG] EmbedCV
From: Clem Taylor
clem.taylor at gmail.com
Date: Tue Oct 17 21:23:54 CDT 2006
> > So you can write
> > Image< uint16_t, 320, 240 > anImg;
> > Image< float, 320, 240 > anotherImg;
>
> My experience is that for embedded stuff people are often willing to
> make a compromise and stick to one particular representation.
>
> So, as long as you use an appropriate type (lets call it Pixel_t or
> Number_t) then you could still make a choice about the type of number
> to be used, but you'd have to use the same type for all of the
> images/algorithims.
Dave, I'm not so sure that statement applies to image processing.
Often, you really can't just can't afford to do everything in some
basic type. Most of the time you can, but in some places you need
extra precision.
For example, in the stuff I'm doing at work, we have images with:
binary images (bit packed only used as intermediate results)
binary images (stored in 1 byte/pixel)
8 bit unsigned pixels
16 bit signed pixels
16 bit unsigned pixels (rare because of hardware issues with the
DSP we are using)
32 bit signed pixels (typically S15Q16 fixed point)
We compile two different versions of the code, one for sensors with 8
bit pixels and one for sensors with 16 bit pixels and we pick which
firmware to run on the sensor used.
How well the typical DSP C compiler will vectorize will depend
entirely on data types used. For example on the chip I'm using right
now, it has a bunch of instructions to operate on packed 16 bit signed
data, but it doesn't have the same hardware for operating on packed 16
bit unsigned data [why the hardware designers wouldn't make this type
of stuff symmetric is beyond me]. Pick the wrong type (unsigned vs
signed) and the code will run >2x slower. Ouch!
> And of course, there are the inevitable games that can be played with
> the preprocessor... Not for the faint of heart, but still useful
> enough to get some performance out where it counts.
This is what we do. We have a bunch of types for different pixel types
that are selected at compile time. As long as the types are chosen
correctly, the compiler hides all the details. However this falls
apart when you start using compiler intrinsics (thing C-like wrappers
for hardware instructions that compile down to a single instruction).
In the places were we use intrinsics we basically have to implement
multiple versions of the code that gets sorted out at compile time (or
at run time in a few cases).
--Clem
More information about the DPRG mailing list
|
