bit manipulation..newbie doubt

[vaneric001]

hi
i came across a post by another member about packing r,g,b values
(ints) into a single value as follows

int packedvalue=(255 << 24) | ((r & 0xff) << 16)|((g & 0xff) << 8)|(b
& 0xff);

so that a pixel with (155,147,145) will make -6581359

what is the need for the & 0xff ? coz even without that the result is
same.I am not very familiar with the bit manipulation methods..but a
reply post mentioned that the top 8 bits are set to 1 for making
transparency .can anyone explain this in easier terms?
(the orig post was here http://groups.google.co.in/group/comp.unix.programmer/browse_thread/thread/90562b7a3af79ec1)


thanks
eric

 

[Walter Roberson]

i came across a post by another member about packing r,g,b values
(ints) into a single value as follows

int packedvalue=(255 << 24) | ((r & 0xff) << 16)|((g & 0xff) << 8)|(b
& 0xff);

You seem to have missed the dialog pointing out that you should use
long instead of int.

so that a pixel with (155,147,145) will make -6581359

what is the need for the & 0xff

There is no -C- need for the 0xff -- any need for it depends
upon the application. The person who posted that code did not
even know why they were putting in the 0xff.

? coz even without that the result is
same.I am not very familiar with the bit manipulation methods..but a
reply post mentioned that the top 8 bits are set to 1 for making
transparency .can anyone explain this in easier terms?
(the orig post was here http://groups.google.co.in/group/comp.unix.programmer/browse_thread/thread/90562b7a3af79ec1)

Transparency is not a C matter: it is a graphics matter. So
the rest of this is OT for comp.lang.c:

[OT]

If you look further back in that thread you will find several
references to ARGB, not just RGB. ARGB is (Alpha, Red, Green, Blue).
Alpha is the transparency information. Scale the Alpha field to get a
value between 0 and 1. Then, if you are painting this new pixel of
color (R,G,B0 on top of an existing pixel of color (r,g,b), then you
"mix" the new color with the old color, with low alpha indicating that
you want mostly the old color in the mix (making the new object quite
transparent) and with high alpha indicating that you want mostly the
new color in the mix (making the new object mostly opaque). The
blending formula used (remember alpha is 0 to 1) is:

((1-alpha) * r + alpha * R,
(1-alpha) * b + alpha * B,
(1-alpha) * g + alpha * G)

Thus, if you happen to be sending your data to an ARGB painting
system and you have left the top bits in the ARGB as 0
(because you have put only RGB information there with the rest 0)
then the extracted alpha of 0 would indicate that the new pixel is
to be completely transparent, showing only the underlying pixel --
so the new image would not show up at all.

If you happen to be sending your data to an ARGB painting system
and you have set the top bits in the ARGB as 0xff, then the
extracted alpha of 255 would scale to 1 and would thus indicate
that the new pixel is to be completely opaque, showing only the
new pixel and none of the underlying pixel -- which is probably
what was expected.

If you happen to be sending your data to an RGB painting sytem
instead of an ARGB painting system then it does not matter what
you put into those top bits.

Hence, if you do not know whether you are working with an ARGB
system or an RGB system, it is safer to put 0xff into the top bits:
doing so will make the image show up in the ARGB system where it
wouldn't have otherwise, and nothing will be hurt if it turns
out that the system is RGB rather than ARGB.

 

[vaneric001]

thanks a lot Walter..that teaches me a lot
eric

 

[Army1987]

You seem to have missed the dialog pointing out that you should use
long instead of int.

If he needs four channels (alpha, red, green, blue) with 8 bits each,
unsigned long would be even a better idea.

 

[vippstar]

If he needs four channels (alpha, red, green, blue) with 8 bits each,
unsigned long would be even a better idea.

Or C99, <stdint.h> and uint32_t

 

[Ben Bacarisse]

Or C99, <stdint.h> and uint32_t

unsigned long is more portable. If you use stdint.h types,
int_least32_t and uint_fast32_t have the advantage of being required
to exit!

 

[Keith Thompson]

unsigned long is more portable. If you use stdint.h types,
int_least32_t and uint_fast32_t have the advantage of being required
to exit!

No, exit() still takes an argument of type int. int_least32_t and
uint_fast32_t are, however, required to *exist*.

}

 

[MisterE]

You seem to have missed the dialog pointing out that you should use
long instead of int.

Is this implementation dependant, or does long have to be 32bit by C
definition and int can be smaller?

 

[CBFalconer]

Is this implementation dependant, or does long have to be 32bit
by C definition and int can be smaller?

long has to be at least 32 bit. int and short have to be at least
16 bit. char has to be at least 8 bit. long long (C99) has to be
at least 64 bit. See the header file <limits.h> and the C
standard.

 

[Walter Roberson]

You seem to have missed the dialog pointing out that you should use
long instead of int.

[/QUOTE]

Is this implementation dependant, or does long have to be 32bit by C
definition and int can be smaller?

long must be *at least* 32 bits in C;
int must be *at least* 16 bits in C.