3

The PHP imagecolorat() function can be used to get the RGB values of an image pixel, as demonstrated in the documentation:

$im = imagecreatefrompng("php.png");
$rgb = imagecolorat($im, 10, 15);
$r = ($rgb >> 16) & 0xFF;
$g = ($rgb >> 8) & 0xFF;
$b = $rgb & 0xFF;

I don't understand the last three lines at all; I know that they return the correct values, but I cannot figure out how the >> and & operators work together to do so. Could someone please explain?

For reference, when $rgb = 9750526, the RGB values turn out to be(148,199,254).

Thanks for any responses.

hakre
  • 193,403
  • 52
  • 435
  • 836
LonelyWebCrawler
  • 2,866
  • 4
  • 37
  • 57
  • 1
    check that out: [php bitwise operators reference](http://php.net/manual/en/language.operators.bitwise.php). But this requires explanation, I agree. – madfriend Jul 19 '12 at 22:39

5 Answers5

11

& and >> are two different bitwise operators (Bitwise operators in PHP). They work with the bit representation of the values, which gives us a few useful (and fast!) possibilities.

>> is right shift. If you right shift a value, you're moving all the bits to the right in the representation. If you have "11100" and right shift it by two places, you're left with "111" (the bits shifted off on the right end disappears). The number on the right side of >> indicates the number of bits to shift.

& is bitwise and. If you have two values represented as 111000 and 101011, and decide to bitwise and them, you'll end up with 101000 (the bits where the same bits in both values are set will be 1, otherwise 0).

We now have what we need to make sense of the code above. $rgb contains an integer value (the value is not interesting, but the bit pattern is), which represents 24 bits (32 bits for RGBA, but we'll ignore that here). The value consists of 8 bits for red, 8 bits for green and 8 bits for blue. We're however not interested in what number those 24 bits represent together, but what the separate R, G and B values are.

Our value represent the following bits for the colors:

rrrrrrrr gggggggg bbbbbbbb 

If we shift this bitmask with >> 16, we'll get:

                  rrrrrrrr

This is what >> 16 does, and leaves us with just the bits representing the red color. As we've now moved the bits all the way down, the value represents a number in [0, 255]. We then add & 255 (which here is written as 0xFF in hexadecimal notation) to remove any stray bits above the 8 we're interested in. We'll get to how that happens now, when we look at how we get the G value:

Our value still bravely represents the different colors:

rrrrrrrr gggggggg bbbbbbbb 

If we shift this bitmask 8 places with >> 8, we'll get:

         rrrrrrrr gggggggg

But wait! This is not just the bits that represents g, but also the bits that represent r! This is not the value we're after (as we just want g's). We were lucky in the previous example since we didn't have any bits set above r, but this time we've really got our work cut out for us. But we know about &, and it's time to see it actually to it's stuff.

We now have:

         rrrrrrrr gggggggg

And then we apply & 255 (0xFF in your code), which is representing in a bit value as:

         00000000 11111111

Since & only keeps the bits which are set in both operands, we'll end up with just the g values:

                  gggggggg

The bits that represented red in the shifted value are now 0, and we're left with only the bits representing the green of the original color. As they've been shifter into the same 8 bits that represent [0, 255], we've got our value yet again.

The last value is easier, as it's already located where we want it: in the bits representing [0, 255]. We can just do the & operation here, and get out on the other side:

rrrrrrrr gggggggg bbbbbbbb & 
00000000 00000000 11111111

Which ends up with:

                  bbbbbbbb

And we've got our blue value as well.

Hope that explains it!

MatsLindh
  • 49,529
  • 4
  • 53
  • 84
  • So the first `& 0xFF` is unnecessary? – Isius Mar 30 '15 at 16:31
  • 1
    @Isius Depends (and that's why you usually want to include it). If the PNG has 32-bit color values, the first byte will be the alpha channel - and if you don't do `& 0xFF`, you'll end up with two bytes intead of just the single one. Extend the examples with an `aaaaaaaaa` section of bits ahead of `rrrrrrrr`. – MatsLindh Apr 08 '15 at 08:25
1

I'm guessing that the first occurrence, >>16, is shifting all the bits to the right until only red remains, then cutting off the start of the number with &0xFF. Although I can't tell the bit depth of red in that example (I would expect a multiple of 3 bytes for the color), it's sort of like this:

rrggbb = 125438 // input
>> 16 // shift right (might be 8 for this example)
0000rr = 000012 // result
& 0xFF // cut beginning
rr = 12

And similar for the other colors.

whiterook6
  • 3,270
  • 3
  • 34
  • 77
  • The result of the shifting operation is actually `0000rr` - zeros are shifted in on the left side. – Niko Jul 19 '12 at 22:43
1

>> means bit-wise right-shift, so the bits are moved n (16 and 8 respectively) positions to the right:

R = 1 Byte = 8 Bits

RRGGBB >> 16  =  0000RR
RRGGBB >> 8   =  00RRGG

The bit-wise AND operation & is used to remove remaining stuff that we don't want in the result, by using a mask that is zero everywhere except in the part that should stay:

00RRGG & 0000FF = 0000GG 
Niko
  • 26,516
  • 9
  • 93
  • 110
1

Let's try:

$rgb = 9750526;
var_dump(sprintf('%032b', $rgb));

$rgb = 00000000100101001100011111111110 //integer is 32 or 64 bit - b part is last 8bits

you need only 3rd, 2nd and 1st byte, so >> (shift) them and you get binary

$rgb >> 16 =  string(32) "00000000000000000000000010010100" //r part is last 8 bits
$rgb >> 8 =  string(32) "00000000000000001001010011000111" //g part is last 8 bits

& 0xFF is and operation with 11111111 so as a result you get

r = 10010100
g = 11000111
b = 11111110

and I hope those are (148,199,254) ;)

mrok
  • 2,680
  • 3
  • 27
  • 46
0

imageColorAt() returns a 24-bit number containing red, green and blue values. Red value is multiplied by 2^16, green by 2^8, and blue is left "as is".

In hexadecimal, your value is 0x94C7FE; by shifting it right 16 bits, you lose the last four nibbles and are left with 0x94. The "& 0xFF" takes the last 8 bits (and therefore it's superfluous).

Usually this shift'n'cut is done like this:

$value = imageColorAt(...)   // Gets 94C7FE
$blue  = $value & 0xFF;       // Takes the last "FE" (254 in decimal)
$value >>= 8;                 // Shifts right, 94C7 remains
$green = $value & 0xFF;       // Takes "C7"
$value >>= 8;                 // Shifts right, 94 remains
$red   = $value;              // Takes "94" hex, which is 148 dec.
LSerni
  • 55,617
  • 10
  • 65
  • 107