Dark Bit Factory & Gravity
PROGRAMMING => C / C++ /C# => Topic started by: va!n on January 09, 2015
-
What is the best way to handle an image in memory for image processing (filters, effects, drawing)?
Storing the image just in 1D array or would it be better to store it in a 2D array? However, is it
better to read each color R,G,B,A as byte for a 32bit image or to read it just as long and using shifts
to manipulate each color?
At the moment i am working on a test project, where the image is stored in a 1D buffer.
void DrawGreyscale()
{
temp = bitsDib / 8;
int i;
BYTE r, g, b, y;
for (i = 0; i < cxDib * cyDib * temp; i+=temp) {
b = bitmap2[i ]; // Blue
g = bitmap2[i + 1]; // Green
r = bitmap2[i + 2]; // Red
y = (r + g + b) / 3;
bitmap[i] = y;
bitmap[i + 1] = y;
bitmap[i + 2] = y;
}
}
Any improvment ideas for easy and fast image processing (clean code/handling)?
An 1D array gives nice speed improvments for using filters/effects on the complete image, because only
one loop is required. But when wanting to manipulate a special x,y position in the 1D array, a lot of
extra muls, divs, mods are required and may slow down operations a lot.
How does Photoshop stores imagedatas internally? 1D, 2D? Thanks for feeedback.
-
What is the best way to handle an image in memory for image processing
Nobody knows what's the "best way" to solve your specific problem because you didn't tell what your specific problem is.
Are you looking for speed or code size? And on what platform?
Storing the image just in 1D array or would it be better to store it in a 2D array?
Simply arrange your data in the same way as you're going to access it.
If your data is not going to fit into the cache (or even memory), it makes sense to process it in smaller blocks.
If you want to make use of simd, make sure to start each block properly aligned.
If you want to make use of multicore, make sure a cacheline doesn't cover two blocks.
is it better to read each color R,G,B,A as byte for a 32bit image or to read it just as long and using shifts to manipulate each color?
Depends very much on your sepcific architecture.
for (i = 0; i < cxDib * cyDib * temp; i+=temp) {
Can the compiler make sure that cxDib, cyDib & temp never change (how) ?
If not it will do two muls for every run of the loop.
y = (r + g + b) / 3;
Division is still slow in 2015.
An 1D array gives nice speed improvments [...] because only one loop is required.
No. The second loops costs 1 add & 1 jump per scanline (and probably a mispredicted branch). That's completely neglectable unless your actual filter code isn't totally trivial.
to manipulate a special x,y position in the 1D array, a lot of extra muls, divs, mods are required
So that doesn't make any sense, right? :)
-
to manipulate a special x,y position in the 1D array, a lot of extra muls, divs, mods are required
pointers are your friend :)
<edit i wrote a suggestion and it was a lot of poo :D..so i have revised it, probably multicore is as good as it gets for a speedup after everything is as optimized as much as possible. you can easily split a buffer into number of cpu core segments and render too these all at the same time... with good code comes good cpu core scalability too, only downside is that with each core you decide to use you have too duplicate all your variables too give that core its own set,... or problems will happen.
-
y = r*0.2989 + g*0.5870 + b*0.1140
hi, this is not faster but more correct.