ZoneMinder Forums

Hello,

I'm a little perplexed by the following code snipped found in zm_image.cpp. During initialization, abs_table is created on the heap with 6*255+1 entries, where each entry is one unsigned byte. However, while building the table attempts are made to cast and integer with a range of [0, 3*255] into the 8 bit space.

void Image::Initialise()
{
.
.
abs_table = new unsigned char[(6*255)+1];
abs_table += (3*255);
.
.
for ( int i = -(3*255); i <= (3*255); i++ )
{
abs_table = abs(i);
}


I only find three places in the code where the table is implemented:

1) when colours is equal to one:
unsigned char *pdiff, *psrc, *pref;
*pdiff++ = abs_table[*psrc++ - *pref++];

2) when config.y_image_deltas is true:
register int red, green, blue;
red = y_r_table[*psrc++ - *pref++];
green = y_g_table[*psrc++ - *pref++];
blue = y_b_table[*psrc++ - *pref++];
*pdiff++ = abs_table[red + green + blue];

3) and when config.y_image is false:

red = abs_table[*psrc++ - *pref++];
green = abs_table[*psrc++ - *pref++];
blue = abs_table[*psrc++ - *pref++];

*pdiff++ = (JSAMPLE)((red + green + blue)/3);

In all cases, the range of abs_table is -255 to 255, and not -3*255 to 3*255. Is this an oversight? (I suspect that originally in the architecture, the pref stored an RGB 24 bit value).

-W

The idea of the abs table is to be able to do abs_table[value] to get its absolute value. e.g. int ab = abs_table[-40]; will store 40 into integer variable ab.

I have a much faster solution to this and other performance killers in ZM. I don't want to reveal details yet, but stay tuned

mastertheknife.