Need help with using binary arithmetic to get pixel color

cocos2d for iPhone » Programming » cocos2d support (graphics engine)

Need help with using binary arithmetic to get pixel color

(10 posts) (6 voices)

Started 2 years ago by jonathan0382
Latest reply from hvilela

Tags:

jonathan0382
Member

Hi all, hope you're all well.

I have a question concerning using binary arithmetic to get pixel color. I have seen Ernesto's code on pixel collisions and have found it to be very useful. I can successfully implement it to check the alpha at a pixel using the following:

if (pixels[j] & 0xff000000){ do something } //note pixels is const UInt32

I understand (unless I'm mistaken) that what the above does is take the HEX code of the pixel and use binary arithmetic to multiply it by 0xff000000. This is basically a mask to extract the alpha, right? If there is any color then the alpha must be greater than 1 and so the value returned by the binary arithmetic will be 1, and so the if statement is satisfied.

So the above is all good, but now I want to take it a step further and use similar arithmetic to get the rgb value of the pixel. Is there a similar mask (similar to & 0xff000000) to do this?

Thanks,

Jonathan0382

Posted 2 years ago #
Codemattic
Moderator

"use binary arithmetic to multiply it"
not multiply, bitwise "and":

http://en.wikipedia.org/wiki/Bitwise_operation#AND

"Is there a similar mask (similar to & 0xff000000)"

0x00ffffff

Posted 2 years ago #
jonathan0382
Member

Thanks Codemattic for clearing up bitwise "and" instead of multiplying. The link you posted makes a lot of sense.

From my tests the mask 0x00ffffff returns 255 is the alpha is > 0. Is there a way of using these masks to get the rgb value? Suppose I have a red color with red at 255, green at 0, and blue at 0. Is there a mask to return this value? I think I'm possibly misunderstanding the hex values. Yeah, I'm just fkin confused now!

Thanks for the help.

jonathan0382

Posted 2 years ago #

CJ
Moderator

This should help...
I put these in ccTypes.h

static inline ccColor4B
ccc4FromUInt(const uint bytes)
{
	GLubyte r	= bytes >> 24 & 0xFF;
	GLubyte g	= bytes >> 16 & 0xFF;
	GLubyte b	= bytes >> 8 & 0xFF;
	GLubyte a	= bytes & 0xFF;

	return ccc4(r, g, b, a);
}

static inline uint
uintFromCCC4(const ccColor4B ccColor)
{
	return (ccColor.r << 24 | ccColor.g << 16 | ccColor.b << 8 | ccColor.a);
}

static inline ccColor3B
ccc3FromUInt(const uint bytes)
{
	GLubyte r	= bytes >> 16 & 0xFF;
	GLubyte g	= bytes >> 8 & 0xFF;
	GLubyte b	= bytes & 0xFF;

	return ccc3(r, g, b);
}

static inline uint
uintFromCCC3(const ccColor3B ccColor)
{
	return (ccColor.r << 16 | ccColor.g << 8 | ccColor.b);
}

Feel free to use this code w/o restriction. And Riq, if you see this feel free to add these to Cocos as well.

Posted 2 years ago #

Lam
Member
Since color for that pixel can come in a variety of bit formats we have to make sure Ernesto at least declared his format type.

I'm not sure how much you know about bit operations so don't be angry if I explain the basics first.

We know the maximum storage is a 32-bits since he uses an int (uint32 actually).
So that's why the mask looks like 0xff000000 because one hex digit is 4 bits so we have 8 digits to represent the total 32-bits.

It looks like Ernesto wants a byte per color and the opacity. A byte is an 8-bit hex so you can have values from [0,1,2,3..255] or if written in hex [0x00, 0x01,0x02,..0xff].

Wait a minute...

[No really! You should wait exactly 1 full minute before reading below]

Hey that's exactly like ccColor4B!

We know how to use ccColor4B. Let's hack at that a while to understand these bits.
```
// full opacity
ccColor4B c = {0,0,0,255};

// We can do this all in one statement but let's make it less confusing.
// we cast the color to uint32 and use some print flags to print hex in NSLog.
uint32_t *ptrToColor = (uint32_t*)(&c);
NSLog(@"%08x",*ptrToColor);

Output for 255 opacity: ff000000
Output for 128 opacity: 80000000
Output for 1 opacity  : 01000000
```
This is great the value for alpha is right where Ernesto said the mask should capture the value.

Let's check out red.
```
Output for 255 r: 000000ff
Output for 128 r: 00000080
Output for 1 r  : 00000001
```
Awesome.. so red seems to also be in the end of the mask

Hmm... now green
```
Output for 255 g: 0000ff00
Output for 128 g: 00008000
Output for 1 g  : 00000100
```
I think it's starting to make sense. I'm going to assume blue is right before green since it's the last sport left :).

But the next question is "why is it reversed"?
Well it's about endianness of the byte and our machine is little endian.
http://en.wikipedia.org/wiki/Endianness

So I want to grab out the color value huh...
So let's say i have green at full opacity and want that color value (should be 255).

We mask it yeah! (hope you understood all the info above to use the right mask).
but we get....65280!
That's over 255!
I can't store that into a byte!

Well now what?...
There must be some way to move the bits residing in the green mask 0x0000ff00 to the range [0..255] (which is 0x000000ff).

I'll leave that for a later question since this post is getting too long.

I think that's it. Well I hope this cleared up at least something for you or at the very least it enabled you to dig further and understand bit operations more.

I was dealing with all these headaches too when I created my set/get pixel operations on textures. I posted about it at:
http://www.cocos2d-iphone.org/forum/topic/2449
Posted 2 years ago #
jonathan0382
Member

@Lam: thank you for the excellent introduction to bit operations. Before yesterday I knew next to nothing about it at all, so I appreciate you taking the time to explain it. I still don't understand it completely, but I know enough to get what I want up and running, which is something. Thanks.

@CJ: thanks for the methods. I used parts of what you wrote and basically ended up with this:

if (pixels[j] & 0xff000000){//if alpha then check the red, green, blue of the color. //0 if no color (transparent)
GLubyte r = pixels[j] & 0xFF;
GLubyte g = pixels[j] >> 8 & 0xFF;
GLubyte b = pixels[j] >> 16 & 0xFF;
GLubyte a = pixels[j] >> 24 & 0xFF;

//NSLog(@"rgba is %i, %i, %i, %i", r,g,b,a);

if(r==255 && b==0 && g==0)collisionMap[j] = 1;
and so on for different colors
}

At runtime I just look up the value given by the color and take the appropriate action.

Thanks all!

Jonathan0382

Posted 2 years ago #
jonathan0382
Member

Here is something interesting:

GLubyte r = pixels[j] & 0xFF;
GLubyte g = pixels[j] >> 8 & 0xFF;
GLubyte b = pixels[j] >> 16 & 0xFF;
GLubyte a = pixels[j] >> 24 & 0xFF;

works for the simulator, but I found that when I test on a device I need to switch the red and blue to this:

GLubyte b = pixels[j] & 0xFF;
GLubyte g = pixels[j] >> 8 & 0xFF;
GLubyte r = pixels[j] >> 16 & 0xFF;
GLubyte a = pixels[j] >> 24 & 0xFF;

Anyone have any idea why? Also, does anyone know how to make the compiler check for the target device/simulator in an if statement and then compile different code depending upon this if statement?

Posted 2 years ago #
Lam
Member
That's the gotcha about endianness of the architecture.

I'm still trying to figure that one out for my MutableTexture2D =/

What's going on is that the simulator runs on a little-endian architecture (Intel).
The device runs on a mixed-endian/middle-endian architecture (arm) from the looks of the byte swapping.

I've been digging around in hopes of a portable way to deal with all this endianness craziness and I've found out CFSwap functions that can help with these problems but I haven't used them yet =/

Oh and if you're looking for a target checking then it's

TARGET_IPHONE_SIMULATOR
```
#if TARGET_IPHONE_SIMULATOR
// Simulator stuff
#endif
```
Posted 2 years ago #
Steve Oldmeadow
Administrator

@jonathan0382 - your bgr problem could be something to do with the fact that bgr is the native format for iPhone video memory, see here: http://iphonedevelopment.blogspot.com/2008/10/iphone-optimized-pngs.html

Posted 2 years ago #
hvilela
Member

I know this post is really old, but the @CJ functions should be part of the Cocos core, don't you think?

Posted 1 year ago #

RSS feed for this topic

Reply

You must log in to post.