12

How do I convert a RGB colour value to just plain decimal?

So I have: RGB(255,255,255) is white
Its decimal equivalent is: 16777215

I have tried thinking it might just be:

var dec = r*g*b; // but this doesn't work

Although that doesn't work.

Anyone know of the algorithm/equation to convert from RGB (or rgba) to decimal?

sazr
  • 24,984
  • 66
  • 194
  • 362
  • 3
    16,777,215 is the decimal equivalent of the hex version, 0x00FFFFFF, of your RGB(255,255,255). – Chris O Dec 12 '11 at 01:07
  • What do you plan to do with these values? To what software/functions/etc are you given them? – Nicol Bolas Dec 12 '11 at 01:29
  • I have colour values from a flash application, which are in decimal & I need to display them in html/css & also convert back visa-versa. – sazr Dec 12 '11 at 01:37

6 Answers6

20

RGB integers are typically treated as three distinct bytes where the left-most (highest-order) byte is red, the middle byte is green and the right-most (lowest-order) byte is blue. You can retrieve the values of these individual bytes like this:

var c = 0xff03c0; // 16712640
var components = {
    r: (c & 0xff0000) >> 16, 
    g: (c & 0x00ff00) >> 8, 
    b: (c & 0x0000ff)
};

You can re-create a color from its components by shifting the bytes back in:

c = (components.r << 16) + (components.g << 8) + (components.b);

In your case, simply substitute components.r (etc) with your actual variables.

Wayne
  • 59,728
  • 15
  • 131
  • 126
12

A much better answer (in terms of clarity) is this:

'Convert RGB to LONG:
 LONG = B * 65536 + G * 256 + R

'Convert LONG to RGB:
 B = LONG \ 65536
 G = (LONG - B * 65536) \ 256
 R = LONG - B * 65536 - G * 256

LONG is your long integer (decimal) that you want to make. Easy huh? Sure, bitshift

Sam Brown
  • 129
  • 1
  • 2
  • 1
    @DanielA.White may not think so, but I cannot see how any other answer to this question is half as clear as this one. Even I can I understand this. – John Bingham Jul 15 '16 at 04:55
  • 1
    This only appears easier to someone who doesn't know bit manipulation in the same way that a bad answer in English appears to be better than a good answer in French to somebody who doesn't read French. Learn bit manipulation and you learn the generalizable principles that make my answer much clearer in the long run. – Wayne Mar 14 '19 at 15:50
  • 1
    actually its: LONG = R * 65536 + G * 256 + B (you mixed up B and R) see https://www.rapidtables.com/web/color/RGB_Color.html – vorwerg-ni Nov 26 '20 at 11:14
3
if (color.substr(0, 1) === '#') {
    return color;
}
var digits = /(.*?)rgb\((\d+), (\d+), (\d+)\)/.exec(color);
var red = parseInt(digits[2]);
var green = parseInt(digits[3]);
var blue = parseInt(digits[4]);
var rgb = blue | (green << 8) | (red << 16);
return rgb.toString(10);
3

I agree that bitshift is clearer and probably better performance.

That said, if you want a math answer due to language support (such as doing this in a spreadsheet) modulus % and trunc() or floor() make it simple:

Assuming 8 bit values for red green and blue of course (0-255):

var rgbTotal = red * 65536 + green * 256 + blue;

var R = Math.trunc( rgbTotal / 65536 );
var G = Math.trunc( ( rgbTotal % 65536 ) / 256 );
var B = rgbTotal % 256;

Discussion: Pointing to sam's answer, RGB values are nearly always big endian in terms of order, certainly on webpages, jpeg, and png. Personally I think it's best to multiply red by 65536 instead of blue, unless you're working with a library that requires it otherwise.

To return to separate values:

  • For R, just divide by 65536 and truncate the remainder.
  • For G, we discard R via mod 65536 then dividing by 256, truncating the remainder (remainder is blue).
  • For B, we take mod 256, which disposes of the two higher bytes.

For R & G the number needs to be truncated to discard the remainder, language specific, mainly we want the integer. In javascript Math.trunc() is the easy way, and Math.floor() also works. It's not needed for B as that IS the remainder from the modulus — however this also assumes that we don't need error checking such as from user input, i.e. the value for B is always an integer 0-255.

Myndex
  • 3,952
  • 1
  • 9
  • 24
2
var dec = (b & 0xff) << 16 + (g & 0xff) << 8 + (r & 0xff);

(I think that's the correct order for the r,g,b values)

Update

I just checked for browser applications and I got the order wrong, so the correct formula for browsers (read HTML+CSS+javascript) is:

var dec = r << 16 + g << 16 + b;

Assuming r,g,b values <= 255

Other API's may expect a different order for the r,g,b values. I seem to remember at least one that has the order reversed (per my original answer), but I think which one it is at the moment.

Andrew Cooper
  • 32,176
  • 5
  • 81
  • 116
  • You may well be right about the order, in which case, my answer is wrong :( – Martin James Dec 12 '11 at 01:17
  • The correct order in terms of what? For who? The order depends on who's *reading* the value. – Nicol Bolas Dec 12 '11 at 01:28
  • @Nicol - No, the correct order depends on the API. I'm not sure about the Win32 API, but for browser based applications (which I assume is being addressed here) I'm pretty sure that Blue is the high-order byte (of the three) and Red is the low-order byte. – Andrew Cooper Dec 12 '11 at 01:37
  • seem to be getting the wrong colours, are you sure thats the right order? – sazr Dec 12 '11 at 01:37
  • If those variables just hold individual color components, then there's really no point to the bit-masks. – Wayne Dec 12 '11 at 01:39
  • @Jake - Not 100%, no. Try swapping `r` and `b`. – Andrew Cooper Dec 12 '11 at 01:40
  • @lwburk - True. The bit-masks are there for safety in case the individual variables contain values > 255 for some reason. You could also do `max(r, 255)` if you want to clip the value rather than mask it (which may be more appropriate for some applications). – Andrew Cooper Dec 12 '11 at 01:43
  • @AndrewCooper - Right, because if they do contain values greater than 255, then the mask is going to create effects that were almost certainly un-expected/wanted. It should probably just be treated as an error in that case. – Wayne Dec 12 '11 at 01:46
  • @Martin James - Nope. Your answer is correct. See my update. – Andrew Cooper Dec 12 '11 at 01:53
  • Your updated answer is incorrect - should be `g << 8`. – Nick Grealy Oct 24 '22 at 23:12
0

You need to left-shift the R by 16, the G left by 8 and or both in to the B. Look at the values as bits and all will become clear:

R 255 = 11111111B G 255 = 11111111B B 255 = 11111111B

Shift R 16: 111111110000000000000000 Shift G 8: 000000001111111100000000

or into B: 111111111111111111111111

Convert to decimal: 16777215

Martin James
  • 24,453
  • 3
  • 36
  • 60