• 13
• 16
• 19
• 27
• 9

# RGB to hex

This topic is 2343 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I got a function which colors pixels but it either needs a single int or a hex value to do so. I've managed to get my values in to a string so I just need to read that string correctly. If all the values are 255 my string would look like "FFFFFF" but I need to send this to my coloring function as 0xFFFFFF.

There is another way I think but I'm not sure if this would work and that would be to interpret the string as hex and return the value as int but I dont know how to do this either.

##### Share on other sites

I got a function which colors pixels but it either needs a single int or a hex value to do so. I've managed to get my values in to a string so I just need to read that string correctly. If all the values are 255 my string would look like "FFFFFF" but I need to send this to my coloring function as 0xFFFFFF.

There is another way I think but I'm not sure if this would work and that would be to interpret the string as hex and return the value as int but I dont know how to do this either.

For something performance critical like real time rendering(which is what i assume your doing), you likely don't want to be using strings in this way. Why not work with ints to begin with?

##### Share on other sites
You shouldn't use strings for this because the performance will be atrocious at best, like Burnt_Fyr said, and there is a much simpler way too. You have a function that accepts an int. You didn't give details but most probably the int is implicitly split in 4 8-bit fields that each represent the value of one color component (one byte may be unused or used for the alpha (transparency) component). What you want to do is take 3 8-bit values one for each Red Green and Blue and pack them together in the int right? This can be done using simple boolean operations.

For example see what the following C code does:

 int r, g, b; r = 0; g = 255; b = 140; int packed = 0; packed = packed | ((b << 0) & 0x000000FF) | ((g << 8) & 0x0000FF00) | ((r << 16) & 0x00FF0000); 

Now we have an int with the following format: 00000000rrrrrrrrggggggggbbbbbbbb, which can be passed to the function you mentioned.

Of course b << 0 is reduntant but I wanted to make the pattern clear.

This could also be achieved using unions or bitfields in C and C++ but my personal preference would be the first way, because I don't want to even bother trying to find possible undefined behaviour/portability issues with bitfields/unions, and it is an one-liner anyways.

##### Share on other sites

You shouldn't want to use strings for this because the performance will be atrocious at best, like Burnt_Fyr said, and there is a much simpler way too. You have a function that accepts an int. You didn't give details but most probably the int is implicitly split in 4 8-bit fields that each represent the value of one color component (one byte may be unused or used for the alpha (transparency) component). What you want to do is take 3 8-bit values one for each Red Green and Blue and pack them together in the int right? This can be done using simple boolean operations.

For example see what the following C code does:

 int r, g, b; r = 0; g = 255; b = 140; int packed = 0; packed = packed | ((b << 0) & 0xFFFFFF00) | ((g << 8) & 0xFFFF00FF) | ((r << 16) & 0xFF00FFFFF); 

Now we have an int with the following format: 00000000rrrrrrrrggggggggbbbbbbbb, which can be passed to the function you mentioned.

Why do you do "packed |"? packed is already 0, so why put it there at all? And shouldn't all your 0s be Fs and all your Fs be 0s (excluding all the 0xs which stay 0xs)?

Right now you have essentially this:

 packed = 0 | ((0x8c << 0) & 0xFFFFFF00) | ((0xff << 8) & 0xFFFF00FF) | ((0x00 << 16) & 0xFF00FFFFF); or packed = 0 | (0x8c & 0xFFFFFF00 | (0xFF00 & 0xFFFF00FF) | (0x0 & 0xFF00FFFFFF); or packed = 0 | (0 | 0 | 0); 

edit: though what you said was the right idea, so I plus 1ed you anyway.

Definitely agree that you don't want to pass this as a string. Even if it's not performance intensive you don't want to pass it as a string unless it's being stored as a string just because it's kind of a bad habit.

double edit: oops you corrected it :-p