How to load a long array with processing

cheese

Hi,

it is quite straight forward to load a integer (1 byte) using the function byte b[] = loadBytes("file");

However, I do not find any function to load a long (4 bytes) array.

Does anybody has experience with this?

Thx C.

GoToLoop

Given loadBytes() gets you a byte[], you may try to convert each 4 sequential byte indices as 1 int index into an int[] manually, relying on the left-shift << operator to position each byte within the new int, plus gluing them as 1 int w/ the bitwise OR | operator:

1. https://Processing.org/reference/leftshift.html
2. https://Processing.org/reference/bitwiseOR.html

GoToLoop

An easier option is to wrap() your byte[] to become a ByteBuffer:
http://docs.Oracle.com/javase/8/docs/api/java/nio/ByteBuffer.html#wrap-byte:A-

Then invoke asIntBuffer() upon that in order to have an IntBuffer view over it:
http://docs.Oracle.com/javase/8/docs/api/java/nio/ByteBuffer.html#asIntBuffer--

Now you can use IntBuffer & Buffer methods in order to access the byte[] as if it was an int[]: \m/

1. http://docs.oracle.com/javase/8/docs/api/java/nio/IntBuffer.html
2. http://docs.oracle.com/javase/8/docs/api/java/nio/Buffer.html

You may even magically get an int[] freely outta it via method array(), I believe: [-O<
http://docs.Oracle.com/javase/8/docs/api/java/nio/IntBuffer.html#array--

Although it's Arduino related, and asFloatBuffer() was used instead of asIntBuffer(), this very old forum post can help you out to have some idea on how to pull that out: :-\"
https://forum.Processing.org/two/discussion/12757/transmission-of-a-float-through-a-serial-link

Lord_of_the_Galaxy

@cheese int is 4 bytes in Java, long is 8 bytes. This is different from Arduino.

cheese

@GoToLoop. Thank you a lot - I will try your solutions @weekend.

@Lord_of_the_galaxy I know. But it is not important. I just wanna load 4 byte int and not 1 byte int data. (I just was looking for the loading function).

Lord_of_the_Galaxy

Ok.

cheese

Dear GoToLoop,

once more thank you. Finally, today I had time. I used your first link and it was straight forward:

byte b[] = loadBytes("/Users/cheese/Dropbox/_programming/imgs/2dseq3"); 

...
...
...

for (slice=0; slice < z_dim; ++slice) {
  print ("   slice :" + (slice+1));

  for (xdir=0; xdir < x_dim; ++xdir) {
    for (ydir=0; ydir < y_dim; ++ydir) {

      d = b[i] << 24;
      e = b[i+1] << 16;
      f = b[i+2] << 8;
      g = b[i+3] << 0;

      bilder[xdir][ydir][slice]=d+e+f+g;;
      i=i+4;
    }
  }
}

It was just used to open reconstruced 3D MRI data from a old MR System.

Best cheese

GoToLoop

https://forum.Processing.org/two/discussion/15473/readme-how-to-format-code-and-text

Glad you figured that out! <:-P
Just an extra tip: After the << operations, use operator | rather than + to glue them together.
Like this: bilder[xdir][ydir][slice] = d | e | f | g;. Should be slightly faster. $-)

cheese

Hi,

this is not working. The img looks noisy and processing crashes (need force quit).

best c.

Lord_of_the_Galaxy

@GoToLoop why would OR be faster than addition? I thought in integers both should take same amount of time. Or is this a thing of Java?

GoToLoop

All bitshifting operations are faster than arithmetic 1s for all CPUs.

Lord_of_the_Galaxy

@GoToLoop That's strange. Why would that be? AFAIK, the ADD and SUB assembly commands on most CPUs take a single cycle to execute. Multiplication and division take longer times, but addition? Or is it a problem caused due to the fact that there are much longer propagation delays in ADDITION/SUBTRACTION circuits than bit wise logical operations and hence the designers decided to add an extra clock for each ADD/SUBTRACT operation?

GoToLoop

AFAIK, the ADD and SUB assembly commands on most CPUs take a single cycle to execute.

AFAIK, it takes more than 1 cycle for ADD & SUB. And it takes even more for floating-point operands! 8-|

Lord_of_the_Galaxy

Floating point, I know. It takes a fairly large no of cycles for almost any floating point operations, and even for integer multiplication/division.

Nonetheless, we're using Java, so these few extra cycles won't affect us much, even in a for loop running a million times each frame. Atleast in C/C++ we may see some difference.

GoToLoop

... so these few extra cycles won't affect us much, ...

Java's generated bytecode is very close to assembly.
But it is targeted to a virtual machine rather than a real 1.
But once the bytecode is interpreted by the VM at runtime, it becomes actual machine code!
And the quality of that machine code depends on the quality of the bytecode as well! ~O)

Lord_of_the_Galaxy

Yes, but unless almost all your bytecode is just addition operators, replacing with OR won't help. And in processing, that is not valid.

(I should've said Processing, not Java, in my previous comment)

GoToLoop

From a strict technical point of view, using arithmetic operators like + for bitwise operations is wrong.

The expression d + e + f + g is pretty awkward after these bitshifting operations: :@)

d = b[i] << 24;
e = b[i+1] << 16;
f = b[i+2] << 8;
g = b[i+3];

The most natural solution is indeed d | e | f | g. Which is also the most performant as well! \m/

GoToLoop

And in Processing, that is not valid.

Both << and | bitwise operators are "official" entries in Processing's web reference: :-\"

1. https://Processing.org/reference/leftshift.html
2. https://Processing.org/reference/bitwiseOR.html

Lord_of_the_Galaxy

Yes, the more natural solution is bit wise.

You got me wrong there, on the second point. I meant that generally, in a Processing sketch, the final code will be so complex that the difference between using arithmetic operators and bit wise operators is negligible.