Subtraction/difference between bytes in Java - java

I'm trying to subtract one byte from another while making sure no overflow happens, but get unexpected results.
My case is that I have an byte black and white image, of which I want to subtract the background. Hence I need to work with bytes and prevent overflows from happening. I have some difficulty presumably with the signedness of the bytes when subtracting the background image from the other image. Data2 is the background array, and data1 is the other image.
In the following code, I expect data2 array to be subtracted from data1 array. However I get low values when I am sure there should be high ones.
for (int i = 0; i < data1.length; i++) {
if (data1[i] > data2[i]) {
dest[i] = (byte) (data1[i] - data2[i]);
} else {
dest[i] = 0;
}
}
I figured I should make sure data2 byte isn't negative and being added to data1.
So I came to:
for (int i = 0; i < data1.length; i++) {
if (data1[i] > data2[i]) {
dest[i] = (byte) ((int)data1[i] & 0xff - (int)data2[i] & 0xff - 128);
} else {
dest[i] = 0;
}
}
However this also doesn't give the right results.
My thoughts on this currently are:
(byte) ((int)data1[i] & 0xff - (int)data2[i] & 0xff - 128);
(int) cast: make sure bytes are cast to integer.
&0xff: make value unsigned.
- subtraction smaller value from bigger value.
- 128: subtract 128 to make signed again.
(byte): cast back to byte.
I hope I'm doing something stupidly wrong here, or my problem resides somewhere else of which I can't figure out where.
Edit
I seem to have figured out a part of the issue:
data1[i] > data2[i] is handled wrong (in my case) when the bytes are signed. Instead:
if ((data1[i] & 0xff) > (data2[i] & 0xff)) {
seems to produce the right results, instead of the previous comparison.

The point here is that your bytes come from an API that uses 8 bits to encode the light of the pixel, so they range 0; 0xFF. However Java bytes are -128; 127, so any bit pattern after 0x7F will be interpreted as a negative number. For example the bits in 0xF0 are 128 if the byte is unsigned and -16 if interpreted as a signed byte:
System.out.println(0xFF > 0); // true
System.out.println((byte) 0xFF > 0); // false
So when comparing your unsigned bytes you want to promote pixels to int with Byte.toUnsignedInt(byteVal) (or ((int) byteVal) & 0xFF on Java 7).

Always remember Java bytes are signed. If data1[i] is 127, and data2[i] is -128, then data1[i] > data2[i], but data1[i] - data2[i] does not fit into a signed byte; that result is 255.
If you treat the bytes as unsigned, that's fine. That more-or-less means printing them out after using & 0xFF, and such. That will work just fine; it will give the right results if you treat them as unsigned correctly.

To ensure that you only substract non negative bytes from from bytes that are greater you should use :
for (int i = 0; i < data1.length; i++) {
if (data1[i] > data2[i] && data2[i]>=0 ) {
dest[i] = (byte) (data1[i] - data2[i]);
} else {
dest[i] = 0;
}
}
Your second code does not work because the & operator promotes the values to type int.
Consider the case where data1=127 (0x7F) and data2=-128 (0x80).
data1 & 0xff is type int and has value 127 (0x0000007F)
data2 & 0xff is type int and has value 128 (0x00000080)
data1[i] & 0xff - data2[i] & 0xff is type int and has value -1 (0xFFFFFFFF)
(byte)(data1[i] & 0xff - data2[i] & 0xff) is type byte and has value -1 (0xFF)
So you still have gotten an overflow

For some reason, comparing bytes is handled weirdly. If I convert the bytes to unsigned ints in the comparison, the comparison works correctly and my results are as I expected them.
I can then subtract the bytes as if they were unsigned as Louis Wasserman pointed out, which was new to me.
for (int i = 0; i < data1.length; i++) {
if ((data1[i] & 0xff) > (data2[i] & 0xff)) {
dest[i] = (byte)(data1[i] - data2[i]);
} else {
dest[i] = 0;
}
}

Related

How to convert an int to byte while keeping order

I am working with Local Binary Patterns (LBP) which produce numbers in the range 0-255.
That means that they can fit in a byte (256 different values may be included into a byte). So that explains why many (if not all) implementation in java I have found uses byte[] to store these values.
The problem is that since I am interested in the rank of these values when converted to byte (from int for example) they do not keep the previous rank they had (as int for example) since byte are signed (as all but chars in java I think) and so the greater 128 values (127 and after) of the range 0-255 becomes negative numbers. Furthermore I think they are inverted in order (the negative ones).
Some examples to be more specific:
(int) 0 = (byte) 0
(int) 20 = (byte) 20
(int) 40 = (byte) 40
(int) 60 = (byte) 60
(int) 80 = (byte) 80
(int) 100 = (byte) 100
(int) 120 = (byte) 120
(int) 140 = (byte) -116
(int) 160 = (byte) -96
(int) 180 = (byte) -76
(int) 200 = (byte) -56
(int) 220 = (byte) -36
(int) 240 = (byte) -16
My question is whether there is a specific way to maintain the order of int values when converted to byte (meaning 240 > 60 should hold true in byte also -16 < 60!) while keeping memory needs minimum (meaning use only 8bits if that many are required). I know I could consider comparing the byte in a more complex way (for example every negative > positive and if both bytes are negative inverse the order) but I think it's not that satisfactory.
Is there any other way to convert to byte besides (byte) i?
You could subtract 128 from the value:
byte x = (byte) (value - 128);
That would be order-preserving, and reversible later by simply adding 128 again. Be careful to make sure you do add 128 later on though... It's as simple as:
int value = x + 128;
So for example, if you wanted to convert between an int[] and byte[] in a reversible way:
public byte[] toByteArray(int[] values) {
byte[] ret = new byte[values.length];
for (int i = 0; i < values.length; i++) {
ret[i] = (byte) (values[i] - 128);
}
return ret;
}
public int[] toIntArray(int[] values) {
int[] ret = new byte[values.length];
for (int i = 0; i < values.length; i++) {
ret[i] = values[i] + 128;
}
return ret;
}
If you wanted to keep the original values though, the byte comparison wouldn't need to be particularly complex:
int unsigned1 = byte1 & 0xff;
int unsigned2 = byte2 & 0xff;
// Now just compare unsigned1 and unsigned2...

Confused About Bit Shifting (Counting Bits in Byte)

I'm trying to count the number of set bits in a byte but I appear to be running into some issues I can't find answers to.
My code currently looks like
public static int numBits(byte input){
int count = 0;
while (input != 0){
if ((input & 1)==1){
count++;
}
input >>= 1;
}
return count;
}
It appeared to work fine until I tried x = -1.
This ended up creating an infinite loop as value 1 bits were being inserted. So I stumbled upon
Java: right shift on negative number
which to my interpretation meant I should use input >>>= 1; but this still led to an infinite loop.
So I tried to figure out what was going on by trying
byte x = -1;
System.out.println(x >>> 1);
System.out.println(x >> 1);
which lead to
2147483647
-1
leaving me more confused. Where did the number 2147483647 come from and where might I be making a logic mistake?
The >>> operator means shift to the right, but do not sign-extend.
Your trial is pretty close, but you're not actually modifying x, so you can do:
int x = -1;
x = x >>> 1;
System.out.println(x);
x = x >> 1; // highest bit = 0 now
System.out.println(x);
Which will yield
2147483647
1073741823
Notice that I'm using int rather than byte here, since the result of bit shifts coerces the input to at least be integer sized.
Interestingly, when you run:
byte input = -1;
input = (byte) (input >>> 1);
The result is still -1. This is because of the type coercion happening with this operator mentioned above. To prevent this from affecting you, you can mask the bits of input to make sure you only take the first 8:
byte input = -1;
input = (byte) ((input & 0xFF) >>> 1);
Putting this together, if you were to run:
byte input = -1;
input = (byte) ((input & 0xFF) >>> 1);
System.out.println(input);
input = (byte) ((input & 0xFF) >> 1);
System.out.println(input);
You get the expected results:
127
63
This is all being caused by the way signed integers are stored as binary values. The way the highest bit of the number determines the sign (sort of—zero makes things weird), and the sign was being preserved with the arithmetic shift. Your print statements are giving weird results because the results are being promoted to int values instead of bytes.
If you want a really simple fix for this, you can just use an int to store your value, but make sure to mask off everything but the lowest-order byte:
public static int numBits(byte inByte){
int count = 0;
int input = inByte & 0xFF;
while (input != 0){
if ((input & 1)==1){
count++;
}
input >>= 1;
}
return count;
}
Like I said in my comment above, you should really read about Two's complement representation of signed numbers in binary. If you understand how negative numbers are represented, and the difference between arithmetic/logical shifts, all of that will make perfect sense.
You might find how the JVM actually does it is interesting. Note: there is only 8 bits so you don't really need a loop.
public static int bitCount(int i) {
// HD, Figure 5-2
i = i - ((i >>> 1) & 0x55555555);
i = (i & 0x33333333) + ((i >>> 2) & 0x33333333);
i = (i + (i >>> 4)) & 0x0f0f0f0f;
i = i + (i >>> 8);
i = i + (i >>> 16);
return i & 0x3f;
}
NOTE: On the x86/x64, the JVM replaces this with an intrinsic. i.e. it uses a single machine code instruction. If you copy this method and compare it will calling the original it is 3x slower as the JVM only replaces a hard coded list of methods, so it will replace Integer.bitCOunt, but not a copy.
In short, use the built in method instead of re-inventing it.

How to find most significant bit (MSB)

I want to know which value the first bit of a byte has.
For example:
I have byte m = (byte) 0x8C;
How could I know if the first bit is an 1 or a 0 ?
Can anyone help me out ?
It depends what you mean by "first bit". If you mean "most significant bit" you can use:
// 0 or 1
int msb = (m & 0xff) >> 7;
Or if you don't mind the values being 0x80 or 0, just use:
// 0 or 0x80
int msb = m & 0x80;
Or in fact, as a boolean:
// Uses the fact that byte is signed using 2s complement
// True or false
boolean msb = m < 0;
If you mean the least significant bit, you can just use:
// 0 or 1
int lsb = m & 1;
If the first bit is the lowest bit (ie bit 0), then
if((m & 1) >0) ...
should do it.
In general,
if ((m & (1<<N)) > 0) ...
will give you whether or not bit N is set.
If, however, you meant the highest bit (bit 7), then use N=7.
Assuming you mean leftmost bit, bitwise and it with 0x80 and check if it is zero nor not:
public boolean isFirstBitSet(byte b) {
System.out.println((b & (byte)0x80));
return (b & (byte)0x80) < 0;
}
If you mean lowest order bit you will need to and with 0x01 and check a different condition:
public boolean isFirstBitSet(byte b) {
System.out.println((b & (byte)0x01));
return (b & (byte)0x80) > 0;
}
Use the bitwise and operator.
public class BitExample {
public static void main(String args[]) throws Exception {
byte m = (byte)0x8C;
System.out.println("The first bit is " + (m & (byte)0x01));
m = (byte)0xFF;
System.out.println("The first bit is " + (m & (byte)0x01));
}
}
// output is...
The first bit is 0
The first bit is 1
Its a bit of a hack but you can use
if(x >> -1 != 0) // top bit set.
This works for byte, short, int, long data types.
However for most types the simplest approach is to compare with 0
if (x < 0) // top bit set.
This works for byte, short, int, long, float, or double
(Ignoring negative zero and negative NaN, most people do ;)
For char type you need to know the number of bits. ;)
if (ch >>> 15 != 0) // top bit set.
This code gives you msb(most significant bit)/biggest number which is a
power of 2 and less than any given number.
class msb{
void main(){
int n=155;//let 110001010
int l=(Integer.toBinaryString(n)).length();//9
String w="0"+Integer.toBinaryString(i).substring(1);//010001010
i=Integer.parseInt(w,2);
System.out.println(n^i);//110001010^010001010=100000000
}
}

How do I split an integer into 2 byte binary?

Given
private int width = 400;
private byte [] data = new byte [2];
I want to split the integer "width" into two bytes and load data[0] with the high byte and data[1] with the low byte.
That is binary value of 400 = 1 1001 0000
so data[0] should contain 0000 0001
and data[1] should contain 1001 0000
Using simple bitwise operations:
data[0] = (byte) (width & 0xFF);
data[1] = (byte) ((width >> 8) & 0xFF);
How it works:
& 0xFF masks all but the lowest eight bits.
>> 8 discards the lowest 8 bits by moving all bits 8 places to the right.
The cast to byte is necessary because these bitwise operations work on an int and return an int, which is a bigger data type than byte. The case is safe, since all non-zero bits will fit in the byte. For more information, see Conversions and Promotions.
Edit: Taylor L correctly remarks that though >> works in this case, it may yield incorrect results if you generalize this code to four bytes (since in Java an int is 32 bits). In that case, it's better to use >>> instead of >>. For more information, see the Java tutorial on Bitwise and Bit Shift Operators.
For converting two bytes the cleanest solution is
data[0] = (byte) width;
data[1] = (byte) (width >>> 8);
For converting an integer to four bytes the code would be
data[0] = (byte) width;
data[1] = (byte) (width >>> 8);
data[2] = (byte) (width >>> 16);
data[3] = (byte) (width >>> 24);
It doesn't matter whether >> or >>> is used for shifting, any one bits created by sign extension will not end up in the resulting bytes.
See also this answer.
This should do what you want for a 4 byte int. Note, it stores the low byte at offset 0. I'll leave it as an exercise to the reader to order them as needed.
public static byte[] intToBytes(int x) {
byte[] bytes = new byte[4];
for (int i = 0; x != 0; i++, x >>>= 8) {
bytes[i] = (byte) (x & 0xFF);
}
return bytes;
}
Integer is 32 bits (=4 bytes) in java, you know?
width & 0xff will give you the first byte,
width & 0xff00 >> 8 will give you the second, etc.
To get the high byte, shift right by 8 bits then mask off the top bytes. Similarly, to get the low byte just mask off the top bytes.
data[0] = (width >> 8) & 0xff;
data[1] = width & 0xff;
int width = 400;
byte [] data = new byte [2];
data[0] = (byte) ((width & 0xFF00) >> 8);
data[1] = (byte) (width & 0xFF);
for(int b = 0; b < 2; b++) {
System.out.println("printing byte " + b);
for(int i = 7; i >= 0; i--) {
System.out.println(data[b] & 1);
data[b] = (byte) (data[b] >> 1);
}
}
I suggest you have a look at the source for HeapByteBuffer. It has the conversion code for all primitive data types. (In fact you could just use a ByteBuffer ;)

How do I convert a byte array to a long in Java?

I am reading 8 bytes of data in from a hardware device. I need to convert them into a numeric value. I think I want to convert them to a long as that should fit 8 bytes. I am not very familiar with Java and low level data type operations. I seem to have two problems (apart from the fact there is almost no documentation for the hardware in question), The bytes are expecting to be unsigned, so I can't do a straight integer conversion. I am not sure what endianness they are.
Any advice would be appreciated.
Ended up with this (taken from some source code I probably should have read a week ago):
public static final long toLong (byte[] byteArray, int offset, int len)
{
long val = 0;
len = Math.min(len, 8);
for (int i = (len - 1); i >= 0; i--)
{
val <<= 8;
val |= (byteArray [offset + i] & 0x00FF);
}
return val;
}
Shifting bytes according to the endianness of the data is fairly straightforward. There is a small trick with the long datatype, however, because a binary operation on integral types of int or smaller promotes the operands to int. For left shifts larger than 31 bits, this will result in zero, since all of the bits have been shifted out of the int range.
So, force promotion to long by including a long operand in the calculation. Below, I do this by masking each byte with the value 0xFFL, which is a long, forcing the result to be a long.
byte[] buf = new byte[8];
/* Fill buf somehow... */
long l = ((buf[0] & 0xFFL) << 56) |
((buf[1] & 0xFFL) << 48) |
((buf[2] & 0xFFL) << 40) |
((buf[3] & 0xFFL) << 32) |
((buf[4] & 0xFFL) << 24) |
((buf[5] & 0xFFL) << 16) |
((buf[6] & 0xFFL) << 8) |
((buf[7] & 0xFFL) << 0) ;
Byte#longValue() should do it
And if not (thanks for the source example) you can use java.nio.ByteBuffer such as in
public static long toLong(byte[] b) {
ByteBuffer bb = ByteBuffer.allocate(b.length);
bb.put(b);
return bb.getLong();
}
The initial order is BIG_ENDIAN you can reed more here
I believe that you could benefit from using java.nio. This is how you can store 8 bytes in a long:
// Byte Array TO Long
public static long batol(byte[] buff) {
return batol(buff, false);
}
public static long batol(byte[] buff, boolean littleEndian) {
assert(buff.length == 8);
ByteBuffer bb = ByteBuffer.wrap(buff);
if (littleEndian) bb.order(ByteOrder.LITTLE_ENDIAN);
return bb.getLong();
}
Of course, the resulting longs will have signed representation, but they will have identical binary values to the source data. For a 64 bit+ unsigned representation and arithmatic, you'll need to use BigInteger. Here's how to convert from "unsigned" data stored in a long to a correct BigInteger:
// "Unsigned" Long TO Big Integer
public static BigInteger ultobi(long ul) {
byte[] buff = new byte[8];
ByteBuffer.wrap(buff).asLongBuffer().put(ul);
return new BigInteger(+1, buff);
}
ByteBuffer buffer = ByteBuffer.wrap(bytes);
buffer.getLong();
For the endianness, test with some numbers you know, and then you will be using a byte shifting to move them into the long.
You may find this to be a starting point.
http://www.janeg.ca/scjp/oper/shift.html
The difficulty is that depending on the endianess will change how you do it, but you will shift by 24, 16, 8 then add the last one, basically, if doing 32 bits, but you are going longer, so just do extra shifting.
Take a look at BigInteger(byte[]). It is almost what you want except that it is a signed one. So you may add one more byte to it before you pass it on to BigInteger.
Another thing is that you should be aware of what endian your bytes are.
Hope this helps.
If you're reading from an InputStream, you may also want to look at DataInputStream.readLong(). Java 1.5 introduced Long.reverseBytes(long) which may help you with endianness.
You can use:
byte bVal = 127;
Long longVar = Long.valueOf(bVal);
public static long convertToLong(byte[] array)
{
ByteBuffer buffer = ByteBuffer.wrap(array);
return buffer.getLong();
}
The next code parses bytes as a signed number of arbitrary length ≤ 8.
static long bytesToSignedNumber(boolean reverseOrder, byte... bytes) {
if (bytes.length > 8) bytes = Arrays.copyOfRange(bytes, 0, 8); //delete this line to ignore the higher excess bytes instead of the lower ones
int l = bytes.length;
long number = 0;
for (int i = 0; i < l; i++) {
long current;
if (l==3 || l==5 || l==6 || l==7 //delete this line if you want to operate with 3,5,6,7-byte signed numbers (unlikely)
|| !reverseOrder && (i > 0)
|| reverseOrder && (i < l-1)) {
current = ((long) bytes[i]) & 0x0000_0000_0000_00ff; //unsigned
} else {
current = (long) bytes[i]; //signed
}
if (reverseOrder) number += current << (8 * i);
else number = (number << 8) + current;
}
return number;
}
It parses an byte array as a number, of minimum existing type, converted to long. A few examples:
bytesToSignedNumber(false, 0x01, 0x04) returns 260 (2 bytes as short)
bytesToSignedNumber(false, 0xF1, 0x04) returns -3836 (2 bytes as short)
bytesToSignedNumber(false, 0x01, 0x01, 0x04) returns 65796 (3 bytes as int)
bytesToSignedNumber(false, 0xF1, 0x01, 0x04) returns 15794436 (3 bytes as int)
bytesToSignedNumber(false, 0xF1, 0x01, 0x01, 0x04) returns -251592444 (4 bytes as int)
bytesToSignedNumber(false, 0x0F, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x04) returns 1081146489369067777 (8 of 9 bytes as long)
Another Alternative
From Google
com.google.common.primitives
Longs.fromByteArray(bytes);

Categories

Resources