[Insight-developers] Re: [Insight-users] "Look-up-table" suggestion

[Peter Cech]

On Mon, Jun 26, 2006 at 13:44:16 +0000, Martin Kavec wrote:
> Hi,
> 
> I am implementing a filter in which I need to perform  e^( pixelintensity). In 
> the present implementation this is the major performance bottleneck (80%). I 
> thought to generate a look-up-table of e^(x) function using a 
> std::vector<...>, resized to cover the whole dynamic range of a PixelType. 
> However, I am hitting a ceiling with this approach since this would be very 
> memory-intensive solution for PixelType > 32 bits. 
> 
> Opinions, on what wold be the most sensible approach in generating the LUT and 
> keeping the filter templated over the PixelType, would be appreciated.

Here are my (a bit random) thoughts on the subject:

Direct LUT makes sense for smaller data types (signed/unsigned char and
short), with int you can use exp(a+b) = exp(a)*exp(b) and use two LUTs,
one for lower 16 bits and one for upper 16 bits. With floating point
numbers, it is possible to do some tricks by splitting mantissa and
exponent, but for that you need to know exactly the representation of
float/double values in memory. Not very portable and a bit complicated,
so calling exp() function might be actually faster.

I would use simple array instead of std::vector as no resizing is needed.

Putting such LUT into standalone class can be a good idea, there might
be other filter using it in the future.

I would invoke LUT generation into filter's constructor - it is likely
it will be used and if filter is rerun, it will save the LUT
initialization compared to generating LUT at the GenerateData stage.

Speed in 2D case: with small images with short or int PixelType, LUT
approach will be actually slower and "small" depends on CPU type, but
without benchmarks its hard to tell whether we need to be concerned
about that.

That's about it for the time being.

Regards,
Peter