Converting RGB to 16-bit color - speed question

Started by
1 comment, last by Russell 22 years, 5 months ago
Currently, I am using a macro to convert the three RGB values into a 16-bit color value. I was thinking, would it be faster to compute a 3-demensional array of the 16-bit color values, indexed by the RGB values? Example: // Current method color = rgb(red, blue, green); // Proposed method color = rgb[red][blue][green]; And if this would be faster, would it be worth using up half a MB of memory?
Advertisement
Half a megabyte?

Assuming your source red, green and blue each have a range of 0-255, that''s:

256 * 256 * 256 = 16777216

Also I assume the data type of the array will be 16bits wide, so that''s:

16777216 * 2 (16bits==2bytes) = 33554432.

33554432bytes / 1024 = 32768Kilobytes

32768Kb / 1024 = 32Megabytes...



If the memory usage didn''t kill you, the cache misses certainly would. Memory runs much slower than the CPU clock speed - on modern CPUs doing things which don''t require access to memory is preferable (unless they take more cycles than an access to memory+the cost of cache misses).

Assuming the macro is just doing shifts and masking, then it''ll be better than the look up table.


--
Simon O''''Connor
Creative Asylum Ltd
www.creative-asylum.com

Simon O'Connor | Technical Director (Newcastle) Lockwood Publishing | LinkedIn | Personal site

It be better just to calculate it.

inline unsigned short rgb(unsigned char r, unsigned char g, unsigned char b)
{
static unsigned short Ret,tg,tb;
Ret=(r>>3);
tg=(g>>2);
tb=(b>>3);
Ret+=(tg)+(tb);
return Ret;
}

That should/would/could be a way to do it. Obviously, there''s more than one way to write this, and probably much more efficient ways (think inline assembly), but this would be much better than having a 256*256*256*2 array!!!

Billy

BillyB@mrsnj.com <-> If you''ve got any questions.

This topic is closed to new replies.

Advertisement