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/com...562b7a3af79ec1)


thanks
eric

In article <a26a07e6-ab31-400f-934a-816e31243314@e10g2000prf.googlegroups.com>,
<vaneric001@gmail.com> wrote:

>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/com...562b7a3af79ec1)

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.
--
"Is there any thing whereof it may be said, See, this is new? It hath
been already of old time, which was before us." -- Ecclesiastes

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

Walter Roberson wrote:

> In article <a26a07e6-ab31-400f-934a-816e31243314@e10g2000prf.googlegroups.com>,
> <vaneric001@gmail.com> wrote:
>
>>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.
If he needs four channels (alpha, red, green, blue) with 8 bits each,
unsigned long would be even a better idea.

--
Army1987 (Replace "NOSPAM" with "email")

On Feb 2, 5:00 pm, Army1987 <army1...@NOSPAM.it> wrote:
> Walter Roberson wrote:
> > In article <a26a07e6-ab31-400f-934a-816e31243...@e10g2000prf.googlegroups.com>,
> > <vaneric...@gmail.com> wrote:
>
> >>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.
>
> 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

vippstar@gmail.com writes:

> On Feb 2, 5:00 pm, Army1987 <army1...@NOSPAM.it> wrote:
>> Walter Roberson wrote:
>> > In article <a26a07e6-ab31-400f-934a-816e31243...@e10g2000prf.googlegroups.com>,
>> > <vaneric...@gmail.com> wrote:
>>
>> >>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.
>>
>> 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

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!

--
Ben.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> vippstar@gmail.com writes:
>> On Feb 2, 5:00 pm, Army1987 <army1...@NOSPAM.it> wrote:
[...]
>>> 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
>
> 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*.

8-)}

--
Keith Thompson (The_Other_Keith) <kst-u@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

> 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?