|
[DPRG] EmbedCV
Subject: [DPRG] EmbedCV
From: Dave Hylands
dhylands at gmail.com
Date: Tue Oct 17 21:32:48 CDT 2006
Hi Clem,
> 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)
OK - I guess I took it too far. Having a set of types that could be
picked at compile time would also be fine.
> 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).
Linux does this quite a bit. They'll do stuff using inline functions
that looks highly inefficient (with things like switch statements
based on word size), but the optimizer boils it all down to just the
single case and eliminates all of the code that couldn't possibly be
executed.
--
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/
More information about the DPRG mailing list
|
