Bit shift help.

[hyn]

I'm trying to extract the alpha value from a 32 bit Number, like this:

var a:Number = ((c & 0xFF000000) >> 24);
where c = 0xEEDDEEEE for example.

trace("a: " + a.toString(16)); // -12

Obviously I expect a to be FF, but its -12 in hex!

How can I get a to be the correct alpha value?

The strange thing is that this works:

var r1:Number= ((c & 0x00FF0000) >> 16);
trace("r1: " + r1.toString(16)); // DD


Thanks

[sigman]

You should expect actually EE as a result.

If your ARGB color is 0xEEDDEEEE then alpha is EE (first two values and others are DD - red, EE - green and EE - blue).

What you want to do is to first shift bits to the right (>>24) so you will get 0xFFFFFFEE and then mask with 0x000000FF to get only alpha value.

Anyways, after shifting I was also getting negative 12 but the final result after masking is as expectedk. I also noticed that if I use uint instead of Number - then I get correct value shown after shifting.

Below is the code:

var argb_value:Number = 0xEEDDEEEE;
trace("ARGB value : " + argb_value.toString(16));

var mask_value:Number = 0x000000FF;
trace("mask  : " + mask_value.toString(16));
trace("----------------------");

argb_value = argb_value >> 24;
trace("ARGB value after shifting : " + argb_value.toString(16));
argb_value = (mask_value & argb_value);

trace("after masking = alpha channel : " + argb_value.toString(16));

and here is traced result:

ARGB value : eeddeeee
mask : ff
----------------------
ARGB value after shifting : -12
after masking = alpha channel : ee

When using uints instead of numbers I'm getting:

ARGB value : eeddeeee
mask : ff
----------------------
ARGB value after shifting : ffffffee
after masking = alpha channel : ee

Can't find explenation on why -12 is being traced when using Number after shifting. Is it because value is being shifted out of range?

[lordofduct]

you're problem is that alpha is in the top 8 bits. The leading bit of which represents the 'sign' of an int...

take:

0xFF000000

in binary is:

11111111 00000000 0000000 00000000

that first 1 there says it's a negative int... this is why ARGB is a uint, so that it isn't considered negative

There are two different 'right shifts'

>> - right shift

>>> - unsigned right shift

the second of which ignores the sign and just shifts...




next, we don't need to mask Alpha if we do unsigned right shift, because 0's get padded in...

the result is:

function extractAlpha( value:uint ):uint
{
    return value >>> 24;
}

I'm going to write a BitHelper class right now... for your consideration here is 5 basic functions for colours:

package com.lordofduct.util
{
    public class BitHelper
    {
        public function BitHelper()
        {
        }
        
        /**
         * ARGB Colour Helpers
         */
        static public function colorsToARGB( r:int, g:int, b:int, alpha:int=0xFF ):uint
        {
            return (alpha << 24) | ((r & 0xFF) << 16) | ((g & 0xFF) << 8) | (b & 0xFF);
        }
        
        static public function extractAlpha( value:uint ):uint
        {
            return value >>> 24;
        }
        
        static public function extractRed( value:uint ):uint
        {
            return (value >> 16) & 0xFF;
        }
        
        static public function extractGreen( value:uint ):uint
        {
            return (value >> 8) & 0xFF;
        }
        
        static public function extractBlue( value:uint ):uint
        {
            return value & 0xFF;
        }
        
        
    }
}

[bowljoman]

Hey awesome! Maybe you could do a Mac /windows format switcher function too.

This is what Im using in c++.

THe operation is to switch the 32-bit integers and the rotate the results so that the colors are correct and the top is up.

flashIn->GetSandy(buffer5);  
        
        
        RGBQUAD * data=(RGBQUAD*)buffer5;
        RGBQUAD  b;
        for (int kk=0;kk<320*240;kk++)
        {
            b.rgbReserved=(BYTE)(data->rgbBlue);
            b.rgbRed=(BYTE)data->rgbGreen;
            b.rgbGreen=(BYTE)data->rgbRed;
            b.rgbBlue=(BYTE)data->rgbReserved;
            *data=b;
            data++;
            
        }
        
        data-=CSAMP/4;
//Rotates image to top-up      
adc->Translate(Source5,(char*)data);

[lordofduct]

mac -> windows format switcher?

I'm sorry, but I rarely if ever use Mac so I don't know much about the OS (I do use Solaris and Linux which are also Unix like, but what you're referencing isn't familiar to me).

Got a link or something?

[bowljoman]

When sharing byte arrays between Big endian and little endian based computer systems using external networking/ frameworks.

[lordofduct]

Originally Posted by bowljoman

When sharing byte arrays between Big endian and little endian based computer systems using external networking/ frameworks.

Something like this:

function rotateBytes( value:uint ):uint
{
    return ((value & 0xFF) << 24) | (((value >> 8) & 0xFF) << 16) | (((value >> 16) & 0xFF) << 8) | (value >>> 24);
}

basically breaks a 4 byte word into 4 and rotates the bytes around.


Here's some of the things I thought useful:

http://code.google.com/p/lodgamebox/...NumberUtils.as

[sigman]

Thanks for your reply Lordofduct. Hovewer I don't understand one thing in terms of bit shifting...

Originally Posted by lordofduct

>> - right shift

>>> - unsigned right shift

I noticed that if you have 32 bit value with leading bit "1", let say:
11101110 11011101 11101110 11101110

and I use bit shifting by eight >>8
I get:
11111111 11101110 11011101 11101110 (traced using uint(variable).toString(2))

but when using unsigned bit shifting >>>8
I get:
00000000 11101110 11011101 11101110

I would rather expect:
100000000 in leading byte when using >>. Why is 1 being duplicated with every bit shift?

[bowljoman]

When you shift the bits , something needs to fill the empty spots, since the computer still has to read the entire variable.

an regular integer (not the 27 bit version in as3) is 32 bits. Shift them to the right, and somthing need to fill the slots at the left.

>> uses 1's

>>> uses 0's

<< always uses 0's to fill in the bit slots from the right.

[lordofduct]

>> - is signed (as in positive or negative) right bit shift
>>> - is unsigned (ignores positive or negatie) right bit shift

let look at an int as stored in memory. For the sake of ease I'm going to use an 8 bit int instead of a 32 bit integer (easier to read)


this is the values 0 -> 10:
0000 0000
0000 0001
0000 0010
0000 0011
0000 0100
0000 0101
0000 0110
0000 0111
0000 1000
0000 1001
0000 1010

now let's look at these as negative -1 -> -11
1111 1111
1111 1110
1111 1101
1111 1100
1111 1011
1111 1010
1111 1001
1111 1000
1111 0111
1111 0110
1111 0101

now all negative values have a high leading bit of 1... meaning it's negative. The values count backwards from uint.MAX_VALUE down to int.MAX_VALUE and represent negative values... and quite nicely this method causes the 0's and 1's to look as if they swapped jobs!

notice that I did 0->10 and -1->-11. I did this for a reason... if you consider 0 in the positive range (because it's high leading bit is 0), it is in the 0 index slot. But what would be the first negative value then? -1... because it's in the 0 index slot.

Actually the NOT of 0 is -1

the NOT of any positive value equals the -(+value + 1)


Anyways, let's take some value... I'm going to use +15

0000 1111

now let's >> 1 at a time and see the results

0000 1111 == 15
0000 0111 == 7
0000 0011 == 3
0000 0001 == 1
0000 0000 == 0

now let's take -16 and do the same

why -16? Because the NOT of 15 is -16

0000 1111 == 15
1111 0000 == -16

so:

1111 0000 == -16
1111 1000 == -8
1111 1100 == -4
1111 1110 == -2
1111 1111 == -1


now they act similar. >> pays attention to the sign... shift along with it... and the valuees adjust in the same pattern no matter the sign.

We essentially pad with what ever sign it is at that moment.

Imagine if it didn't:

1111 0000 == -16
1011 1000 == -72
1001 1100 == -100
1000 1110 == -114
1000 0111 == -121
1000 0011 == -125
1000 0001 == -127
1000 0000 == -128


and there that's how the sign fits together...




then >>> is unsigned... it just always pads with zeros.


So to clarify what bowlojomon said:

>> - pads with 1 or 0, if negative or positive respectively
>>> - pads with 0 no matter what







...

@Bowljomon - the 'int' type is 32-bit in AS3.

int.MAX_VALUE is 2147483647, which is (2^31) - 1, which means 31 bits of significant value... which leaves 1 bit for sign padding.

The integer when put encoded to be passsed via AMF may be different (I'm not sure what there is there). But the actual internal int is 32-bit.