ARGB to red green and blue
BlitzMax Forums/BlitzMax Programming/ARGB to red green and blue
| ||
| How on earth does this work? I've tried loads of variations with bitshifting and masks and it always produces either 0 or 255. Can anyone give me a simple example that reads a pixel from an image and returns the red,green, blue and alpha components from the argb value? thanks James |
| ||
| alpha = argb & $FF000000 red = argb & $00FF000000 green = argb &0000FF00 blue = argb &$000000FF |
| ||
| To get values 0-255 alpha=(argb shr 24) & $FF red=(argb shr 16) & $FF green=(argb shr 8) & $FF blue=argb & $FF |
| ||
| OK now that we are on this topic, I've always been too imbarrassed to ask this question... Can you go a little further and tell me how those formulae work. Regards, Eric |
| ||
| It shifts the bits to right with the given amount of steps. A 32bit color is an int. Its size is 4bytes. Every byte represents the information for 1 color (8 bits normally) to get the value of every color, you have either to shift it or straight bitfilter it instead of doing 2 operations for 1 job. (in Blitz3D it was needed to do shr etc as you didn't have real hex to straight bitfilter it) |
| ||
| ? & in Max is different to bitwise and in B3D? Can you explain the difference a bit more. |
| ||
| thanks - Falken's solution works, but I couldn't get Dreamora's solution to work. |
| ||
| and is only logical operator in blitzmax while & is bitwise operator. Vorderman: sorry had an 00 too much in the red line. This one should work: alpha = argb & $FF000000 red = argb & $00FF0000 green = argb &0000FF00 blue = argb &$000000FF ( the shr does nothing else than that. It just shifts the stuff to right to "kill" the 0s ... so it is an operation that is not needed if you know the exact bit length ) |
| ||
Hmm, nope that still doesn't work - I get numbers like this -x:44,z:55 r:6553600 g:25600 b:100 a:-16777216 x:45,z:55 r:3407872 g:13312 b:52 a:-16777216 x:46,z:55 r:589824 g:2304 b:9 a:-16777216 the bitshifting solution does work though, producing this - x:44,z:55 r:100 g:100 b:100 a:255 x:45,z:55 r:52 g:52 b:52 a:255 x:46,z:55 r:9 g:9 b:9 a:255 It's reading from a greyscale image, so r,g and b should all be the same, and I've checked pixels in the image and they match these numbers. So, there must be some difference in the way the bitshift works, or in the way the bitmask is applied. |
| ||
| So, there must be some difference in the way the bitshift works, or in the way the bitmask is applied. No. It's doing the same thing. Observe:Value 255,255,255,255 in Hex: $FFFFFFFF What Dreamora does is filter out the information he doesn't need. However he does not shift (binary division) the results to give "human friendly" numbers (Least Significant Byte position). You can do this by shifting later. Hex: $FFFFFFFF AND: $00FF0000 ' < Filtering out the red component. SHL: $000000FF ' < Making the red component "least significant byte". What Falken does is generally considered slightly more elegant. He starts by shifting to the value he wants to the LSB, and then eliminates unwanted data (everything that isn't the LSB, since he only wants a byte value returned). Hex: $FFFFFFFF SHL: $0000FFFF ' < Making the red component "LSB". AND: $000000FF ' < Filtering out the red component. |
   |