Extracting color from 32-bit pixel...

So... I started programming again. Been almost two years since I've
done anything. Went back to the project I was working on before I
quit and totally forgot where I was... so I started over.

Anywho, I came across some functions that extract the Red, Green,
and Blue bytes from a 32-bit pixel, but don't understand *why* I did
what I did. Here's the function.

Code:

---

unsigned char Pixel32_ExtractR(unsigned int pixel)
{
    return ((pixel >> 16) & 0xFF);
}

---

Thing is,I don't know why the & 0xFF is necessary. I know what & does,
but why did I do it here? Do I even need it? Wouldn't shifting the bits
alone be enough? Please explain why not, detailed.

Damnit, starting over blows. I don't remember *anything*. Hehe.

Thank ya,

ethic

Let's say you've got four bytes. Each byte in this case is 8 bits. You want the third one. You shift half way over, and now you have 2 bytes left. You only want one. If you do this:

Code:

---

return allthebytes >> 16;

---

You're returning 2 bytes. That's not what you want. So, you mask off the one byte that you want, and return that.

Code:

---

return ((allthebytes >> 16) & 0xFF);

---

Quzah.

Quote:

---

You're returning 2 bytes.

---

Last I checked an unsigned char is only 1 byte...

So it is. I suppose I should've paid attention to the return type. ;)


Quzah.

So in other words, in this example it's probably not really needed, but is almost more of something put in by habit.

I believe possibly endianness could affect this too, no? I don't know my endians well enough however to justifiably have a solid opinion on that.

Quote:

---

Originally Posted by jverkoey

I believe possibly endianness could affect this too, no? I don't know my endians well enough however to justifiably have a solid opinion on that.

---

Endianness is a effect of storage. Values don't have endianness. So if you are shifting a value, you need not worry about endianness.

If you would be examining one byte of a multibyte integer by its memory location, then you have introduced an endianness issue into the problem.

Other interesting descriptions.

Why return an unsigned char instead of just "int"? Also, bitmap data can probably also be declared "int", since any math performed would usually be done on the extracted bytes. I use these macros instead of functions (for when the pixel format is fixed, and won't change):

Code:

---

#define makecol(b, g, r)        (b | (g << 8) | (r << 16))
#define makecola(b, g, r, a)        (b | (g << 8) | (r << 16) | (a << 24))

#define getr(c)                ((c & 0x000000FF))
#define getg(c)                ((c & 0x0000FF00) >> 8)
#define getb(c)                ((c & 0x00FF0000) >> 16)
#define geta(c)                ((c & 0xFF000000) >> 24)

---