Optimize c++ bitmap processing algorithm [closed] - c++

Question

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
I have written the next algorithm (for Android/NDK) to apply levels to a bitmap. The problem is that is really very slow, on a fast device such as the SGSIII can take up to 4 seconds for a 8MP image. And on devices with ARMv6 takes ages (over 10 seconds). Is there any way to optimize it?
void applyLevels(unsigned int *rgb, const unsigned int width, const unsigned int height, const float exposure, const float brightness, const float contrast, const float saturation)
{
float R, G, B;
unsigned int pixelIndex = 0;
float exposureFactor = powf(2.0f, exposure);
float brightnessFactor = brightness / 10.0f;
float contrastFactor = contrast > 0.0f ? contrast : 0.0f;
for (int y = 0; y < height; y++)
{
for (int x = 0; x < width; x++)
{
const int pixelValue = buffer[pixelIndex];
R = ((pixelValue & 0xff0000) >> 16) / 255.0f;
G = ((pixelValue & 0xff00) >> 8) / 255.0f;
B = (pixelValue & 0xff) / 255.0f;
// Clamp values
R = R > 1.0f ? 1.0f : R < 0.0f ? 0.0f : R;
G = G > 1.0f ? 1.0f : G < 0.0f ? 0.0f : G;
B = B > 1.0f ? 1.0f : B < 0.0f ? 0.0f : B;
// Exposure
R *= exposureFactor;
G *= exposureFactor;
B *= exposureFactor;
// Contrast
R = (((R - 0.5f) * contrastFactor) + 0.5f);
G = (((G - 0.5f) * contrastFactor) + 0.5f);
B = (((B - 0.5f) * contrastFactor) + 0.5f);
// Saturation
float gray = (R * 0.3f) + (G * 0.59f) + (B * 0.11f);
R = gray * (1.0f - saturation) + R * saturation;
G = gray * (1.0f - saturation) + G * saturation;
B = gray * (1.0f - saturation) + B * saturation;
// Brightness
R += brightnessFactor;
G += brightnessFactor;
B += brightnessFactor;
// Clamp values
R = R > 1.0f ? 1.0f : R < 0.0f ? 0.0f : R;
G = G > 1.0f ? 1.0f : G < 0.0f ? 0.0f : G;
B = B > 1.0f ? 1.0f : B < 0.0f ? 0.0f : B;
// Store new pixel value
R *= 255.0f;
G *= 255.0f;
B *= 255.0f;
buffer[pixelIndex] = ((int)R << 16) | ((int)G << 8) | (int)B;
pixelIndex++;
}
}
}

Answer 1

Most of your computations can be trivially tabled... the whole processing can become
for (int i=0; i<n; i++) {
int px = buffer[i];
int r = tab1[(px >> 16) & 255];
int g = tab1[(px >> 8) & 255];
int b = tab1[px & 255];
gray = (kr*r + kg*g + kb*b) >> 16;
grayval = tsat1[gray];
r = brtab[tsat2[r] + grayval];
g = brtab[tsat2[g] + grayval];
b = brtab[tsat2[b] + grayval];
buffer[i] = (r << 16) | (g << 16) | b;
}
where
tab1 is a table of 256 bytes tabling the result of exposure and constrast processing
tsat1 and tsat2 are 256 bytes tables for saturation processing
brtab is a 512-bytes table for brightness processing
Note that without saturation processing you would need just a lookup per component in a 256 bytes table.
A huge speed problem can be because you are using floating-point computations where there is no dedicated hardware for it. Software implementation of floating point is really slow.

Answer 2

You're reducing your fast int based RGB values to slower floats and then using a lot of floating point multiplication for your adjustments. Better to multiply your adjustments (brightness, saturation etc...) by 256 and store them as ints, and don't use any floating point in your inner loop.

Answer 3

(1.0f - saturation) is the same everywhere, therefore you can just assign it to a variable.
Instead of >> 16) / 255.0f and >> 8) / 255.0f you can convert them to single multiplications. Or, you can divide them by 256 instead of 255 with >> 10 and >> 8 respectively:
R = ((pixelValue & 0xff0000) >> 10);
G = ((pixelValue & 0xff00) >> 2);

Answer 4

Several point to optimize that code
Favor integer computation, that mean that instead of transforming your RGB data from [0, 255] to [0, 1] do the inverse and transform all your contrast, brightness etc to be between 0 and 255
clipping operation can often be simplify with a clipping table to remove if-else statement .
R = clip[R'];
I notice a strange clipping section
// Clamp values
R = R > 255.0f ? 255.0f : R < 0.0f ? 0.0f : R;
G = G > 255.0f ? 255.0f : G < 0.0f ? 0.0f : G;
B = B > 255.0f ? 255.0f : B < 0.0f ? 0.0f : B;
here it look like your are still in [0, 1] range so it useless !
at the end review your formula because it seems that exposure and brightness can be fact prize to remove some op.
Finally that code is a good candidate for SIMD and MIMD, so look if MMX/SSE or OpenMP can solve your performance issue.