RGB separation

specci48

Well-Known Member
Licensed User
Longtime User
Hi bdiscount,

since there is no build-in feature for that, you have to do this manually with an own sub. You can use something like this:
B4X:
Sub Globals
   red = 0
   green = 0
   black = 0   
End Sub

Sub App_Start
   ...
   Color2RGB(bitmap1.GetPixel1(w,h))
   ...      
End Sub

Sub Color2RGB(color)
   colorNum = color + 16777216
   red = Int(colorNum / 65536)      
   green = Int((colorNum - red * 65536) / 256)   
   black = colorNum - red * 65536 - green * 256
End Sub

specci48
 

Cableguy

Expert
Licensed User
Longtime User
Just a minor rectification...
It's Red, Green, Blue (not Black)
 

willisgt

Active Member
Licensed User
Explain, please...

Specci, what purpose does this serve:

B4X:
colorNum = color + 16777216


Gary
 

Cableguy

Expert
Licensed User
Longtime User
Hi bdiscount,


Color2RGB(bitmap1.GetPixel1(w,h))

This calls the Clor2RGB sub passing the pixel(x,y) color value

Sub Color2RGB(color)
colorNum = color + 16777216
red = Int(colorNum / 65536)
green = Int((colorNum - red * 65536) / 256)
black = colorNum - red * 65536 - green * 256
End Sub[/CODE]

Color2RGB takes the color value obtained from the pixel and converts it to an RGB value....

In the desktop, RGB has an extra value (chanel) Alpha (opacity), so it becomes ARGB... The 16777216 I'm gessing is to workaround this issue, asuming the full opacity value...
 

specci48

Well-Known Member
Licensed User
Longtime User
:signOops:

... translation error ... keep the blue and cancel the black ... ;)

Specci, what purpose does this serve:

B4X:
colorNum = color + 16777216

This changes the original (negative) value into a positive format. If you code this

B4X:
a = Rgb(0,0,0)
b = Rgb(255,255,255)
a gets the value -16777216 and b gets the value -1.


specci48
 

bdiscount

Active Member
Licensed User
specci
your formula doesn't give me the correct rgb
I have a grey r=192 g = 192 b = 192

when I get pixel I get 3749946 on the device (only place I work.) 3749946/65536 =57.219 (red)
3749946 + 16777216 = 20527162 / 65536 = 313.219(red)

Have got it wrong?
 

agraham

Expert
Licensed User
Longtime User
Have got it wrong?
Have you missed a minus sign?

-3749946 gives R=198, G=199, B=198, which could be a correct approximation for R=192, G=192, B=192 as your device probably only supports something like 64K colours rather than the full 8bits on each colour.
 
Last edited:

bdiscount

Active Member
Licensed User
I'm using a Dell Axim X51v. I placed color rects on form with known RGB and the numbers I get i put thru you formula. I did see the ques you posted and forgot but now I will pick them using that info. Thanks for your help.
:sign0060:
 

DavidN

Member
Licensed User
You can always inspect the bits of the returned color value to validate what you should be getting. In basic4ppc the returned color value is of type DECIMAL, which is 32-bits. Which is 4 bytes. I took a look at the values in the bytes and deduced that 3 of the bytes corresponded to the R, G, and B color values respectively. The fourth byte was discarded; it probably corresponds to the Alpha value used on the desktop (but not the mobile device). A function to extract the RGB color values could be written using bit operations to shift and mask the relavant bits, but you's need to use the bitwise object library. Or you could just do some math as suggested in the previous posts. Depending on how the compiler optimizes the code, the bitwise approach may be faster. Or not. At some point I'll code it up and benchmark it. However, Erel may introduce a getRGBcolor function in a future version of basic4ppc, that I'd use.
 

bdiscount

Active Member
Licensed User
I have converted number to hex and got bytes the first =FF which means it negative the remaining 3 bytes tell me the same as specci results.
I hope the RGB sub comes out soon. I am tring to save a portion of a image on the form ie: x,y,wide,high,save/open

I will keep trying.
 

agraham

Expert
Licensed User
Longtime User
I have converted number to hex and got bytes the first =FF which means it negative the remaining 3 bytes tell me the same as specci results.
That first byte is a fourth value, Alpha, that on the desktop represents transparency. The value you have is actually 255 meaning totally opaque. Zero would be totally transparent. It only appears negative because a colour value is actually four 8 bits values (0 to 255) packed into a 32 bit integer and Alpha occupies the sign bit at the top of the number.
 
Top