This question already has answers here:
What does << mean in Java?
(8 answers)
Closed 8 years ago.
i was working through the following oracle java class and came across this line of code:
public synchronized int getRGB() {
return ((red << 16) | (green << 8) | blue);
}
I am lost as to what "<<" means, I also don't know what the return statement is suppose to return
It is a bit shift operation. Read more here. It will pack these 3 numbers into one integer.
24 bit colors are often represented as RRRRRRRRGGGGGGGGBBBBBBBB, with 8 bit values for each color. Your code takes the red value, shifts it 16 bits, shifts the green value 8 bits, and keeps the blue value unshifted, then performs a logical OR, which in this case is the same as adding the values. Think of it this way:
Your byte values for each color:
Red = 00011010
Green = 10101010
Blue = 11111111
The shifted values become:
Red << 16 =
00011010 00000000 00000000
Green << 8 =
00000000 10101010 00000000
Blue =
00000000 00000000 11111111
The logical OR combines them into:
00011010 10101010 11111111
which is your 24 bit RGB value, which is returned.
public synchronized int getRGB() {
return ((red << 16) | (green << 8) | blue);
}
I am lost as to what "<<" means, I also don't know what the return statement is suppose to return?
First off, the '<<' is called a bit shift operator. There is a fantastic write-up about them located here.
As to your second question, look at the signature of the method... it's going to return an int. BUT, in this case, it is going to return and int containing the value of blue and the bit shifted values of red and green.
Hope this helps!
x << y means "shift binary representation of x to left y places"
For instance
System.out.println(4 << 2);
will print 16.
4 is 100 in binary. If you shift 100 to the left 2 places, you get 10000 which is 16 in decimal.
Related
I read some Java code and came across the | operator.
Can anyone what the operator is doing in this context?
for (int i=0; i<8; i++) {
x[i] = hexBytes[i*4] << 24
| hexBytes[i*4+1] << 16
| hexBytes[i*4+2] << 8
| hexBytes[i*4+3];
}
The bitwise OR (and AND) can be used for bit handling. AND allows you to extract a set of bits: int lowest8bits = 0xFFFFF & 0xFF;.
With OR you can insert bits. In the code above, 4 bytes are inserted to the same int by shifting them to the right position and ORing them.
10010010 byte
10010010 00000000 << 8
00000000 00000000 00000000 00010110 The int we're building
00000000 00000000 10010010 00010110 End result in int after OR
Operators used are:
"<< (left shift)" : Binary Left Shift Operator. The left operands
value is moved left by the number of bits specified by the right
operand.
">> (right shift)" : Binary Right Shift Operator. The left operands value is moved right by the number of bits specified by the
right operand.
"| (bitwise or)" : Binary OR Operator copies a bit if it exists in either operand.
In your code:
hexBytes[i*4] << 24
binary value of hexBytes[i*4] is left shifted by 24 bit. same with others and the result is OR by the bitwise | operator.
It's the bitwise or. See this article for more information: https://www.baeldung.com/java-bitwise-operators
3.1 refers to this specific operator. It also explains the left shift << operator
I am trying to create a mask to view specific bits on a long in Java. I tried the following:
long mask = ~ (0xffffffff << 32);
If I print this on the console it will return 0 but I am expecting 4294967295 since my result should look like 0x00000000FFFFFFFFL and 2^32 - 1 equals 4294967295. When I shift a long mask it works but I do not understand why.
long mask = ~ (0xFFFFFFFFFFFFFFFFL << 32);
Can anyone explain me this behavior?
Java assumes that if you're performing arithmetic operations on ints, then you want to get an int back, not a long. (The fact that you assign the output to a long after the calculation is done does not affect the calculation itself.)
Left-shifting an int (which is 32 bits) by 32 places does nothing. When you left-shift an int, only the five lowest-order bits of the right-hand operand are used, giving a number in the range 0 to 31.
http://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.19
That's why (0xffffffff<<32)==0xffffffff, and ~(0xffffffff<<32)==0
When shifting a long (which is 64 bits), the six lowest-order bits are used, giving a number in the range 0 to 63.
If you use 0xffffffffL, then Java will know to produce another long. So you can shift by 32 places without going off the left end of the number.
Left shift is modulus†the size of the data type, e.g. a shift of an int of 32 bits has no effect.
(0xffffffff << 32) ==
(0xffffffff << (32 % Integer.SIZE)) ==
(0xffffffff << (32 % 32)) ==
(0xffffffff << 0) ==
0xffffffff
And ~ of 0xffffffff is 0x00000000, i.e. 0 which is what you see.
Then with 64 bit, the full 32 bit shift is applied as it is less than 64:
(0xffffffffL << 32) ==
(0xffffffffL << (32 % Long.SIZE) ==
(0xffffffffL << (32 % 64) ==
(0xffffffffL << 32) ==
0xffffffff00000000L
†Strictly speaking it's taking the last 5 bits for ints and last 6 for longs, which makes a difference over modulus for negative left shifts.
I have a decimal (not hexadecimal) color code and, using Java, I need to convert it to the three RGB colors.
So for example, 16777215 (pure white) needs to get converted to Red: 255 Green: 255 Blue: 255.
65280 (pure green) needs to get converted to Red: 0 Green 255: Blue: 0 Here is a converter for more examples.
Just doing some small calculations and playing with the calculator on the page linked above, I have determined:
Red equals 65536 (256^2)
(255x65536 = 16711680, aka pure red)
Green equals 256 (256^1)
(255x256 = 65280, aka pure green)
Blue equals 1 (256^0)
(255x1 = 255, aka pure blue)
I can tell it obviously has something to do with bytes, but I am missing that last little bit. I am not the best with the whole concept of bits/bytes/etc and how it interacts with Java, so it is likely fairly simple.
So, anyone know the best way of going about this? What would be the best way to convert a single numerical decimal color into the three separate RGB values using java?
You where telling right: RGB values are encoded as bytes in a int. R is byte 2, G is byte 1 and B is byte 0, summing up to a 24bit color depth. Depending on the endianess, this could be a possible representation.
00000000 00000000 00000000 00000000 <-- 32bit int
^ ^ ^
| | |
+--red here | +--green here
8bit | 8bit
|
+--blue here
8bit
You can extract RGB values with some bit shift and masking:
int red = (color >> 16) & 0xff;
int green = (color >> 8) & 0xff;
int blue = color & 0xff;
You could do
Color color = new Color(16777215);
int red = color.getRed();
int green = color.getGreen();
int blue = color.getBlue();
You can get the channels out by simple bitwise operations.
int r = (color >> 16) & 0xff;
int g = (color >> 8) & 0xff;
int b = color & 0xff;
From there, it should be easy to do whatever you want with the color information.
Decimal, hexadecimal: does not matter. Your computer uses binary representations internally.
You may have noticed that 0xFF00 == 65280.
Decimal and Hexadecimal are user representations.
I know I am a bit late, but...
int r = color / 65536;
int g = (color - r * 65536) / 256;
int b = color - r * 65536 - g * 256;
This is really doing the exact same thing as the binary shifts even though it doesn't use bitwise operators. This also only works when using valid RGB values (meaning each value is an integer between 0 and 255). For efficiency, however, I would use the binary shifts from the above answers.
I found this line of code: this.red = (float)(par4 >> 16 & 255) / 255.0F; where red has been declared as a float.
I am trying to understand what it does, especially because the full code is:
this.red = (float)(par4 >> 16 & 255) / 255.0F;
this.blue = (float)(par4 >> 8 & 255) / 255.0F;
this.green = (float)(par4 & 255) / 255.0F;
this.alpha = (float)(par4 >> 24 & 255) / 255.0F;
GL11.glColor4f(this.red, this.blue, this.green, this.alpha);
so I'm guessing this somehow uses different locations of an int (par4) to color text. par4 is equal to 553648127 in this case.
What do those four lines mean, notably the >> 16 & 25?
RGB with alpha channel (usually known as RGBA or aRGB) are four bytes packed into one integer.
AAAAAAAARRRRRRRRBBBBBBBBGGGGGGGG // the original par4, each char represents one bit.
// where ARBG stands for alpha, red, blue and green bit.
The shift and and operator are used to retrieve each individual byte. For example, par4 >> 16 & 255 is first right-shifting the integer 16 bits such that the original 3rd byte is located at base, and the 255 is served as mask to extract only one byte.
And par4 >> 16 will right-shift the original byte 16 bits;
0000000000000000AAAAAAAARRRRRRRR
Finally, applying &255, which is 00000000000000000000000011111111 in bit-representation, will mask the last 8 bits:
0000000000000000AAAAAAAARRRRRRRR
& 00000000000000000000000011111111
= 000000000000000000000000RRRRRRRR
This gives you the red byte.
>> is the right-bit-shift operator. This is more easily seen in binary:
b1000 >> 3 = b0001
You see how it moved the bits right.
& is the bitwise AND operator. The result of x & y will be a value with only the bits in x and y that were both on being on.
b1 & b1 = b1
b1 & b0 = b0
b0 & b1 = b0
b11 & b01 = b01
So
this.red = (float)(par4 >> 16 & 255) / 255.0F;
...takes the value from par4 and shifts the bits right 16 bits to move the "red" value to the rightmost part. Then it masks off anything other than the rightmost byte of that. Then it divides the value (which must be in the range 0 to 255, inclusive) by 255 as a float, resulting in a floating point value between 0.0 and 1 telling us how "red" the color was.
And similarly for blue and green.
Then it uses the same mechanism to determine how strong the alpha channel (transparency) is.
Bitwise-anding with 255 (0b11111111) discards all bits from an integer except the eight least significant bits. If you right-shift first, you can access eight-bit groups from other areas of that integer.
par4 seems to define a color with RGB value and alpha as an integer with 4 bytes.
So the 4 bytes are singled out by shifting the bytes "lower" bytes to the right with the >> operator and masking out the "higher" bytes with the & 255.
Afterwards the byte value is normalized to a float value between 0.0 and 1.0 via the / 255.0f.
If the 4 bytes in our integer are like AARRGGBB, where AA, RR, GG, BB each denote a byte and you e.g. want to single out the red color, you first shift away the green and blue bytes with >> 16, which will leave you with an integer 0000AARR, then you mask out the alpha with the & 255, which will leave you with an integer 00000000RR, where RR is now 1 byte (2 half-bytes) with values between 0 and 255, which you finally transform to a float between 0.0 and 1.0 by division with the / 255.0f.
May be I am too tired.
Why dont't the following display the same value?
int x = 42405;
System.out.println(x << 8);
System.out.println((x &0x00ff) << 8);
The lower bits should be clear in both cases
EDIT: Okay, I'm leaving the bottom part for posterity...
If x is int, then it's pretty simple: x << 8 will have the same value as x & 0xff if and only if none of the "middle" 16 bits are set:
The top 8 bits of x will be rendered irrelevant by the left shift
The bottom 8 bits of x are preserved by the masking
If there are any of the "middle" 16 bits set, then x & 0xff will differ from x in a bit which is still preserved by the shift, therefore the results will be different.
I don't understand why you'd expect them to always give the same results...
I'm going to assume that the type of x is byte, and that it's actually negative.
There's no shift operation defined for byte, so first there's a transformation to int... and that's what can change depending on whether or not you've got the mask.
So let's take the case where x is -1. Then (int) x is also -1 - i.e. the bit pattern is all 1s. Shift that left by 8 bits and you end up with a bit pattern of 24 1s followed by 8 0s:
11111111111111111111111100000000 = -256
Now consider the second line of code - that's taking x & 0xff, which will only take the bottom 8 bits of the promoted value of x - i.e. 255. You shift that left by 8 bits and you end up with 16 0s, 8 1s, then 8 0s:
00000000000000001111111100000000 = 65280
Below, x is > 0xff , and in one case you mask away the upper 3 bytes, meaning you
you do (0x123 & 0x00ff) << 8 , which will be 0x23 << 8 And that is quite different from 0x123 << 8
int x = 0x123;
System.out.println(x << 8); //prints 74496
System.out.println((x &0x00ff) << 8); //prints 8960
And if x is a byte, it will get "promoted" to int before the shift, and if it's negative, it'll sign extend, and you get a whole lot of 1 bits set in the integer, which is masked away with &0xff in one case, and not masked away in the other
i.e.
byte x = (byte)0xAA; //x is negative
System.out.println(x << 8); //prints -22016
System.out.println((x &0x00ff) << 8); //prints 43520