Skip to content

Instantly share code, notes, and snippets.

@jed
Forked from 140bytes/LICENSE.txt
Created May 20, 2011 18:54
Show Gist options
  • Star 11 You must be signed in to star a gist
  • Fork 5 You must be signed in to fork a gist
  • Save jed/983535 to your computer and use it in GitHub Desktop.
Save jed/983535 to your computer and use it in GitHub Desktop.
convert RGB to HEX
function(
a, // red, as a number from 0 to 255
b, // green, as a number from 0 to 255
c // blue, as a number from 0 to 255
){
return "#" + // return a number sign, and
( // combine the octets into a 32-bit integer as: [1][a][b][c]
( // operator precedence is (+) > (<<) > (|)
256 // [1][0]
+ a // [1][a]
<< 8 // [1][a][0]
| b // [1][a][b]
)
<< 8 // [1][a][b][0]
| c // [1][a][b][c]
)
.toString(16) // then serialize to a hex string, and
.slice(1) // remove the 1 to get the number with 0s intact.
}
function(a,b,c){return"#"+((256+a<<8|b)<<8|c).toString(16).slice(1)}
DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE
Version 2, December 2004
Copyright (C) 2011 Jed Schmidt <http://jed.is>
Everyone is permitted to copy and distribute verbatim or modified
copies of this license document, and changing it is allowed as long
as the name is changed.
DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. You just DO WHAT THE FUCK YOU WANT TO.
{
"name": "rgb2hex",
"description": "Converts RGB colors to a hexadecimal string.",
"keywords": [
"color",
"css",
"hex",
"rgb"
]
}
@mathiasbynens
Copy link

16777216 could be shortened to 1<<24.

@jed
Copy link
Author

jed commented May 21, 2011

also, i checked MDC again, and since << is higher than | we can get rid of a bunch of parens.

@atesgoral
Copy link

You can shave one byte by reorganizing the octet combination as:

function(a,b,c){return"#"+((256+a<<8|b)<<8|c).toString(16).slice(1)}

@mathiasbynens
Copy link

@jed: Re: your comment on checking MDC for operator precedence – when in doubt, you could always use @qfox’s online ES Parser tool: http://esparser.qfox.nl/

@jed
Copy link
Author

jed commented Jun 3, 2011

@atesgoral: wow, done. the original is much more readable, unfortunately... would you mind taking a crack at the annotation?

@mathiasbynens: i still haven't been able to grok that tool fully. @qfox is really insane: his last quiz made me feel like a total JS n00b.

@mathiasbynens
Copy link

i still haven't been able to grok that tool fully.

Me neither, but if you just enter e.g. a<<16+1<<24 and hit the “Parse” button, it immediately becomes clear which operators take precedence.

Under “Pruning” you can also enable “flatten parse tree (replace nodes with single child by that child)”, which really helps if you’re just testing for precedence.

Here’s a live example: http://esparser.qfox.nl/#runnow:on,no-single-parents:on,code:a%3C%3C16+1%3C%3C24

Pro tip: add http://esparser.qfox.nl/#runnow:on,no-single-parents:on,code:%s to your custom search engines / location bar shortcuts in your browser of choice.

@jed
Copy link
Author

jed commented Jun 3, 2011

heh, i think you and i have different meanings for the word 'immediately'... the above helps a lot, but looking at the mdc chart is usually a lot faster for me.

@atesgoral
Copy link

@jed: Instead of forking, I'll just add the annotation here:

  return "#" +   // return a number sign, plus
  (
    // Combine the octets into a 32-bit integer as:
    // [1][a][b][c]
    // Operator precedence is (+) > (<<) > (|)
    (
      256  // [1][0]
      + a  // [1][a] 
      << 8 // [1][a][0]
      | b  // [1][a][b]
    )
    << 8   // [1][a][b][0]
    | c    // [1][a][b][c]
  )

@jed
Copy link
Author

jed commented Jun 3, 2011

thanks, @atesgoral. you're on a total roll!

@GarrettS
Copy link

GarrettS commented Sep 3, 2011

Haven't perf tested this, but the bitwise ops should be fast. Great stuff here.

@GarrettS
Copy link

GarrettS commented Sep 3, 2011

None of these rgbToHex functions should ever be a bottleneck. But I wanted to test these to see anyway. Just to see.

http://jsperf.com/rgbtohex/5

The original tests use inline code, but those I've added use functions. That's a lousy comparison for a test case. Should all of them use functions, or does it make sense to use inline code for JsPerf?

@mathiasbynens
Copy link

@GarrettS

Should all of them use functions, or does it make sense to use inline code for JsPerf?

IMHO it would make more sense to declare the functions in the preparation/setup code section on jsPerf, and then have the actual tests themselves only consist of a single function call. That seems like the fairest comparison. Something like this: http://jsperf.com/rgbtohex/6

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment